BACnet vs Modbus vs OPC UA (plus LonWorks og KNX): en guide for bygningsintegratorer

Photo by Troy Bridges on Unsplash.

Vælger du den forkerte protokol dag ét i en BMS-integration, betaler du stadig for det fem år senere, typisk i form af en gateway-boks, som ingen husker at have konfigureret. Får du det rigtigt, nævnes den samme integration knap i overleveringsnoterne. Indsatsen er så skæv, og alligevel træffes beslutningen sjældent bevidst. De fleste bygninger arver bare den protokol, den sidste kontrolentreprenør leverede.

Det er ikke nødvendigvis forkert. BACnet, Modbus og OPC UA har alle stadig et job at gøre, og de fleste bygningsbestande kører mere end én af dem side om side. LonWorks dukker stadig op på ældre BAS-retrofits; KNX ejer ofte rumsbelysnings- og solafskærmningsstacken i europæiske bygninger. Det, 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 løber tør for vej, og hvad det betyder for gatewayen eller agenten, der sidder ovenpå. Denne guide dækker de seks, du møder oftest, inklusive hvornår en BACnet Modbus-gateway (eller en LonWorks/KNX-bro) er det ærlige svar frem for en ombygning.

BACnet: standarden, med to varianter

BACnet (Building Automation and Control Network) er den protokol, de fleste moderne BMS taler hjemme, med god grund. Det er en ANSI/ASHRAE- og ISO-standard bygget specifikt til denne opgave, og den definerer, hvad et stykke data betyder, ikke bare hvordan bytes bevæger sig: en "værdi", der ankommer via BACnet, bærer allerede en objekttype, en temperatur, et sætpunkt, en alarmtilstand. Det semantiske lag er præcis det, en generisk industriprotokol ikke giver dig, og det er derfor BACnet blev bygningsautomationens lingua franca snarere end en generel feltbus tilpasset opgaven.

BACnet MS/TP vs BACnet/IP

Der 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 feltniveau-controllernetværk, især alt installeret før et steds seneste større opdatering. De to taler ikke direkte sammen. Et MS/TP-segment har brug for en router eller gateway for at nå et IP-netværk, og på ældre anlæg finder du flere sådanne broer stablet i et skab, hver en fejlpoint, ingen har revideret i årevis. Objektnavngivning er teknisk standardiseret, men leverandører fortolker specifikationen med nok lokal variation til, at en styretekniker, der bevæger sig mellem en Siemens Desigo-bestand og en Schneider EcoStruxure-bestand, stadig rammer friktion, når punkter skal mappes rent.

For alle, der bygger oven på et BMS, er den praktiske takeaway, at BACnet-dækning alene ikke garanterer en nem læsning. Bekræft, om netværket, du integrerer med, kører IP eller MS/TP, og budgetér for gatewayen, hvis det er det sidste. Fuld detalje om protokollen, inklusive hvordan objektmodellen virker, findes på vores BACnet-ordbogsside.

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

Modbus går forud for BACnet med mere end et årti. Modicon introducerede den i 1979, og den overlever i dag af samme grund som en masse gammel, kedelig teknologi overlever: den er enkel, den er royaltyfri, og hver leverandør af hver energimåler, undermåler og ældre anlægskontroller allerede ved, hvordan man implementerer den. 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 pakker den samme datamodel ind i Ethernet og er den nemmere at integrere på et moderne netværk. En seriel RTU-måler når et IP-netværk via en gateway, samme mønster som BACnet MS/TP.

Fangsten ved Modbus er, at den bærer værdier, ikke betydning. En klient poller en enhed for 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 har brug for enhedens registerkort for at vide, hvad du læser, og det kort bor i en PDF fra målerleverandøren, ikke i protokollen selv. Får du kortet forkert, indlæser du gladeligt skrald, der ser ud som data. Der er heller ingen autentificering eller kryptering indbygget, 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 læser nativt. Den blanding er præcis det råmateriale energistyringssoftware har brug for for at vende aflæsninger til beslutninger, forudsat at hvert register først mappes til noget fysisk. Mere om protokollen selv 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 bygget med den mest bevidste ingeniørkunst. Den erstattede den ældre OPC Classic-standard og blev designet fra starten til at være platformsuafhængig, serviceorienteret og sikker: autentificering, kryptering og adgangskontrol er en del af specifikationen, ikke boltet på bagefter, som de skulle være for Modbus. Den definerer også en ægte rig objektmodel, tættere på BACnet end Modbus, hvilket gør integrationen betydeligt mindre skrøbelig, når den først er sat op.

OPC UA's hjemmebane er fremstilling og procesindustri, hvor den er blevet tæt på et standardvalg til maskine-til-maskine-dataudveksling. I bygninger dukker den op, hvor BMS'et er blevet moderniseret for nylig, eller hvor bygnings- og industrielle data konvergerer, for eksempel et datacenter, en fabrik med tilhørende 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, selvom den ikke startede der. Abonnementer på værdiændringshændelser virker nativt, så du får pushede opdateringer snarere end konstant polling, og den sikkerhedsprofil, der bruges på et givet sted, afgør præcist, hvordan autentificering håndteres ved tilslutning. Det fulde billede findes på vores OPC UA-ordbogsside.

