Was ist MQTT?
MQTT (Message Queuing Telemetry Transport) ist ein schlankes Nachrichtenprotokoll, das auf dem Publish/Subscribe-Prinzip basiert und speziell für Umgebungen mit instabilen Netzwerken, geringer Bandbreite und ressourcenbeschränkten Geräten entwickelt wurde. In der Fertigungsindustrie ist MQTT eines der meistgenutzten Protokolle für die Übertragung von Maschinendaten an Cloud-Plattformen und MES-Systeme.
Das Protokoll wurde 1999 von IBM und Arcom für die Überwachung von Öl-Pipelines über Satellitennetzwerke entwickelt, 2013 als offener Standard unter OASIS veröffentlicht und hat sich seitdem als De-facto-Standard für IIoT-Kommunikation etabliert. Der entscheidende Vorteil gegenüber klassischen Request/Response-Protokollen wie HTTP: MQTT hält Verbindungen dauerhaft offen und überträgt Daten nur dann, wenn sich etwas ändert, was den Netzwerk-Overhead auf ein Minimum reduziert.
Wie MQTT in der Fertigungspraxis funktioniert
MQTT trennt Sender und Empfänger vollständig voneinander. Kein Gerät kommuniziert direkt mit einem anderen, alle Nachrichten laufen über einen zentralen Broker.
| Rolle |
Funktion |
Beispiel in der Fertigung |
| Publisher |
Sendet Nachrichten zu einem Topic an den Broker |
IoT-Gateway an der CNC-Maschine sendet Zykluszeit |
| Broker |
Empfängt, filtert und verteilt Nachrichten |
Mosquitto oder HiveMQ auf dem Edge-Server |
| Subscriber |
Empfängt Nachrichten zu abonnierten Topics |
Cloud-MES empfängt OEE-relevante Signale in Echtzeit |
Topics sind hierarchisch strukturiert, zum Beispiel "werk/halle1/anlage03/zustand". Ein MES-System kann damit selektiv nur die Daten einer bestimmten Anlage oder einer gesamten Halle abonnieren, ohne den gesamten Datenstrom verarbeiten zu müssen. Bei 200 vernetzten Maschinen ist diese Filterlogik entscheidend für die Systemperformance.
MQTT definiert drei Quality-of-Service-Stufen: QoS 0 sendet einmalig ohne Bestätigung, QoS 1 garantiert mindestens eine Zustellung, QoS 2 garantiert exakt eine Zustellung. Für sicherheitsrelevante Fertigungsdaten wie Qualitätsmesswerte oder Alarme sollte QoS 2 verwendet werden, auch wenn dies mehr Netzwerkressourcen beansprucht.
MQTT vs. OPC-UA: Wann welches Protokoll
In der Fertigungsautomatisierung werden MQTT und OPC-UA häufig als Alternativen diskutiert. Sie lösen aber unterschiedliche Probleme und werden in der Praxis oft kombiniert.
| Kriterium |
MQTT |
OPC-UA |
| Protokolltyp |
Transport-Protokoll |
Transport + Datenmodell |
| Datenmodellierung |
Keines, nur Nachrichten |
Standardisiertes Informationsmodell |
| Ressourcenbedarf |
Sehr gering |
Mittel bis hoch |
| Interoperabilität |
Eingeschränkt ohne gemeinsames Schema |
Hoch durch standardisierte Namespaces |
| Typischer Einsatz |
Cloud-Anbindung, Edge-to-Cloud |
Maschine-zu-Maschine, MES-Integration |
In modernen IIoT-Architekturen ist die Kombination aus beiden Protokollen verbreitet: OPC-UA kommuniziert zwischen SPS und Edge-Gateway, MQTT transportiert die aggregierten Daten von dort in die Cloud. OPC-UA over MQTT, seit 2020 offiziell spezifiziert, vereint beide Ansätze in einem Standard.
Sicherheit in MQTT-Implementierungen
MQTT ist von Haus aus ein schlankes Protokoll ohne eingebaute Sicherheitsmechanismen. In Produktionsumgebungen ist das ein kritischer Punkt, der in der Praxis häufig unterschätzt wird.
Mindestanforderungen für MQTT in der Fertigung: TLS-Verschlüsselung auf Transportebene, zertifikatsbasierte Authentifizierung statt Benutzername/Passwort, Topic-basierte Zugriffskontrolle im Broker und Netzwerksegmentierung zwischen OT und IT. MQTT-Broker wie HiveMQ oder Mosquitto unterstützen alle diese Mechanismen, sie müssen aber explizit konfiguriert werden. Ein MQTT-Broker ohne TLS in einem Produktionsnetzwerk ist ein Sicherheitsrisiko, das wir bei IIoT-Projekten regelmäßig antreffen.
Typische Fehler bei MQTT-Implementierungen in der Fertigung
Fehler 1: Kein Datenmodell definiert. MQTT transportiert beliebige Payloads, macht aber keine Vorgaben zum Format. Ohne gemeinsames Schema zwischen Publisher und Subscriber entstehen Datensilos, die keine übergreifende Auswertung erlauben. JSON mit festgelegter Feldstruktur oder Sparkplug B als MQTT-Erweiterung für industrielle Daten lösen dieses Problem.
Fehler 2: QoS-Level pauschal auf 0 gesetzt. QoS 0 ist das ressourcensparendste Setting, bietet aber keine Zustellgarantie. Für Produktionsdaten die in OEE-Berechnungen oder Qualitätsdokumentation einfließen, ist QoS 0 ungeeignet. Verlorene Nachrichten erzeugen Datenlücken, die im MES als Stillstand interpretiert werden.
Fehler 3: Broker-Ausfall nicht eingeplant. Ein einzelner MQTT-Broker ist ein Single Point of Failure. In Produktionsumgebungen mit 24/7-Betrieb braucht der Broker entweder ein Clustering-Setup oder eine persistente Queue, die Nachrichten bei Verbindungsunterbrechung zwischenspeichert.
Häufige Fragen zu MQTT
Ist MQTT für alle Maschinentypen geeignet?
MQTT eignet sich für alle Maschinen, die über ein IP-Netzwerk erreichbar sind. Ältere Maschinen ohne Netzwerkschnittstelle benötigen ein IoT-Gateway, das Maschinensignale erfasst und als MQTT-Publisher in das Netzwerk einspeist. Das Gateway übernimmt die Protokollkonvertierung, die Maschine selbst bleibt unverändert.
Was ist der Unterschied zwischen MQTT und REST-API?
REST-APIs arbeiten nach dem Request/Response-Prinzip: ein System fragt aktiv an, das andere antwortet. MQTT ist ereignisgesteuert: Daten werden sofort übertragen, wenn sie anfallen, ohne dass ein System aktiv anfragen muss. Für Echtzeit-Maschinendaten mit hoher Aktualisierungsfrequenz ist MQTT deutlich effizienter als REST.
Welche MQTT-Broker werden in der Industrie eingesetzt?
Die verbreitetsten Broker in industriellen Umgebungen sind HiveMQ, Mosquitto und EMQX. HiveMQ ist auf Enterprise-Anforderungen ausgelegt und bietet native OPC-UA-Integration. Mosquitto ist ein schlanker Open-Source-Broker für kleinere Installationen. EMQX skaliert auf Millionen gleichzeitiger Verbindungen und eignet sich für große IIoT-Plattformen.
Wie SYMESTIC MQTT-Daten direkt in Echtzeit-OEE und Produktionskennzahlen verarbeitet, zeigt SYMESTIC Cloud MES in der Praxis.
