- IT&Production - https://www.it-production.com -

MQTT im Industrial Internet of Things

Erfolgsgeschichte eines Protokolls

MQTT im Industrial Internet of Things

Obwohl das MQTT-Protokoll bereits seit etwa zwei Jahrzehnten existiert, ist es durch sein Konzept bestens für moderne IIoT-Anwendungen geeignet. Vor allem für solche, die sich auf eine aktive Benachrichtigung stützen. Also dort, wo Geräte nur bei Bedarf Daten bereitstellen und nicht regelmäßig, wie bei der passiven Benachrichtigung. Doch wie lässt sich der Erfolg von MQTT im IIoT erklären, und was sollte man vor dem Einsatz des Übertragungsprotokolls wissen?

 (Bild: Moxa Europe GmbH) [1]

(Bild: Moxa Europe GmbH)

Das MQTT-Messaging-Protokoll wurde erstmals 1999 von IBM und Cirrus Link (damals noch Arcom Control Systems) entwickelt und ist ab Version 3.1 seit 2013 als ISO-Standard akzeptiert. MQTT verwendet ein Publish-Subscribe-Muster, um Nachrichten auszutauschen. Ein MQTT-System umfasst einen Broker und mehrere Clients, bei denen die Clients entweder Publisher oder Subscriber, also Abonnenten, sein können. Publisher senden Daten an den Broker in Form von MQTT-Paketen, die aus einem ‚Thema‘ und einer ‚Nutzlast‘ bestehen. Der Broker verteilt die Daten dann an die Abonnenten, je nachdem, für welche Themen sie sich interessiert haben. Das MQTT-Protokoll legt kein Standardformat für die Datenübertragung fest, obwohl Anwendungen üblicherweise das JSON-Protokoll oder Nur-Text verwenden. Im Vergleich zu anderen Protokollen bietet MQTT für IoT-Anwendungen eine Reihe von Vorzügen.

Messaging-Muster für Pub-Sub

Im Vergleich zu anderen Request-Response-Pattern-Protokollen ermöglicht das von MQTT verwendete Publish-Subscribe-Muster, dass IoT-Entwickler bestimmte häufige Verbindungsprobleme lösen können. Anfrage-Antwort-Muster (Request-Response-Muster) erfordern beispielsweise, dass Client und Server gleichzeitig online sind, um sicherzustellen, dass Daten erfolgreich übertragen und empfangen werden. Insbesondere für IIoT-Anwendungen kann es jedoch unmöglich sein, dass Geräte eine ausreichend starke Verbindung zum Netzwerk aufrechterhalten, um die erforderlichen Daten zu empfangen, folglich ist das Anfrage-Antwort-Muster für solche Anwendungen nicht geeignet. Das MQTT-Muster für Veröffentlichungen und Abonnements ist auf Situationen zugeschnitten, in denen nicht garantiert wird, dass Geräte gleichzeitig mit dem Netzwerk verbunden sind. Der MQTT-Broker ist in dieser Hinsicht entscheidend. Der Broker fungiert als Informationszentrum, indem er Daten annimmt, die von als ‚Herausgeber‘ bezeichneten Clients an ihn gesendet wurden, und die Daten dann an als ‚Abonnenten‘ bezeichnete Clients gesendet werden. Wenn der Broker die Daten an einen Abonnenten sendet, prüft er zuerst, ob der Zielclient online ist oder nicht. Wenn nicht, kann der Broker die Daten aufbewahren, bis der Abonnent online ist, und diese dann senden. Ein Vorteil dieser Strategie ist, dass nur der Broker ständig online sein muss. Die Clients – sowohl Publisher als auch Abonnenten- müssen nur online sein, wenn eine Verbindung verfügbar ist oder wenn sie Daten senden oder empfangen müssen.

Ereignisgesteuert

Bei Verwendung eines Publish-Subscribe-Musters veröffentlichen MQTT-Clients nur Daten an den Broker, wenn bestimmte Bedingungen erfüllt sind: z.B. könnte ein Warnsignal darauf hinweisen, dass die Temperatur eines bestimmten Geräts zu hoch ist. Eine andere Möglichkeit, diese Art von Vorgang zu beschreiben, besteht darin, dass Clients aktiv Daten aktualisieren, anstatt passiv darauf zu warten, dass ein anderes Gerät die Daten anfordert. Bei IoT-Anwendungen werden Kommunikationsgebühren abhängig von der Anzahl der übertragenen Datenpakete berechnet. Verglichen mit einem Anforderungs-Antwort-Muster spart MQTT Geld, da zur Durchführung der Datenübertragung nur unidirektionale Kommunikation erforderlich ist.

Architektur zur direkten Anbindung an die Cloud (Bild: Moxa Europe GmbH) [2]

Architektur zur direkten Anbindung an die Cloud (Bild: Moxa Europe GmbH)

Viele-zu-Viele-Kommunikation

Einer der Hauptvorteile von MQTT besteht darin, dass ein Publish-Subscribe-Muster verwendet werden kann, um auf einfache Weise eine Kommunikation zwischen vielen Benutzern herzustellen. Das Machine-to-Machine-(M2M)-Konzept, bei dem die Kommunikation zwischen mehreren Teilnehmern realisiert wird, ist eines der heißesten Themen im IIoT. In werkseitigen M2M-Anwendungen teilen Maschinen an jeder Station ihren eigenen Prozessstatus mit Maschinen an anderen Stationen. Das Teilen von Informationen auf diese Weise dient zur Automatisierung der Produktionsoptimierung, ohne dass manuelle Eingaben von Bedienern erforderlich sind. Da MQTT zur Implementierung der M2M-Kommunikation verwendet wird, müssen Maschinen nur eine Verbindung mit dem Broker aufbauen, anstatt direkt miteinander zu kommunizieren, wodurch beim Handshaking eine erhebliche Zeitersparnis entsteht. Da ein Broker die Kommunikation zwischen allen Maschinen abwickelt, ist die Datenübertragung zuverlässiger.

