MQTT, BACnet IP & Modbus TCP: Multi-Protokoll-Kommunikation auf Kompakt Ethernet PLC

Ein DIN-Schienenmodul, das MQTT zur Cloud, BACnet zum Gebäude und Modbus TCP zu den Maschinen spricht. Dieser Satz beschreibt ein Panel voller Gateways. Es beschreibt jetzt eine einzelne Ethernet-fähige kompakte CPU, und die Multi-Protokoll-Geschichte auf der xLogic Plattform ist kein Marketing-Slide — sie ist in der Firmware dokumentiert, über die Handbuchrevisionen hinweg: MQTT seit V1.04, BACnet seit V1.57, Modbus seit Tag eins.

Hier ist, wie man das nutzen kann, ohne einen Wartungsalbtraum zu schaffen.

Die Protokollkarte

Jedes Protokoll hat sein natürliches Publikum, und der Trick besteht darin, sie getrennt zu halten:

  • Modbus TCP— der Maschinenboden: VFDs, HMIs, SCADA, andere PLCs. Deterministisch, registerbasiert, der universelle industrielle Handshake
  • MQTT— die Cloud: Telemetrie an einen Broker veröffentlichen, Dashboards abonnieren. Ereignisgesteuert, NAT-freundlich, für unzuverlässige Netzwerke gebaut
  • BACnet— das Gebäude: Maschinenräume, AHUs, BMS-Headends. Die Muttersprache der Immobilienbranche

Eine CPU, die allen drei Zielgruppen dient, bedeutet, dass der Maschinenbauer, der Facility-Manager und das Cloud-Dashboard dasselbe Gerät sehen — jeder in seiner eigenen Sprache, ohne dass jemand eine Konverterbox benötigt.

Echtes Gebäude: Kleiner Technikraum

Ein Technikraum mit einer AHU, zwei Fan-Coil-Gruppen und einer Wärmepumpe: Modbus TCP zur lokalen HMI und den VFDs, BACnet zum Gebäude-BMS für Planung und Alarme, MQTT zu einem Cloud-Service für Remote-Trendanalysen. Drei Protokolle, ein Controller, ein Programm. Der BMS-Ingenieur fragte, wer das Gateway hergestellt hat. Die Antwort — "es gibt kein Gateway" — brachte eine Stille, die volle fünf Sekunden dauerte.

Diese Stille ist das Produkt, das funktioniert.

Was getrennt gehalten werden sollte

Die Protokolle können die CPU teilen, aber sie sollten den Datenplan nicht teilen. Kartiere die Punkte einmal, absichtlich: welche Register sind Modbus-sichtbar, welche Objekte sind BACnet, welche Themen sind MQTT. Eine einzige Punktkarte, die in einer Tabelle gepflegt wird, verhindert das klassische Versagen — eine Registernummer ändert sich und drei Systeme gehen stillschweigend in den Stau.

Und denke an die Modellgrenzen: BACnet/IP und MQTT benötigen die Ethernet-fähigen CPUs. Die nur serielle Modelle behalten Modbus RTU und BACnet/MSTP. Überprüfe das Modell gegen die Anforderungen vor dem Versprechen, nicht nach dem Kaufauftrag.

Der Unterstützungswinkel, den niemand preislich berücksichtigt

Multi-Protokoll ist nicht nur ein Feature; es ist eine Verkaufschance. Ausschreibungen verlangen jetzt standardmäßig nach BMS-Integration, Cloud-Konnektivität als Checklistenpunkt. Ein Controller, der beides ohne Zusatzmodule beantwortet, kommt über den Vorqualifizierungsfilter. Der Preisunterschied zwischen den Einzelprotokoll- und Multi-Protokoll-Versionen ist gering; der Unterschied, an welchen Projekten du bieten darfst, ist es nicht.

Disziplin der Punktkarte

Multi-Protokoll ist ein Segen und eine Falle. Der Segen: eine CPU, die drei Systeme bedient. Die Falle: drei Systeme, die leicht unterschiedliche Versionen der Wahrheit lesen. Die Lösung ist langweilig und nicht verhandelbar — eine einzige Punktkarte, die jeden Wert einmal auflistet, mit seinem Register, seinem BACnet-Objekt und seinem MQTT-Thema in derselben Zeile.

