Evaluering av tilgang til alarmer og kalenderstyring

STAVANGER KOMMUNE Evaluering av tilgang til alarmer og kalenderstyring Juli 2013 Redpill Linpro AS Lervigsveien 16 4014 Stavanger www.redpill-linpro.no

Innhold 1. Oppsummering...4 2. Introduksjon...6 3. Teknologier...6 3.1. OPC...6 3.2. BACnet...7 3.3. Web Services...7 4. SD-anlegg...8 4.1. EM Systemer...8 4.1.1. Teknisk miljø...8 4.1.2. Fremgangsmåte - Hente alarmer...8 4.1.3. Fremgangsmåte Kalenderstyring...9 4.1.4. Konklusjon...9 4.2. GK/Tridium Niagara...10 4.2.1. Teknisk miljø...10 4.2.2. Fremgangsmåte - Hente alarmer...10 4.2.3. Fremgangsmåte Kalenderstyring...10 4.2.4. Konklusjon...10 4.3. Johnson Controls/Metasys...11 4.3.1. Teknisk miljø...11 4.3.2. Fremgangsmåte - Hente alarmer...12 4.3.3. Fremgangsmåte Kalenderstyring...13 4.3.4. Konklusjon...13 4.4. Kverneland Elektriske...13 4.4.1. Teknisk miljø...13 4.4.2. Fremgangsmåte - Hente alarmer via OPC...14 4.4.3. Fremgangsmåte - Hente alarmer fra database...14 4.4.4. Fremgangsmåte Kalenderstyring...14 4.4.5. Konklusjon...14 4.5. Rogaland Elektro/Trend...15 4.5.1. Teknisk miljø...15 4.5.2. Fremgangsmåte - Hente alarmer...15 4.5.3. Fremgangsmåte Kalenderstyring...16 4.5.4. Konklusjon...16 4.6. Schneider Electric TAC Vista...17 4.6.1. Teknisk miljø...17 4.6.2. Fremgangsmåte - Hente alarmer...17 4.6.3. Fremgangsmåte Kalenderstyring...19 4.6.4. Konklusjon...19 4.7. Siemens...19 4.7.1. Teknisk miljø...19 4.7.2. Fremgangsmåte - Hente alarmer...19 4.7.3. Fremgangsmåte Kalenderstyring...21 Side 2 av 30

4.7.4. Konklusjon...21 4.8. Symmetry...22 4.8.1. Teknisk miljø...22 4.8.2. Fremgangsmåte - Hente alarmer...22 4.8.3. Fremgangsmåte Kalenderstyring...23 4.8.4. Konklusjon...23 4.9. EOS...24 4.9.1. Teknisk miljø...24 4.9.2. Fremgangsmåte - Hente alarmer...24 4.9.3. Fremgangsmåte Kalenderstyring...25 4.9.4. Konklusjon...25 5. Video...26 5.1. BlueCherry...26 5.1.1. Teknisk miljø...26 5.1.2. Fremgangsmåte - Hente alarmer...26 5.1.3. Fremgangsmåte Kalenderstyring...26 5.1.4. Konklusjon...26 6. FDV...27 7. Framtidsmuligheter...27 7.1. Visjonen...27 7.2. Eksisterende systemer...28 7.2.1. EM-systemer...28 7.2.2. GK... 28 7.2.3. Johnson Controls...29 7.2.4. Kverneland Elektriske...29 7.2.5. Rogaland Elektro...29 7.2.6. Schneider...29 7.2.7. Siemens... 29 7.2.8. Symmetry...29 7.3. Produkter kjøpe, lage, eller...?...29 7.3.1. Proprietære produkter...29 7.3.2. Åpen kildekode...30 7.4. Interkommunalt samarbeid...30 Side 3 av 30

1. Oppsummering På oppdrag fra Stavanger kommune har Redpill Linpro vurdert mulighetene for integrering mot kommunens ulike automatiserings- og kontrollsystemer for bygg fra ulike leverandører. Integreringen er vurdert ut fra mulighet for hente ut alarmer og konfigurere systemene via kalenderfunksjonalitet. Resultatene av analysen summeres i følgende tabell. Vi finner at det å hente ut alarmer og kunne prioritere/filtrere disse vil være en relativt enkel oppgave for de fleste utstyrsleverandørene, med et par unntak. En har sett for seg at en i alarmportalen skal kunne klikke på en alarm, og derved komme direkte inn på aktuelt sted i vedkommende toppsystem for å kvittere ut alarmen der. Dette viser seg å være relativt vanskelig. Et par av leverandørene benytter web-baserte løsninger, og for disse vil det være relativt enkelt å kunne linke til, i det minste, rett applikasjon. De øvrige benytter «tykke klienter» som ikke enkelt kan startes opp fra en nettleser. Der vil det sannsynligvis være mest hensiktsmessig å basere seg på manuell oppstart av aktuelt toppsystem. Kalenderstyring krever toveis kommunikasjon, og blir derved vesentlig mer komplisert. Selv om en for de fleste leverandørenes vedkommende har en teoretisk mulighet for å få det til, vil det føre til en dramatisk kostnadsøkning i forhold til en ren alarmportal. I tillegg vil usikkerheten i et slikt prosjekt være vesentlig. Det anbefales derfor at slik funksjonalitet utsettes til en senere fase. Side 4 av 30