Erfolgsgeschichte eines Protokolls

MQTT im Industrial Internet of Things

Sicherheit im IIoT

Sicherheit ist für IIoT-Anwendungen ein Hauptanliegen. In Bezug auf MQTT unterstützt der Broker Kontonamen und Kennwörter, um zu verhindern, dass nicht autorisierte Clients eine Verbindung zum Broker herstellen, um Themen zu abonnieren. MQTT unterstützt auch die TLS-Verschlüsselung für Datenübertragungen, um die Wahrscheinlichkeit zu reduzieren, dass Daten während der Übertragung gehackt werden.

Direkte Verbindung zur Cloud

Die meisten öffentlichen Clouddienste (AWS, Azure, Google Cloud, Alibaba Cloud usw.) unterstützen das MQTT-Protokoll, damit Edge-Geräte eine direkte Verbindung zur Cloud herstellen können. Bei der Auswahl eines solchen Dienstes sollten mindestens die Faktoren Wartung, Service und Zuverlässigkeit sowie die verfügbaren Data Mining-Tools berücksichtigt werden. Der direkte Anschluss von Edge-Geräten an die Cloud hat Vorteile; man sollte jedoch auch die verschiedenen Probleme kennen, die mit der Einführung von Cloudservices für IIoT-Anwendungen zusammenhängen. Da Clouddienste den Benutzern die Anzahl der übertragenen Datenpakete in Rechnung stellen, ist es meist nicht kostengünstig, Daten von Edge-Geräten direkt an einen Cloudservice zu übertragen. Selbst wenn die Edge-Geräte über ein Mobilfunknetz mit der Cloud verbunden sind, muss man dennoch für diesen Mobilfunkdienst bezahlen. Ein zweiter Punkt betrifft die Datensicherheit: Obwohl Clouddienste gut geschützte Umgebungen zum Speichern von Benutzerdaten bieten, zögern einige Benutzer immer noch, sensible Daten in die Cloud hochzuladen. Für die meisten IIoT-Anwendungen ist das Einrichten eines Gateways am Feldstandort zum Sammeln von Randgerätedaten und/oder zur Aktivierung der M2M-Kommunikation am Feldstandort eine Möglichkeit, die Kosten zu reduzieren und gleichzeitig der Datensicherheit Rechnung zu tragen. Das Gateway ist normalerweise ein Embedded Computer, und obwohl es nicht unbedingt für die Rolle des MQTT-Brokers und des MQTT-Clients konfiguriert werden muss, ist es dennoch möglich. Als MQTT-Broker kann das Gateway die M2M-Datenübertragung vor Ort durchführen. Als MQTT-Client kann das Gateway Feldgerätedaten sammeln und die verwendbaren Daten an ein Scada-System, eine HMI oder einen Cloudservice senden. Diese Gateway-Lösung senkt die Kosten weiter, indem MQTT verwendet wird, um die M2M-Kommunikation am Standort vor Ort und nicht über die Cloud zu ermöglichen.

Architektur zur Anbindung eines lokalen Gateways (Bild: Moxa Europe GmbH) [3]

Architektur zur Anbindung eines lokalen Gateways (Bild: Moxa Europe GmbH)

Konvertieren in eine IIoT-Anwendung

Viele ältere Geräte unterstützen MQTT nicht. In Fabriken verwenden Gebäudetechniker meist ein Remote-I/O-Setup für den Datenzugriff und die Umgebungsüberwachung. Darüber hinaus werden Protokoll-Gateways zur Erfassung von Leistungsmesser-Daten und zur Überwachung des Energieverbrauchs verwendet. Wenn das MQTT-Protokoll zur Übertragung von Daten in die Cloud verwendet wird, müssen die Ingenieure zunächst neue Remote-I/O-Produkte und Gateways integrieren, die MQTT unterstützen. Die Umstellung einer Fabrik auf ein IIoT-basiertes Setup kann eine große Investition erfordern.

IT und OT zusammenführen

Einer der grundlegenden Aspekte einer IIoT-Anwendung besteht darin, OT-Daten zu sammeln und in die Cloud zu übermitteln, woraufhin die Daten verarbeitet und/oder analysiert werden können. Die Herausforderung ergibt sich aus der Tatsache, dass die IT- und OT-Industrie unterschiedliche Übertragungsprotokolle verwenden. Modbus, eines der meistverbreiteten Protokolle im OT-Bereich, verwendet Datenpakete mit kleinen Headern und Datenlasten, damit die Pakete über Netzwerke mit begrenzter Bandbreite übertragen werden können. Andererseits verwenden IT-Ingenieure IT-Protokolle wie MQTT, RESTful API und SNMP, um Daten zu sammeln. Viele IT-Ingenieure sind daher nicht mit Modbus vertraut. Hier gilt es, die passenden Komptenzen aufzubauen und zusammenzubringen. Wenn diese Fallstricke durch gute Vorbereitung und Investitionsentscheidungen umgangen wurden, kann das traditionsreiche Protokoll seine Vorteile in seiner IIoT-Anwendung voll ausspielen.