Beginne die Tabelle am ersten Tag, bevor der erste Block verkabelt wird. Spalten: Wertname, Modbus-Register, BACnet-Objekttyp und Instanz, MQTT-Thema, Datentyp, Skalierung, Aktualisierungsrate und welches System autoritativ für Schreibvorgänge ist. Die letzte Spalte ist wichtiger, als die Leute denken — wenn das BMS und das Cloud-Dashboard beide einen Sollwert ändern wollen, muss jemand gewinnen, und die Karte sagt, wer. Ohne sie kämpfen zwei Systeme um einen Wert und die Maschine verhält sich um 3 Uhr morgens unberechenbar.

Versioniere die Karte mit dem Programm. Jede Firmware-Änderung, jeder hinzugefügte Punkt, jede Umnummerierung — die Karte wird im selben Commit aktualisiert. Ich habe Projekte geerbt, bei denen die Karte zwei Jahre veraltet war und drei Personen unterschiedliche Kopien hatten. Sie neu aufzubauen, dauerte eine Woche des Starrens auf Registertabellen. Eine Woche. Sei nicht dieses Projekt.

Und teste die protokollübergreifenden Pfade absichtlich: schreibe einen Sollwert vom BMS, verifiziere, dass die Maschine reagiert, verifiziere, dass das Cloud-Dashboard die Änderung anzeigt. Ein End-to-End-Test pro Punkt, bei der Inbetriebnahme, fängt die Mapping-Fehler ein, solange sie günstig zu beheben sind.

Firmware- und Versionsrealität

Die Protokollfunktionen kamen in Wellen, und die Geschichte der Handbuchrevisionen erzählt die Geschichte: MQTT in 4.2, der Webserver in 4.5, WiFi-Anweisungen in 6.0, BACnet in 6.2, SR-22-Unterstützung in 6.2.1. Wenn du ein Multi-Protokoll-Projekt planst, ist die Firmware-Version kein Detail — sie ist eine Anforderung. Eine CPU, die vor zwei Jahren ausgeliefert wurde, benötigt möglicherweise ein Update, bevor sie BACnet spricht, und der Update-Pfad hängt vom Modell ab.

Mache die Firmware-Prüfung zu einem Teil der Pre-Sales-Checkliste. Notiere die Version auf der Bestellung, bestätige sie bei der Lieferung und dokumentiere sie auf dem Inbetriebnahmeblatt. Das teuerste Gespräch in diesem Geschäft ist "es sollte das unterstützen" gefolgt von "dieses hier tut es nicht."

Und halte die Protokolle ehrlich über ihre Stärken. BACnet für das Gebäude, Modbus für die Maschinen, MQTT für die Cloud — jeweils auf dem Kabeltyp, für den es entworfen wurde. Die Ethernet-CPU verarbeitet alle drei gleichzeitig; sie macht sie nicht magisch zu einem Protokoll, und das sollte sie nicht. Die Trennung ist es, die die Anlage am Laufen hält, wenn die Cloud-Verbindung abbricht — der lokale Modbus- und BACnet-Verkehr wartet nicht auf das Internet.

Die Gewohnheit der Protokolldokumentation

Ein Drei-Protokoll-Controller ohne Protokollkarte ist ein Museumsexponat. Die Disziplin kostet eine Stunde bei der Inbetriebnahme und spart jede Woche, wenn sich das Gebäude ändert: ein Blatt, das jeden Punkt auflistet, sein Modbus-Register, sein BACnet-Objekt und sein MQTT-Thema — mit der Schreibberechtigung markiert. Das Blatt lebt mit den Schaltschrankzeichnungen, versioniert mit dem Programm. Wenn der BMS-Ingenieur fragt "welcher Wert ist die Zulufttemperatur?" ist die Antwort eine Zeile, nicht ein Nachmittag der Registerarchäologie.

Kaufe die Version mit den Protokollen. Die Projekte werden folgen.