Denne tabellen gir en konsentrert oversikt over funn for hver enkelt leverandør. Kolonnen «Kalenderstyring» reflekterer situasjonen i forhold til et kortsiktig alarmportalprosjekt. Kolonnene om framtidsmuligheter gjelder muligheter for innpassing av dagens systemer i en mer omfattende løsning. Leverandør Hente alarm Kalender styring Framtidsmuligheter i dagens anlegg BACnet OPC Kommentar Energi: Rogaland Elektro / Trend Bra Ikke mulig J J BACnet: kun nyere systemer, og krever lisensavgift på 3500NOK/kontroller. OPC mot eldre systemer. God dokumentasjon fra Trend Johnson Controls / Metasys Bra Ikke mulig J J Uklart om OPC fungerer i de systemer som er levert. Schneider Electric TAC Vista Bra Vanskelig J J OPC krever lisens og konsulentarbeid, estimert 250 000NOK. GK/Tridium Niagara Vanskelig Vanskelig J J Alarmer kan kke hentes ut i dag, men kan utvikles av GK. BACnet og OPC kun for nyere systemer. Krever kompetansehevning/opplæring. Siemens Bra Ikke mulig J N Forutsetter lisens, konsulent og serviceavtale, estimert 120 000 NOK. Dokumentasjon vanskelig å bruke. Kverneland Elektriske Vanskelig Vanskelig N J Støtter OPC API, men mangler dokumentasjon og forutsetter tilgang til fagperson. EM Systemer Ikke mulig Ikke mulig N J SOAP/RPC API dårlig dokumentert og standardisert. Ingen database EOS Bra Ikke relevant Analyseverktøy hvor kalenderstyring ikke er relevant. Adgangskontroll Symmetry Bra Ikke mulig N N Kan levere Web Services API med mangelfull funksjonalitet. Video: BlueCherry Bra Ikke relevant Video-overvåking, kalenderstyring er ikke relevant. Vurderingsnøkkel: Bra - Data er mulig å lese via godt designet database OK - Data er mulig å lese via database Vanskelig - Data er vanskelig lese grunnet feks lite dokumentasjon, manglende støtte e.l. Side 5 av 30

2. Introduksjon Rapporten beskriver metoden benyttet for å vurdere hvordan data kan samles inn fra utstyr (SD-anlegg, adgangskontroll, alarm, videoovervåking) plassert i bygg i forbindelse med Stavanger Kommunes alarmportal prosjekt. Målsetningen er et teknisk grunnlag for potensielle leverandører til bruk ved estimering av datafangst fra slikt utstyr. Det forsøkes gi svar på hvor komplekst det vil være å: Hente ut alarm-meldinger Utvikle kalenderstyring i tilknytning til portalen Gjennom oppdragets gang har det blitt klart at teknisk dokumentasjon for uthenting av alarmer kan utformes på en vesentlig mer hensiktsmessig måte enn opprinnelig forutsatt. Det er utviklet en enkel «demo»-applikasjon som implementerer slik uthenting i praksis. I dette dokumentet vil en se utdrag/eksempler fra hvordan alarmer presenteres i denne applikasjonen gjennom en nettleser. Den er tilgjengelig hos Stavanger kommune på adresse: http://admsys193.svgkomm.svgdrift.no Kildekoden for denne applikasjonen vil dokumentere nøyaktig hvordan uthenting av alarmer foretas. Av praktiske årsaker oppbevares denne kildekoden for øyeblikket hos Redpill Linpro. Den vil bli levert til kommunen og/eller andre tilbydere på forespørsel. 3. Teknologier Prinsipielt vil det være en fordel om en i løsninger som denne portalen kan kommunisere med definerte grensesnitt som vedlikeholdes av utstyrsleverandøren. Alternativet er å hente data direkte fra utstyrets egen database. Det viser seg at de grensesnitt (API-er) som tilbys av aktuelle leverandører, er vanskelige å arbeide med. Det skyldes dels dårlige implementasjoner, dels manglende dokumentasjon, og dels manglende kompetanse hos leverandørene. Det viktigste hinderet er imidlertid de kostnader det ville medføre. Samtidig finner vi for de fleste leverandører, at alarmer kan hentes ut på en svært enkel måte direkte fra databasen. Enkelheten her medfører at de prinsipielle betenkeligheter en normalt har mot slikt, blir vesentlig redusert. Konklusjonen blir derfor at direkte uthenting fra databasen blir anbefalt metode for dette prosjektet. I den grad definerte grensesnitt finnes, blir disse omtalt nedenfor i dette dokumentet. De øvrige avsnitt i dette kapittelet gir derfor en kortfattet generell beskrivelse av de teknologier som anvendes. 3.1. OPC En finner at flere av de leverandørene som er aktuelle her, støtter en standard kalt OPC til en viss grad. OPC er en industristandard som sikter mot datakommunikasjon i forbindelse med prosesskontroll/-styring. Standarden forvaltes av et organ ved navn OPC Foundation se http://en.wikipedia.org/wiki/opc_foundation. Side 6 av 30

OPC bygger på en kommunikasjonsstandard fra Microsoft, kalt OLE. Tradisjonelt har OPC derfor vært nært knyttet opp mot Windows servere og annen teknologi fra Microsoft, har kunnet ses som noe mindre åpen enn en kunne ønske. OPC UA er en fornyet utgave av standarden, hvor hovedhensikten er en modernisering i forhold til den generelle utvikling innen IT. Større grad av åpenhet vil sannsynligvis være en konsekvens av dette. Blant det aktuelle leverandørene her, er det Schneider som hevder å kunne støtte OPC UA i dag, mens et par andre snakker om framtidige planer. Analysen viser imidlertid at OPC i dag er lite anvendelig i praksis for vårt formål. Hovedårsaken er kostnadsnivået det medfører. De fleste leverandørene som støtter OPC har ikke levert dette til sine installasjoner i Stavanger kommune. Støtte for OPC krever en egen server. Denne fører til lisenskostnader. Det vesentligste kostnadselementet er likevel arbeid med oppsett og konfigurasjon av en slik server. Det kan være snakk om beløp i størrelsesorden 100.000 kroner. Det kunne en sikkert leve med om det var snakk om en server. Det er imidlertid slik at ytelsen i en OPC server er slik at en ikke vil kunne etablere en server for et antall bygg. En må regne med minst en server pr. bygg i enkelte tilfeller kanskje flere. I tillegg er det slik at informasjon som hentes ut fra OPC er i form av «rådata» - det vil si informasjon som må tolkes for at det skal gi mening for en driftsoperatør. Slik tolking av rådata må i så fall programmeres som en del av portalprosjektet. Det vil medføre en betydelig kostnad i seg selv, spesielt siden OPC UA er så komplekst at det sannsynligvis vil være relativt få utvklere med relevant dybdekompetanse. SD-leverandørene har selv utført denne programmeringsjobben i forbindelse med sine ulike toppsystemer. Resultatet legges ut i tilnærmet klartekst i databasen. Uthenting av alarmer kan derfor gjøres svært enkelt derfra, som nevnt ovenfor. 3.2. BACnet Dette er en annen kommunikasjonsstandard som et stykke på vei dekker det samme området som OPC. Den er imidlertid mer åpen og mer anvendelig. Vårt inntrykk er også at den er mer gjennomarbeidet, og at den er mer motstandsdyktig mot leverandørers «snarveier», blant annet fordi den definerer standardiserte egenskaper som må overholdes for at en skal kunne påberope seg støtte for BACnet. Mer informasjon kan finnes på http://en.wikipedia.org/wiki/bacnet. Enkelte av dagens SD-leverandører kan også levere støtte for BACnet, men færre enn for OPC. Samtidig vil BACnet ikke føre til reduserte utviklingskostnader i forhold til det som ble skissert for OPC. Av den grunn vil BACnet ikke endre vår konklusjon på kort sikt. Vi ser imidlertid muligheter for at BACnet kan være interessant på lengre sikt. Mer om det mot slutten av dette dokumentet. 3.3. Web Services Dette er teknologi utviklet for datautveksling over Internett (World Wide Web) (men det fungerer jo like bra lokalt). I dette dokumentet nevnes vi forskjellige kommunikasjonsteknikker som benyttes for Web Services - REST og SOAP. Side 7 av 30

