BACnet vs. Modbus vs. OPC UA (plus LonWorks und KNX): Leitfaden für Gebäudeintegratoren

Photo by Troy Bridges on Unsplash.

Wählen Sie am ersten Tag einer BMS-Integration das falsche Protokoll, zahlen Sie fünf Jahre später immer noch dafür, meist in Form einer Gateway-Box, an deren Konfiguration sich niemand mehr erinnert. Treffen Sie die richtige Wahl, wird dieselbe Integration in den Übergabenotizen kaum erwähnt. Der Einsatz ist so ungleich verteilt, und trotzdem wird die Entscheidung selten bewusst getroffen. Die meisten Gebäude erben einfach, welches Protokoll der letzte Regelungsanbieter geliefert hat.

Das ist nicht notwendigerweise falsch. BACnet, Modbus und OPC UA haben alle noch eine Aufgabe zu erfüllen, und die meisten Gebäudebestände betreiben mehr als eines von ihnen parallel. LonWorks taucht weiterhin in älteren BAS-Retrofits auf; KNX beherrscht oft die Raumbeleuchtungs- und Beschattungsstack in europäischen Gebäuden. Was für jeden zählt, der Sensor- und Zählerdaten in eine Analyseschicht bringen will, ist zu wissen, welches Protokoll was tut, wo jedes an seine Grenzen kommt, und was das für das Gateway oder den Agenten bedeutet, der darauf aufsetzt. Dieser Leitfaden behandelt die sechs, denen Sie am häufigsten begegnen, einschließlich wann ein BACnet-Modbus-Gateway (oder eine LonWorks-/KNX-Brücke) die ehrliche Antwort ist statt eines Umbaus.

BACnet: der Standard, mit zwei Varianten

BACnet (Building Automation and Control Network) ist das Protokoll, das die meisten modernen GLT-Systeme nativ sprechen, und das aus gutem Grund. Es ist ein ANSI/ASHRAE- und ISO-Standard, der speziell für diese Aufgabe gebaut wurde, und er definiert, was ein Datenstück bedeutet, nicht nur, wie Bytes wandern: ein „Wert“, der über BACnet ankommt, trägt bereits einen Objekttyp, eine Temperatur, einen Sollwert, einen Alarmzustand. Genau diese semantische Schicht gibt ein generisches Industrieprotokoll nicht her, und deshalb wurde BACnet zur Lingua franca der Gebäudeautomation statt eines angepassten Allzweck-Feldbusses.

BACnet MS/TP vs. BACnet/IP

Unübersichtlich wird es bei der Trennung zwischen BACnet/IP und BACnet MS/TP. IP ist die moderne, Ethernet-native Variante; MS/TP ist die ältere serielle Variante, die noch auf vielen Feldcontroller-Netzen läuft, besonders auf allem, was vor dem letzten größeren Standort-Refresh installiert wurde. Die beiden sprechen nicht direkt miteinander. Ein MS/TP-Segment braucht einen Router oder ein Gateway, um ein IP-Netz zu erreichen, und an älteren Standorten finden Sie mehrere solcher Brücken gestapelt in einem Schrank, jede ein Ausfallpunkt, den seit Jahren niemand geprüft hat. Objektnamen sind technisch standardisiert, aber Hersteller interpretieren die Spezifikation mit genug lokaler Variation, dass ein Regelungstechniker, der zwischen einem Siemens-Desigo- und einem Schneider-EcoStruxure-Bestand wechselt, beim sauberen Punktmapping weiterhin Reibung spürt.

Für alle, die auf ein GLT-System / BMS aufsetzen, lautet die praktische Erkenntnis: BACnet-Abdeckung allein garantiert kein einfaches Auslesen. Klären Sie, ob das Netzwerk, mit dem Sie integrieren, IP oder MS/TP läuft, und budgetieren Sie das Gateway, wenn es Letzteres ist. Details zum Protokoll, einschließlich des Objektmodells, finden Sie auf unserer BACnet-Glossarseite.

Modbus: alt, einfach und immer noch an jedem Zähler

Modbus liegt mehr als ein Jahrzehnt vor BACnet. Modicon führte es 1979 ein, und es überlebt heute aus demselben Grund wie viel alte, langweilige Technik: es ist einfach, lizenzfrei, und jeder Hersteller jedes Energiezählers, Unterzählers und Legacy-Anlagencontrollers weiß schon, wie man es implementiert. Zwei Varianten sind aktiv im Einsatz. Modbus RTU ist die originale serielle Form über RS-485 oder RS-232 mit kompakten Binärframes. Modbus TCP packt dasselbe Datenmodell in Ethernet und lässt sich auf einem modernen Netz leichter integrieren. Ein serieller RTU-Zähler erreicht ein IP-Netz über ein Gateway, dasselbe Muster wie bei BACnet MS/TP.

