MQTT
MQTT (Message Queuing Telemetry Transport) ist ein schlankes Kommunikationsprotokoll für die Maschine-zu-Maschine-Kommunikation. Es wurde speziell für Umgebungen mit begrenzter Bandbreite und instabilen Netzwerkverbindungen entwickelt. Heute ist es als eines der zentralen Protokolle im Industrial Internet of Things (IIoT) und in der vernetzten Fertigung fest etabliert.
Inhalt
- Was ist MQTT?
- Wie funktioniert MQTT? (Broker, Client, Server, Topics)
- Welche QoS (Quality of Service)-Stufen gibt es bei MQTT?
- Was sind die Vorteile von MQTT?
- Was sind die Grenzen und Herausforderungen von MQTT?
- MQTT vs. OPC UA – was sind die Unterschiede?
- Wo wird MQTT eingesetzt? (Anwendungsfälle in IIoT & Fertigung)
- Was brauche ich, um MQTT einzusetzen?
- Wie hat sich MQTT entwickelt? (Geschichte & Versionen)
- Zusammenfassung
Was ist MQTT?
MQTT steht für Message Queuing Telemetry Transport und bezeichnet ein leichtgewichtiges Messaging-Protokoll, das auf dem Publish-Subscribe-Prinzip basiert. Anders als klassische Client-Server-Kommunikation – bei der zwei Parteien direkt miteinander sprechen – entkoppelt MQTT Sender und Empfänger über eine zentrale Vermittlungsinstanz, den sogenannten Broker.
Das Protokoll wurde ursprünglich für die Fernüberwachung von Ölpipelines entwickelt, bei der Satellitenverbindungen teuer, schmalbandig und teils unzuverlässig waren. Diese Herkunft erklärt seine wichtigsten Eigenschaften: minimaler Overhead, robuste Nachrichtenzustellung auch bei instabilen Verbindungen und effizienter Umgang mit Ressourcen.
Heute ist MQTT ein etablierter Standard in IoT-Infrastrukturen – von der Gebäudeautomation über vernetzte Fahrzeuge bis hin zur industriellen Fertigung.
Wie funktioniert MQTT? Broker, Client, Server und Topics erklärt
Das MQTT-Modell besteht aus drei Kernkomponenten: Broker, Publisher und Subscriber. Zusammen bilden sie eine flexible Kommunikationsarchitektur, in der Publisher und Subscriber einander nicht direkt kennen müssen.
Der MQTT-Broker (Server)
Der Broker ist das Herzstück jedes MQTT-Netzwerks. Er nimmt eingehende Nachrichten entgegen und leitet sie an alle Clients weiter, die diese Topics abonniert haben. Die fachliche Bedeutung der Nutzdaten interpretiert der Broker dabei nicht – er fungiert als reiner Vermittler zwischen Sendern und Empfängern. Weit verbreitete Lösungen sind etwa Eclipse Mosquitto, HiveMQ oder EMQX. Für den Betrieb werden üblicherweise die von der IANA registrierten Ports 1883 für unverschlüsselte MQTT-Verbindungen und 8883 für MQTT über TLS verwendet.
Publisher und Subscriber (Clients)
Jeder Teilnehmer im Netzwerk ist ein MQTT-Client – entweder als Publisher (Datensender), als Subscriber (Datenempfänger) oder in beiden Rollen gleichzeitig. Ein Temperatursensor in der Produktion etwa sendet kontinuierlich Messwerte an den Broker; ein Leitsystem auf der Empfängerseite hat diesen Datenstrom abonniert und reagiert automatisch auf Grenzwertüberschreitungen.
Publisher und Subscriber (Clients)
Jeder Teilnehmer im Netzwerk ist ein MQTT-Client – entweder als Publisher (Datensender), als Subscriber (Datenempfänger) oder in beiden Rollen gleichzeitig. Ein Temperatursensor in der Produktion etwa sendet kontinuierlich Messwerte an den Broker; ein Leitsystem auf der Empfängerseite hat diesen Datenstrom abonniert und reagiert automatisch auf Grenzwertüberschreitungen.
Welche QoS (Quality of Service)-Stufen gibt es bei MQTT?
Ein wesentliches Merkmal von MQTT ist die Steuerung der Übertragungszuverlässigkeit über drei Quality-of-Service-Stufen (QoS). Je nach Anwendungsfall lässt sich damit der Trade-off zwischen Geschwindigkeit, Netzwerk-Overhead und Zustellsicherheit gezielt steuern.
QoS 0 – At most once (höchstens einmal)
Die Nachricht wird einmalig gesendet, ohne Bestätigung. Geht sie verloren, erfolgt keine Wiederholung. Diese Stufe eignet sich für unkritische Telemetriedaten, bei denen ein gelegentlicher Datenverlust tolerierbar ist – etwa bei hochfrequenten Sensorwerten, bei denen der nächste Messwert ohnehin kurze Zeit später folgt.
QoS 1 – At least once (mindestens einmal)
Der Broker sendet die Nachricht und erwartet eine Bestätigung vom Empfänger. Bleibt diese aus, überträgt er sie erneut, bis der Empfang quittiert ist. Das sichert die Zustellung mindestens einmal ab; dieselbe Nachricht kann jedoch mehrfach ankommen. Empfänger müssen also mit Duplikaten umgehen können.
QoS 2 – Exactly once (genau einmal)
Der aufwendigste Modus: Ein mehrstufiger Handshake stellt auf Protokollebene sicher, dass die Nachricht beim Empfänger genau einmal ankommt. Diese Stufe verursacht den höchsten Overhead und ist für Fälle vorgesehen, in denen weder Nachrichtenverlust noch Duplikate akzeptabel sind – etwa bei Quittierungen, Fertigungsaufträgen, Qualitätsfreigaben oder Abrechnungsdaten.
Was sind die Vorteile von MQTT?
MQTT hat sich nicht zufällig als De-facto-Standard im IIoT durchgesetzt. Die Architektur bringt eine Reihe von Eigenschaften mit, die gerade in industriellen Umgebungen entscheidend sind.
Geringer Ressourcenbedarf: Das Protokoll arbeitet mit einem minimalen Nachrichten-Overhead – ein MQTT-Paket kann wenige Byte klein sein. Selbst Geräte mit sehr begrenzter Rechenleistung und knappem Arbeitsspeicher, wie einfache Mikrocontroller an Maschinensteuerungen oder Sensoren direkt an der Fertigungslinie, können problemlos als MQTT-Clients betrieben werden. Das senkt die Hardwareanforderungen und damit die Kosten pro angebundenem Gerät erheblich.
Robustheit bei schlechter Netzwerkqualität: MQTT ist darauf ausgelegt, auch bei hoher Latenz, begrenzter Bandbreite oder instabilen Verbindungen zuverlässig zu funktionieren – eine Eigenschaft, die in weitläufigen Produktionshallen oder an entlegenen Maschinen täglich relevant ist. Verbindungsabbrüche werden durch einen konfigurierbaren Keep-Alive-Mechanismus erkannt. Für zeitweise offline gegangene Clients kann der Broker Nachrichten unter bestimmten Voraussetzungen zwischenspeichern, etwa bei persistenten Sessions und QoS 1 oder QoS 2. Retained Messages erfüllen dagegen eine andere Funktion: Sie speichern pro Topic die zuletzt veröffentlichte Nachricht mit dem Retained-Flag und liefern neuen Subscribern dadurch sofort den letzten bekannten Zustand.
Skalierbarkeit ohne Architekturbruch: Die Entkopplung von Publisher und Subscriber erlaubt es, Tausende von Endgeräten an einen einzigen Broker anzubinden, ohne die bestehende Infrastruktur anpassen zu müssen. Eine neue Maschine, ein zusätzlicher Sensor oder ein weiteres Leitsystem lassen sich jederzeit einbinden – das System wächst mit, ohne neu geplant werden zu müssen.
Bidirektionale Kommunikation: Im Gegensatz zu reinen Polling-Mechanismen, bei denen ein System regelmäßig aktiv anfragen muss, können über MQTT Steuerbefehle genauso einfach an Geräte gesendet werden, wie Statusinformationen empfangen werden. Das ist ein entscheidender Vorteil für Regelkreise und Fernsteuerungsszenarien in der Fertigung.
Zeitnahe Datenverfügbarkeit: Durch das ereignisgesteuerte Publish-Subscribe-Modell stehen neue Messwerte unmittelbar nach ihrer Erfassung allen passenden Abonnenten zur Verfügung – ohne zusätzliche Polling-Verzögerung. Für zeitkritische Anwendungen wie Qualitätssicherung, Anlagenüberwachung, Zustandsmonitoring oder Prozessvisualisierung ist das ein wesentlicher Vorteil gegenüber intervallbasierten Übertragungsverfahren.
Offener, breit unterstützter Standard: MQTT ist ein international standardisiertes Protokoll mit einer großen Entwicklercommunity und ausgereiftem Ökosystem. Nahezu alle gängigen Programmiersprachen verfügen über stabile Client-Bibliotheken, und die meisten IIoT-Plattformen sowie Cloud-Anbieter unterstützen MQTT nativ – was Integrationsprojekte erheblich vereinfacht.
Was sind die Grenzen und Herausforderungen von MQTT?
So gut MQTT für viele IIoT-Szenarien geeignet ist – es gibt Anforderungen, für die das Protokoll an seine Grenzen stößt.
Kein eingebautes Datenmodell: MQTT transportiert Nachrichten als rohe Bytes ohne festgelegtes Format. Welche Bedeutung ein Messwert hat, welche Einheit er trägt oder wie er sich zu anderen Werten verhält, ist im Protokoll selbst nicht definiert. Das erfordert zusätzliche Konventionen oder Metadaten auf Anwendungsebene.
Sicherheit nicht vollständig im Protokollkern: MQTT selbst verschlüsselt keine Nachrichten. Sicherheit wird in der Praxis über TLS auf Transportebene sowie über Authentifizierung, Autorisierung und Zugriffskontrollen im Broker umgesetzt. Das ist leistungsfähig, erfordert aber eine sorgfältige Konfiguration – nicht zuletzt im Hinblick auf Datenschutz.
Keine fachliche Transaktionslogik: MQTT kann die Zustellung einzelner Nachrichten über QoS-Stufen absichern, etwa mit QoS 2 für eine genau einmalige Zustellung auf Protokollebene. Komplexe, zustandsbehaftete Abläufe – etwa mehrstufige Auftrags- oder Prozessabläufe mit Rückmeldeschleifen – bildet MQTT jedoch nicht selbst ab. Solche Prozesszustände, Abhängigkeiten und Fehlerfälle müssen auf Anwendungsebene modelliert werden.
Broker als möglicher Single Point of Failure: In einfachen Architekturen ist die zentrale Rolle des Brokers zugleich eine Schwachstelle. Fällt ein einzelner Broker aus, kann die Kommunikation unterbrochen werden. Hochverfügbare Setups mit Clustering, Replikation oder verwalteten Broker-Diensten sind möglich, erhöhen aber die technische Komplexität.
MQTT vs. OPC UA – was sind die Unterschiede?
In industriellen Umgebungen begegnen sich MQTT und OPC UA häufig als scheinbare Konkurrenten – tatsächlich sind sie komplementäre Technologien, die unterschiedliche Problemstellungen adressieren.
OPC UA (Open Platform Communications Unified Architecture) ist ein umfassender Industriestandard, der neben dem Datentransport auch semantische Datenmodellierung, Sicherheit, Zugriffskontrolle und plattformunabhängige Interoperabilität definiert. Werte werden dabei nicht nur übertragen, sondern können über ein Informationsmodell mit Bedeutung, Einheit, Datentyp und Kontext beschrieben werden. Das Gerät beschreibt sich gewissermaßen selbst.
MQTT hingegen ist deutlich schlanker und agnostisch gegenüber Inhalten. Es definiert, wie Nachrichten transportiert werden – nicht, was sie fachlich bedeuten.
| Merkmal | MQTT | OPC UA |
|---|---|---|
| Hauptfokus | Datentransport | Datenmodellierung + Transport |
| Ressourcenbedarf | Sehr gering | Höher |
| Semantik | Keine Semantik im Protokollkern | Über Informationsmodell integriert |
| Sicherheit | Typischerweise über TLS, Broker-Konfiguration und ACLs | Im Standard umfassend vorgesehen |
| Typische Anwendung | Sensordaten, Telemetrie, Edge-to-Cloud | Maschinenintegration, MES/SCADA, industrielle Interoperabilität |
In der Praxis werden beide Protokolle oft kombiniert: OPC UA strukturiert und beschreibt Daten auf Maschinenebene, MQTT überträgt sie effizient in Richtung Cloud oder übergeordneter Systeme. Mit OPC UA PubSub ist die Übertragung strukturierter OPC-UA-Daten über MQTT inzwischen formal spezifiziert.
Wo wird MQTT eingesetzt? Anwendungsfälle in IIoT und Fertigung
MQTT findet überall dort Verwendung, wo viele Geräte zuverlässig und ressourcenschonend Daten austauschen müssen. In der industriellen Fertigung sind das vor allem folgende Szenarien:
Maschinenzustandsüberwachung (Condition Monitoring)
Sensoren an Produktionsanlagen senden kontinuierlich Vibrations-, Temperatur- oder Druckwerte über MQTT an übergeordnete Systeme. Abweichungen vom Normalzustand lassen sich dadurch zeitnah erkennen, bevor sie zu ungeplanten Stillständen führen. Ein Automobilzulieferer kann beispielsweise zahlreiche Prüf- oder Prozesspunkte parallel überwachen und Qualitätsabweichungen automatisch an ein Analyse- oder Leitsystem melden – ohne dass ein Mensch aktiv Daten abfragen muss.
Fertigungsdatenerfassung (MDE)
MQTT dient als Transportschicht für die automatische Erfassung von Maschinendaten – etwa Stückzahlen, Taktzeiten oder Fehlercodes – und deren Weiterleitung an MES- oder ERP-Systeme. In einer verketteten Produktionslinie publiziert jede Maschine ihren Status eigenständig; das übergeordnete System abonniert alle relevanten Topics und erhält so ein laufend aktualisiertes Bild der Gesamtauslastung.
Edge-to-Cloud-Kommunikation
An der Schnittstelle zwischen Shopfloor und Cloud-Plattformen hat sich MQTT als schlankes Protokoll für die Übertragung von Telemetrie- und Zustandsinformationen etabliert. Daten werden am Edge vorverarbeitet und anschließend effizient weitergeleitet – etwa wenn ein Produktionsstandort Maschinendaten an eine zentrale Analyseplattform übermittelt, die standortübergreifende OEE-Auswertungen erstellt.
Predictive Maintenance
Die kontinuierliche Übertragung von Sensordaten ist eine wichtige Grundlage für vorausschauende Instandhaltung. Ein typisches Szenario: Vibrationssensoren an Spindeln einer CNC-Maschine liefern per MQTT fortlaufend Messwerte; ein Analysemodell erkennt anhand charakteristischer Muster frühzeitig Hinweise auf einen möglichen Lagerausfall und löst automatisch einen Wartungsauftrag aus.
Energiemanagement
Verbrauchsdaten von Maschinen, Beleuchtung oder Klimatechnik lassen sich über MQTT zentral bündeln und zeitnah auswerten. In einer Gießerei beispielsweise können Lastspitzen gezielt reduziert werden: Sobald der Gesamtverbrauch einen definierten Schwellenwert überschreitet, drosselt das System nicht kritische Verbraucher oder verschiebt energieintensive Prozesse – auf Basis fortlaufend eintreffender MQTT-Nachrichten.
Was brauche ich, um MQTT einzusetzen?
Der Einstieg in MQTT ist technisch überschaubar – die Kernkomponenten sind schnell zusammengestellt, und dank der breiten Ökosystemunterstützung gibt es für nahezu jeden Anwendungsfall fertige Bausteine.
MQTT-Broker
Der Broker ist die zentrale Infrastrukturkomponente einer klassischen MQTT-Architektur. Für den Einstieg und kleinere Installationen eignet sich Eclipse Mosquitto – ein schlanker Open-Source-Broker, der auf Standard-Hardware läuft und einfach zu konfigurieren ist. Für produktive Umgebungen mit hohen Anforderungen an Skalierbarkeit und Verwaltbarkeit bieten sich kommerzielle Broker-Lösungen oder gehostete MQTT-Dienste großer Cloud- und Plattformanbieter an.
MQTT-Client-Bibliothek
Auf jedem Gerät oder System, das Daten senden oder empfangen soll, wird eine MQTT-Client-Bibliothek benötigt. Die Auswahl ist groß: Für Python ist Eclipse Paho MQTT eine etablierte Lösung mit breiter Dokumentation; für Java, C und weitere Sprachen existieren ebenfalls ausgereifte MQTT-Client-Implementierungen. Embedded-Systeme und Mikrocontroller werden über speziell optimierte Bibliotheken oder Frameworks angebunden, etwa PubSubClient oder ArduinoMqttClient im Arduino-Umfeld sowie den MQTT-Client von ESP-IDF für ESP32-basierte Systeme.
Netzwerkverbindung
MQTT selbst stellt keine besonderen Anforderungen an die Netzwerkinfrastruktur – es läuft über jede TCP/IP-fähige Verbindung, ob Ethernet, WLAN oder Mobilfunk. Für verschlüsselte Übertragung wird TLS auf Transportebene empfohlen, was je nach Sicherheitsmodell eine passende Zertifikatsverwaltung voraussetzt.
Planung der Topic-Struktur
Kein Tool, aber in der Praxis oft unterschätzt: Bevor die ersten Geräte angebunden werden, sollte die Topic-Hierarchie sorgfältig geplant werden. Eine konsistente Benennung – etwa nach dem Schema standort/bereich/maschine/datenpunkt – erleichtert spätere Erweiterungen erheblich und verhindert ein schwer wartbares Durcheinander im laufenden Betrieb.
Test- und Debugging-Tools
Für Entwicklung, Tests und Fehlersuche sind grafische MQTT-Clients sehr hilfreich. Werkzeuge wie MQTT Explorer machen die Topic-Struktur sichtbar, zeigen eingehende Nachrichten live an und ermöglichen es, Testnachrichten manuell zu publizieren – ohne dafür direkt eigenen Code schreiben zu müssen.
Wie hat sich MQTT entwickelt? Geschichte und Versionen
MQTT wurde 1999 von Andy Stanford-Clark (IBM) und Arlen Nipper (damals Arcom) entwickelt, um Sensordaten von Ölpipelines zuverlässig über schmalbandige und teure Satellitenverbindungen zu übertragen. Die Anforderungen damals – geringer Ressourcenbedarf, knappe Bandbreite und hohe Zuverlässigkeit – haben das Protokolldesign bis heute geprägt.
2013 begann die Standardisierung von MQTT bei OASIS, der Organization for the Advancement of Structured Information Standards.
MQTT 3.1.1 wurde 2014 als OASIS-Standard verabschiedet und später auch als ISO/IEC 20922:2016 ratifiziert. Diese Version ist bis heute in vielen produktiven Umgebungen im Einsatz.
MQTT 5.0 wurde 2019 als OASIS-Standard verabschiedet und brachte wesentliche Erweiterungen: verbesserte Fehlerbehandlung, Message Expiry, Shared Subscriptions für Lastverteilung sowie umfangreichere Metadaten in Form von User Properties. Für neue Projekte ist MQTT 5.0 in der Regel die bevorzugte Wahl, sofern Broker und Clients die Version vollständig unterstützen.
MQTT kompakt: die wichtigsten Punkte
MQTT ist ein schlankes, auf dem Publish-Subscribe-Prinzip basierendes Kommunikationsprotokoll, das speziell für ressourcenbeschränkte Geräte und unzuverlässige Netzwerke entwickelt wurde. Sein zentrales Element ist der Broker, der Nachrichten zwischen sendenden und empfangenden Clients vermittelt, ohne dass diese direkt miteinander kommunizieren müssen.
Drei QoS-Stufen erlauben eine gezielte Abstufung der Zustellsicherheit – von der schnellen Übertragung ohne Zustellbestätigung bis hin zur genau einmaligen Zustellung auf Protokollebene. Im Vergleich zu OPC UA punktet MQTT mit geringem Ressourcenbedarf und hoher Skalierbarkeit; für semantisch reichhaltige Datenmodelle wird es in der Praxis häufig mit OPC UA kombiniert.
In der vernetzten Fertigung und im IIoT ist MQTT heute fest etabliert: als Übertragungsschicht für Maschinendaten, als Bindeglied zwischen Shopfloor und Cloud und als Grundlage für Anwendungen von der Zustandsüberwachung bis zur vorausschauenden Instandhaltung. Mit MQTT 5.0 steht eine moderne, funktional erweiterte Version bereit, die auch anspruchsvollere IIoT-Architekturen unterstützt.
