MQTT Technologie-Lösungen

Was ist MQTT?

MQTT (Message Queuing Telemetry Transport) ist ein schlankes Nachrichtenprotokoll nach dem Publish/Subscribe-Prinzip. Geräte senden ihre Daten nicht direkt an einen Empfänger, sondern veröffentlichen sie unter einem Topic, etwa werk1/halle3/presse7/temperatur, an einen zentralen Broker. Jede Anwendung, die dieses Topic abonniert hat, bekommt die Nachricht zugestellt. MQTT läuft über TCP/IP, ist seit 2014 ein OASIS-Standard und in Version 3.1.1 als ISO/IEC 20922 genormt; die aktuelle Version MQTT 5 ergänzt unter anderem bessere Fehlermeldungen und Nachrichten-Metadaten.

Wofür man MQTT im IIoT einsetzt

In der Industrie ist MQTT vor allem das Transportprotokoll zwischen Shopfloor und IT: Gateways und Edge-Geräte sammeln Werte aus Maschinen, Sensoren und Steuerungen und schicken sie per MQTT an eine Cloud-Plattform, ein Dashboard oder eine Datenbank. Weil Sender und Empfänger sich nicht kennen müssen, wächst eine MQTT-Architektur einfach mit. Drei Dienstgüten (QoS 0, 1 und 2), gespeicherte letzte Werte (Retained Messages) und die Last-Will-Nachricht bei Verbindungsabbruch machen das Protokoll robust gegen wacklige Netze, etwa über Mobilfunk. MQTT ist außerdem das Rückgrat der meisten Unified-Namespace-Architekturen.

MQTT oder OPC UA?

Die beiden Standards konkurrieren weniger, als es oft heißt. OPC UA beschreibt Maschinendaten semantisch, mit Datentypen, Einheiten und standardisierten Informationsmodellen, und ist in Steuerungen und Maschinen weit verbreitet. MQTT transportiert Daten effizient und skalierbar, schreibt aber nicht vor, wie eine Nachricht aufgebaut ist. In der Praxis liest ein Gateway die Daten per OPC UA aus der Maschine und verteilt sie per MQTT weiter. Wer Struktur auch im MQTT-Payload will, greift zu Sparkplug B oder zu OPC UA PubSub über MQTT.

So sieht eine MQTT-Architektur in der Praxis aus

Am Anfang steht meist ein Edge-Gateway an der Maschine oder im Schaltschrank. Es liest Werte per OPC UA, Modbus oder IO-Link, wandelt sie in MQTT-Nachrichten um und publiziert sie an einen Broker im Werk. Dort abonnieren Dashboards, Datenbanken für Zeitreihen und das MES die Topics, die sie brauchen. Eine Bridge oder ein zweiter Broker in der Cloud übernimmt ausgewählte Daten für standortübergreifende Auswertungen. Fällt die Verbindung nach außen aus, läuft die lokale Ebene weiter.

Worauf man bei der Auswahl achten sollte

Die wichtigste Entscheidung ist der Broker. Eclipse Mosquitto ist schlank und quelloffen und reicht für viele Einzelanlagen. Für mehrere Standorte, Hochverfügbarkeit und zehntausende Verbindungen kommen Cluster-fähige Broker wie HiveMQ oder EMQX oder die MQTT-Dienste der Cloud-Anbieter infrage. Daneben sollte man früh festlegen, wie Topics benannt werden und welches Payload-Format gilt, denn nachträgliche Umbenennungen sind teuer. Und ohne TLS-Verschlüsselung und Authentifizierung pro Gerät gehört kein Broker ins Produktionsnetz.