Protokoller

01Vores udgangspunkt for valg af protokoller

Målet er ikke, at alle systemer i bygningen skal tale samme sprog.

En moderne bygning vil normalt bestå af flere forskellige kommunikationslag. Nogle protokoller egner sig godt mellem hovedsystemer og controllere, mens andre er udviklet specifikt til eksempelvis belysning, målere eller andre feltkomponenter.

Det vigtigste er, at arkitekturen er gennemskuelig, veldokumenteret og gør data tilgængelige uden unødigt at binde bygningsejeren til én leverandør.

IP-baseret kommunikation giver et godt overliggende integrationslag

Mellem hovedsystemer, controllere, gateways og dataplatforme giver IP-baseret kommunikation normalt god mening. Det gør systemerne lettere at forbinde, segmentere, overvåge og integrere med andre IT-systemer.

I klassisk bygningsautomation vil BACnet/IP ofte være et oplagt valg, fordi protokollen er udviklet til bygningsautomation og understøttes af mange forskellige leverandører.

Det betyder ikke, at al kommunikation på det tekniske netværk nødvendigvis skal være BACnet/IP. Modbus TCP, systemspecifikke API'er og andre IP-baserede grænseflader kan også være relevante.

Men hvis man efterfølgende ønsker at kunne udveksle data, eksempelvis til CX2, er det fornuftigt at kræve én bestemt protokol. CX2 anbefaler BACnet/IP. I et nyt byggeri hører det krav hjemme i udbudsmaterialet, se Anbefalinger til nye byggerier.

Serielle protokoller har en naturlig plads

Tættere på feltudstyret er serielle bussystemer meget udbredte og kan være både enkle og økonomiske. DALI-2 til belysning og Modbus RTU til controllere, VAV-spjæld, målere og andre tekniske komponenter er eksempler på protokoller, der ofte findes på dette niveau.

Det er derfor ikke et mål i sig selv at føre Ethernet helt ud til hver sensor, aktuator eller måler.

Bimålerne er et godt eksempel. Alle bygninger har et antal af dem, og nogle bruges til afregning og udgiftsfordeling, andre til driftsovervågning. M-Bus er udviklet specifikt til fjernaflæsning af målere og er derfor et naturligt valg til varme-, vand- og energimålere, især når mange målere skal samles i et egentligt målernetværk.

Båndbredden er til gengæld begrænset. Betjener den samme bus mange målere, kan opdateringsfrekvensen blive så langsom, at det går ud over anvendeligheden, hvis man har brug for højtopløselige data til driftsanalyse. Modbus RTU er meget udbredt i elmålere og findes også i varmemålere. Det kan lade sig gøre i vandmålere, men er sjældent den billigste løsning.

Serielle busser har dog nogle egenskaber, man bør være opmærksom på. Flere komponenter deler typisk samme bus og kabelføring. En fejl i kabel, terminering, adressering eller én komponent kan derfor påvirke kommunikationen med flere enheder og være mere tidskrævende at lokalisere end en fejl på en individuel IP-forbindelse.

Hvor kritisk funktionen er, bør derfor også indgå i valget af arkitektur.

02Trådløs kommunikation kan være det rigtige valg

Trådløs kommunikation er særlig interessant dér, hvor datamængderne er begrænsede, enhederne kan fungere med relativt lave opdateringshastigheder, eller hvor kabling vil være uforholdsmæssigt dyr eller vanskelig.

Det kan eksempelvis være:

• bimålere
• temperatur- og fugtfølere
• indeklimasensorer
• status- og overvågningspunkter
• sensorer i eksisterende bygninger, hvor nye kabler er vanskelige at etablere

Til måleropsamling og simple IoT-formål er både Wireless M-Bus og LoRaWAN relevante teknologier.

Wireless M-Bus

Wireless M-Bus er tæt knyttet til målerområdet og findes som kommunikationsmulighed i mange målerprodukter. Hvis opgaven primært er trådløs aflæsning af eksempelvis varme- og vandmålere, kan Wireless M-Bus derfor være et naturligt valg.

LoRaWAN

