Rapport

                        

 

 

Förstudie – Gränssnitt för SÖ-system i lokaler

 

Åke Blomsterberg och reinhold larsson

 

 

 

 

2001-10-22

J&W uppdrag nr.

 

 

 

 

 

 

 

Syfte.................................................................................................................................... 1

Bakgrund.......................................................................................................................... 1

Kartläggning av sö-system.................................................................................... 2

Problem med gränssnitt i moderna sö-system............................................. 7

förbättringsmöjligheter och KONSEKVENSER............................................... 8

slutsatser...................................................................................................................... 10

Syfte

Att först identifiera dagsläget dvs. vad de olika leverantörerna på marknaden kan erbjuda idag. Ett antal SÖ-system kartläggs översiktigt med avseende på datamiljö (Windows eller annan miljö), kommunikation (via telenätet, Internet, bärbar PC etc.), användargränssnitt (översiktbilder, detaljbilder, momentanvärden etc.), programvaror, rapportfunktioner, larmfunktioner, styrmöjligheter.

Därefter bestäms vilka funktioner t.ex. statistik, felsökning, simuleringar, som går att utveckla och vad får det för konsekvenser. Ett antal leverantörer av SÖ-system intervjuas.

Bakgrund

Behovet av för samordnad hantering av datoriserade styr- och övervakningssystem för fastigheter har vuxit fram under 90-talet. Detta tack vare en brist på standardisering inom branschen och en protektionistisk inställning hos framförallt de större leverantörerna av styrsystem när det gäller att låta andra få tillgång till företagsunika kommunikationsprotokoll mm. Ofta är systemen slutna och tekniskt komplicerade. Ett stort behov av att göra systemen mer användarvänliga finns. De mindre styrentreprenörerna, som sett en möjlighet att komma in på marknaden, har drivit på utvecklingen av öppna system. Sedan mitten av 90-talet finns öppna system d v s programvaror som via ett grafiskt användarsnitt och drivrutiner kan kommunicera med tekniska produkter, DUC:ar, oavsett fabrikatet på produkten.

Sedan länge har det för industrin funnits programvaror som via ett grafisk användarsnitt och drivrutiner kan kommunicera med fler i en process förekommande datorstyrda enheter av olika fabrikat. Exempel på processer som styrs och övervakas på detta sätt finns bl.a. inom livsmedelsindustrin och läkemedelsindustrin. Utvecklingen av SÖ-system för industrin ligger ofta före utvecklingen av SÖ-system för fastigheter.

Varje leverantör av SÖ-system för fastigheter har för sina egna DUC:ar individuella protokoll och programvaror. Detta innebär att flödesscheman och driftbilder kan se olika ut mellan olika leverantörer, och att principer för inställningar av olika värden kan skilja sig åt. Grundprogramvaran och drivrutinerna i ett öppet system formar om informationen så att den kan presenteras på samma sätt oavsett fabrikat på DUC:arna. Samma teknik för inställning av värden används.

Grundprogramvaran i öppna system är ofta ett grafiskt användarsnitt, t.ex. Windows, som i sin tur är knuten till en objektdatabas och till de speciella drivrutinerna. Vanligt förekommande leverantörer är FIX, InTouch Citet och CdC-Engin.

Microsofts program Excel och Access, knutna till ovannämnda programvaror, används ofta för speciella analyser eller för lagring av information. Analyser kan vara förbrukningsstatistik, kostnadsuppföljning för media och energiprofiler för olika system och delsystem. Kompletterande analysprogram tillverkas ofta av separata företag, ofta leverantörer av styr- och övervakningsutrustning.

Öppna systemlösningar baseras på dagens teknik och utgår ifrån befintliga installationer, befintlig styr- och övervakningsutrustning. Nya systemkoncept arbetar med LonWorks/EIB-teknologi och kräver utbyte av det mesta av installationerna inklusive ledningar. Den nya teknologin bygger på den s.k. installationsbusstekniken.

I öppna systemlösningar kan man vanligen:

q       Rita och presentera driftbilder

q       Avläsa och ändra bör-värden på temperaturer, hastighet, tryck

q       Ställa in start- och stopptider för belysning, värme, ventilation, med hänsyn till verksamheten

q       Ta emot och skriva ut larm

