BACnet vs. Modbus vs. OPC UA: en guide til bygningsintegratorer

Vælger du den forkerte protokol på dag ét i en BMS-integration, betaler du stadig for det fem år senere, oftest i form af en gatewaykasse ingen husker at have konfigureret. Får du det rigtigt, nævnes den samme integration næsten ikke i overdragelsesnoterne. Indsatsen er så skæv, og alligevel bliver beslutningen sjældent taget med vilje. De fleste bygninger arver bare, hvilken protokol den sidste kontrolentreprenør leverede.

Det er ikke nødvendigvis forkert. BACnet, Modbus og OPC UA har alle stadig et job at udføre, og de fleste bygningsbestande kører mere end en af dem side om side. Hvad der betyder noget for alle, der forsøger at få sensor- og målerdata ind i et analyselag, er at vide hvilken protokol der gør hvad, hvor hver enkelt løber tør, og hvad det betyder for gatewayen eller agenten der sidder oven på den. Denne guide dækker alle tre, plus oBIX, den nyere tilkomst de fleste integratorer kun har mødt en eller to gange.

BACnet: standarden, med to varianter

BACnet (Building Automation and Control Network) er den protokol de fleste moderne BMS taler indfødt, og med god grund. Det er en ANSI/ASHRAE- og ISO-standard bygget specifikt til dette job, og den definerer, hvad et datapunkt betyder, ikke bare hvordan byte'ne bevæger sig: en "værdi" der ankommer via BACnet, bærer allerede en objekttype, en temperatur, et sætpunkt, en alarmstatus. Det semantiske lag er præcis det en generisk industriel protokol ikke giver dig, og det er hvorfor BACnet blev bygningsautomationens lingua franca frem for en generel feltbus tilpasset opgaven.

Hvor det bliver rodet, er opdelingen mellem BACnet/IP og BACnet MS/TP. IP er den moderne, Ethernet-native version; MS/TP er den ældre serielle variant, der stadig kører på mange feltniveaustyringsnetværk, især alt installeret før en bygnings sidste større renovering. De to taler ikke direkte med hinanden. Et MS/TP-segment kræver en router eller gateway for at nå et IP-netværk, og på ældre bygninger finder du flere sådanne broer stablet i et skab, hver en fejlpunkt ingen har revideret i årevis. Objektbenævnelse er teknisk standardiseret, men leverandører tolker specifikationen med nok lokal variation, at en kontrolingeniør der bevæger sig mellem en Siemens Desigo-bestand og en Schneider EcoStruxure-bestand stadig vil ramme friktion, når punkter skal mappes rent.

For alle der bygger på et BMS, er den praktiske konklusion, at BACnet-dækning alene ikke garanterer en nem aflæsning. Bekræft om netværket du integrerer med kører IP eller MS/TP, og budgetter for gatewayen hvis det er det sidste. Fulde detaljer om protokollen, inklusive hvordan objektmodellen fungerer, findes på vores BACnet-ordbogsside.

Modbus: gammel, simpel, og stadig på hver måler

Modbus går forud for BACnet med mere end et årti. Modicon introducerede det i 1979, og det overlever i dag af samme grund som meget gammel, kedelig teknologi overlever: det er simpelt, det er royaltyfrit, og hver leverandør af hver energimåler, undermåler og ældre anlægsstyring ved allerede, hvordan man implementerer det. Der er to varianter i aktiv brug. Modbus RTU er den oprindelige serielle form, der kører over RS-485 eller RS-232 med kompakte binære rammer. Modbus TCP indpakker den samme datamodel i Ethernet og er den nemmeste at integrere på et moderne netværk. En seriel RTU-måler når et IP-netværk gennem en gateway, samme mønster som BACnet MS/TP.

Hagen ved Modbus er, at det bærer værdier, ikke betydning. En klient forespørger en enhed om indholdet af et nummereret register, og det er det: ingen selvbeskrivelse, ingen indbyggede enheder, ingen indikation af om register 40012 er en kWh-aflæsning eller en ventilposition. Du skal have enhedens registerkort for at vide, hvad du læser, og det kort findes i en PDF fra målerleverandøren, ikke i selve protokollen. Får du kortet forkert, indlæser du glædeligt skrald der ligner data. Der er heller ingen indbygget autentificering eller kryptering, hvilket sjældent er et problem på et isoleret målernetværk, men værd at vide før du eksponerer et for noget bredere.

I praksis eksisterer Modbus og BACnet konstant side om side: BACnet kører BMS'et, Modbus fodrer de målere BMS'et ikke indfødt læser. Den blanding er præcis det råmateriale energistyringssoftware skal bruge for at omdanne aflæsninger til beslutninger, forudsat at hvert register først mappes til noget fysisk. Mere om selve protokollen findes på vores Modbus-ordbogsside.

OPC UA: moderne, sikker og semantisk

OPC UA (Unified Architecture) er den nyeste af de tre mainstream-protokoller og den der er bygget med den mest bevidste ingeniørkunst. Den afløste den ældre OPC Classic-standard og blev designet fra grunden til at være platformsuafhængig, serviceorienteret og sikker: autentificering, kryptering og adgangskontrol er del af specifikationen, ikke tilføjet bagefter som de skulle være for Modbus. Den definerer også en genuint rig objektmodel, tættere på BACnets tilgang end Modbus, hvilket gør integrationen betydeligt mindre skrøbelig, når den er sat op.