oBIX: den nyere, mest på Niagara

oBIX (Open Building Information Exchange) fortjener sit eget afsnit, ikke fordi det erstatter noget, men fordi det bliver ved med at dukke op i specifikke hjørner af bygningsstacken, som de andre tre protokoller ikke dækker lige så rent. Det er en OASIS-standard, først offentliggjort i 2006, og den tager en anden teknisk tilgang: XML over HTTP-webservices snarere end en formålsbygget bygningsprotokol eller en industriel feltbus. I praksis er stedet, du møder oBIX, en Tridium Niagara-station. Niagara eksponerer sine punkter over oBIX (og ofte BACnet også), og enhver Honeywell WEBs-installation eller tredjeparts-JACE, der kører på Niagara-frameworket, tilbyder typisk 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.

LonWorks: ældre BAS, der stadig dukker op

LonWorks (ofte brandet LonWorks / LonTalk) var 1990'ernes distribuerede kontrolstack: SNVT-typede variabler, en peer-to-peer-feltbus og en stor installeret base i ældre Schneider TAC-, Honeywell- og Siemens-bestande. Nye specifikationer vælger den sjældent; når et sted stadig har LonWorks, er det typisk en retrofit, der lader feltcontrollere på plads. Den praktiske vej ind i et moderne analyselag er næsten altid en LonWorks-til-BACnet-gateway, der præsenterer de punkter som BACnet-objekter, ikke en nativ LonWorks-driver på hvert nyt værktøj.

KNX: rumniveau i Europa, ofte ved siden af BACnet-HVAC

KNX er stærk i Europa til rumsbelysning, solafskærmning og brugergrænseflader. Bussen er decentraliseret: enheder taler sammen uden en central controller, der ejer hver kontakt. I erhvervsbygninger betyder det typisk KNX til den lejernære rumsstack og BACnet til den centrale HVAC-/BMS-rygrad. De eksisterer side om side via en BACnet-KNX-gateway snarere end at én protokol absorberer den anden. For tyske, nordiske og bredere EU-bestande, forvent den blanding; til analyse, behandl KNX som LonWorks: budgetér gatewayen, der løfter rums punkterne til BACnet (eller et andet allerede understøttet feed) i stedet for at antage, at hvert værktøj taler KNX nativt. Se også vores understøttede integrationer for, hvordan Explore forbinder, når de punkter sidder på en læsbar bus.

Sammenligningen i overblik

Gateways og protokolkonvertering

Kan BACnet kommunikere med Modbus? Ja, på samme bestand, hver uge. De bliver ikke den samme protokol. En BACnet Modbus-gateway (eller router) oversætter punkter, så hver side beholder sin egen model: Modbus-registre på målersiden, BACnet-objekter på BMS-siden. Samme mønster dækker LonWorks → BACnet og KNX → BACnet, når en rums- eller ældre feltbus skal fodre en moderne rygrad.

De konverteringer, du oftest vil idriftsætte:

• Modbus-målere og anlæg → BACnet (eller direkte ind i en analyseagent, der allerede taler Modbus)
• LonWorks ældre controllere → BACnet under BAS-modernisering
• KNX-rumsstack → BACnet-BMS for én fælles operatørvisning
• Serielle segmenter (BACnet MS/TP, Modbus RTU) → IP via fysiske gateways eller routere

Gateways er en mappings- og idriftsættelsesomkostning, og de er et fejlpoint. Budgetér dem. Lad ikke som om en blandet-protokolbestand bliver "én protokol", fordi en boks sidder i skabet. Til analyse specifikt læser FrostLogic Edge Agent BACnet, Modbus, OPC UA og oBIX nativt; LonWorks og KNX ankommer typisk, efter at en anlægsgateway præsenterer dem som BACnet (eller et andet understøttet feed). Det er den ærlige vej ind i FrostLogic Explore, ikke et krav om, at hver feltbus tales fra ende til ende.

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, oBIX, LonWorks eller KNX 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 med skriveadgang slået fra fra start, og sender dataene til FrostLogic Explore, som omdanner dem til en rangeret beslutningskø i stedet for endnu et dashboard. Skriveadgang til specifikke punkter er tilgængelig, når du giver den et omfang. 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 bruges sammen / kan BACnet kommunikere med Modbus? Ja. De eksisterer side om side på de fleste blandede bestande, og en BACnet Modbus-gateway er, hvordan de deler punkter, når hver side har brug for den andens model. BACnet kører typisk BMS'et og dets controllere; 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 jeg brug for en gateway til LonWorks eller KNX for at fodre analyse? Typisk ja. Explores Edge Agent læser BACnet, Modbus, OPC UA og oBIX nativt. LonWorks og KNX ankommer næsten altid via en anlægsgateway, der præsenterer de punkter som BACnet (eller et lignende understøttet feed). Budgetér gatewayen og dens punktmapping; antag ikke nativ LonWorks eller KNX på analysesiden.

BACnet/IP vs MS/TP: hvilken har jeg brug for en gateway til? BACnet/IP og BACnet MS/TP taler ikke direkte. MS/TP har brug for en router eller gateway for at nå et IP-netværk. Hvis dine feltcontrollere stadig sidder på MS/TP, planlæg den bro, før en IP-nativ analyseagent kan læse dem.

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.