Schwerpunkte

MQTT mit Sparkplug versus OPC UA

Intelligente Kommunikation für das IIoT – Teil 2

08. Juni 2021, 09:00 Uhr   |  Von Anja Helmbrecht-Schaar

Intelligente Kommunikation für das IIoT – Teil 2
© Shutterstock

Im ersten Teil des Artikels in Elektronik-Ausgabe 7/2021 wurden die Unterschiede zwischen OPC UA und MQTT mit Sparkplug erläutert. Im zweiten Teil geht es in die technischen Details. Wann ist MQTT mit Sparkplug eine echte Alternative zu OPC UA und wann ergänzen sie sich?

In Teil 1 des zweiteiligen Artikels wurde gezeigt, wie MQTT dazu beitragen kann, eine schlanke Infrastruktur im produktionsnahen Umfeld aufzubauen und welche Vorteile das Protokoll mit sich bringt. Mit dem Verwenden eines Publish-Subscribe-Protokolls wie MQTT und der dafür notwendigen Komponente, dem Message Broker, ändert sich grundlegend die Architektur: von Client-Server-basiert hin zu Message-basiert.
 
Alle Nachrichten laufen über den Broker. MQTT-Clients verbinden sich zum Broker und können sich auf beliebige Topics anmelden (Bild 1). Bezüglich OPC UA übernimmt der Broker dabei die Aufgabe der Server. Alle beteiligten MQTT-Clients sind lose gekoppelt, das heißt es gibt keine direkten Beziehungen untereinander. Kein Client muss die anderen Kommunikationsteilnehmer im System kennen.

Entkoppelte Architektur mit MQTT im IIoT: MQTT Clients verbinden sich zum Broker und können sich auf beliebige Topics anmelden
© HiveMQ

Bild 1. Entkoppelte Architektur mit MQTT im IIoT: MQTT Clients verbinden sich zum Broker und können sich auf beliebige Topics anmelden.

Mit dem Ansatz ist das Gesamtsystem einfacher zu warten, Anwender können neue Komponenten schneller hinzufügen und es ist wesentlich einfacher, Daten über das Gesamtsystem hinweg zu analysieren. Jedoch stellt dies Anwender vor neue Herausforderungen. Herkömmliche Geräte und Schnittstellen erwarten unterschiedliche Topics, Dateninhalte und Datenstrukturen. Anwendungen erwarten wiederum andere Formate und Anwender müssen die Dateninhalte verstehen. Das bedeutet: Es ist ein einheitlicher Kontext nötig, den Anwender mittels Sparkplug bereitstellen können.

Sparkplug: eine Definition

Sparkplug ist ein Projekt der Eclipse Foundation [1]. Mit Sparkplug stellt Eclipse eine offene und frei verfügbare Spezifikation bereit. Sie beschreibt, wie Edge Gateways oder native MQTT-fähige Endgeräte und MQTT-Anwendungen über eine zentrale Komponente, den MQTT-Broker, bidirektional kommunizieren können. Sparkplug definiert, wie MQTT in einer geschäftskritischen Echtzeit-OT-Umgebung zu verwenden ist. Es definiert einen Standard, der für Anwendungsfälle in industriellen Anwendungen und insbesondere für SCADA-, Tag- und Metrik-Darstellungen optimiert wurde. Die Spezifikation beschreibt, wie die Prinzipien in Echtzeit-SCADA-Projekten am besten zu verwenden sind.

Derzeit gibt es zwei mit Sparkplug definierte Schemata, wobei das zweite – Sparkplug B – eine spezifische Lösung im Produktionsumfeld bietet. Hierzu wurde ein Datenmodell in Zusammenarbeit mit Systemintegratoren und Kunden, die MQTT verwenden, entwickelt. Die Sparkplug-Spezifikation umfasst die drei folgenden Themen:

Festlegen eines Topic-Namensraumes
Das freie, dynamische Verwenden von Topic-Namen ist ein großes Plus von MQTT. Jedoch ist für den Einsatz in der Produktion ein Festlegen auf eine zu definierende Ontologie nötig. Hiermit kennen und verstehen alle beteiligten Geräte und Anwendungen die Begriffe und die zwischen ihnen bestehenden Beziehungen im Themenraum und können diese anwenden.

Spezifikation der Datenstrukturen des Payloads
Analog zum Festlegen des Topic-Namensraumes müssen Anwender für den Einsatz von MQTT in Produktionsumgebungen ein Schema für die Inhalte der Nachrichten, also des Payloads, definieren. Sehr elegant ist das mit den nativen Konzepten von MQTT 5 umzusetzen, offiziell wird jedoch auf MQTT 3 verwiesen.

Definition des Zustandsmanagements
Da MQTT ursprünglich für das Überwachen von Echtzeitsystemen entwickelt wurde, war der Fokus von Anfang an darauf gerichtet, mit Netzwerkausfällen, niedriger Bandbreite und hoher Latenz gut umgehen zu können. Hier dient das Konzept der MQTT-Sessions als Basis – die Funktion ist vollständig zu implementieren.