q       Avläsa förbrukningsuppgifter, upprätta förbrukningsprofiler för olika objekt med hjälp av lämpligt presentationsprogram.

Kartläggning av sö-system

Följande leverantörer av SÖ-system har kartlagts översiktligt dvs. nedanstående informationen gör inte anspråk på att vara fullständig:

q       INU-Control (Honeywell)

q       Exomatic

q       TAC

q       ABB Automation Technology Products (framförallt leverantör av SÖ-system till industrin)

q       Landis & Staefa (Siemens Building Technologies)

q       Kabona

 

Leverantör	INU-Control, INU-vision 2.3
Allmän beskrivning	Öppet system. PC-baserat datorsystem för central styrning, övervakning och uppföljning av framförallt de VVS-tekniska installationerna
Datamiljö	Windows 95/98, Windows NT 4.0, utveckling i XP också pågång.
Kommunikation	PC, nätverk, fast uppkoppling eller via telenätet, LON (främst inom kontorfastigheter med rumsmoduler). Web klient för spridning av information. Flera operativsystem som även klarar MAC datavärlden.
Användargränssnitt	15 st standardbilder samt 35 tilläggsblock över olika typer av VVS-system samt 100 st standardsymboler, alla utförda enligt svensk standard. Scannade bilder kan importeras som översiktbilder.
Programvaror	Prognosstyrning – SMHI, Signum
Rapportfunktioner	Grundmodul med bl.a. energisignatur, driftmodul, ekonomimodul
Larmfunktioner	Minicall, GSM-text, fax, e-post, utökad, reläutgång, Tateco
Styrmöjligheter	Drivrutiner mot de flesta fabrikat
Övrigt	On-line hjälpsystem; energi och klimatuppföljning via Internet. EKO-torget exempel på support som erbjuds.

 

Leverantör	Exomatic
Allmän beskrivning	Datoriserade lösningar för styrning, reglering och fjärrövervakning av fastigheter
Datamiljö	Citect, Windows
Kommunikation	PC, nätverk, fast uppkoppling eller via telenätet, Intranet, Internet, EIB, LON
Användargränssnitt	Operativsystem för framställning av processbilder, protokoll m m.
Programvaror	Excel, Citect, Windows - baserad mjukvara. SQL-databas för behandling av mätvärden. EXO-report, EXO4 Signal view.
Rapportfunktioner	Upprättas i främst Excel miljö efter kundens egna önskemål.
Larmfunktioner	Minicall, GSM-text etc
Styrmöjligheter	Drivrutiner anpassade till de flesta fabrikat.
Övrigt	Användartillgängligheten, Säkerhetsfunktionerna utvecklas.

 

Leverantör	TAC I/NET 2000
Allmän beskrivning	Öppet, fullt integrerat SÖ-system för inneklimatkontroll, tillgänglighetskontroll och energimanagement för byggnader.
Datamiljö	Windows 95/98, Windows NT 4.0
Kommunikation	PC, Internet, nätverk, fast uppkoppling eller via telenätet
Användargränssnitt	Grafisk editor för skapa valfria systemsidor. Ett stort antal vanligen använda symboler och former
Programvaror	Microsoft Access
Rapportfunktioner
Larmfunktioner	Minicall, GSM-text etc.
Styrmöjligheter	Drivrutiner mot de flesta fabrikat
Övrigt	Direktkoppling möjlig till TAC:s fastighetsförvaltningssystem, som bl.a. innehåller TAC Vista Energiberäkning för beräkning av energiförbrukning (förmodligen graddagsmodell) och energikostnader i fastighetens ventilationssystem samt för simulering av olika driftalternativ.

 

