Was Sie schon immer über MQTT im IIoT wissen wollten?

Was Sie schon immer über MQTT
im IIoT wissen wollten…

Obwohl das MQTT-Protokoll bereits seit fast drei Jahrzehnten existiert, eignet es sich aufgrund seiner Konzeption ideal für IIoT-Anwendungen, den neuesten Trend in der Automatisierungstechnik. Dies gilt insbesondere für Anwendungen, die sich auf eine aktive Benachrichtigung stützen, bei der Geräte nur bei Bedarf Daten bereitstellen, im Gegensatz zur passiven Benachrichtigung, in denen Geräte regelmäßig abgefragt werden. Warum MQTT im IIoT so erfolgreich ist und was man vor dem Einsatz des Übertragungsprotokolls wissen sollte, erläutert der folgende Beitrag.

Bild: Moxa Europe GmbH

Das MQTT-Messaging-Protokoll wurde erstmals 1999 von IBM und Cirrus Link entwickelt und ist ab Version 3.1 seit 2013 als ISO-Standard akzeptiert. MQTT verwendet ein Publish-Subscribe-Muster (siehe Abbildung unten), um Nachrichten auszutauschen. Wie in der Abbildung dargestellt, umfasst ein MQTT-System 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 Vorteile, die es ideal für IoT-Anwendungen machen.

MQTT ist das Top-Protokoll für IIoT-Anwendungen. Publish-Subscribe-Muster (Bild: Moxa Europe GmbH)

MQTT ist das Top-Protokoll für IIoT-Anwendungen. Publish-Subscribe-Muster (Bild: Moxa Europe GmbH)

Messaging-Muster für Publish-Subscribe

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, und 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 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.

Abung 3: QoS 0: höchstens einmal (Bild: Moxa Europe GmbH)

Abbildung 3: QoS 0: höchstens einmal (Bild: Moxa Europe GmbH)

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.

Abung 4: QoS 1: mindestens einmal (Bild: Moxa Europe GmbH)

Abbildung 4: QoS 1: mindestens einmal (Bild: Moxa Europe GmbH)

Seiten: 1 2 3 4 5Auf einer Seite lesen

Thematik: Allgemein
Moxa Europe GmbH
www.moxa.com

Das könnte Sie auch Interessieren