Der Haken bei Modbus: es trägt Werte, nicht Bedeutung. Ein Client pollt ein Gerät nach dem Inhalt eines nummerierten Registers, und das ist alles: keine Selbstbeschreibung, keine eingebauten Einheiten, kein Hinweis, ob Register 40012 eine kWh-Ablesung oder eine Ventilstellung ist. Sie brauchen die Registerkarte des Geräts, um zu wissen, was Sie lesen, und diese Karte steckt in einem PDF des Zählerherstellers, nicht im Protokoll selbst. Liegt die Karte falsch, lesen Sie fröhlich Datenmüll ein, der wie Daten aussieht. Es gibt auch keine eingebaute Authentifizierung oder Verschlüsselung, was auf einem isolierten Zählernetz selten ein Problem ist, aber man sollte es wissen, bevor man eines breiter exponiert.

In der Praxis koexistieren Modbus und BACnet ständig: BACnet betreibt das GLT-System, Modbus speist die Zähler, die das GLT nicht nativ liest. Genau diese Mischung ist das Rohmaterial, das Energiemanagement-Software braucht, um Ablesungen in Entscheidungen zu verwandeln, sofern jedes Register zuerst auf etwas Physisches gemappt wird. Mehr zum Protokoll selbst auf unserer Modbus-Glossarseite.

OPC UA: modern, sicher und semantisch

OPC UA (Unified Architecture) ist das neueste der drei Mainstream-Protokolle und das mit der bewusstesten Technik. Es ersetzte den älteren OPC-Classic-Standard und wurde von Anfang an plattformunabhängig, dienstorientiert und sicher entworfen: Authentifizierung, Verschlüsselung und Zugriffskontrolle gehören zur Spezifikation, statt nachträglich aufgeschraubt zu werden wie bei Modbus. Es definiert auch ein echt reiches Objektmodell, näher an BACnet als an Modbus, was die Integration deutlich weniger spröde macht, sobald sie steht.

Heimat von OPC UA sind Fertigung und Prozessindustrie, wo es für den Maschinen-zu-Maschinen-Datenaustausch nahe an einem Default liegt. In Gebäuden taucht es auf, wo das GLT-System kürzlich modernisiert wurde oder Gebäude- und Industriedaten zusammenlaufen, etwa in einem Rechenzentrum, einer Fabrik mit Büroblock oder überall dort, wo OT- und IT-Teams eine gemeinsame Datenschicht teilen sollen. Genau diese Konvergenz macht OPC UA für die Gebäudeintegration relevant, obwohl es dort nicht begonnen hat. Abonnements auf Wertänderungsereignisse funktionieren nativ, Sie bekommen also Push-Updates statt Dauerpolling, und das am Standort genutzte Sicherheitsprofil bestimmt, wie Authentifizierung beim Verbindungsaufbau gehandhabt wird. Das Gesamtbild steht auf unserer OPC UA-Glossarseite.

oBIX: das neuere, meist auf Niagara

oBIX (Open Building Information Exchange) verdient einen eigenen Abschnitt, nicht weil es etwas ersetzt, sondern weil es immer wieder in Ecken des Gebäudestacks auftaucht, die die anderen drei Protokolle nicht so sauber abdecken. Es ist ein OASIS-Standard, erstmals 2006 veröffentlicht, und geht technisch anders vor: XML über HTTP-Webservices statt eines zweckgebauten Gebäudeprotokolls oder eines industriellen Feldbusses. In der Praxis begegnet man oBIX an einer Tridium-Niagara-Station. Niagara stellt seine Punkte über oBIX bereit (und oft auch über BACnet), und jede Honeywell-WEBs-Installation oder ein Drittanbieter-JACE auf dem Niagara-Framework bietet in der Regel dieselbe Option.