SOAP er den opprinnelige teknikken her, basert på utveksling av data i XML-format. Et sentralt konsept i SOAP er WSDL. Dette er en teknisk definisjon av et SOAP grensesnitt, som en utvikler kan importere direkte i sitt program, og som derved forenkler deler av utviklingsarbeidet. Det forutsettes jo da at WSDL filen er korrekt satt opp, noe dette prosjektet har vist ikke alltid er tilfellet. SOAP anses i dag som gammel teknologi som er tungvint å jobbe med, og den er lite brukt for nyutvikling. REST er den moderne teknikken for datautveksling i dag Den baserer seg på å bruke metoder i den standardiserte HTTP protokollen for lesing, skriving, modifisering eller sletting av data. Den kan utveksle data i binær form, JSON, XML, ren tekst. Hovedgrunnen til REST er populært idag er at det er mulig å bruke en vanlig nettleser for å teste datautveksling. Noe som gjør det mulig at ikke-teknikere også kan være med på å teste datautveksling. 4. SD-anlegg 4.1. EM Systemer Kartleggingsansv. Epost Olav Grønås Gjerde olav.gjerde@redpill-linpro.com Telefon +47 969 01 108 Firma Redpill Linpro Kartlagt dato Mars 2013 4.1.1. Teknisk miljø Kartleggingen er utført på følgende miljø. Windows 2008 Java SOAP/RPC API 4.1.2. Fremgangsmåte - Hente alarmer Denne leverandøren har ingen database en kan hente alarmer fra. De kan levere et SOAP basert grensesnitt, som vi finner lite anvendelig. For det første er det basert på en versjon av SOAP som er så gammel at den er definert før standarden ble ferdigstilt. Det betyr at det er vanskelig å finne utviklingsverktøy som kan brukes. Blant annet så er det vanskelig å sende en request med SOAPUI programmet, som er de facto standard for testing av SOAP Web Services. Dokumentasjon er ikke umiddelbart tilgjengelig, men utleveres fra leverandøren på forespørsel. WSDL kan hentes fra http://10.72.24.15:1024/wsdl/ihpcserverint og utgjør jo noe dokumentasjon i seg selv. Vi finner API-et vanskelig å benytte fordi: WSDL'en inneholder feil i henhold til standard Side 8 av 30

Enkelte operasjoner feiler totalt Gammel SOAP standard (se ovenfor) Dokumentasjonen fra leverandøren samsvarer ikke med det som er levert til Stavanger kommune Leverandøren opplyser følgende, som en kommentar: «Vi kan levere et toppsystem som kan kommunisere både via OPC (DA, HDA, UA) og BACnet (MSTP/TCP). De systemene vi har levert til Stavanger Kommune per i dag kan kommunisere med OPC DA. Det vil si, vi har en OPC Server i hvert enkelt prosjekt vi har levert. Denne må bare aktiveres. For å kommunisere med OPC så benyttes normalt en OPC Tunneler programvare for å komme rundt COM/DCOM og sikkerhetsproblematikk knyttet til OS. Vi kan dermed levere et toppsystem (SCADA) som kan kommunisere med hvert enkelt prosjekt via OPC.» I og med at en her forutsetter et spesifikt toppsystem, strider dette mot Stavanger kommunes intensjoner med dette prosjektet. 4.1.3. Fremgangsmåte Kalenderstyring Finner ingen metoder som kan styre dette direkte. 4.1.4. Konklusjon Stavanger kommunes intensjon var at alle SD-anlegg skal logge data til database. EM-systemer er i dag ikke i stand til å levere en slik løsning. Det er mulig de kan få dette levert fra sin leverandør, men fremdeles vil ingen hos EM-Systemer sitte med kompetansen til å sette opp en databaseløsning eller å kunne bistå Stavanger Kommune med særskilte krav eller til analyse/datamodellering av data fra anleggene. SOAP API-et er gammelt, bryter med standarden, er dårlig dokumentert, og unødvendig komplekst. Det kan tenkes at en kan klare å hente ut alarmer dersom en har betydelig bistand fra EM-systemer i utviklingsfasen, men det er også godt mulig at det må gjøres endringer i anleggenes programvare for å få det til. For denne leverandøren anses det derfor at både uthenting av alarmer og kalenderstyring ikke vil være mulig innenfor rimelige kostnadsrammer. Fordeler: Ingen spesielle Ulemper: Viser seg å være usikre på tekniske fagspørsmål og viser svakt kunnskapsnivå. Har ingen database Kunnskapsnivå API er dårlig. Side 9 av 30

