
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. 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 alle drei, plus oBIX, den neueren Ankömmling, dem die meisten Integratoren nur ein- oder zweimal begegnet sind.
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 entwickelt wurde, und er definiert, was ein Datenpunkt bedeutet, nicht nur, wie sich die Bytes bewegen: Ein über BACnet ankommender "Wert" trägt bereits einen Objekttyp, eine Temperatur, einen Sollwert, einen Alarmstatus. Diese semantische Schicht ist genau das, was ein generisches Industrieprotokoll nicht bietet, und der Grund, warum BACnet zur lingua franca der Gebäudeautomation wurde, statt ein für die Aufgabe adaptierter Universal-Feldbus zu sein.
Unübersichtlich wird es bei der Aufteilung zwischen BACnet/IP und BACnet MS/TP. IP ist die moderne, Ethernet-native Version; MS/TP ist die ältere serielle Variante, die noch auf vielen Feldebene-Controller-Netzwerken läuft, insbesondere allem, was vor der letzten größeren Renovierung eines Standorts installiert wurde. Die beiden sprechen nicht direkt miteinander. Ein MS/TP-Segment braucht einen Router oder ein Gateway, um ein IP-Netzwerk zu erreichen, und in älteren Gebäuden findet man mehrere solcher Brücken in einem Schrank gestapelt, jede ein seit Jahren nicht überprüfter Ausfallpunkt. Die Objektbenennung ist technisch standardisiert, aber Hersteller interpretieren die Spezifikation mit genug lokaler Abweichung, dass ein Regelungstechniker, der zwischen einem Siemens-Desigo-Bestand und einem Schneider-EcoStruxure-Bestand wechselt, trotzdem auf Reibung stößt, wenn Punkte saubermappen sollen.
Für jeden, der auf einem GLT-System aufbaut, ist die praktische Erkenntnis, dass BACnet-Abdeckung allein kein einfaches Auslesen garantiert. Klären Sie, ob das Netzwerk, mit dem Sie integrieren, IP oder MS/TP läuft, und kalkulieren Sie das Gateway ein, falls Letzteres. Vollständige Details zum Protokoll, einschließlich der Funktionsweise des Objektmodells, finden Sie auf unserer BACnet-Glossarseite.
Modbus: alt, einfach, und immer noch an jedem Zähler
Modbus geht BACnet um mehr als ein Jahrzehnt voraus. Modicon führte es 1979 ein, und es überlebt heute aus demselben Grund, aus dem viele alte, unspektakuläre Technologien überleben: Es ist einfach, es ist lizenzfrei, und jeder Hersteller jedes Energiezählers, Unterzählers und Altanlagenreglers weiß bereits, wie man es implementiert. Es gibt zwei aktiv genutzte Varianten. Modbus RTU ist die ursprüngliche serielle Form, die über RS-485 oder RS-232 mit kompakten Binärrahmen läuft. Modbus TCP verpackt dasselbe Datenmodell in Ethernet und lässt sich in einem modernen Netzwerk leichter integrieren. Ein serieller RTU-Zähler erreicht ein IP-Netzwerk über ein Gateway, dasselbe Muster wie bei BACnet MS/TP.
Der Haken bei Modbus ist, dass es Werte transportiert, keine Bedeutung. Ein Client fragt ein Gerät nach dem Inhalt eines nummerierten Registers ab, und das ist alles: keine Selbstbeschreibung, keine eingebauten Einheiten, kein Hinweis darauf, ob Register 40012 ein kWh-Messwert 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ählernetzwerk selten ein Problem ist, aber wissenswert, bevor man eines für etwas Größeres öffnet.
In der Praxis existieren Modbus und BACnet ständig nebeneinander: BACnet betreibt das GLT-System, Modbus versorgt die Zähler, die das GLT-System nicht nativ liest. Diese Mischung ist genau das Rohmaterial, das Energiemanagement-Software braucht, um Messwerte in Entscheidungen zu verwandeln, vorausgesetzt jedes Register wird zuerst etwas Physischem zugeordnet. Mehr zum Protokoll selbst finden Sie auf unserer Modbus-Glossarseite.
OPC UA: modern, sicher und semantisch
OPC UA (Unified Architecture) ist das jüngste der drei gängigen Protokolle und das mit der bewusstesten Ingenieursarbeit entwickelte. Es ersetzte den älteren OPC-Classic-Standard und wurde von Anfang an darauf ausgelegt, plattformunabhängig, serviceorientiert und sicher zu sein: Authentifizierung, Verschlüsselung und Zugriffskontrolle sind Teil der Spezifikation, nicht nachträglich angeflanscht, wie es bei Modbus der Fall wäre. Es definiert außerdem ein wirklich reichhaltiges Objektmodell, näher an BACnets Ansatz als an Modbus, was die Integration nach der Einrichtung deutlich weniger fragil macht.
OPC UAs Heimterrain sind Fertigung und Prozessindustrien, wo es nahezu zum Standard für den Maschine-zu-Maschine-Datenaustausch geworden ist. In Gebäuden taucht es dort auf, wo das GLT-System vor kurzem modernisiert wurde oder wo Gebäude- und Industriedaten zusammenlaufen, etwa in einem Rechenzentrum, einer Fabrik mit angeschlossenem Bürogebäude oder an jedem Standort, wo OT- und IT-Teams eine gemeinsame Datenschicht nutzen sollen. Diese Konvergenz ist ein wesentlicher Grund, warum OPC UA für die Gebäudeintegration wichtig ist, obwohl es dort nicht angefangen hat. Abonnements auf Wertänderungsereignisse funktionieren nativ, sodass Sie Push-Updates statt ständigem Polling erhalten, und das an einem Standort verwendete Sicherheitsprofil bestimmt genau, wie die Authentifizierung beim Verbindungsaufbau gehandhabt wird. Das vollständige Bild finden Sie auf unserer OPC UA-Glossarseite.
oBIX: das neuere, meist bei Niagara
oBIX (Open Building Information Exchange) verdient einen eigenen Abschnitt, nicht weil es etwas ersetzt, sondern weil es immer wieder in bestimmten Ecken des Gebäude-Stacks auftaucht, die die anderen drei Protokolle nicht so saubere abdecken. Es ist ein OASIS-Standard, erstmals 2006 veröffentlicht, und verfolgt einen anderen technischen Ansatz: 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, der auf dem Niagara-Framework läuft, 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.
Der Vergleich auf einen Blick
| BACnet | Modbus | OPC UA | oBIX | |
|---|---|---|---|---|
| Anwendungsfall | Gebäudeautomationsnetzwerke | Zähler, Unterzähler, Altanlagen | Industrielle + modernisierte Gebäudedaten | Niagara/Tridium-Stationsdaten |
| Semantik | Reiches Objektmodell, selbstbeschreibend | Keine; nur rohe Registerwerte | Reiches Objektmodell, selbstbeschreibend | Selbstbeschreibende Web-Ressourcen |
| Sicherheit | Variiert je nach Herstellerimplementierung | Nicht eingebaut | In der Spezifikation eingebaut | HTTP-Schicht (TLS, wo konfiguriert) |
| Typische Ausrüstung | Modernes GLT-System, RLT-Anlagen, Controller | Energie-/Wasserzähler, Frequenzumrichter, Altanlagen | Fertigungssysteme, modernisiertes GLT-System | Tridium-Niagara-Stationen, Honeywell WEBs, JACEs |
| Analysebereitschaft | Hoch, sobald IP vs. MS/TP geklärt ist | Niedrig, bis Register gemappt sind | Hoch, direkt einsatzbereit | Hoch für Niagara-native Daten |
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 oder oBIX 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 rein lesend aus und sendet die Daten an FrostLogic Explore, das sie in eine geordnete Entscheidungswarteschlange verwandelt statt in ein weiteres Dashboard. 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 im selben Gebäude koexistieren? Ja, und das ist in der Praxis der häufigste Aufbau. BACnet betreibt typischerweise das GLT-System und seine Controller, während Modbus Energiezähler, Unterzähler und Altanlagen versorgt, die nie auf BACnet umgestellt wurden. Keines der beiden Protokolle muss verschwinden, damit das andere funktioniert.
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.
FrostLogic Explore bringt Sensor Intelligence, Szenariosimulation und Grounded AI in Gewerbe- und Industriegebäude. Mehr über Sensor Intelligence erfahren oder sprechen Sie es mit uns durch.
Neugierig, wie das bei Ihrem Gebäude aussehen würde?
Was verrät Ihnen Ihr Gebäude nicht?
Sagen Sie uns, was Sie herausfinden wollen: schleichend steigender Energieverbrauch, ein BMS, dem Sie nicht trauen, Compliance, der Sie hinterherlaufen. Wir hören erst zu und sagen Ihnen dann offen, ob Explore hilft. 30 oder 60 Minuten, Sie entscheiden. In jedem Fall unverbindlich.
