MQTT im Industrial IoT: Architektur, QoS und Sicherheit

Publish/Subscribe: So funktioniert MQTT

MQTT ist ein schlankes Nachrichtenprotokoll auf Basis von TCP, entwickelt für Netze mit geringer Bandbreite, instabilen Verbindungen oder hoher Latenz. Genau deshalb gehört es zu den meistgenutzten Protokollen im Industrial IoT: von Sensordaten einer Fertigungslinie bis zu Zustandsmeldungen, die Edge-Gateways im Bergbau an eine zentrale Plattform senden.

Sender und Empfänger kommunizieren bei MQTT nie direkt miteinander. Jeder Client verbindet sich ausschließlich mit einem Broker:

• Ein Publisher veröffentlicht eine Nachricht auf einem Topic, etwa die Temperatur eines Motors.
• Ein Subscriber abonniert ein oder mehrere Topics.
• Der Broker nimmt Nachrichten entgegen und stellt sie allen passenden Abonnenten zu.

Diese Entkopplung hat praktische Folgen: Geräte müssen ihre Datenabnehmer nicht kennen. Neue Abnehmer wie ein Dashboard, eine Zeitreihendatenbank oder ein Alarmdienst lassen sich ergänzen, ohne die Geräte anzufassen. Verbindungen werden vom Gerät aus nach außen aufgebaut, was Firewall-Regeln vereinfacht. Der feste Header umfasst nur wenige Byte, was bei Mobilfunk- oder Satellitenverbindungen ins Gewicht fällt.

Topic-Hierarchien entwerfen

Topics sind hierarchische Zeichenketten, getrennt durch /. Ihr Aufbau ist eine frühe Architekturentscheidung, denn eine spätere Änderung betrifft alle Geräte und alle Abnehmer. Bewährt hat sich eine Struktur entlang der physischen oder organisatorischen Gliederung des Standorts:

site/area/line/asset/telemetry/temperature

Abonnenten können zwei Platzhalter nutzen: + steht für genau eine Ebene, # für alle folgenden Ebenen. So empfängt site/area/+/+/alarms/# sämtliche Alarme aller Linien eines Bereichs.

Empfehlungen aus der Praxis

• Kleinbuchstaben, keine Leerzeichen, keine Sonderzeichen und kein führender /.
• Telemetrie, Zustand, Alarme und Befehle in getrennten Zweigen führen, damit Berechtigungen und QoS je Zweig festgelegt werden können.
• Eine eindeutige Gerätekennung ins Topic aufnehmen, damit Zugriffslisten (ACLs) darauf aufbauen können.
• Das Payload-Format dokumentieren: JSON ist gut lesbar, binäre Formate wie Protobuf eignen sich für schmalbandige Verbindungen.
• Veränderliche Werte oder Zeitstempel gehören in die Nutzdaten, nicht ins Topic.

Zustellgarantien und Sitzungszustand

QoS-Stufen

MQTT kennt drei Quality-of-Service-Stufen. Wichtig: QoS gilt je Teilstrecke, also einmal zwischen Publisher und Broker und einmal zwischen Broker und jedem Abonnenten. Wirksam ist die niedrigere der beiden Stufen.

Stufe	Garantie	Mechanismus	Typischer Einsatz
QoS 0	Höchstens einmal	Senden ohne Bestätigung	Hochfrequente Telemetrie, bei der ein verlorener Wert unkritisch ist
QoS 1	Mindestens einmal	PUBLISH und PUBACK, Duplikate möglich	Ereignisse, Alarme und Befehle mit idempotenter Verarbeitung
QoS 2	Genau einmal	Vierstufiger Handshake	Fälle, in denen Duplikate teuer sind und Mehraufwand vertretbar ist

Retained Messages

Der Broker speichert je Topic die letzte als „retained“ markierte Nachricht und liefert sie neuen Abonnenten sofort aus. Das ist nützlich für Zustandswerte wie online/offline oder den aktuellen Sollwert, bei laufenden Telemetrieströmen dagegen meist überflüssig.

Last Will and Testament

Beim Verbindungsaufbau kann ein Client eine „letzte Nachricht“ hinterlegen. Bricht die Verbindung unkontrolliert ab und läuft das Keep-Alive-Intervall ab, veröffentlicht der Broker diese Nachricht stellvertretend. In Kombination mit einem Retained-Status-Topic entsteht so eine einfache, verlässliche Verfügbarkeitsüberwachung für Geräte und Gateways.

Persistente Sitzungen

Bei einer persistenten Sitzung hält der Broker die Abonnements eines getrennten Clients sowie dessen noch nicht zugestellte QoS-1- und QoS-2-Nachrichten vor. Das hilft Gateways an instabilen Verbindungen. Warteschlangengröße und Aufbewahrungsdauer sollten jedoch begrenzt werden, um den Speicher des Brokers zu schützen. Ein lokaler Puffer auf dem Edge-Gateway ist die wichtige Ergänzung.

MQTT 5 und Absicherung

Was MQTT 5 ergänzt