4.2. GK/Tridium Niagara Kartleggingsansv. Epost Olav Grønås Gjerde olav.gjerde@redpill-linpro.com Telefon +47 969 01 108 Firma Redpill Linpro Kartlagt dato Mars 2013 4.2.1. Teknisk miljø Kartleggingen er utført på følgende miljø. Windows 2008 SQL Server 2008 Kommunen har i dag to versjoner av plattformen installert Niagara R2 og den noe mer moderne Niagara AX. 4.2.2. Fremgangsmåte - Hente alarmer Det leveres en databaseløsning, men denne er strukturmessig rotete og vanskelig å jobbe i. I analysefasen var det også slik at den ikke fungerte hos Stavanger kommune. Alarmer kan derfor per dags dato ikke hentes ut. En kan bestille utvikling av denne funksjonaliteten fra GK. I tillegg til de kostnader dette vil medføre, må en i så fall også tenke gjennom problematikken omkring vedlikehold av det som er utviklet. Dersom leverandøren oppgraderer sin programvare, er det mulig at spesielt utviklet funksjonalitet også må endres. 4.2.3. Fremgangsmåte Kalenderstyring Mulig med Niagara AX. Men det vil være kostbart, da en må investere betydelig i å øke kompetansen om Niagara rammeverket. 4.2.4. Konklusjon Alarmer kan per dags dato ikke hentes ut, men kan en bestille forbereding av dagens leveranse fra GK, med de kostnadsmessige konsekvenser som følger med. Dagens dataoppsett viser at leverandøren har svake databasekunnskaper. Kalenderstyring vil kreve investering i kompetansehevning/opplæring av Niagara rammeverket for å jobbe mot API-et. Fordeler: Niagara rammeverket Niagara har nettportal for tekniske fagfolk. Ulemper: Databasekunnskaper. Vanskelig / tar lang tid å få hjelp. Kan ikke hente ut alarmer per dags dato. Side 10 av 30

4.3. Johnson Controls/Metasys Kartleggingsansv. Epost Olav Grønås Gjerde olav.gjerde@redpill-linpro.com Telefon +47 969 01 108 Firma Redpill Linpro Kartlagt dato Mars 2013 4.3.1. Teknisk miljø Kartleggingen er utført på følgende miljø. Windows 2008 SQL Server 2008 Side 11 av 30

4.3.2. Fremgangsmåte - Hente alarmer Her bli data hentet direkte fra databasen. Alarmer ligger i databasen JCIEvents og i tabell tblevent. Databasen er strukturmessig ryddig og oversiktlig. Eksempel på utlisting av alarmer: Databasespørringen er som følger: SELECT TOP 10 [eventid],i.itemname,i.itemfullyqualifiedreference,i.itemdescription,[utccreationdatetime],[priority],[message] FROM [JCIEvents].[dbo].[tblEvent] e Side 12 av 30

INNER JOIN [JCIEvents].[dbo].[tblItem] i ON e.itemid = i.itemid ORDER BY utccreationdatetime DESC Siden denne databasen er strukturmessig bra og har gode selvbeskrivende navn så anser vi databasen som en utmerket måte å få hentet ut alarmer på. Prioriteringsverdier som er viktige for å kunne lage Alarmportalen, er også på plass som en ser på skjermbildet. 4.3.3. Fremgangsmåte Kalenderstyring Ikke mulig, da det ikke finnes verktøy til å utføre dette. Det er mulig å gå i dialog med Johnson Controls direkte for å finne løsninger, da men dette vil koste tid og penger. 4.3.4. Konklusjon Veldig enkelt å hente alarmer fra databasen. For toveiskommunikasjon, nødvendig for kalenderstyring, støtter Johnson Controls forskjellige protokoller, blant annet både BACnet og OPC se http://www.johnsoncontrols.com/content/us/en/products/building_efficiency/products-and-syste ms/building_management/systems_integration.html Men dette vil innebære relativt omfattende utviklingsarbeid, og derved koste mye tid og penger for å få til. Fordeler: Databasen er bra strukturmessig bra og enkel å hente ut data fra. Ulemper: Ingen API. 4.4. Kverneland Elektriske Kartleggingsansv. Epost Olav Grønås Gjerde olav.gjerde@redpill-linpro.com Telefon +47 969 01 108 Firma Redpill Linpro Kartlagt dato Mars 2013 4.4.1. Teknisk miljø Kartleggingen er utført på følgende miljø. Windows 2008 SQL Server 2008 OPC / Python OpenOPC Side 13 av 30

4.4.2. Fremgangsmåte - Hente alarmer via OPC Kverneland elektriske har levert en løsning med OPC servere som en kan kommunisere med OPC DA protokollen. Jeg greide å opprette tilkobling mot en server/prog_id med navnet ICONICS.Simulator.1 og å hente ut verdier fra objekter fra denne serveren. Det var litt problemer med å hente ut verdier fra de andre serverne. Men dette er mulig å få til ved å jobbe litt tettere sammen med Kverneland Elektriske. 4.4.3. Fremgangsmåte - Hente alarmer fra database Databasen heter kelogdata og er strukturmessig veldig rotete. Hver installasjon ser ut til å ha sine egne tabeller, alarmene finner en i Alarmlog tabellen. Dessverre så viste det seg at dataoverføringa der har også stoppet opp. 4.4.4. Fremgangsmåte Kalenderstyring Det er mulig å få til kalenderstyring med å bruke OPC, men det vil ligge mye ekstraarbeid ved at det må konfigureres et oppsett på portalsiden for å kunne hente ut data fra utstyr og målere på en konsistent måte. 4.4.5. Konklusjon Kverneland elektriske kan bare levere løsninger som bruker OPC. Deres underleverandør leverer løsninger som baserer seg på proprietære kommunikasjonprotokoller, og baserer seg på OPC om en trenger friere tilgang til rådata. Databasen som er levert av Kverneland Elektriske er strukturmessig uoversiktlig. Etter flere dagers dialog og spørsmål om såpass enkle ting om logging og om hvorfor det er ingen data etter 23 Desember 2012, så får vi framdeles ikke presise svar. De bygger visstnok logging til database med verktøy levert av underleverandøren istedenfor å bruke tradisjonelle database verktøy. Dette betyr av vi sitter igjen med et inntrykk av at databasekompetansen er ganske tynn hos Kverneland Elektriske. De påstår at det kan leveres data akkurat som Stavanger kommune skulle ønske, men dette kan bli meget dyrt å få gjort skikkelig. OPC-biten ser det ut som de har god kontroll på, og de leverer OPC serverer ferdig konfigurert med et standard oppsett som gjør OPC løsningen deres billigere enn konkurrentene. Fordeler: Gode OPC kunnskaper. Svarer hurtig og vennlig på spørsmål. Presise svar angående bygg og automasjon. Pris på OPC Ulemper: Databasekompetanse. Bare fokusert på OPC som mulighet til tovegskommunikasjon Gir dårlige svar angående databaselogging og dens status. Side 14 av 30