LoRaWAN er bredere orienteret mod IoT og kan anvendes til mange forskellige typer sensorer og enheder. Det kan derfor være interessant, hvis det samme trådløse netværk skal anvendes til flere formål end alene måleraflæsning.

Der kan eksempelvis være både målere, temperaturfølere, fugtfølere og andre simple sensorer på samme overliggende LoRaWAN-infrastruktur.

LoRaWAN kan desuden bruges aktivt og ikke kun til aflæsning. Et relæ på et LoRaWAN-modul kan eksempelvis afbryde strømmen til udstyr uden for brugstiden, så standbyforbruget forsvinder, uden at der skal trækkes nye kabler.

04IP-baseret kommunikation og seriel kommunikation

Forskellen mellem IP-baseret og seriel kommunikation handler ikke kun om hastighed. De to arkitekturer har forskellige egenskaber.

IP-baseret kommunikation

En IP-enhed er normalt individuelt tilsluttet bygningens datanetværk og kan identificeres og kommunikeres med gennem netværksinfrastrukturen. Det giver blandt andet mulighed for:

• individuel forbindelse til enheder og controllere
• netværkssegmentering
• central overvågning
• fleksibel kommunikation mellem systemer
• integration til servere og softwareplatforme

Til gengæld stiller det større krav til koordinering mellem automation og IT, herunder IP-adresser, VLAN, firewallregler og adgangsforhold.

At en protokol bruger IP betyder heller ikke i sig selv, at kommunikationen er sikker eller krypteret.

Seriel kommunikation

På en seriel bus deler flere enheder typisk samme fysiske kommunikationsforbindelse. Det er den mest økonomiske løsning, især tæt på feltudstyret.

Til gengæld bliver topologien mere afhængig af korrekt kabling, terminering og adressering, og fejlfinding kan være vanskeligere, når mange enheder deler den samme bus.

Derfor ser vi ikke IP og seriel kommunikation som to alternativer, hvor den ene nødvendigvis bør erstatte den anden. De kan med fordel anvendes på forskellige niveauer i samme bygning.

05Åbne og proprietære grænseflader

En åben eller standardiseret protokol gør det typisk lettere for forskellige produkter og leverandører at kommunikere sammen. Det kan give:

• mindre leverandørafhængighed
• lettere integration på tværs
• større frihed ved senere udskiftning af produkter
• bedre mulighed for at anvende data i tredjepartssystemer

Men en åben protokol er ikke automatisk ensbetydende med en god integration. Implementeringen betyder mindst lige så meget. Et BACnet-anlæg kan eksempelvis være vanskeligt at integrere, hvis objekter og metadata er mangelfuldt opbygget. Omvendt kan en leverandørspecifik API være teknisk veldokumenteret og fungere godt.

Det væsentlige spørgsmål er derfor ikke kun, om protokollen er åben.

Har bygningsejeren stabil og dokumenteret adgang til sine data, også hvis leverandøren senere skiftes?

Lokal dataudveksling er som udgangspunkt attraktiv, fordi den reducerer afhængigheden af eksterne tjenester. Cloudbaserede integrationer kan være nødvendige, hvor systemerne ikke tilbyder lokal udveksling.

06Kryptering og sikkerhed

Mange protokoller i bygningsautomation er udviklet på et tidspunkt, hvor det tekniske netværk blev betragtet som et lukket miljø. De har derfor ikke nødvendigvis indbygget kryptering eller moderne autentifikation.

Nyere teknologier kan i højere grad understøtte krypteret kommunikation, men sikkerheden bør ikke vurderes ud fra protokollen alene. Den samlede sikkerhed afhænger også af:

• netværkssegmentering
• firewallregler
• adgangskontrol
• håndtering af fjernadgang
• opdatering af enheder og software
• dokumentation af forbindelser
• adskillelse mellem databehandling og kritisk bygningsautomation

En krypteret protokol kan være en fordel, men den erstatter ikke en gennemtænkt netværksarkitektur.

Hvordan den arkitektur ser ud i praksis, står i Teknisk netværk og IT-sikkerhed og data.