OPC UA's hjemmebane er fremstilling og procesindustrier, hvor det er blevet tæt på standard for maskine-til-maskine dataudveksling. I bygninger dukker det op, hvor BMS'et er blevet moderniseret for nylig, eller hvor bygnings- og industrielle data konvergerer, for eksempel et datacenter, en fabrik med en tilknyttet kontorblok, eller et sted hvor OT- og IT-teams bliver bedt om at dele et datalag. Den konvergens er en stor del af, hvorfor OPC UA betyder noget for bygningsintegration, selv om det ikke startede der. Abonnementer på værdiændringshændelser fungerer nativt, så du får push-opdateringer i stedet for konstant polling, og sikkerhedsprofilen der er i brug på et givet sted, bestemmer præcis hvordan autentificering håndteres ved forbindelsestidspunktet. Det fulde billede findes på vores OPC UA-ordbogsside.

oBIX: den nyere, mest på Niagara

oBIX (Open Building Information Exchange) er værd et afsnit for sig selv, ikke fordi den erstatter noget, men fordi den fortsat dukker op i specifikke hjørner af bygningsstakken, som de andre tre protokoller ikke dækker så rent. Det er en OASIS-standard, først udgivet i 2006, og den tager en anden teknisk tilgang: XML over HTTP-webservices frem for en specialbygget bygningsprotokol eller en industriel feltbus. I praksis er stedet du møder oBIX en Tridium Niagara-station. Niagara eksponerer sine punkter via oBIX (og ofte også BACnet), og enhver Honeywell WEBs-installation eller tredjeparts-JACE der kører på Niagara-frameworket vil typisk tilbyde samme mulighed.

Vi tilføjede oBIX-support til FrostLogic Edge Agent, fordi vi konstant stødte på præcis denne situation: en blandet bestand, hvor de fleste bygninger taler BACnet rent, men en eller to kører en Niagara-supervisor, der er nemmere at læse over oBIX. Edge Agent taler nu fire protokoller, BACnet, Modbus, OPC UA og oBIX, og dens første live oBIX-forbindelse kørte mod et Tridium Niagara BMS. Det er ikke et casestudie, bare hvordan integrationsmatricen ser ud i en normal uge med onboarding af bygninger. Hvis du kører en Niagara-bestand specifikt, dækker vores Honeywell Niagara-integrationer-side forbindelsesdetaljerne, og mekanikken bag oBIX selv findes på vores oBIX-ordbogsside.

Sammenligningen i overblik

Hvad dette betyder for at få data ind i et analyselag

Intet af dette ændrer, hvad et analyselag faktisk har brug for: læseadgang til hvad der allerede kører, uden at røre kontrolsystemet. Et bygningsstyringssystem, der kører BACnet til sine ventilationsanlæg, Modbus til sine målere og muligvis OPC UA eller oBIX et sted i mixet, er ikke et integrationsproblem, der løses én gang. Det er den normale form for en reel bygningsbestand, og indtagslaget skal håndtere det hele på én gang, ikke tvinge et sted til at standardisere på én protokol, før det kan læses.

FrostLogic Edge Agent er bygget omkring den realitet. Den sidder på BMS-pc'en eller -serveren, læser BACnet, Modbus, OPC UA og oBIX skrivebeskyttet, og sender dataene til FrostLogic Explore, som omdanner dem til en rangeret beslutningskø i stedet for endnu et dashboard. Leverandørspecifik opsætning, hvad enten det er et Siemens Desigo BACnet-netværk eller en Schneider EcoStruxure-bestand med sine egne særheder, er dokumenteret på vores integrationssider frem for begravet i en generisk protokolspecifikation. Hvad end dit BMS taler, læser vi det. Se understøttede integrationer.

Ofte stillede spørgsmål

Hvilken protokol skal jeg bruge til en ny BMS-integration? Brug hvad udstyret allerede taler. BACnet er det sikre standardvalg for et moderne BMS og det, man skal specificere, hvis man skriver en ny kontrolkontrakt. Tvang ikke et protokolskifte alene for standardiseringens skyld; en fungerende Modbus-måler eller et OPC UA-feed fra et procesystem behøver ikke udskiftning.

Kan BACnet og Modbus eksistere side om side i samme bygning? Ja, og det er det mest almindelige setup i praksis. BACnet kører typisk BMS'et og dets controllere, mens Modbus fodrer energimålere, undermålere og ældre anlæg der aldrig blev flyttet op til BACnet. Ingen af protokollerne behøver forsvinde, for at den anden kan fungere.

Har FrostLogic Explore brug for en gateway til OPC UA? Nej. Explore læser OPC UA nativt, inklusive abonnementer på værdiændringshændelser, med autentificering og kryptering håndteret efter den sikkerhedsprofil stedet allerede bruger. Gateways kommer i spil for BACnet MS/TP og Modbus RTU, de to serielle varianter, ikke for OPC UA.

Hvad er oBIX, og har jeg brug for det? oBIX er en webservicestandard til at læse bygningsdata over HTTP, oftest mødt på en Tridium Niagara-station. Du har brug for det specifikt, hvis en del af din bestand kører Niagara eller et Niagara-baseret produkt som Honeywell WEBs. Hvis dine bygninger kører et standard BACnet-BMS med Modbus-målere, kommer oBIX simpelthen ikke på tale.