MQTT (Message Queuing Telemetry Transport) hat sich in den letzten Jahren als de-facto Standard im Industrial IoT etabliert. In modernen Produktionsumgebungen bildet MQTT oft das Rückgrat eines Unified Namespace (UNS). Der UNS definiert einen einheitlichen Datenraums, der als Single Source of Truth für alle Echtzeit-Informationen einer Fabrik dient. Dieser Artikel gibt einen Überblick über die Entstehung von MQTT und beleuchtet die wesentlichen Eigenschaften. Zudem zeigt der Artikel die Vorteile mit Schwerpunkt auf dem Unified Namespace in der Fertigungsindustrie auf.
MQTT: Von IBM zum Standard im Industrial IoT
MQTT (Message Queuing Telemetry Transport) wurde 1999 von Andy Stanford-Clark (IBM) und Arlen Nipper (damals bei Arcom) entwickelt. Ursprünglich konzipiert für Öl-Pipelines und Satellitenkommunikation, zielte das Protokoll auf den Einsatz in besonders bandbreitenarmen und instabilen Netzwerken ab. Dabei ist der Name ein historisches Relikt: „Message Queuing“ bezieht sich auf die damals genutzte IBM-MQ-Infrastruktur – nicht auf die tatsächlichen Fähigkeiten des Protokolls. Im Kern stand von Anfang an der leichtgewichtige und zuverlässige Transport von Telemetriedaten im Vordergrund.
Um die Verbreitung voranzutreiben, veröffentlichte IBM 2010 MQTT 3.1 als offenen Standard. 2013 wurde MQTT dem OASIS-Konsortium übergeben und 2014 als offizieller OASIS-Standard (Version 3.1.1) ratifiziert. Heute ist MQTT ein offener OASIS- und ISO-Standard (ISO/IEC 20922). Durch seine Effizienz und Einfachheit hat es sich schnell als bevorzugtes Protokoll im IoT und speziell auch im Industrial IoT durchgesetzt. Viele IoT-Plattformen – von Cloud-Diensten bis zu SCADA-Systemen – unterstützen MQTT, was dessen Stellung als Industrie-Standard weiter festigt.
Wie funktioniert MQTT?
MQTT folgt dem Publish/Subscribe-Prinzip mit einem zentralen Vermittler – dem sogenannten Broker. Alle teilnehmenden Systeme agieren als MQTT-Clients und verbinden sich mit diesem Broker. Dabei kann ein Client Nachrichten auf einem bestimmten Thema (Topic) veröffentlichen oder sich auf Topics abonnieren, um entsprechende Nachrichten zu empfangen. Der Broker übernimmt dabei das Routing: Er verteilt eingehende Nachrichten automatisch an alle Clients, die das jeweilige Topic abonniert haben. Durch diese Architektur sind Sender und Empfänger vollständig entkoppelt. Der Datenproduzent muss weder die Anzahl noch die Identität oder den Standort der Empfänger kennen. Ebenso benötigen empfangende Systeme keine Informationen über die Quelle der Daten.
Dieses lose Kopplungsprinzip schafft hohe Flexibilität, Skalierbarkeit und Wartungsfreundlichkeit – insbesondere im Kontext verteilter industrieller Systeme. Dabei werden die Daten in einer hierarchischen Themenstruktur (Topic-Namespace) organisiert, der dem Aufbau eines Dateisystems ähnelt (z.B. Fabrik1/Halle3/Linie2/OfenX/Temperatur). Dies ermöglicht es, Informationen logisch nach der Organisationsstruktur zu ordnen. Empfänger können über sogenannte Wildcards ganze Teilbäume abonnieren, um gezielt Informationen aus bestimmten Bereichen zu erhalten.
Die wichtigsten Eigenschaften
MQTT bietet eine Reihe von Eigenschaften, die es besonders attraktiv für IoT- und Industrieanwendungen machen, unter anderem:
1. Leichtgewichtig und effizient
Das Protokoll wurde für Umgebungen mit geringer Bandbreite und hohen Latenzen entwickelt. Die Nachrichten Header sind extrem klein und die Kommunikation erfolgt in kompakten binären Formaten. MQTT verursacht dadurch nur minimalen Overhead. Dies führt dazu, dass MQTT auf einfachen Mikrocontrollern betrieben werden kann. Zudem ist MQTT auch unter schwierigen Bedingungen robust und zuverlässig in der Datenübertragung – etwa über Mobilfunk- oder Satellitenverbindungen.
2. Entkoppelt und hoch skalierbar
Durch die zentrale Rolle des Brokers sind Sender und Empfänger vollständig entkoppelt. Neue Geräte oder Anwendungen können jederzeit in die Kommunikation eingebunden werden, ohne dass bestehende Systeme angepasst werden müssen. Sie veröffentlichen oder abonnieren lediglich die für sie relevanten Topics. Diese lose Kopplung vereinfacht die Integration heterogener Systeme erheblich und unterstützt eine agile, modulare Systemarchitektur. Zugleich ist MQTT äußerst skalierbar: Ein einzelner Broker kann den Nachrichtenaustausch für tausende bis hin zu Millionen von Clients koordinieren.
3. Zuverlässige Übertragung
MQTT wurde speziell für den Einsatz in instabilen oder latenzanfälligen Netzwerken konzipiert. Über drei definierte Quality-of-Service-Stufen (QoS 0, 1 und 2) lässt sich die Zustellzuverlässigkeit jeder Nachricht gezielt steuern – von „at most once“ bis hin zu „exactly once“. Je nach Anwendungsfall kann so ein passender Kompromiss zwischen Latenz, Netzwerkbelastung und Zustellsicherheit gewählt werden.
4. Ereignisgesteuert (Push statt Polling)
MQTT basiert auf dem Prinzip „Report by Exception“ – anstatt Daten zyklisch abzufragen (Polling), werden sie nur gesendet, wenn sich ein Zustand ändert oder ein relevantes Ereignis eintritt. Diese ereignisgesteuerte Push-Kommunikation minimiert unnötigen Datenverkehr und entlastet Netzwerke sowie Endgeräte. Gleichzeitig wird sichergestellt, dass alle Abonnenten stets mit den aktuellsten Informationen versorgt werden – ohne die Latenzen klassischer Abfragezyklen.
5. Offener Standard
MQTT ist ein offener OASIS-Standard. Dieser ist frei verfügbar und wird von einer großen Community sowie allen großen Cloud-Plattformen unterstützt. Dabei existieren zahlreiche Implementierungen und Client-Bibliotheken für nahezu alle Programmiersprachen. Unternehmen können so herstellerunabhängige IoT-Infrastrukturen aufbauen, in der alle Teilnehmer dieselbe Sprache sprechen. Ein weiterer Grund, warum viele Unternehmen auf MQTT setzen.
Was ist der Unified Namespace (UNS)
In der industriellen Automatisierung vollzieht sich ein Paradigmenwechsel: Weg von starren, hierarchischen Kommunikationsstrukturen hin zu ereignisgesteuerten, echtzeitfähigen Datennetzwerken. Dabei dient ein Unified Namespace (UNS) als zentrale, kontextbezogene Datenplattform, die alle Echtzeitinformationen eines Unternehmens über alle Ebenen hinweg (von OT bis IT) vereinheitlicht. Er fungiert als Informationsquelle für alle Produktionsdaten und ersetzt damit individuelle Punkt-zu-Punkt-Verbindungen durch einen zentralen Message Broker.
Alle IT- und OT-Systeme publizieren ihre Daten zentral im Message Broker und abonnieren ausschließlich die für sie relevanten Informationen. Dadurch entfallen dedizierte Punkt-zu-Punkt-Verbindungen zwischen einzelnen Systemen, die Anzahl notwendiger Integrationen sinkt signifikant. So können IT-Anwendungen wie BI-Tools, MES oder Cloud-Services in Echtzeit auf Produktionsdaten zugreifen, ohne direkt mit SPS-Protokollen interagieren zu müssen. Umgekehrt lassen sich auf dieser Basis Steuerbefehle aus übergeordneten Systemen an Maschinen und Steuerungen übermitteln. Mehr zu den Grundprinzipien des Unified Namespace (UNS) erfahren Sie hier.
MQTT im Unified Namespace (UNS)
Um der Rolle einer zentralen Datenplattform in der Fabrik technisch gerecht zu werden, muss ein Messaging-System eine Reihe spezifischer Anforderungen erfüllen. MQTT bringt genau die dafür erforderlichen Eigenschaften mit – im Folgenden systematisch aufgeschlüsselt.
1. Geringe Latenz: Ereignisse in Echtzeit verfügbar machen
Industrielle Anwendungsfälle wie Zustandsüberwachung, Predictive Maintenance oder prozessnahe Steuerlogik erfordern Latenzen im Bereich weniger Millisekunden. MQTT ist für die Übertragung von Nachrichten mit minimalem Overhead ausgelegt:
- Die Protokollstruktur ist binär und extrem schlank (fester Header: 2 Bytes)
- Die Verbindung bleibt dauerhaft offen (TCP + optional TLS),
- Die Nachrichtenübertragung erfolgt ereignisgetrieben (Push) ohne Polling.
Damit ermöglicht MQTT im Unified Namespace (UNS) eine sehr geringe End-to-End-Latenz – typischerweise im einstelligen Millisekundenbereich bei lokaler Infrastruktur.
2. Hohe Verfügbarkeit: Redundanz auf Systemebene
Produktionssysteme benötigen eine hochverfügbare Messaging-Infrastruktur. MQTT erfüllt diese Anforderung durch:
- Broker-Clustering: Moderne MQTT-Broker unterstützen horizontale Skalierung über mehrere Knoten hinweg.
- Persistente Sessions & Message Retention: Nachrichten und Zustände werden im Broker gespeichert und übergeben, sobald der Empfänger wieder online ist.
- Last-Will-Mechanismus: Bei unerwarteten Verbindungsabbrüchen kann der Broker automatisch Statusänderungen verteilen – z. B. Maschinenstatus auf „offline“ setzen.
Durch diese Funktionen lässt sich MQTT in hochverfügbare, fehlertolerante UNS-Architekturen integrieren, bei Bedarf auch über Replikation über mehrere Standorte hinweg.
3. Quality-of-Service: Konfigurierbare Zustellgarantie je nach Anwendung
Ein UNS muss sowohl hochfrequente Telemetrie-Datenübertragung als auch kritische Transaktionen unterstützen. MQTT bietet dafür drei klar definierte Quality-of-Service-Stufen:
- QoS 0 – At most once: Ungesicherte, latenzoptimierte Kommunikation, z. B. für Live-Telemetrie.
- QoS 1 – At least once: Nachrichten werden so lange gesendet, bis eine Empfangsbestätigung erfolgt. Ideal für allgemeine Betriebsdaten.
- QoS 2 – Exactly once: Zustellung exakt ein Mal – für Transaktionen, Steuerdaten oder MES-Anbindungen.
Zusätzlich unterstützt MQTT Zustellmechanismen, die sicherstellen, dass Nachrichten auch bei Netzunterbrechungen erhalten bleiben. Damit lässt sich die gewünschte Zuverlässigkeit granular pro Topic oder Nachrichtentyp definieren. Weitere Details zu QoS finden Sie hier.
4. Edge/Cloud-Skalierbarkeit: Verteilte Architektur mit konsistenter Struktur
Ein moderner UNS ist nicht monolithisch, sondern hierarchisch strukturiert und geografisch verteilt. MQTT eignet sich hervorragend für solche Architekturen:
- Edge-Einsatzfähigkeit: MQTT-Clients benötigen nur minimalste Ressourcen. Selbst kleine Gateways oder SPS-nahe Devices können als MQTT-Publisher agieren.
- Cloud- und Cluster-Fähigkeit: MQTT-Broker skalieren horizontal, können in Kubernetes-Umgebungen laufen und global verteilte Clients bedienen.
- Namespace-Strukturierung: Die hierarchischen MQTT-Topics ermöglichen logisch abgegrenzte Datenräume (z. B. pro Werk, Linie oder Maschine). Per Wildcards lassen sich selektiv ganze Subsysteme abonnieren oder weiterleiten.
So lassen sich lokale UNS-Instanzen pro Standort mit einem zentralen, unternehmensweiten Namespace logisch und technisch integrieren – mit konsistenter semantischer Struktur.
5. Ergänzende Eigenschaften
Es gibt zahlreiche weitere Eigenschaften, die MQTT im Unified Namespace (UNS) besonders prädestinieren:
- Retained Messages: MQTT erlaubt es, den letzten bekannten Wert eines Topics im Broker zu speichern – essenziell für ein zustandsbasiertes UNS.
- Push-Kommunikation (Publish/Subscribe): Statt zyklischer Abfragen erfolgt die Datenverteilung ereignisbasiert, was Latenzen senkt und Ressourcen schont.
- Sicherheit: MQTT bietet TLS-Verschlüsselung, Authentifizierung und ACLs für rollenbasierten Zugriff – industrietauglich und compliant.
MQTT 3.1.1 vs. MQTT 5 im Unified Namespace (UNS)
Während MQTT 3.1.1 in der Industrie weit verbreitet ist und die Anforderungen eines UNS erfüllt, bringt MQTT 5 einige interessante technische Erweiterungen mit. Diese sind speziell für komplexe und dynamische UNS-Architekturen relevant.
1. Benutzerdefinierte Eigenschaften (User Properties)
MQTT 5 ermöglicht das Anhängen beliebiger Schlüssel-Wert-Paare an jede Nachricht. Diese „User Properties“ erlauben es, zusätzliche semantische Informationen (z. B. Einheiten, Grenzwerte, Quellmetadaten) direkt über den Payload zu transportieren – ohne Änderung am Payload-Format. Im UNS lassen sich damit Kontextinformationen maschinenlesbar und standardisiert weitergeben.
Beispiel: Ein Sensor veröffentlicht einen Temperaturwert auf dem Topic: factory1/hall3/line2/ovenX/temperature. Der Payload enthält lediglich den reinen Messwert. Zusätzliche Kontextinformationen – etwa Einheit, Schwellenwert oder Standort – werden nicht in der Payload kodiert, sondern über MQTT 5 User Properties als strukturierte Metadaten mitgesendet. Diese befinden sich im Header der MQTT-Nachricht, genauer gesagt im Properties-Bereich des Publish-Pakets.
2. Reason Codes & Negative Acknowledgements
Im Gegensatz zu MQTT 3.1.1 erlaubt MQTT 5 eine granulare Rückmeldung bei fehlgeschlagenen Verbindungs- oder Veröffentlichungsversuchen – mit konkretem Fehlercode. Dies erleichtert die Fehlerdiagnose und ermöglicht eine robuste Betriebsüberwachung im UNS, insbesondere bei komplexen Produktionsnetzwerken mit wechselnden Topologien.
Beispiel: Ein Edge-Gateway versucht, Sensordaten an den Broker zu senden. Aufgrund einer fehlenden Berechtigung lehnt der Broker die Nachricht ab. Anders als bei MQTT 3.1.1 gibt es bei MQTT 5 nun eine explizite Rückmeldung mit Reason Code im PUBACK- oder CONNACK-Paket.
3. Topic Aliases
Um Bandbreite bei häufig wiederkehrenden Topics zu sparen – etwa in hochfrequenter Sensordatenübertragung – unterstützt MQTT 5 die Definition von Topic-Aliasen. Der eigentliche Topic-String muss nur einmal übertragen werden, danach genügt ein Alias-Index (z.B. Topic Alias: 5412). In großen und komplexen UNS-Strukturen kann dies die Latenz und CPU-Last spürbar reduzieren.
4. Verbesserte Session- und Nachrichten-Kontrolle
MQTT 5 bietet erweiterte Steuerungsmöglichkeiten für ressourcenbeschränkte Clients mit geringer Interaktionsfrequenz. Dies können Geräte sein, die nur gelegentlich Daten senden oder empfangen. Wichtige Parameter sind:
- Session Expiry Interval: Bestimmt, wie lange eine Client-Session nach Verbindungsabbruch auf dem Broker erhalten bleibt (inkl. Subscriptions und unzugestellten QoS-Nachrichten).
- Message Expiry Interval: Gibt an, wie lange eine Nachricht im Broker gespeichert bleibt, wenn der Empfänger gerade nicht verbunden ist – danach wird sie verworfen, um veraltete Daten zu vermeiden.
- Maximum Packet Size: Legt die maximale Größe von MQTT-Nachrichten fest, die ein Client oder Broker akzeptiert – nützlich zur Begrenzung von Last und Ressourcenverbrauch bei leistungsschwachen Geräten.
5. Request-Response-Semantik
Mit dem optionalen Response Topic-Feld unterstützt MQTT 5 eine strukturierte Anfrage-/Antwort-Kommunikation, was z. B. für Diagnoseprozesse oder Kommandos zwischen IT und OT-Systemen innerhalb des UNS hilfreich ist. Damit wird MQTT im Unified Namespace (UNS) nicht nur für Event-Streaming, sondern auch für transaktionsartige Kommunikation einsetzbar.
Beispiel: Ein IT-System (z. B. ein Wartungstool) möchte den aktuellen Zustand eines bestimmten Antriebs im Shopfloor abfragen. Hierzu veröffentlicht es eine Nachricht auf einem definierten Request-Topic. Der Antrieb (bzw. dessen Steuerung oder Gateway) ist so konfiguriert, dass er dieses Topic abonniert und bei Eingang eines Requests eine Antwort generiert. Die Antwort wird zurückpubliziert. Das IT-System kann die Antwort anhand des Correlation Data eindeutig dem ursprünglichen Request zuordnen.
6. Subscription Identifier und Shared Subscriptions
Durch eindeutige Subscription IDs lassen sich Subscriptions systematisch verwalten und auswerten. Shared Subscriptions ermöglichen Load-Balancing unter mehreren Abonnenten, was für verteilte Datenverarbeitung (z. B. Microservices) ein entscheidender Skalierungsfaktor ist.
Zusammenfassung
| Kriterium | MQTT 3.1.1 | MQTT 5.0 |
|---|---|---|
| Standardisierung | OASIS Standard (2014), weit verbreitet | OASIS Standard (2019), abwärtskompatibel zu 3.1.1 |
| Topic-Strukturierung | Vollständig unterstützt (hierarchisch, Wildcards) | Identisch zu 3.1.1 |
| Quality of Service (QoS) | 0, 1, 2 | 0, 1, 2 |
| Retained Messages | Unterstützt | Unterstützt |
| Session-Management | Einfach (Clean Session / Persistent Session) | Erweiterte Parameter (Session Expiry, Message Expiry, Max Packet Size) |
| Metadaten (User Properties) | Nicht unterstützt | Benutzerdefinierte Key-Value-Paare pro Nachricht |
| Fehlerrückmeldung (Reason Codes) | Nur Verbindungsfehler mit generischer Begründung | Detaillierte Reason Codes für alle MQTT-Aktionen |
| Request-Response-Unterstützung | Muss per Topic-Konvention realisiert werden | Nativ über Response Topic und Correlation Data |
| Topic Aliases | Nicht verfügbar | Reduzierter Overhead bei langen/redundanten Topic-Namen |
| Subscription Identifiers | Nicht verfügbar | Klare Unterscheidung paralleler Subscriptions |
| Shared Subscriptions | Nicht spezifiziert | Native Lastverteilung auf mehrere Subscriber |
| Diagnose- & Fehlertoleranz | Eingeschränkt (nur grundlegende Rückmeldungen) | Umfassende Kontrolle durch Reason Codes, Disconnect-Pakete etc. |
| Eignung für verteilte UNS-Architektur | Basisfähig | Für skalierbare, dynamische UNS-Strukturen optimiert |
Fazit
MQTT ist heute ein etablierter Standard im Unified Namespace (UNS) – leichtgewichtig, robust und hoch skalierbar. Dabei unterstützt MQTT 3.1.1 bereits zentrale Prinzipien wie Entkopplung, Push-basierte Kommunikation und hierarchische Topic-Strukturen. MQTT 5 baut darauf auf und erweitert das Protokoll gezielt um Funktionen für komplexe und sehr dynamische Systeme: etwa semantisch angereicherte Nachrichten, detailliertes Session-Management, strukturierte Fehlerrückmeldungen und native Lastverteilung über Shared Subscriptions.