4.5. Rogaland Elektro/Trend Kartleggingsansv. Epost Olav Grønås Gjerde olav.gjerde@redpill-linpro.com Telefon +47 969 01 108 Firma Redpill Linpro Kartlagt dato Mars 2013 4.5.1. Teknisk miljø Kartleggingen er utført på følgende miljø. Windows 2008 SQL Server 2008 4.5.2. Fremgangsmåte - Hente alarmer a) Database Trend logger data til deres eget oppsett av MSSQL database. De har ikke fått til å bruke fellesdatabasen. Dette viser at Rogaland Elektro ikke sitter på gode databasekunnskaper, Heldigvis så er det en triviell sak å hente ut alarmer med følgende spørring: SELECT TOP 10 * FROM i96x.dbo.alarms ORDER BY originalalarmtime DESC Dette betyr Rogaland benytter seg av et oppsett utviklet av deres underleverandør, og der finnes gode databasekunnskaper. Men en ulempe er at det ikke er satt prioriteringsverdi, for den er alltid -1. Dette gjør det umulig å filtrere for å skille normale alarmer fra kritiske. Vi har forstått det slik at Stavanger kommune har mulighet til å sette disse verdiene selv, slik at alarmer vil kunne få meningsfylte verdier her. Side 15 av 30

Eksempel på utlisting av alarmer: 4.5.3. Fremgangsmåte Kalenderstyring Ikke mulig per dags dato. 4.5.4. Konklusjon Uttrekk av alarmer fra databasen er trivielt. Ellers er dokumentasjon på utstyr og muligheter for integrasjoner en ting Trend ser på som viktig for sine kunder. Og det virker som om Trend satser på åpne standarder og muligheter for leverandøruavhengighet i løsninger som blir levert fra dem. Side 16 av 30

Fordeler: God databasestruktur. Fokus på åpne standarder og tredjeparts integrasjoner hos underleverandøren Trend. Hurtig og presise svar om bygg og automasjon. Ulemper: Ekstrakostnad for å ta i bruk BACnet, selv til dagens IQ3 og IQ4 kontrollere. Dårlig databasekompetanse hos Rogaland Elektro. 4.6. Schneider Electric TAC Vista Kartleggingsansv. Epost Olav Grønås Gjerde olav.gjerde@redpill-linpro.com Telefon +47 969 01 108 Firma Redpill Linpro Kartlagt dato Mars 2013 4.6.1. Teknisk miljø Kartleggingen er utført på følgende miljø. Windows 2008 SQL Server 2008 4.6.2. Fremgangsmåte - Hente alarmer Data ligger i databasen taclogdata og i tabellene Event, som må joines med AlarmEvent. Databasen er strukturmessig veldig bra. Den er veldig oversiktlig og har konsistent beskrivelse av felter. Alarmer kan hentes ut med følgende spørring: SELECT TOP 10 e.[eventid],e.[eventtype],e.[eventdatetime],e.[username],e.[objecttype],e.[freetext],o.[objectid],a.[priority],e.[objectkey] FROM [taclogdata].[dbo].[event] e Side 17 av 30

INNER JOIN [taclogdata].[dbo].[alarmevent] a ON e.eventid = a.eventid INNER JOIN [taclogdata].[dbo].[objectpathname] o ON e.objectpathnameid = o.objectpathnameid ORDER BY EventDatetime DESC Eksempel på utlisting av alarmer: Schneider bruker OPC protokollen for kommunikasjon til styringsenhetene. De har støtte for OPC DA og utvikler støtte for OPC UA som kan tas i bruk i dagens eksisterende anlegg i Stavanger kommune. For å kunne ta OPC i bruk så må Schneider sette opp en OPC server. Det bør kunne være nok til å kunne ta i bruk OpenOPC rammeverket og sette opp en gateway/proxy, men dette er nok ikke en løsning Schneider støtter og det spørs om de vil ha en supportavtale med Stavanger Kommune ved skriving av data. Side 18 av 30

4.6.3. Fremgangsmåte Kalenderstyring Bare mulig ved installasjon og oppsett av ekstra OPC servere. Dette vil være svært tidkrevende og kostbart. 4.6.4. Konklusjon Å lese alarmer fra databasen er trivielt. Databasen har god datastruktur og er oversiktlig. Schneider kan sette opp OPC for å få til toveis-kommunikasjon for kalenderstyring, men dette koster. For å sette opp en OPC server og en OPC gateway, samt konfigurering og oppsett av alle enheter. Så regner Schneider med, som et grovt estimat, at det vil koste mellom 200 000 og 250 000 kr for Stavanger kommune. Dette er minimalt med lisensutgifter, og består hovedsakelig (85%) av konsulentarbeid. Pris for serviceavtale må reforhandles, og vil naturligvis gå noe opp. Schneider er veldig opptatt av at ting skal fungere og de ønsker å være med i denne prosessen for å kunne ha oversikt over hva en kan gjøre og hva en ikke kan gjøre på deres systemer. Fordeler: Hurtig og presise svar bygg og automasjon. Hurtig og presise svar IT. God database. Ulemper: Lager nytt API basert på OPC UA, som er en svært kompleks standard. OPC oppsett og konfigurasjon er dyrt. 4.7. Siemens Kartleggingsansv. Epost Olav Grønås Gjerde olav.gjerde@redpill-linpro.com Telefon +47 969 01 108 Firma Redpill Linpro Kartlagt dato Mars 2013 4.7.1. Teknisk miljø Kartleggingen er utført på følgende miljø. Windows 2008 SQL Server 2008 4.7.2. Fremgangsmåte - Hente alarmer Siemens har sitt eget program med dokumentasjon for å kommunisere med utstyr plassert i Side 19 av 30

