BACnet vs Modbus vs OPC UA (plus LonWorks och KNX): en guide för fastighetsintegratörer

Photo by Troy Bridges on Unsplash.

Väljer du fel protokoll dag ett i en BMS-integration betalar du fortfarande för det fem år senare, oftast i form av en gatewaybox som ingen minns att de konfigurerade. Får du rätt nämns samma integration knappt i överlämningsanteckningarna. Insatserna är så skeva, och ändå görs beslutet sällan medvetet. De flesta fastigheter ärver bara vilket protokoll den senaste kontrollentreprenören levererade.

Det är inte nödvändigtvis fel. BACnet, Modbus och OPC UA har alla fortfarande ett jobb att göra, och de flesta fastighetsbestånd kör mer än en av dem sida vid sida. LonWorks dyker fortfarande upp i äldre BAS-retrofitter; KNX äger ofta rumsbelysning och solskydd i europeiska byggnader. Det som spelar roll för alla som försöker få sensor- och mätardata in i ett analyslager är att veta vilket protokoll som gör vad, var vardera tar slut, och vad det betyder för gatewayen eller agenten som sitter ovanpå det. Denna guide täcker de sex du möter oftast, inklusive när en BACnet Modbus-gateway (eller en LonWorks/KNX-brygga) är det ärliga svaret snarare än en ombyggnad.

BACnet: standarden, med två varianter

BACnet (Building Automation and Control Network) är protokollet de flesta moderna BMS talar hemma, med god anledning. Det är en ANSI/ASHRAE- och ISO-standard byggd specifikt för denna uppgift, och den definierar vad en datapunkt betyder, inte bara hur bytesen rör sig: ett "värde" som anländer via BACnet bär redan en objekttyp, en temperatur, ett börvärde, ett larmläge. Det semantiska lagret är exakt det ett generiskt industriprotokoll inte ger dig, och det är varför BACnet blev fastighetsautomationens lingua franca snarare än en generell fältbuss anpassad för uppgiften.

BACnet MS/TP vs BACnet/IP

Där det blir rörigt är uppdelningen mellan BACnet/IP och BACnet MS/TP. IP är den moderna, Ethernet-baserade versionen; MS/TP är den äldre seriella varianten som fortfarande körs på många fältnivå-styrenhetsnät, särskilt allt som installerades före fastighetens senaste stora uppfräschning. De två talar inte med varandra direkt. Ett MS/TP-segment behöver en router eller gateway för att nå ett IP-nät, och på äldre anläggningar hittar du flera sådana bryggor staplade i ett skåp, var och en en felpunkt som ingen granskat på åratal. Objektnamngivning är tekniskt standardiserad, men leverantörer tolkar specifikationen med tillräckligt lokal variation att en styrsystemingenjör som rör sig mellan ett Siemens Desigo-bestånd och ett Schneider EcoStruxure-bestånd fortfarande får friktion när punkter ska mappas rent.

För alla som bygger ovanpå ett BMS är den praktiska lärdomen att BACnet-täckning ensam inte garanterar en enkel läsning. Bekräfta om nätet du integrerar mot kör IP eller MS/TP, och budgetera för gatewayen om det är det senare. Fullständiga detaljer om protokollet, inklusive hur objektmodellen fungerar, finns på vår BACnet-ordlistesida.

Modbus: gammalt, enkelt och fortfarande på varje mätare

Modbus föregår BACnet med mer än ett decennium. Modicon introducerade det 1979, och det överlever idag av samma skäl som mycket gammal, tråkig teknik överlever: det är enkelt, det är royaltyfritt, och varje leverantör av varje energimätare, undermätare och äldre anläggningsstyrenhet redan vet hur man implementerar det. Det finns två varianter i aktiv användning. Modbus RTU är den ursprungliga seriella formen, som körs över RS-485 eller RS-232 med kompakta binära ramar. Modbus TCP sveper samma datamodell i Ethernet och är den enklare att integrera på ett modernt nät. En seriell RTU-mätare når ett IP-nät via en gateway, samma mönster som BACnet MS/TP.

Fångsten med Modbus är att det bär värden, inte betydelse. En klient pollar en enhet efter innehållet i ett numrerat register, och det är allt: ingen självbeskrivning, inga inbyggda enheter, ingen indikation om huruvida register 40012 är en kWh-avläsning eller en ventilposition. Du behöver enhetens registerkarta för att veta vad du läser, och den kartan bor i en PDF från mätarleverantören, inte i protokollet självt. Får du kartan fel kommer du glatt att mata in skräp som ser ut som data. Det finns heller ingen autentisering eller kryptering inbyggd, vilket sällan är ett problem på ett isolerat mätarnät men värt att veta innan du exponerar ett mot något bredare.

I praktiken samexisterar Modbus och BACnet ständigt: BACnet kör BMS, Modbus matar mätarna som BMS inte läser inbyggt. Den mixen är exakt det råmaterial energiledningsprogramvara behöver för att förvandla avläsningar till beslut, förutsatt att varje register först mappas till något fysiskt. Mer om protokollet självt finns på vår Modbus-ordlistesida.