Leverantör	ABB Automation Products
Allmän beskrivning	Öppet SÖ-system. Arbetar i PLC-system. Helhetslösningar mot kund och tar även hand om gränssnitten. Produktutveckling och försäljning till konkurrerande styr- och reglerföretag.
Datamiljö	Officepaket för industrin, förenklad version för fastighetsautomation. Windows NT, Windows 2000, Windows XP
Kommunikation	OPC kommunikation ner till PLC-system. Direkt mot I/O-enheter  via soft PLC och operatörsinterface. Direkt mot Web-läsare eller WAP-server och internet eller intranet.
Användargränssnitt	Internet Explorer, EngineeringIT med editorer
Programvaror	OperatorIT som arbetar i Excel, Access, Vision Basic eller med SQL-servrar. Hjälpprogram upprättas efter kundens önskemål, typ energistatistik etc – dessa uppgifter hämtas direkt från OperatorIT programvaran.
Rapportfunktioner	Exempel tidkanaler, energistatistik et c appliceras efter kundens önskemål och uppbyggda efter den programvara som används
Larmfunktioner	Byggs upp helt efter kundens önskemål, kan sända till DHC, minicall, GSM-text internetadress etc.
Styrmöjligheter	Standard OPC-server, drivrutin, vilket innebär helt öppet protokoll och att alla skall därmed skall kunna hämta informationen.
Övrigt	Informationstillgängligheten. Olika Aspect ObjektsTM –system som gör det möjligt att länka all möjlig information till en enda komponent eller system direkt i bildfunktion. Alla länkmöjligheter är dock ännu inte utvecklade för fastighetsapplikationer. Aspects –system Aspects – Navigering

 

 

Leverantör	Siemens (Landis & Gyr) UNIGYR DDC
Allmän beskrivning	Öppet SÖ-system. Styr och reglerar olika typer av applikationer för värme- och luftbehandling samt individuell rumsreglering i små och medelstora anläggningar.
Datamiljö	Windows 95/98, Windows NT 4.0
Kommunikation	PC, via telenätet,
Användargränssnitt	Editorer för framställning av processbilder, trender och protokoll.
Programvaror
Rapportfunktioner
Larmfunktioner	Minicall, GSM-text, fax
Styrmöjligheter	Drivrutiner mot de flesta fabrikat
Övrigt

 

Siemens (Landis & Gyr) har även SÖ-systemet DESIGO med systemarkitekturen INTEGRAL, samt DESIGO med systemarkitekturen VISONIK. Det förstnämnda SÖ-systemet kan förutom styrning av värme,  ventilation, klimat, kyla och el ansvara för andra specifika uppgifter t.ex. brand-  och inbrottslarm, tillträdeskontroll och TV-system. Systemet kan  anpassas till allt från småhus till stora byggnadskomplex. Gamla  och nya system kan anslutas. Det  andra  SÖ-systemet har liknande funktion.

Leverantör	Kabona AB
Allmän beskrivning	Systemet är baserat på PLC-system från Schneider som har en programmeringsmiljö som utgår från en världsstandard. (IEC 61 131-3). I PLC systemet programmeras alla grundfunktioner, såsom regulatorer, sekvenser, manöverfunktioner m m. Som användargränssnitt används en WDC (WebDatorCentral) där hårdvaran består av en enkortsdator system PC104. Den egenutvecklade mjukvaran till denna enhet är skriven i Linux som är ett öppet operativsystem. I användargränssnittet används vanligen Webläsare, ex Internet Explorer, Netscape från valfri dator. Genom denna systemuppbyggnad får man ett gemensamt användargränssnitt oavsett om man befinner sig lokalt i fastigheten eller på distans. Systemet behöver ingen central programvara eller DHC.
Datamiljö	På PLC nivå IEC 61 131-3, på WDC nivån – Linux.
Kommunikation	WDC ansluts via TCP/IP till Internet/Intranet, mellan WDC och PLC används TCP/IP alternativt Modbus, Profibus, FIP, m m.
Användargränssnitt	Vanlig Web-läsare via PLC, Handdator m m. Via WDC avläses samtliga data, åtkomstnivå via olika inloggningsnivåer. Här finns även annan dokumentation såsom flödesbilder, funktionstexter etc.
Programvaror	På PLC nivå används Schneiders programvara Concept, och vid köp av WDC ingår programvaran som är skriven i Linux.
Rapportfunktioner	Samtliga värden loggas automatiskt, data kan skickas via e-post i 4 olika mätningsintervall, 30 s, 5 min, 1 h och 1 dygn. Data överförs i ACHII-format.
Larmfunktioner	Larm och information skickas via SMTP – meddelande, som kan levereras som e-post, SMS fax m m.
Styrmöjligheter	Via WDC ställs börvärden, tidkanaler, larminställningar, start/stopp – funktioner m m.
Övrigt	Ingen central programvara behövs, d v s någon form av DHC, endast utbildning på ett användargränssnitt behövs.

 