anlegg. Vi ser ikke det som mulig å hente ut alarmer med dette verktøyet. Dokumentasjonen mangler denne informasjonen. Databasen derimot er godt strukturert og oversiktlig. For å kunne lese data, og alarmer spesifikt, kan ordnes ved å lese rett fra databasen. Databasen DIV23!PRJ=Stavanger_kommune!DB=ISHTALM og tabellen Alarm er der en leser alarmer fra. Denne tabellen inneholder hva slags element som feiler og tidspunktet alarmen ble registrert. En finner også informasjon om kvittering og hvem som har kvittert. AlarmEntryID er unik, og vil aldri endres så lenge alarmen er lik. Når alarmen blir fikset så vil alarmen automatisk slette seg selv fra den tabellen. Så det er ikke historikk på alarmer der. Historikk finner en i databasen DIV23!PRJ=Stavanger_kommune!DB=ISHTLOG og tabellen LogEntry om man joiner deviceid og objectid med det som står i alarmtabellen. Eksempel på databasespørring: SELECT [AlarmEntryId],[SiteId],[DeviceId],[ObjectId],[TechnicalDesignation],[ObjectDescription],[MessageText],[AlarmCount],[ToAlarmTimeDI],[LastChangeTimeDI],[FireAlarmCategory] FROM [DIV23!PRJ=Stavanger_kommune!DB=ISHTALM].[dbo].[Alarm] ORDER BY AlarmEntryId Side 20 av 30

Eksempel på alarmer: 4.7.3. Fremgangsmåte Kalenderstyring Ikke mulig. 4.7.4. Konklusjon Å lese alarmer fra databasen er trivielt. Databasen har god datastruktur for å kunne lage litt mer komplekse måter å hente ut data og alarmer. Det er tenkelig at en kunne utviklet kalenderstyring og annen toveis kommunikasjon gjennom deres toppsystem Desigo Insight, men dokumentasjonen her er svært dårlig, og dette systemet er forbundet med høye kostnader. Fordeler: God database Ulemper: Desigo Insight er veldig dyrt. Dokumentasjon til Desigo Insight kan bli mye bedre. Side 21 av 30

4.8. Symmetry Kartleggingsansv. Epost Olav Grønås Gjerde olav.gjerde@redpill-linpro.com Telefon +47 969 01 108 Firma Redpill Linpro Kartlagt dato Mars 2013 4.8.1. Teknisk miljø Kartleggingen er utført på følgende miljø. Windows 2008 SQL Server 2008 4.8.2. Fremgangsmåte - Hente alarmer Symmetri leverer et SOAP basert web service API. Derimot var det ingen funksjonalitet for å hente alarmer eller opprette kalenderbasert styring. Derimot så er det enkelt å lese alarmer fra databasen. SELECT [AlarmHotListTableID], [WhereName], [ChainName], [AlarmConditionName], [DateTimeOfFirstAlarm], [AlarmPriority] FROM [multimaxtxn].[dbo].[alarmhotlisttable] where [AlarmPriority] <= 20 Og for å få alarmer på noen andre brukere enn administratorer som tester SELECT [OperatorActivityTableID], [UserName], [DateTimeOfAction], [MachineName], [UserActivity] FROM [multimaxtxn].[dbo].[operatoractivitytable] WHERE [UserName]!= 'mikketeus' and [UserName]!= 'Odd' AND [UserActivity] = 'Logged on' Side 22 av 30

Eksempel på utlisting av alarmer: 4.8.3. Fremgangsmåte Kalenderstyring Ikke mulig. 4.8.4. Konklusjon Uttrekk fra database er trivielt. Databasen er og godt strukturert og oversiktlig. Fordeler: God database. Ulemper: ingen oppdaget Side 23 av 30

4.9. EOS Kartleggingsansv. Epost Olav Grønås Gjerde olav.gjerde@redpill-linpro.com Telefon +47 969 01 108 Firma Redpill Linpro Kartlagt dato Mars 2013 4.9.1. Teknisk miljø Kartleggingen er utført på følgende miljø. Linux MySQL 4.9.2. Fremgangsmåte - Hente alarmer Dette er en moderne Java applikasjon som har et REST API Dessverre så har ikke dette API-et funksjonaliteten vi trenger for å hente ut alarmer/avvik. De tilbyr en egen cloud tjeneste som heter Notify som også har et REST API for å hente ut data, men dette betyr at data blir send til Gurusoft/Oneco sin database. Databasen kjører på admsys135, databasenavnet er Teksal og har brukernavnet Gurusoft11. For å hente uttrekk av avvik/overskridelser så vil følgende spørring være et godt utgangspunkt: SELECT TOP 20 log.[id],log.[time],tag.[title],log.[value],log.[threshold_value],log.[code],log.[threshold_text],log.[description],log.[priority],log.[threshold_status],log.[status] FROM [Teksal].[dbo].[gsr_log_exceeding] log INNER JOIN [Teksal].[dbo].[gsr_tag] tag ON log.tag_id = tag.id ORDER BY time DESC Side 24 av 30

Eksempel på utlisting av alarrmer: 4.9.3. Fremgangsmåte Kalenderstyring Analyse verktøy hvor kalenderstyring ikke er relevant. 4.9.4. Konklusjon Å hente avvik fra databasen er klart det enkleste alternativet. REST API-et som er av den moderne typen, har et forbedringspotensiale når det kommer til dokumentasjon. Idag blir det noe vanskelig for en tekniker å kunne ta REST API-et i bruk da dokumentasjonen er tynn. Fordeler: God database. Ulemper: Dokumentasjon til REST Aperiet kunne vært bedre. Funksjonalitet til å kunne hente ut avvik med API-et eksisterer ikke. Side 25 av 30

