MQTT in der Industrieautomation: Praxishandbuch für Hersteller

Was ist MQTT?

Wer sich mit dem Industrial Internet of Things (IIoT) befasst, stößt unweigerlich auf das Akronym MQTT. Zwar relativ neu in der Automation, existiert das Protokoll seit über 20 Jahren. Ursprünglich für die Datenübertragung aus abgelegenen Ölfeldern entwickelt, fand es lange kaum Verbreitung außerhalb dieser Nische. Heute etabliert es sich als eines der Hauptprotokolle für Digitalisierungsprojekte in der Fertigung.

MQTT steht für Message Queuing Telemetry Transport. Es ist ein Client-Server-Publish/Subscribe-Messaging-Transportprotokoll – ein leichtgewichtiges Protokoll für kleine Datenpakete in bandbreitenbeschränkten Anwendungen. Kern ist ein OASIS-Standard für IoT-Konnektivität.

Historie

Ende der 1990er Jahre bestand Bedarf an einem leichtgewichtigen Protokoll für Datenübertragung von entfernten Ölstandorten mit extrem niedrigen Verbindungsgeschwindigkeiten (bis 300 Baud). Die Strategie: Nutzung der Fähigkeiten der Transportschicht (TCP). Das Anwendungsprotokoll sollte Redundanzen entfernen, die die Übertragungslast erhöhen. Es musste zustandsbehaftet (stateful) sein und nur bei Änderungen melden („report by exception“). Unter diesen Vorgaben entwickelten Phillips 66, Arlen Nipper (Cirrus Link Solutions) und Andy Stanford-Clark (IBM) das MQTT-Protokoll.

Frühe kommerzielle Nutzung

Automation-Unternehmen wurden Anfang der 2000er mit MQTT angesprochen, doch die einzige weitere kommerzielle Nutzung war Facebook Messenger und Apple Messages. Das herausragende Merkmal: Das Protokoll garantiert Zustand und Datenqualität. Beim Tippen sah der Empfänger die drei typischen Punkte. Auch in Heimüberwachung und Wetterdatenanwendungen genutzt, blieb MQTT lange begrenzt.

Adoption in der Automation

Mitte der 2010er Jahre bewarb Arlen Nipper MQTT erneut bei Automation-Unternehmen. Bedarf: zusätzliche Fertigungsdaten aggregieren ohne nennenswerte Netzlast. Es fehlten noch Fähigkeiten für die Fertigung. Cirrus Link Solutions und Inductive Automation entwickelten den Sparkplug-Standard mit für Automation nötigen Attributen: definierte Topic-Sets, standardisiertes Payload-Format, Nachrichtenkompression.

Strukturüberblick

MQTT nutzt eine hierarchische Topic-Struktur analog zu Dateisystemen. Beispiel Windows: Desktop → Eigene Dokumente → Familie → David. Pfad: Desktop/Eigene Dokumente/Familie/David. Ich speichere (publish) in David. Wer lesen will, abonniert (subscribe) David.

Geräte publizieren/abonnieren einen ähnlichen Topic-Pfad (Namespace). Organisation: allgemein → spezifisch. Je höher ich abonniere, desto mehr Daten empfange ich. Wildcards: * = aktuelles Level und darunter; + = eine Ebene tiefer. Beispiele folgen.

Ausrichtung an ISA-Standards

ISA-95 ist in der Fertigung etabliert: Standardmodell und Terminologie für die Schnittstelle zwischen Unternehmens- und Leitebene. Obwohl oft als Hierarchie (ERP oben, Devices unten) verstanden, regelt es בעיקר Fertigungsdaten und deren Struktur. Da MQTT Topic-Namespaces nutzt, lassen sich diese problemlos an ISA-95 anpassen. Empfehlung: Topic-Namespace nach Enterprise, Site, Area, Line, Cell aufbauen. Root-Ordner des Publishers/Subscribers auf passender Ebene. Beispiel: SPS steuert Cell → publiziert in Enterprise/Site/Area/Line/Cell. Prozesshistorian für Area → abonniert Enterprise/Site/Area.

Architektur & Konnektivität

Häufige Frage: Was bei Verbindungsverlust? Mehrere Lösungen:

• Store-and-Forward: SCADA-Systeme auf Control-Layer sammeln Daten weiter, bis MQTT-Broker-Verbindung wiederhergestellt ist. Zeitstempel bleiben intakt.
• Backup-Broker: Primärer Broker + automatischer Failover auf Backup-Broker. Konfiguration über Applikation (z. B. SCADA).
• Clustering: Mehrere Broker im Cluster, alle kennen sich, teilen Nachrichten. Bei Verbindungsverlust nahtloses Routing zu anderem Broker ohne Datenverlust. Für anwendungen, die keinen Datenverlust tolerieren.
• Bridging: Enterprise-Applikationen nutzen Daten aller Werke. Ein Broker publiziert/brückt Teile oder gesamten Namespace an einen anderen Broker. Werk-Broker brückt zu Enterprise-Broker. Topics und Namespace-Struktur definierbar – limitiert Datenmenge und schafft Kontext. Beispiel: Enterprise/Site vor Area/+/Cell gesetzt → Enterprise/Site/Area/+/Cell am Enterprise-Broker (alle Lines, Cell-Level).

Szenarien kombinierbar: SCADA → Store-and-Forward → MQTT-Cluster → Primär/Backup-Cluster → Werk-Cluster brückt zu Enterprise-Cluster. Ideal für Enterprise-Analytics & ML (brauchen große Mengen guter Daten).

Sicherheit

Hauptbedenken: Cybersecurity bei Fertigungsdaten über Internet. Einzig wahre Sicherheit: Air Gap – verhindert aber Digitalisierung. MQTT-Vorteil: Nur ausgehende Verbindung zum Broker nötig. Keine eingehenden Ports öffnen – sehr attraktiv für IT-Abteilungen.

Zukunftsaussichten

Weitere Artikel werden gängige MQTT-Anwendungen beleuchten. Obwohl „plug-and-play“, werden technische Details gefragt sein. Business-Leader: Auswirkungen auf Digitalisierungsbemühungen prüfen. Engineering-Leader: Auswirkungen auf eigene Arbeit verstehen.

MQTT ersetzt keine bestehende Architektur. Aligned mit Industry 4.0 nutzt es Bestehendes. OPC UA und andere Protokolle bleiben für Steuerungsanwendungen (verborener) nötig. Für Aggregation großer Datenmengen ist MQTT exzellent.