OPC UA: modernt, säkert och semantiskt

OPC UA (Unified Architecture) är det nyaste av de tre mainstream-protokollen och det som byggts med mest medveten ingenjörskonst. Det ersatte den äldre OPC Classic-standarden och designades från början för att vara plattformsoberoende, tjänsteorienterat och säkert: autentisering, kryptering och åtkomstkontroll är en del av specifikationen, inte påskruvade efteråt som de skulle behöva vara för Modbus. Det definierar också en genuint rik objektmodell, närmare BACnet än Modbus, vilket gör integrationen betydligt mindre skör när den väl är uppsatt.

OPC UA:s hemmaplan är tillverkning och processindustri, där det blivit nära ett standardval för maskin-till-maskin- datautbyte. I byggnader dyker det upp där BMS moderniserats nyligen eller där fastighets- och industriella data konvergerar, till exempel ett datacenter, en fabrik med tillhörande kontorsblock, eller vilken anläggning som helst där OT- och IT-team ombeds dela ett datalager. Den konvergensen är en stor del av varför OPC UA spelar roll för fastighetsintegration även om det inte började där. Prenumerationer på värdeändringshändelser fungerar inbyggt, så du får pushade uppdateringar snarare än ständig polling, och säkerhetsprofilen som används på en given anläggning avgör exakt hur autentisering hanteras vid anslutning. Helhetsbilden finns på vår OPC UA-ordlistesida.

oBIX: den nyare, mest på Niagara

oBIX (Open Building Information Exchange) förtjänar ett eget avsnitt, inte för att det ersätter något utan för att det fortsätter dyka upp i specifika hörn av fastighetsstacken som de andra tre protokollen inte täcker lika rent. Det är en OASIS-standard, först publicerad 2006, och tar ett annat tekniskt grepp: XML över HTTP-webbtjänster snarare än ett ändamålsbyggt fastighetsprotokoll eller en industriell fältbuss. I praktiken är platsen du möter oBIX en Tridium Niagara-station. Niagara exponerar sina punkter via oBIX (och ofta BACnet också), och varje Honeywell WEBs-installation eller tredjeparts-JACE som kör på Niagara-ramverket erbjuder typiskt samma alternativ.

Vi lade till oBIX-stöd i FrostLogic Edge Agent eftersom vi ständigt stötte på just den här situationen: ett blandat bestånd där de flesta fastigheter talar BACnet rent men en eller två kör en Niagara-övervakare som är lättare att läsa via oBIX. Edge Agent talar nu fyra protokoll, BACnet, Modbus, OPC UA och oBIX, och dess första levande oBIX-anslutning kördes mot ett Tridium Niagara BMS. Det är inte en fallstudie, bara hur integrationsmatrisen ser ut under en normal vecka av att ansluta fastigheter. Om du kör ett Niagara-bestånd specifikt täcker vår Honeywell Niagara-integrationer-sida anslutningsdetaljerna, och mekaniken bakom oBIX själv finns på vår oBIX-ordlistesida.

LonWorks: äldre BAS som fortfarande dyker upp

LonWorks (ofta märkt LonWorks / LonTalk) var 1990-talets distribuerade styrsystemstack: SNVT-typade variabler, en peer-to-peer-fältbuss och en stor installerad bas i äldre Schneider TAC-, Honeywell- och Siemens-bestånd. Nya specifikationer väljer det sällan; när en anläggning fortfarande har LonWorks är det vanligtvis en retrofit som lämnar fältstyrenheterna på plats. Den praktiska vägen in i ett modernt analyslager är nästan alltid en LonWorks-till-BACnet-gateway som presenterar de punkterna som BACnet-objekt, inte en inbyggd LonWorks-drivrutin i varje nytt verktyg.

KNX: rumsnivå i Europa, ofta bredvid BACnet-HVAC

KNX är starkt i Europa för rumsbelysning, solskydd och användargränssnitt. Bussen är decentraliserad: enheter talar med varandra utan att en central styrenhet äger varje brytare. I kommersiella byggnader betyder det vanligtvis KNX för den hyresgästnära rumsstacken och BACnet för den centrala HVAC-/BMS-ryggraden. De samexisterar via en BACnet-KNX-gateway snarare än att ett protokoll absorberar det andra. För tyska, nordiska och bredare EU-bestånd, räkna med den mixen; för analys, behandla KNX som LonWorks: budgetera gatewayen som lyfter rums punkterna till BACnet (eller ett annat redan stött flöde) istället för att anta att varje verktyg talar KNX inbyggt. Se också våra stödda integrationer för hur Explore ansluter när de punkterna sitter på en läsbar buss.

Jämförelsen i korthet

Gateways och protokollkonvertering

Kan BACnet kommunicera med Modbus? Ja, på samma bestånd, varje vecka. De blir inte samma protokoll. En BACnet Modbus-gateway (eller router) översätter punkter så att varje sida behåller sin egen modell: Modbus-register på mätarsidan, BACnet-objekt på BMS-sidan. Samma mönster täcker LonWorks → BACnet och KNX → BACnet när en rum- eller äldre fältbuss ska mata en modern ryggrad.