5. Video 5.1. BlueCherry Kartleggingsansv. Epost Olav Grønås Gjerde olav.gjerde@redpill-linpro.com Telefon +47 969 01 108 Firma Redpill Linpro Kartlagt dato Mars 2013 5.1.1. Teknisk miljø Kartleggingen er utført på følgende miljø. Linux MySQL 5.1.2. Fremgangsmåte - Hente alarmer BlueCherry er et kameraovervåkningssystem som kjører idag på Linux, det bruker MySQL og har noen tabeller som logger Events/alarmer. Men vi fikk ikke tilgang til denne databasen grunnet mangel av passord. Derimot så viste Michael frem databasen og strukturen der er ryddig og bra. Michael har også laget sitt eget Shell skript som fant kameraer som var nede og ikke svarte. Dette scriptet kan brukes til å sende alarmer videre til alarmportalen. Vi mener nok at dette kan kanskje være en like bra løsning som å lese i fra databasen. 5.1.3. Fremgangsmåte Kalenderstyring Kalenderstyring er ikke relevant for komponenten 5.1.4. Konklusjon Michael, har full kontroll her og god dialog med utviklerne. Uttrekk av data er ingen problem, og Michael har et eget skript for å finne kameraer som ikke skulle fungere. Fordeler: God dialog med utviklerteamet Bra database Ulemper: Bare Michael som sitter på kompetansen? Side 26 av 30

6. FDV Planene for alarmportalen inneholder et ønske om å synkronisere strukturen i bygningsmassen med den struktur som allerede er definert i kommunens FDV-system. For å unngå dobbel administrasjon vil det da være en stor fordel om en kan integrere portalen mot FDV-systemet, slik at endringer kan fanges opp automatisk. I den forbindelse ble det gjort et forsøk på å gjennomføre en tilsvarende teknisk evaluering av FDV-systemet som en her har gjort for andre systemer. Det forsøket strandet på administrative problemer omkring det å skaffe tilgang til FDV-systemet på nødvendig teknisk nivå. I etterkant har en konstatert at det rutinemessig eksporteres en fil fra FDV-systemet som inneholder denne strukturen. Det ble opplyst at dette i dag skjer en gang i uken, men at frekvensen kan økes inntil en gang i timen om nødvendig. Det er da sannsynlig at denne filen kan importeres til portalen for oppdatering av strukturen der, og at dette kan skje med en tilfredsstillende frekvens. 7. Framtidsmuligheter 7.1. Visjonen Teknologien som finnes i dag vil gjøre det mulig å bygge et system hvor en gjennom toveis kommunikasjon kan oppnå svært detaljert overvåking og styring av en rekke funksjoner i bygg. Og dette vil kunne skje med stor grad av automatisering. Det viser seg imidlertid at dette er vanskelig gjennomførbart i praksis i dag. Hovedutfordringen består i at de ulike utstyrsleverandørene dels har svak IT-kompetanse, og dels har lagt seg på en strategi der de søker å binde kunden opp til egne løsninger for alle bygg. En brukerorganisasjon som ønsker å være uavhengig av leverandører, bør søke en løsning basert på åpne standarder for utveksling av informasjon mellom systemer. I dette dokumentet har vi til nå omtalt tre slike BACnet, OPC og Web Services. Web Services er en generell teknologi. Den definerer hvordan meldinger utveksles mellom systemer, men den sier ikke noe om meldingenes innhold, og tolking av dette. Det er opp til leverandøren å definere dette. BACnet og OPC er av en helt annen karakter. Disse er laget spesielt for automasjon og kontroll, og omfatter også spesifikasjoner for hva meldinger skal inneholde og hva innholdet skal bety. Det finnes også et antall alternativer se http://en.wikipedia.org/wiki/list_of_automation_protocols#building_automation_protocols. Disse protokollene blir derved bedre egnet for det formålet vi her har, enn de mer generelle Web Services. Så er det slik at disse protokollene er relativt komplekse. Det betyr at det kreves en god del kompetanse for å arbeide effektivt med dem. Av den grunn vil det sannsynligvis være hensiktsmessig å velge seg en av dem som en vil satse på. Med forbehold om vår begrensede innsikt i det fagfeltet som skal betjenes, virker det som om BACnet framstår som den beste kandidaten. OPC er egentlig konstruert for et litt annet formål enn byggautomasjon. Den må også anses som noe mindre åpen enn BACnet, siden den er Side 27 av 30

bygget på proprietær teknologi fra Microsoft. BACnet ser ut til å ha stor utbredelse blant viktige aktører i markedet, og ser ut til å være styrt av organer som sikrer at de ulike leverandørene implementerer spesifikasjonene på en konsistent måte. Vi ser altså for oss et system der SD-anlegg og andre systemer installert i bygg, støtter BACnet for kommunikasjon inn til en sentral overvåkings- og styringsfunksjon. Med et slikt system vil en kunne oppnå funksjonalitet som Kalenderstyring av temperatur Kalenderstyring av adgang, med muligheter for avvik ved behov Styring av adgang gjennom kommunens sentrale brukerdatabase Mer spesifikk og tilpasset varsling enn dagens alarmer tilbyr Automatiserte rutiner for varsling ved unormale hendelser (brann, flom...) Automatiserte rutiner for tiltak ved slike hendelser (stenge vann, stenge strøm, hindre adgang, etc..) Stenge dører ved innbruddsalarm.. 7.2. Eksisterende systemer Hvordan vil det utstyr som i dag er installert i kommunens bygg, kunne fungere i et slikt scenario? Her følger en gjennomgang av de funn som er gjort gjennom arbeidet med denne rapporten. 7.2.1. EM-systemer Disse løsningene er ovenfor presentert som vanskelige å arbeide med. Vårt syn på framtidsmuligheter vil også gjenspeile dette. Leverandøren hevder at de systemer som er levert til Stavanger kommune, har en OPC server inkludert, og at denne bare må aktiveres. Dersom en velger å gå for BACnet som eneste teknikk, vil altså disse systemene ikke kunne tilpasses. Om en velger OPC, eller begge, vil EM-systemers produkter teoretisk kunne være med. Det gjenstår likevel å verifisere at OPC faktisk fungerer tilfredsstillende, og å få oversikt over de kostnader dette vil medføre. 7.2.2. GK Her leveres systemer basert på plattformen Niagara, som er en avansert utviklingsplattform for denne type systemer. Kommunen har i dag installert to varianter Niagara R2 og Niagara AX. AX er den moderne varianten, og denne støtter et stort antall protokoller, blant annet både BACnet og OPC. Det vil sannsynligvis være mulig å bygge en komplett framtidig løsning med Niagara rammeverket. Det vil imidlertid kreve betydelige investeringer i kompetanse, og vil gi en løsning som er mindre åpen enn andre alternativer, ikke minst på grunn av at tilgang til dokumentasjon og utviklingsverktøy vil være mer begrenset. Systemene basert på Niagara AX vil sannsynligvis kunne integreres inn i en leverandøruavhengig løsning, men også her vil det kreves vesentlig kompetanseheving, alternativt bistand fra leverandøren. Det skal visstnok være mulig å kjøpe tilleggsutstyr som lar systemer laget for kommunikasjon med Niagara AX også fungere mot Niagara R2. I så fall, og om det kan skje innenfor akseptable økonomiske rammer, vil også disse kunne inkluderes i en framtidig løsning. Side 28 av 30