Wir haben oBIX-Unterstützung zum FrostLogic Edge Agent hinzugefügt, weil wir immer wieder genau auf diese Situation gestoßen sind: ein gemischter Bestand, in dem die meisten Gebäude BACnet sauber sprechen, aber ein oder zwei einen Niagara-Supervisor betreiben, der sich einfacher über oBIX auslesen lässt. Der Edge Agent spricht jetzt vier Protokolle, BACnet, Modbus, OPC UA und oBIX, und seine erste produktive oBIX-Verbindung lief gegen ein Tridium-Niagara-GLT-System. Das ist keine Fallstudie, sondern einfach, wie die Integrationsmatrix in einer normalen Woche der Gebäudeeinbindung aussieht. Wenn Sie speziell einen Niagara-Bestand betreiben, deckt unsere Seite Honeywell-Niagara-Integrationen die Verbindungsdetails ab, und die Mechanik von oBIX selbst finden Sie auf unserer oBIX-Glossarseite.

LonWorks: Legacy-BAS, das weiterhin auftaucht

LonWorks (oft als LonWorks / LonTalk geführt) war der verteilte Regelungsstack der 1990er: SNVT-typisierte Variablen, ein Peer-to-Peer-Feldbus und eine große installierte Basis in älteren Schneider-TAC-, Honeywell- und Siemens-Beständen. Neue Ausschreibungen wählen es selten; wenn ein Standort noch LonWorks hat, ist das meist ein Retrofit, der die Feldcontroller belässt. Der praktische Weg in eine moderne Analyseschicht ist fast immer ein LonWorks-zu-BACnet-Gateway, das diese Punkte als BACnet-Objekte anbietet, nicht ein nativer LonWorks-Treiber in jedem neuen Werkzeug.

KNX: Raumebene in Europa, oft neben BACnet-HVAC

KNX ist in Europa stark für Raumbeleuchtung, Beschattung und Bedienoberflächen, und in deutschen sowie vielen weiteren EU-Beständen oft die Raumschicht neben einem BACnet-HVAC-Rücken. Der Bus ist dezentral: Geräte sprechen miteinander, ohne dass ein zentraler Controller jeden Taster besitzt. In Gewerbeimmobilien heißt das typischerweise KNX für den nutzerzugewandten Raumstack und BACnet für die zentrale HVAC-/GLT-Backbone. Sie koexistieren über ein BACnet-KNX-Gateway statt über eine Absorption des einen Protokolls durch das andere. Ein BACnet-KNX-Gateway ist hier Alltag, nicht Ausnahme; für Analytik gilt wie bei LonWorks: budgetieren Sie das Gateway, das Raumpunkte nach BACnet (oder einen anderen bereits unterstützten Feed) hebt, statt anzunehmen, jedes Werkzeug spreche KNX nativ. Siehe auch unsere unterstützten Integrationen, sobald diese Punkte auf einem lesbaren Bus liegen.

Der Vergleich auf einen Blick

Gateways und Protokollkonvertierung

Kann BACnet mit Modbus kommunizieren? Ja, im selben Bestand, jede Woche. Sie werden dadurch nicht dasselbe Protokoll. Ein BACnet-Modbus-Gateway (oder Router) übersetzt Punkte, sodass jede Seite ihr eigenes Modell behält: Modbus-Register auf der Zählerseite, BACnet-Objekte auf der GLT-Seite. Dasselbe Muster deckt LonWorks → BACnet und KNX → BACnet ab, wenn ein Raum- oder Legacy-Feldbus eine moderne Backbone speisen soll.

Die Konvertierungen, die Sie am häufigsten in Betrieb nehmen:

• Modbus-Zähler und Anlagen → BACnet (oder direkt in einen Analyseagenten, der bereits Modbus spricht)
• LonWorks-Legacy-Controller → BACnet bei einer BAS-Modernisierung
• KNX-Raumstack → BACnet-GLT für eine gemeinsame Operator-Sicht
• Serielle Segmente (BACnet MS/TP, Modbus RTU) → IP über physische Gateways oder Router

Gateways sind Mapping- und Inbetriebnahmekosten, und sie sind ein Ausfallpunkt. Budgetieren Sie sie. Tun Sie nicht so, als würde ein gemischter Protokollbestand „ein Protokoll“, weil eine Box im Schrank steht. Für Analytik liest der FrostLogic Edge Agent BACnet, Modbus, OPC UA und oBIX nativ; LonWorks und KNX kommen typischerweise an, nachdem ein Standort-Gateway sie als BACnet (oder einen anderen unterstützten Feed) anbietet. Das ist der ehrliche Weg in FrostLogic Explore, kein Anspruch, jeden Feldbus End-to-End zu sprechen.

Was das für den Weg von Daten in eine Analyseschicht bedeutet

