Elektroniknet Logo

MQTT mit Sparkplug versus OPC UA

Intelligente Kommunikation für das IIoT


Fortsetzung des Artikels von Teil 1

MQTT macht es einfacher

MQTT – Message Queuing Telemetry Transport – bietet als OASIS-Standard mit MQTT 5 eine Spezifikation, die als De-facto-Standard für das IoT gesehen werden kann. OASIS ist hierbei die »Organization for the Advancement of Structured Information Standards«, eine Organisation, die sich mit dem Standardisieren von Industrieprotokollen beschäftigt. Kernprinzip von MQTT ist das Publish-Subscribe-Muster. Es entkoppelt den Client, der eine Nachricht sendet, vom Client oder den Clients, die die Nachrichten empfangen. Sender und Receiver kontaktieren sich nie direkt und wissen auch nichts über die Existenz der anderen. Gesendet (published) oder empfangen (subscribed) werden Nachrichten über sogenannte Topics. Ein Topic ist ein String, der eine URL-ähnliche Struktur aufweist und eine Art Betreff der Nachricht darstellt [3].

Relevante Anbieter

Das MQTT-Publish-Subscribe-Prinzip im Überblick
Bild 3. Das MQTT-Publish-Subscribe-Prinzip im Überblick.
© HiveMQ

MQTT eignet sich aufgrund seiner Schlankheit vor allem für ressourcenarme Geräte und für die Kommunikation in Netzwerken mit geringer Bandbreite. Eine MQTT-Architektur ermöglicht die Kommunikation mit einer unbegrenzten Anzahl von Clients (Bild 3). Da es bereits viele gute Beschreibungen der einzelnen Features gibt [4], wird hier auf eine weitere Beschreibung des Protokolls verzichtet. Es werden lediglich Aspekte im Vergleich mit OPC UA dargestellt.

Die wichtigsten Eigenschaften von MQTT sind:

➔ Leichtgewichtig, auf TCP basierend
➔ Publish-Subscribe-Modell
➔ Sicher
➔ Zustandsbehaftet – Nutzen von Ses sions
➔ Datenagnostisch
➔ Dynamische Topics
➔ Zustellgarantien für Nachrichten
➔ Last Will/Retained-Nachrichtenkonzept
➔ Mit MQTT 5 außerdem: Metadaten wie User-Properties, Payload-Indikatoren oder Content-Typ-Deskriptoren; individuelle Message- und Session-Lebensdauer

Mit Verwenden eines Publish-Subscribe-Protokolls wie MQTT und der hiermit verbundenen Komponente »Message Broker«, ändert sich die Architektur ganz wesentlich. Alle Nachrichten werden über den zentralen Broker verschickt. Außerdem verbinden sich alle MQTT-Clients mit dem Broker und können beliebige Topics abonnieren. Aus Sicht von OPC UA übernimmt der Broker hierbei die Aufgabe der Server. MQTT-Clients sind direkt an Gateways, Geräte oder in Anwendungen implementiert. Alle beteiligten Clients sind lose gekoppelt und stehen nicht direkt miteinander in Beziehung. Der Broker sollte neben den funktionalen Anforderungen ebenso redundant, ausfallsicher, hochverfügbar sowie skalierbar sein.

MQTT versus OPC UA

Die Publish-Subscribe-Architektur für MQTT ist ein signifikanter Unterschied zur Client-Server-basierten OPC-UA-Architektur. Sie ermöglicht eine effiziente Kommunikation der Geräte und Anwendungen. Das Nutzen von Sessions erlaubt es für MQTT-Clients über die Dauer der aktiven Verbindung hinaus Daten zu persistieren. Zum Beispiel Subscriptions, offline Nachrichten oder zusätzliche Informationen, die am Broker gespeichert werden und bei einem Re-Connect für den Client sofort bereitstehen.

Legende zu OPC-UA / MQTT
© HiveMQ