7.2.3. Johnson Controls I henhold til dokumentasjonen (se link i punkt 4.3) støtter disse systemene både BACnet og OPC. Dette er ikke inkludert i det som er levert til Stavanger kommune hittil. 7.2.4. Kverneland Elektriske Her er levert system med aktiv støtte for OPC. Denne er testet og funnet fungerende. Støtte for BACnet kan ikke leveres. Den vesentligste ulempen her, er leverandørens manglende IT-kompetanse. 7.2.5. Rogaland Elektro Nyere systemer fra Trend (IQ3, IQ4) støtter BACnet. I leveransene til Stavanger kommune er dette slått av, men kan enkelt slås på mot en mindre tilleggsavgift (antydet omkring 3 500 kroner). Mot eldre Trend systemer kan en benytte OPC. Trend preges av god kvalitet på dokumentasjon, og det virker som om en aktivt støtter opp om åpne standarder. 7.2.6. Schneider Kan levere støtte for OPC, men til en relativt høy kostnad (se punkt 4.6.4), og vil også kunne levere BACnet. 7.2.7. Siemens Siemens' Desigo produkt skal ifølge dokumentasjonen støtte BACnet, og benytte dette i egen kommunikasjon. To store ulemper her er at dokumentasjonen er vanskelig å benytte, og et relativt høyt kostnadsnivå. 7.2.8. Symmetry Leverer et Web Services API, men dette har ikke funksjonalitet for slike ting som for eksempel å lage kalenderstyring. Eventuell støtte for BACnet eller OPC er ukjent, så en må derfor ta utgangspunkt i at det ikke finnes. 7.3. Produkter kjøpe, lage, eller...? Det finnes et antall programvareprodukter på markedet som tilsynelatende kan danne grunnlag for å virkeliggjøre visjonen. Disse kalles med en fellesbetegnelse for SCADA (Supervisory Control And Data Acqisition) systemer. Mange av dem har mest fokus mot prosesskontroll, og til dels energiforsyning. Men byggautomasjon er absolutt også representert. Disse produktene støtter som regel en rekke protokoller, hvor nok en gang BACnet og OPC ser ut til å være de dominerende. De inneholder funksjonalitet for overvåking, rapportering og styring. I hvilken grad og på hvilken måte de støtter de funksjoner en vil ønske seg i en norsk kommune, vil helt sikkert variere betydelig. 7.3.1. Proprietære produkter Side 29 av 30

Det finnes en rekke leverandører av proprietære SCADA systemer, med varierende egenskaper. En rask Google søk viser for eksempel: Schneider Emerson Copa Data Realflex GE Advantech PowerLogic Fordelen med en slik løsning er at en får programvare med mye funksjonalitet ferdig utviklet. Erfaringsmessig vil det deriblant være en god del en ikke har behov for... og så vil det være enkelte ting en ikke hadde tenkt på selv men som viser seg nyttig. Men «ferdig utviklet» er som regel et noe misvisende uttrykk. En må i de fleste tilfeller regne med å bruke betydelige ressurser i konfigurering slik at programmet fungerer i kommunens spesifikke miljø, og på en måte som passer best mulig inn i organisasjonens arbeidsmønster. Blant ulempene er at det blir vanskelig, eller til dels umulig, å gjøre tilpasninger til egen situasjon. En blir avhengig av leverandørens valg når det gjelder innhold og frekvens i endringer/oppdateringer. En annen ulempe vil ofte være kostnad. Slike produkter vil normalt være belagt med betydelige lisenskostnader, og også løpende vedlikehold. I tillegg skal en slett ikke undervurdere ressursforbruket til installasjon/konfigurering. 7.3.2. Åpen kildekode Det finnes også et antall prosjekter/produkter for SCADA basert på åpen kildekode. Et utvalg kan finnes her: http://sourceforge.net/directory/science-engineering/scada/ En må forvente at disse vil vise stor variasjon i funksjonalitet, og også i grad av ferdigstillelse. Det betyr at en må forvente å måtte gjøre vesentlig mer arbeid med tilpasninger enn for den andre gruppen. Så installasjon/implementering vil koste mer, men så slipper en jo lisenskostnader... Den store fordelen med disse produktene er at en kan bruke et eller flere av dem som basis for egen utvikling/tilpasning. Det betyr at samtidig som en blir med i et miljø av likesinnede (de andre som har tatt i bruk samme produkt), har en full frihet til å skreddersy funksjonalitet etter eget behov. En blir «herre i eget hus», uten å være avhengig av / bundet til en spesifikk leverandør. 7.4. Interkommunalt samarbeid En vesentlig faktor i denne sammenheng er at uansett strategi, så vil innføring av funksjonalitet utover en ren alarmportal bety et vesentlig løft, både økonomisk og i bruk av interne ressurser. Dersom en velger å utvikle en løsning selv, enten med utgangspunkt i et åpen kildekode prosjekt eller fra «blanke ark», står en fritt til å involvere andre kommuner i et samarbeid om en felles plattform. Side 30 av 30