Utöver ovannämnda leverantörer har även en ledande leverantör av SÖ-system till industrin (skulle ha) intervjuats per telefon, nämligen APV automation.

Problem med gränssnitt i moderna sö-system

Det föreligger fortfarande stora brister i hur gränssnitten fungerar vid datorautomatisering. Detta beror till stor del på att det ofta är leverantören som styr utvecklingen av SÖ-systemen i högre grad än att brukaren ställer krav. Beroende av hur SÖ-systemen är uppbyggda måste någon typ av gränssnitt  användas för kommunikationen mellan datorn och dess omvärld. Det blir i vissa fall flera gränssnitt som måste beaktas, dels gränssnittet mellan brukaren och en eventuell huvuddator, dels gränssnittet mellan huvuddator och DUC:ar. Dessutom finns ett gränssnitt mellan DUC och de parametrar som skall styras, mätas mm. Gränssnitten mellan DUC, I/O- enheter etc. är ofta en avgörande länk som glöms bort i sammanhanget då programvara i huvudsystemet skall uppgraderas. Alltför sent upptäcks att de funktioner som finns i dessa gränssnitt inte klarar uppgraderingen utan måste kompletteras eller bytas till nyare modeller vilket blir kostsamt för beställaren. Avgörande för hur funktion och styrning fungerar i ett system är hur snabbt gränssnitten kommunicerar med varandra.

Ett vanligt användarproblem är just gränssnittens sätt att kommunicera. Genom olika uppgraderingar av exempelvis nyare och snabbare datorer kör datorerna helt enkelt ifrån gränssnitten. Problem uppstår också ofta vid uppgraderingar av olika operativsystem, nya drivrutiner och liknande eftersom dessa inte problemfritt kan köras mot det tidigare gränssnittet.

Problemen i de olika gränssnitten består oftast av att utvecklingen av datorprogrammen görs av mer ”kvalificerad ” personal än den personal som skall använda systemen i sitt dagliga arbete. Det är alltför sällan att det är någon som ej är expert på systemet som verkligen får prova funktionen i datorprogrammen, ”köra” operativsystemet, för att se hur det egentligen fungerar med de olika gränssnitten.  ”Vanlig” driftpersonal kan ofta hitta de brister som förekommer i gränssnitten betydligt tidigare än vad en ”kvalificerad” styrtekniker gör, eftersom han kan åstadkomma oväntade användarfunktioner som kan kräva att programmen ändras. Den VVS-kunnige och styrspecialisten talar ofta inte samma ”språk”.

Vad beträffar programvaror för felsökning och simulering, så finns de inte i någon större utsträckning idag. De programvaror, som finns på energisidan, är simuleringar av typen energisignatur eller graddagsberäkningar.

förbättringsmöjligheter och KONSEKVENSER

Framtida SÖ-system kommer att kunna skräddarsys till alla tänkbara behov, vilket innebär att beställaren måste veta vad han vill uppnå och ställa krav därefter. Komponenter av olika fabrikat kan blandas, vilket kan medföra risk för problem. De framtida SÖ-systemen kan komma att kräva omfattande programmeringsarbete, men ger stora möjligheter. SÖ-system kan integreras med förvaltningssystem, ekonomisystem mm. Gränssnittet till operatören är i Windows. Kommunikation sker över ofta över Internet.

Utvecklingen går otroligt snabbt och trenden är att SÖ-systemen kommer att ingå i det normala datanätet som redan finns i fastigheterna. De s k DHC systemen, d v s SÖ-systemen med DUC:ar och en huvuddator som man i sin tur kan ringa upp och kontrollera systemen ifrån en annan dator, kommer mer eller mindre vara överflödiga. Fördelen med den nya tekniken är att flera gränssnitt i SÖ-systemen minskar trots betydligt större möjligheter. Många av de drifttekniker och andra personer som idag arbetar med SÖ-system arbetar också samtidigt i en vanlig datamiljö med exempelvis Internet och Intranet kommer sannolikt ha stor fördel av att bara behöva arbeta i en typ av datamiljö.