De konverteringar du oftast kommer att driftsätta:

• Modbus-mätare och anläggning → BACnet (eller rakt in i en analysagent som redan talar Modbus)
• LonWorks äldre styrenheter → BACnet under BAS-modernisering
• KNX-rumsstack → BACnet-BMS för en gemensam operatörsvy
• Seriella segment (BACnet MS/TP, Modbus RTU) → IP via fysiska gateways eller routrar

Gateways är en mappnings- och driftsättningskostnad, och de är en felpunkt. Budgetera dem. Låtsas inte att ett blandprotokollbestånd blir "ett protokoll" för att en box sitter i skåpet. För analys specifikt läser FrostLogic Edge Agent BACnet, Modbus, OPC UA och oBIX inbyggt; LonWorks och KNX anländer typiskt efter att en anläggningsgateway presenterar dem som BACnet (eller ett annat stött flöde). Det är den sanna vägen in i FrostLogic Explore, inte ett påstående att varje fältbuss talas från ände till ände.

Vad detta betyder för att få data in i ett analyslager

Inget av detta förändrar vad ett analyslager faktiskt behöver: läsåtkomst till vad som redan körs, utan att röra styrsystemet. Ett fastighetsstyrsystem som kör BACnet för sina luftbehandlingsaggregat, Modbus för sina mätare och möjligen OPC UA, oBIX, LonWorks eller KNX någonstans i blandningen är inte ett integrationsproblem att lösa en gång. Det är den normala formen på ett verkligt fastighetsbestånd, och inmatningslagret måste hantera allt samtidigt, inte tvinga en fastighet att standardisera på ett protokoll innan den kan läsas.

FrostLogic Edge Agent är byggd runt den verkligheten. Den sitter på BMS-datorn eller servern, läser BACnet, Modbus, OPC UA och oBIX med skrivåtkomst avstängd från början, och skickar datan till FrostLogic Explore, som omvandlar den till en rankad beslutskö istället för ännu en instrumentpanel. Skrivåtkomst till specifika punkter finns när du beviljar den ett omfång. Leverantörsspecifik uppsättning, oavsett om det är ett Siemens Desigo BACnet-nätverk eller ett Schneider EcoStruxure-bestånd med sina egna särdrag, är dokumenterad på våra integrationssidor snarare än begravd i en generisk protokollspecifikation. Vad ditt BMS än talar, läser vi det. Se stödda integrationer.

Vanliga frågor

Vilket protokoll ska jag använda för en ny BMS-integration? Använd vad utrustningen redan talar. BACnet är det säkra standardvalet för ett modernt BMS och det man ska specificera om man skriver ett nytt kontrollkontrakt. Tvinga inte en protokollbyte enbart för standardiseringens skull; en fungerande Modbus-mätare eller ett OPC UA-flöde från ett processystem behöver inte bytas ut.

Kan BACnet och Modbus användas tillsammans / kan BACnet kommunicera med Modbus? Ja. De samexisterar på de flesta blandade bestånd, och en BACnet Modbus-gateway är hur de delar punkter när varje sida behöver den andras modell. BACnet kör vanligtvis BMS och dess styrenheter; Modbus matar energimätare, undermätare och äldre anläggning som aldrig flyttades upp till BACnet. Inget protokoll behöver försvinna för att det andra ska fungera.

Behöver jag en gateway för LonWorks eller KNX för att mata analys? Vanligtvis ja. Explores Edge Agent läser BACnet, Modbus, OPC UA och oBIX inbyggt. LonWorks och KNX anländer nästan alltid via en anläggningsgateway som presenterar de punkterna som BACnet (eller ett liknande stött flöde). Budgetera gatewayen och dess punktmappning; anta inte inbyggd LonWorks eller KNX på analyssidan.

BACnet/IP vs MS/TP: vilket behöver jag en gateway för? BACnet/IP och BACnet MS/TP talar inte direkt. MS/TP behöver en router eller gateway för att nå ett IP-nät. Om dina fältstyrenheter fortfarande sitter på MS/TP, planera för den bryggan innan en IP-inbyggd analysagent kan läsa dem.

Behöver FrostLogic Explore en gateway för OPC UA? Nej. Explore läser OPC UA inbyggt, inklusive prenumerationer på värdeändringshändelser, med autentisering och kryptering hanterat enligt säkerhetsprofilen fastigheten redan använder. Gateways kommer in i bilden för BACnet MS/TP och Modbus RTU, de två seriella varianterna, inte för OPC UA.

Vad är oBIX och behöver jag det? oBIX är en webbtjänststandard för att läsa fastighetsdata via HTTP, oftast mött på en Tridium Niagara-station. Du behöver det specifikt om delar av ditt bestånd kör Niagara eller en Niagara-baserad produkt som Honeywell WEBs. Om dina fastigheter kör ett standard BACnet-BMS med Modbus-mätare kommer oBIX helt enkelt inte att komma upp.