MQTT ist ein Daten-agnostisches Protokoll, die Payload ist binär und unterliegt keinerlei Spezifikation. Topics unterliegen in ihrer Definition lediglich syntaktischen Anforderungen. Sie sind dynamisch, das heißt Nutzer müssen sie vor dem Verwenden nicht spezifizieren oder erzeugen. Außerdem existieren sie lediglich dann, wenn ein Client sich auf ein Topic »subscribed«, um eingehende Nachrichten zu konsumieren. Wird eine Nachricht auf ein Topic publiziert, das kein Client abonniert hat – und keine Session existiert – wird die Nachricht am Broker verworfen. MQTT baut auf TCP als Transportprotokoll auf. Es gelten die Liefergarantien von TCP bei stabiler Verbindung. Weil MQTT unter anderem für instabile Netzwerke entwickelt wurde, sind drei Servicequalitäten spezifiziert – ein weiterer Unterschied hinsichtlich OPC UA. Ebenso kann das Feature »Retained Messages« im Produktionsumfeld sinnvoll sein: An jedem Topic kann ein Nutzer genau eine Nachricht speichern. Jeder Empfänger, der das Topic abonniert hat, bekommt nach erfolgreicher Anmeldung als erstes diese Nachricht.

Gleiche Relevanz gilt für das »Last-Will-Nachrichtenkonzept«. Es erlaubt, beim Verbinden mit dem Client eine Nachricht festzulegen, die Nutzer beim offline Event verschicken. Ein typischer Anwendungsfall ist das Übermitteln von Statusinformation. Mit MQTT 5 und dem Einführen von User Properties ist es möglich, beliebige Metainformationen in MQTT-Paketen zu übertragen, ohne den Payload dafür zu nutzen. Somit können Nutzer effektiv Metainformationen austauschen. Weitere MQTT 5 Features wie »Content Type«, »Payload Indicator« oder das »Request/Response«-Nachrichten-Pattern mit Hinzunahme von »Correlation Data« sind für Anwendungsfälle aus dem IIoT-Umfeld geeignet.

Auf Broker-Seite sollten Anwender unbedingt darauf achten, dass der Broker die MQTT-Spezifikation komplett implementiert. Hier sind insbesondere für MQTT 5 große Unterschiede bei den einzelnen Brokern zu finden, zum Beispiel im Cloud-Bereich. Viele Merkmale von MQTT 5 sind optional und daher nicht immer implementiert. Das heißt, ein Broker kann als MQTT 5 kompatibel bezeichnet werden, auch wenn er nicht alle Features unterstützt. Eine Gegenüberstellung der implementierten Features für einige Broker in der Cloud zeigt [5].

Herausforderungen im IIoT

IIoT schnell und einfach umsetzen: Vom Aufbau über die Wartung bis hin zu Erweiterungen – das ist die Aufgabe von heute. Hierbei steht der Entwickler vor Herausforderungen wie:

➔ Neue Geräte hinzufügen, anpassen und in die IT-Infrastruktur integrieren
➔ Ändern der Konfiguration am Gerät bezüglich der Messwerte
➔ Ändern von Workflows bezüglich Messen, Verarbeiten oder dem Bereitstellen von Daten.

Ein SCADA-Host dient als nachrichtenorientierte Middleware
Bild 4. Ein SCADA-Host dient als nachrichtenorientierte Middleware.
© HiveMQ

Sind lediglich wenige Komponenten im System vorhanden, ist der Wartungsaufwand für den Betrieb einer Anlage noch überschaubar, insbesondere bei Verwenden des SCADA-Hosts als nachrichtenorientierter Middleware (Bild 4). Bei mehreren Host-Anwendungen und dem Anbinden an weitere Enterprise-IT-Komponenten wird es jedoch sehr komplex.
Bei einer hohen Anzahl führt das zu einem großen Konfigurations- und Wartungsaufwand aufgrund des zugrunde liegenden Architekturmusters. Denn jede Komponente im Request/Response-Ansatz kommuniziert mit den SCADA-Hosts (Bild 5). Bei einem Set-up mit mehreren Hosts entstehen mit Client/Server-Mode-Ansatz:

➔ eine »Spaghetti-Infrastruktur«
➔ separate Integrationspunkte
➔ eine Vielzahl an Request/Response-Anfragen zum Übertragen von Informationen, da kein Polling
➔ langwierige Update-Prozesse über alle Instanzen

Die Herausforderung liegt darin, den Betrieb des Systems effizienter zu gestalten, insbesondere wenn der Anwender Geräte neu einbindet oder aktualisiert.

»Spaghetti-Effekt« bei einer komplexen Client-Server-Infrastruktur
Bild 5. »Spaghetti-Effekt« bei einer komplexen Client-Server-Infrastruktur.
© HiveMQ

Effizienz im Fokus

Die Konzepte der MQTT-Spezifikation eignen sich gut für den Einsatz beim Digitalisieren der Produktion. Ein wesentlicher Vorteil ist der zentrale Broker, also dem Entkoppeln der Daten über eine zentrale Nachrichtenkomponente. Außerdem ist das Thema Sicherheit mit MQTT genauso schnell und vielfältig umsetzbar wie mit OPC UA. Ein weiteres wichtiges und inhärentes Merkmal der beteiligten Clients ist der Client-Status, der mit der MQTT umsetzbar ist. Gateways können als Integratoren für das Anbinden weiterer Geräte agieren, die andere Protokolle benötigen.

Vergleicht man die Effizienz der Protokolle, ist es schwierig, sinnvolle und vergleichbare Benchmarks zu benennen und auszuführen, da Anwendungsfälle sehr unterschiedliche Requirements besitzen. Hinsichtlich eingesetzter CPU, Bandweite und Leistungsaufnahme gibt es jedoch eindeutige Aussagen. Sie zeigen, dass Nutzer mit MQTT wesentlich weniger Bytes verschicken – sowohl für den Verbindungsaufbau als auch für das Versenden der Nachrichtenpakete [6]. Was bleibt, ist die Frage, wie das Protokoll den Weg in verschiedene Anwendungen findet, und was zusätzlich nötig ist, um die Requirements an die Interoperabilität für die industrielle Automation zu erfüllen.

Wie aufbauend auf dem Protokoll weitere Standards definiert werden und was das mit Sparkplug zu tun hat, lesen Sie im zweiten Teil des Artikels in einer der kommenden Ausgaben der Elektronik.


Literatur


[1] OPC UA: http://opcfoundation.org/about/opc-technologies/opc-ua/. 2021. Seite aufgerufen am 18.02.2021.
[2] umati: https://umati.org/. 2021. Seite aufgerufen am 10.02.2021.
[3] Raschbichler, F.: https://www.informatik-aktuell.de/betrieb/netzwerke/mqtt-leitfaden-zum-protokoll-fuer-das-internet-der-dinge.html. 2017. Seite aufgerufen am 18.02.2021.
[4] HiveMQ: https://www.hivemq.com/mqtt-5/. 2021. Seite aufgerufen am 15.02.2021.
[5] HiveMQ: https://www.hivemq.com/blog/hivemq-cloud-vs-aws-iot/. 2021. Seite aufgerufen am 18.02.2021. [6] Hottel, J.: https://cdn2.hubspot.net/hubfs/2335443/Johnathan-Hottell-IIoT-Protocol-Benchmarks.pdf/. 2021. Seite aufgerufen am 15.02.2021.

Anja-Helmbrecht-Schaar von HiveMQ
Anja-Helmbrecht-Schaar von HiveMQ.
© HiveMQ

Die Autorin

Anja Helmbrecht-Schaar arbeitet als Senior MQTT & Architektur Consultant bei HiveMQ, dem Entwickler des Enterprise MQTT Brokers HiveMQ. Sie unterstützt Kunden bei der anwendungsspezifischen Implementation von HiveMQ-Erweiterungen sowie der Einführung und Integration von HiveMQ in die  Systemlandschaft. Als MQTT-Expertin hält sie Workshops rund um den Broker, das Protokoll und seiner Anwendung in verschiedenen Bereichen.


  1. Intelligente Kommunikation für das IIoT
  2. MQTT macht es einfacher

Das könnte Sie auch interessieren

Verwandte Artikel

HiveMQ / dc-square GmbH