Legende MQTT
© HiveMQ

Das Ziel der Sparkplug-Spezifikation besteht darin, die Vorteile von MQTT mit den Anforderungen der Operational Technology zu paaren. Vorteile von MQTT sind zum Beispiel dessen Einfachheit, Effizienz und Verständlichkeit – sowohl beim Implementieren als auch im Betrieb. Außerdem gilt es, einen Sprachraum festzulegen, der allen Systemteilnehmern bekannt ist, ein Status-Management für alle Komponenten zu etablieren und die Nachrichtengrößen auf ein Minimum zu beschränken. Für Entwickler und Planer bedeutet das, dass sie aufgrund der Sparkplug-Spezifikation klare Richtlinien für den Entwurf einer schlanken Infrastruktur erhalten, mit der alle Komponenten arbeiten können.

Die Komponenten im IIoT-Umfeld

In einer Broker-Architektur verbinden sich Geräte, Edge of Network (EoN)-Knoten sowie der SCADA/IIoT-Host mit einem zentralen MQTT-Broker und veröffentlichen und abonnieren Daten. Der SCADA/IIoT-Host ist explizit nicht dafür verantwortlich, Verbindungen zu den Geräten direkt herzustellen oder aufrechtzuerhalten.

Sparkplug-Architektur: EoN-Knoten verbinden die an sie gekoppelten Geräte und Sensoren mit der Infrastruktur, welche kein Sparkplug-Interface besitzen
© HiveMQ

Bild 2. Sparkplug-Architektur: EoN-Knoten verbinden die an sie gekoppelten Geräte und Sensoren mit der Infrastruktur, welche kein Sparkplug-Interface besitzen.

EoN-Knoten verbinden ebenfalls die an sie gekoppelten Geräte und Sensoren mit der Infrastruktur, welche kein Sparkplug-Interface besitzen. Somit ist das EoN-Gateway für das Verwalten seines eigenen Status und dem seiner Geräte sowie für das Empfangen und Senden von Daten der Geräte an die Sparkplug-Infrastruktur verantwortlich (Bild 2).

MQTT-Anwendungen sind Komponenten, die an der Sparkplug-Kommunikation teilnehmen und MQTT-Nachrichten erzeugen und verarbeiten können, jedoch nicht der SCADA/IIoT-Host sind. Wie in Teil 1 bereits erläutert, ist der Broker die zentrale Komponente, die in einem Cluster ausfallsicher und hochskalierbar betrieben wird, und die über Monitoring- und Alarmschnittstellen verfügt. So sind alle Systemkomponenten optimal zu überwachen.

Inzwischen bieten Hersteller für ihre Geräte und Sensoren native MQTT-Schnittstellen an. Ist das Gerät bereits mit Sparkplug ausgestattet, kann es direkt an der Infrastruktur teilnehmen und identifiziert sich selbst als EoN-Knoten. Alle MQTT-Clients, insbesondere der SCADA-Host und die IT-Anwendungen, abonnieren die Themenbereiche, von welchen sie Informationen empfangen wollen. Mithilfe der Definition der Topic-Struktur und der Datenobjekte weiß jeder Client, wo und in welcher Form Informationen abzurufen sind. Die Clients sind zustandsbehaftet, sodass zu keiner Zeit ein Informationsverlust entsteht. Nachrichtentypen sind für bestimmte Informationen festgelegt.

Die wichtigsten Eigenschaften von MQTT
mit Sparkplug auf einen Blick
➔ Zentrale Architektur – Single Source of Truth – einmalige Konfiguration der Prozessvariablen an der Quelle, Verfügbarkeit für alle Teilnehmer
➔ Entkoppeln der Daten – keine benutzerdefinierten Verbindungen zwischen verschiedenen Datenquellen
➔ Leichtgewichtigkeit und Schnelligkeit des Protokolls
➔ Umsetzung aller Features der Spezifikation mit den nativen MQTT-Eigenschaften
➔ Nutzt Transport Layer Security (TLS) für den Datentransport
➔ Zustand aller Komponenten zu jedem Zeitpunkt abrufbar
➔ Struktur und Nachrichtenaufbau (Payload) allen Teilnehmern bekannt
➔ Geringes Datenvolumen über Protobuf und RbE-Prinzip
➔ Effizienter Transport von Echtzeitdaten
➔ Einfache und schnelle Integration neuer Geräte
➔ Neue Maschinen- und Sensordaten stehen allen Teilnehmern sofort zur Verfügung

 

Seite 1 von 2

1. Intelligente Kommunikation für das IIoT – Teil 2
2. Sparkplug-Spezifikation und Umsetzung im Detail

Auf Facebook teilen Auf Twitter teilen Auf Linkedin teilen Via Mail teilen

Das könnte Sie auch interessieren

Verwandte Artikel

HiveMQ / dc-square GmbH