Utvecklingen på datorsidans programvaror innebär att det kommer att ske betydliga förenklingar för användaren, dels för att antal gränssnitt minskas d v s risken för felkällor minskar, dels för att driftpersonalen bara behöver en riktad utbildning. Detta är en klar indikation från samtliga leverantörer idag. Frågan är dock om detta är till fullo för beställaren! Är programvarorna tillräckligt bra för att bara börja användas eller vad krävs? Vad är ”tillräckligt” bra, detta är en fråga man bör ställa sig alltid oavsett vilket system man har för avsikt att välja. Ett system blir tillräckligt bra först när det uppfyller alla de krav jag har som beställare samt att funktionen finns utan fel och brister. Frågan är finns dessa garantier hos någon idag, finns de krav specificerade som beställaren har som mål för anläggningen?

Att utvecklingen går lavinartat på datorsidan är alla överens om. Frågan är hur detta påverkar utvecklingen åt andra hållet d v s det gränssnitt som ligger mellan I/O-enheter, modbus  e t c och andra funktioner som har direktkopplingen till den enskilda komponent i ett system som skall styras på ett eller annat sätt med ett antal olika signaler.

Vi har lärt oss mycket under den tid som SÖ-system verkat, särskilt vilka brister som beställare upplevt och försökt komma till rätta med. Det finns utan tvekan klara förbättringar  i de system som finns idag mot den tidigare versionen av SÖ-system med i princip helt stängda protokoll. De öppna protokollen idag medför inte enbart bättre konkurrensmöjligheter för beställaren utan också betydligt enklare hantering vid uppdateringar e t c, eftersom man i princip kan välja nytt system som kan kommunicera med det gamla.

En stor frågeställning är dock – vad görs åt den största funktionsbristen i ett SÖ-system d v s de brister som finns i själva systemet, komponenten som skall styras. En tidigare studie som gjorts  (R43:1993, Långtidsfunktion hos styr- och reglerutrustning) visar att rena fel i styr- och reglerutrustning samt mätinstrument svarar för ca 47% av alla fel i ett vvs-system, 53% utgörs av andra fel i själva komponenter, sammansatta funktionen, mekaniska fel e t c.

En stor del av felen i styr- och reglersystemen utgörs av felaktiga funktioner i komponenter till styrsystemet som t ex givare, som är felplacerade, har för dålig noggrannhet etc. De rena felaktigheter som kunnat konstateras i datorsystemen har varit mer begränsade men å andra sidan visat sig vara en avgörande del för helheten eftersom det är här som det första gränssnittet ligger för brukaren.

Ingen av de ovannämnda leverantörerna har redovisat att de har för avsikt att utveckla programvaror för avancerad felsökning och simulering av byggnader med sina installationer. Inom IEA har avancerade metoder för felsökning utvecklats (IEA Annex 25 Building optimization and fault diagnosis - source book från 1996 och IEA Annex 34 Demonstrating automated fault detection and diagnosis methods in real buildings – source book från 2001). IEA-arbetet har hittills inte resulterat i programvara. En av leverantörerna har deltagit i en utveckling av felsökningsmetodik som bygger på felträdsanalyser. Detta har dock hittills inte gett något användbart verktyg. SP har tillsammans med en annan leverantör utvecklat en enklare felsökningsmetodik, som skulle kunna bli en användbar metodik. En utvecklings -potential finns med andra ord.

I stort sett samtliga leverantörer utvecklar programvarorna på framförallt datorsidan och i betydligt mindre utsträckning åt andra hållet i gränssnitten. Eftersom datorsidan enbart förenklar användningen av programvara för brukaren kommer det i framtiden finnas ett större behov av att se helheten i funktionerna. Vilka krav ställer vi på att den funktion, komponent som finns i ett system skall klara av att mätas, styras, regleras e t c från ett datoriserat styrsystem. Är vi säkra på att funktionen förbättras för att datorernas programvaror blir alltmer sofistikerade men betydligt enklare att använda.

Den stora bristen i ett SÖ-system är de brister som redan finns inbyggda i det system som skall styras. Oavsett hur utvecklingen framskrider på datorsidan med webläsare, internet/ och intranet funktioner mm som kommer det ursprungliga bristerna i systemfunktionen att kvarstå. Hur ser utvecklingen ut för enskilda komponenter i t ex vvs-system, är dessa beredda på att ta emot och styras av datorernas olika program och drivrutiner. Vilka kommunikationsproblem kommer vi att få mellan detta gränssnitt och datavärlden.