Nichts davon ändert, was eine Analyseschicht tatsächlich braucht: Lesezugriff auf das, was bereits läuft, ohne das Steuerungssystem zu berühren. Ein Gebäudemanagementsystem, das BACnet für seine RLT-Anlagen, Modbus für seine Zähler und möglicherweise OPC UA, oBIX, LonWorks oder KNX irgendwo im Mix betreibt, ist kein Integrationsproblem, das man einmal löst. Es ist die normale Form eines echten Gebäudebestands, und die Erfassungsschicht muss all das gleichzeitig bewältigen, statt einen Standort zu zwingen, sich auf ein Protokoll zu standardisieren, bevor er ausgelesen werden kann.

Der FrostLogic Edge Agent ist um diese Realität herum gebaut. Er läuft auf dem GLT-PC oder -Server, liest BACnet, Modbus, OPC UA und oBIX standardmäßig rein lesend aus und sendet die Daten an FrostLogic Explore, das sie in eine geordnete Entscheidungswarteschlange verwandelt statt in ein weiteres Dashboard. Schreibzugriff auf bestimmte Punkte ist verfügbar, sobald Sie ihm einen Scope freigeben. Herstellerspezifische Einrichtung, ob es sich um ein Siemens-Desigo-BACnet-Netzwerk oder einen Schneider-EcoStruxure-Bestand mit seinen eigenen Eigenheiten handelt, ist auf unseren Integrationsseiten dokumentiert, statt in einer generischen Protokollspezifikation vergraben zu sein. Was auch immer Ihr GLT-System spricht, wir lesen es aus. Siehe unterstützte Integrationen.

Häufige Fragen

Welches Protokoll sollte ich für eine neue GLT-Integration verwenden? Verwenden Sie, was die Anlage bereits spricht. BACnet ist die sichere Standardwahl für ein modernes GLT-System und die, die man bei einem neuen Regelungsvertrag festschreiben sollte. Erzwingen Sie keinen Protokollwechsel allein um der Standardisierung willen; ein funktionierender Modbus-Zähler oder ein OPC-UA-Feed aus einem Prozesssystem müssen nicht ersetzt werden.

Können BACnet und Modbus zusammen genutzt werden / kann BACnet mit Modbus kommunizieren? Ja. Sie koexistieren in den meisten gemischten Beständen, und ein BACnet-Modbus-Gateway ist, wie sie Punkte teilen, wenn jede Seite das Modell der anderen braucht. BACnet betreibt typischerweise das GLT-System und seine Controller; Modbus speist Energiezähler, Unterzähler und Altanlagen, die nie auf BACnet umgestellt wurden. Keines der beiden Protokolle muss verschwinden, damit das andere funktioniert.

Brauche ich ein Gateway für LonWorks oder KNX, um Analytik zu speisen? Meist ja. Der Edge Agent von Explore liest BACnet, Modbus, OPC UA und oBIX nativ. LonWorks und KNX kommen fast immer über ein Standort-Gateway an, das diese Punkte als BACnet (oder einen ähnlichen unterstützten Feed) anbietet. Budgetieren Sie das Gateway und sein Punktmapping; rechnen Sie nicht mit nativem LonWorks oder KNX auf der Analyseseite.

BACnet/IP vs. MS/TP: wofür brauche ich ein Gateway? BACnet/IP und BACnet MS/TP sprechen nicht direkt. MS/TP braucht einen Router oder ein Gateway, um ein IP-Netz zu erreichen. Wenn Ihre Feldcontroller noch auf MS/TP sitzen, planen Sie diese Brücke, bevor ein IP-nativer Analyseagent sie lesen kann.

Braucht FrostLogic Explore ein Gateway für OPC UA? Nein. Explore liest OPC UA nativ, einschließlich Abonnements auf Wertänderungsereignisse, wobei Authentifizierung und Verschlüsselung entsprechend dem am Standort bereits genutzten Sicherheitsprofil gehandhabt werden. Gateways kommen bei BACnet MS/TP und Modbus RTU ins Spiel, den beiden seriellen Varianten, nicht bei OPC UA.

Was ist oBIX, und brauche ich es? oBIX ist ein Webservice-Standard zum Auslesen von Gebäudedaten über HTTP, dem man am häufigsten an einer Tridium-Niagara-Station begegnet. Sie brauchen es speziell, wenn ein Teil Ihres Bestands Niagara oder ein Niagara-basiertes Produkt wie Honeywell WEBs betreibt. Wenn Ihre Gebäude ein Standard-BACnet-GLT-System mit Modbus-Zählern betreiben, wird oBIX schlicht nicht relevant.