• Reason Codes in Bestätigungen für eine präzisere Fehleranalyse.
• User Properties, um Metadaten wie Schema-Version oder Einheit mitzugeben, ohne die Nutzdaten zu ändern.
• Shared Subscriptions zur Lastverteilung auf mehrere Instanzen eines Verarbeitungsdienstes.
• Session Expiry und Message Expiry zur Steuerung der Lebensdauer von Sitzungen und Nachrichten.
• Response Topic und Correlation Data für Anfrage-Antwort-Muster, etwa bei Befehlen.
• Topic Aliases und Receive Maximum zur Verkehrsreduktion und Flusskontrolle.

Wer diese Funktionen nutzen will, sollte prüfen, ob Geräte, Gateways und Broker durchgängig MQTT 5 unterstützen; andernfalls gilt das Verhalten von MQTT 3.1.1.

TLS und Authentifizierung

MQTT selbst verschlüsselt nichts. Im industriellen Umfeld empfiehlt sich folgende Grundausstattung:

• TLS verwenden (üblicherweise Port 8883) und den unverschlüsselten Port 1883 in nicht vertrauenswürdigen Netzen deaktivieren.
• Geräte per Client-Zertifikat (mutual TLS) oder mit individuellen Zugangsdaten je Gerät authentifizieren, niemals mit einem gemeinsamen Passwort.
• ACLs durchsetzen, sodass jedes Gerät nur auf eigene Topics schreibt und nur eigene Befehle liest.
• OT- und IT-Netz trennen und den Broker in einer kontrollierten Zone wie einer Industrie-DMZ betreiben, angelehnt an das Zonen- und Conduit-Modell der IEC 62443.

Sparkplug B und der Vergleich mit OPC UA und HTTP

MQTT regelt den Transport, nicht aber den Aufbau von Topics oder Nutzdaten. Die bei der Eclipse Foundation gepflegte Spezifikation Sparkplug B schließt diese Lücke für den industriellen Einsatz: ein festes Topic-Schema mit dem Präfix spBv1.0, Protobuf-kodierte Nutzdaten sowie Birth- und Death-Nachrichten (NBIRTH, NDEATH, DBIRTH, DDEATH), aus denen die Host-Anwendung erkennt, welche Geräte online sind und welche Messgrößen sie liefern. Sparkplug lohnt sich vor allem dann, wenn mehrere SCADA-Systeme oder Plattformen Daten ohne individuelle Absprachen austauschen sollen.

Kriterium	MQTT	OPC UA	HTTP/REST
Kommunikationsmuster	Publish/Subscribe über Broker	Client/Server sowie PubSub	Anfrage/Antwort
Datenmodell	Frei, mit Sparkplug strukturiert	Umfangreiches, standardisiertes Informationsmodell	Frei, meist JSON
Overhead	Gering	Mittel bis hoch	Höher je Nachricht
Echtzeitdaten	Ja, ereignisgesteuert (Push)	Ja, über Subscriptions und Monitored Items	Nur per Polling oder Webhook
Typische Einordnung	Edge bis Plattform und Cloud	Maschinen- und Steuerungsebene	Anbindung an IT-Systeme

In der Praxis liest häufig ein Edge-Gateway die Steuerungen per OPC UA oder Modbus aus und leitet die Daten per MQTT an die Plattform weiter, während HTTP-Schnittstellen die Anbindung an ERP- und Geschäftssysteme übernehmen.

Broker auswählen und betreiben

Die Auswahl ist groß. Entscheidend sind Größenordnung, Clusteranforderungen, Supportmodell und die Kenntnisse im Team:

• Eclipse Mosquitto: schlanker Open-Source-Broker, gut geeignet für die Edge, Testumgebungen sowie kleine bis mittlere Installationen.
• EMQX: verteilter Broker mit Clusterbetrieb, Regel-Engine und Datenbankanbindungen.
• HiveMQ: auf Unternehmensumgebungen ausgerichteter Broker mit kommerziellen Editionen und Erweiterungen.
• ThingsBoard: integrierter MQTT-Transport zur direkten Geräteanbindung über die eigene Topic-API (zum Beispiel v1/devices/me/telemetry). Ein allgemeiner Broker für beliebigen Austausch zwischen Systemen ist er nicht.

Unabhängig vom Produkt sollten Sie von Beginn an einplanen: Überwachung des Brokers selbst (Verbindungen, Nachrichtenraten, Warteschlangenlängen), Sicherung der Konfiguration, einen Prozess für die Zertifikatserneuerung und Lasttests mit realistischen Gerätezahlen und Senderaten vor der Inbetriebnahme.

Fazit und nächste Schritte

MQTT ist für sich genommen keine Architektur, sondern das Transportrückgrat darin. Ob ein Projekt gelingt, hängt von einem durchdachten Topic-Design, der passenden QoS je Datenart, Sicherheit ab dem ersten Tag und einem klar dokumentierten Datenformat ab. Wenn Sie die Datenarchitektur für eine Fabrik, ein Bergwerk oder einen Industriestandort planen oder überprüfen, finden Sie auf den Seiten zur Industrial IoT Beratung und zum industriellen Monitoring die Vorgehensweise. Ihre konkrete Ausgangslage können Sie über die Kontaktseite schildern.