Det framgår från flera leverantörer och tillverkare av reglerutrustningar att det ofta är problem i de system som skall styras, där regulatorn skall appliceras, antingen är det inte rätt dimension eller tänkt reglerstrategi avviker från regulatorkonceptets förutsättningar. Installatörer påpekar problem som att levererad reglerteknisk utrustning inte uppfyller kravspecifikationerna. Dessutom avviker ofta prestanda på givare, regulatorer etc. från vad tillverkaren angivit.

Vad händer i våra vvs-system, med utveckling av datorernas programvaror men kvarstående brister i de tekniska systemen.

Problemställningen blir allt tydligare. Kraven på beställaren kommer att öka eftersom man i princip kan nyttja vilket styrsystem som helst och vilka programvaror som helst, men fungerar det till de vvs-system som man har. Vilka krav kan man ställa på den slutliga funktionen?, och vilka krav skall man överhuvudettaget ta upp. Idag övertygas man alltmer om vad den nya tekniken klarar av, men man måste ändå som beställare vara medveten om vad det är man vill att detta system skall göra.

Klarar vi av detta idag att ställa tillräckliga krav för att få ett tillräckligt bra system med de önskemål vi haft om SÖ-systemet och dess funktion. Svaret är givet och definitivt nej, vilket klart framgår av ingen validering av SÖ-system sker idag p g a avsaknaden av kravspecifikationer från beställarledet.

En annan aspekt som ofta nämns i datamiljö - sammanhangen är säkerheten, vilka säkerhetsfunktioner kommer att behövas när systemen blir helt öppna och användartillgängligheten är stor. Hur enkelt kan utomstående ta sig in i olika SÖ-system som dessutom kanske samkörs på ett intern nät med det administrativa systemet etc.

 

slutsatser

Förstudien visar att det finns ett stort behov att klargöra den kommande strategin för SÖ-system, vilket kan sammanfattas i följande punkter.

·        Utvecklingen mot IT-baserat gränssnitt mot brukaren förändrar möjligheterna och synsättet på SÖ-systemen. Frågan är hur väl förberedd brukaren är inför detta. Man har ännu ej hunnit arbeta bort de barnsjukdomar som funnits på de traditionella DUC och DHC-systemen.

·        Utvecklingen sker i princip enbart i en riktning nämligen på gränssnitten mot brukaren, kommunikationsgränssnittet mot systemfunktionen och enskilda komponenter halkar efter. Kommer detta att leda till andra systemkrav än rena SÖ-system krav?

·        Vilka möjligheter skapar den nya tekniken att driva fastigheter så energieffektivt som möjligt. Vilka krav behöver ställas för att överhuvudettaget få ett komplett tillförlitligt system. Vilka krav behöver ställas på den som skall ”köra” anläggningen – vilken utbildningsnivå är man som beställare beredd att satsa på och acceptera vid köp av ett SÖ-system, måste systemen och programvaror vara så komplexa att utbildning krävs i stort sett varje gång det sker en liten förändring. Vilka krav behöver ställas  på den som skall analysera systemfunktion och mätresultat t ex energianvändningen, måste man som beställare ”köpa” denna funktion.

 

För att komma vidare i denna studie bör man studera tre viktiga områden kring SÖ-systemen.

·        Hur ser brukaren på gränssnittet och utvecklingen av SÖ-system. Kan man ta åt sig all ny teknik och vilka brister och vad saknas i den nya tekniken. Vad gör brukaren som sitter med ett lite föråldrat SÖ-system idag, vad krävs av denna brukare och hur upplever han situationen.

·        Vad krävs i ett SÖ-system för att det skall kunna ge den vinst som förväntas, inte minst energibesparingen som förväntas och som är en av delmålen med ett SÖ-system. Ett annat delmål är att förenkla driftövervakningen och därmed spara på den organisation som driver anläggningen. Ett sätt att undersöka detta är att driva ett projekt där man visar SÖ-systemens yttersta möjligheter.

·        För att skapa ett enhetligt verktyg som hjälper beställaren att få fram det underlag som krävs för att erhålla ett ”tillräckligt” bra SÖ-system, måste en funktionsriktig kravspecifikation upprättas. Underlaget till denna kravspecifikation kan utarbetas ur erfarenheterna ur ovan projekt samt av de erfarenheter som redan finns i stor omfattning på olika håll.