MQTT mit Sparkplug versus OPC UA

Intelligente Kommunikation für das IIoT – Teil 2

8. Juni 2021, 9:00 Uhr | Von Anja Helmbrecht-Schaar

Fortsetzung des Artikels von Teil 1

Sparkplug-Spezifikation und Umsetzung im Detail

In der Sparkplug-Spezifikation sind verschiedene Nachrichtentypen für das Übertragen von Informationen über Metadaten sowie über den Zustand des jeweiligen Gerätes festgelegt.

Nachrichtentypen
➔ Die Nachrichtentypen »BIRTH/DEATH« Certificates dienen als Statusinformationen. Sie sind über die MQTT-Konzepte Last Will und Retained Messages abzubilden. Edge Gateways nutzen den Nachrichtentyp »NBIRTH« beziehungsweise »NDEATH«. Statusinformationen von nicht Sparkplug-fähigen Geräten sind über »DBIRTH/DDEATH« spezifiziert.
➔ Dateninhalte werden über den Nachrichtentyp »(N/D) DATA« geschickt. Eine DATA-Nachricht wird nach dem Report by Exception (RbE)-Prinzip geschrieben, das heißt, Nachrichten dieses Typs enthalten lediglich Informationen über Änderungen bezüglich des vorherigen Zustands.
➔ Der SCADA-Host nutzt den Nachrichtentyp »STATE«, um über seinen Status zu informieren.
➔ Anweisungen werden über die Nachrichten »(N/D) CMD« an Edge Gateways beziehungsweise einfache Geräte dargestellt.

Struktur
➔ Alle MQTT-Clients, die der Sparkplug-Spezifikation folgen, nutzen eine vorgegebene Struktur für den Topic-Namensraum, die wie folgt zu definieren ist:
[namespace]/[group_id]/[message_type]/[edge_node_id]/{[device_id]}

Berechtigungen und Informationsfluss
➔ Alle EoN-Knoten publishen spezifische Status- und Datennachrichten auf »ihr« Topic und die Nachrichten ihrer Geräte auf die jeweiligen Geräte-Topics.
➔ Alle EoNs sind auf ihr Command-Topic subscribed, um spezifische Nachrichten des SCADA-Hosts zu empfangen.
➔ Ein SCADA-Host abonniert alle relevanten Themen »[namespace]/[group_id]/#«
➔ Command-Nachrichten published der SCADA-Host direkt auf das Topic des jeweiligen EoN-Knotens beziehungsweise des Gerätes am EoN-Knoten.

Umsetzung des Statusmanagements
Ebenfalls mit den nativen Mitteln von MQTT ist das Statusmanagement zu lösen. Hierzu nutzt der Anwender beim Verbindungsaufbau MQTT-Sessions.

Matchmaker+ Anbieter zum Thema

zu Matchmaker+

So können Anwender Nachrichten für MQTT-Clients, die nicht online sind, jedoch eine Session besitzen, managen und gehen nicht verloren. In Kombination von Nachrichtentypen und Topic-Struktur kann der Anwender den Status jedes Clients im System abbilden und lesen. Das Bereitstellen des Status unterliegt den einzelnen Komponenten. Ein Bereitstellen des Status einfacher Geräte übernehmen diejenigen Edge Gateways, die für deren Sparkplug-Kommunikation verantwortlich sind (Bild 3).

Nachrichteninhalt und Format
Als Format ist in Sparkplug B »Protobuf« festgelegt. Mit der Wahl dieses Formats und dessen Umsetzung minimiert sich der Payload und ist zugleich strukturiert, sodass alle Komponenten im System die Informationen eigenständig interpretieren können. Das Festlegen des Namensraums, der Topic-Struktur, ist semantisch mit den zu übertragenden Informationen verbunden.

Die Sparkplug-Spezifikation unterstützt den effizienten Transport von Echtzeitdaten – der Payload ist mit verschiedenen Datentypen definierbar:
➔ Komplexe Datentypen
➔ Datasets
➔ Rich Metric Data inklusive Metadaten
➔ Metric Aliase
➔ Historical Data
➔ File Data

Payload-Daten sind strukturiert und hierarchisch aufgebaut und im Protocol-Buffer-Format encodiert. Der Payload besteht aus einem Datensatz, der mindestens den Timestamp des Verschickens und eine Metrik sowie eine fortlaufende ID enthält. Weitere Attribute sind optional zu verwenden, Beispiel »is_null« kennzeichnet eine leere Metrik (Bild 4).

Spezifische Daten können Anwender über Properties, als Liste mit »key-value-pairs«, oder im Body-Objekt ablegen. Ein weiteres wichtiges Konzept von MQTT & Sparkplug B ist der Report by Exception, das heißt, es werden lediglich Änderungen bezüglich der vorherigen Situation geschickt. Hierdurch verringert sich das Volumen der Daten massiv. Mit den spezifischen Nachrichtentypen sind zu Beginn einer Session Payload Templates, die das komplette Schema der Nachrichteninhalte beschreiben, sowie die initialen Werte mitzuschicken. Aufbauend darauf ist lediglich die Änderung publizierbar und von den konsumierenden MQTT-Clients interpretierbar.

Die Auswahl des Brokers

Ebenso wie in einer Infrastruktur ohne Sparkplug, ist der Message Broker die zentrale Komponente, über die alle Nachrichten verschickt werden und an der sich alle MQTT-Clients auf bestimmten Topics anmelden. Die in der Sparkplug-Spezifikation beschriebene Möglichkeit des Verwendens von mehreren getrennten Brokern, in der Absicht, Ausfallsicherheit zu garantieren, ist mit dem Einsatz eines Cluster-fähigen, hochverfügbaren und ausfallsicheren MQTT-Brokers, wie HiveMQ, nicht nötig.
Somit ist ebenso das Verwalten des Status wesentlich einfacher als in der Spezifikation beschrieben. Ein Cluster-fähiger Broker ist von außen betrachtet eine logische Einheit. So muss nicht mehr festgelegt oder erkannt werden, an welchem Broker sich die Komponenten verbinden. HiveMQ verfügt über ein Web-Interface, das dem Monitoring der MQTT-Clients und der Systemmetriken dient, sowie eine Administrationsoberfläche bietet.

Neben den genannten Eigenschaften ist es mit HiveMQ ebenso möglich, das System mit einer geschäftsspezifischen Logik (Extension System) zu erweitern. Extensions sind sehr einfach in das bestehende System integrierbar. Hier gibt es viele bereits implementierte Open-Source-Anwendungen für häufig vorkommende Anforderungen, die frei verfügbar sind.

Hierzu zählt ebenso die »Sparkplug-InfluxDB Extension«. Es ist eine Erweiterung, die zunächst dazu dient, generisch Sparkplug-Metriken zu validieren, zu lesen und in einer Time-Series-Datenbank wie InfluxDB zu persistieren, um die Gerätemetriken direkt zu visualisieren. Ein Dashboard Template zum direkten Visualisieren auf Influx ist ebenfalls verfügbar [2].

MQTT mit Sparkplug und OPC UA ergänzen sich

Zu den im ersten Teil der Artikelreihe im Abschnitt »MQTT versus OPC UA« genannten Vorteilen, die mit dem Verwenden von MQTT entstehen – wie zentrale Architektur, Entkoppeln der Daten sowie Leichtgewichtigkeit und Geschwindigkeit – kommen die Vorteile hinzu, die mit dem Verwenden von Sparkplug entstehen. Mit der Sparkplug-B-Spezifikation bekommt MQTT ein Framework, das eng in Anlehnung an die Anforderungen an IIoT-Systeme entwickelt wurde.

Für den Einsatz von MQTT in Produktionsumgebungen ist mit Sparkplug ein Sprachraum definiert. So können alle beteiligten Geräte und Anwendungen die Begriffe, und die zwischen ihnen bestehenden Beziehungen im Themenraum erkennen, verstehen und anwenden. So sind die gesendeten Informationen für die Komponenten der IT-Strukturen ohne weitere Meta-Informationen interpretierbar. Mit dem Ansatz können Hersteller ihre Geräte bereits mit der Spezifikation ausliefern. Ein Gerät in eine Architektur mit einer nachrichtenorientierten Middleware zu integrieren, ist wesentlich einfacher als in eine komplexe Client-Server-Struktur, da jede Komponente im System lediglich mit dem Broker kommuniziert und keine weitere Konfiguration nötig ist.

OPC UA und MQTT können jedoch trotzdem zusammenarbeiten, obwohl diametrale Gegensätze vorhanden sind – zum Beispiel wie, wohin und wann Daten zu senden sind. Gibt es alte Geräte, die einen OPC-Server benötigen und die der Anwender trotzdem an die Sparkplug-Infrastruktur anschließen möchte, so ist das möglich. Das im OPC UA vorhandene Pub-Sub-Interface unterstützt nicht alle MQTT-Features, die für eine nahtlose Integration an Sparkplug notwendig wären [3]. So unterstützt die aktuelle OPC UA MQTT-Implementation das Konzept der Verbindungseigenschaften nicht. Zum Beispiel betrifft dies das LWT Feature, das im Sparkplug Context relevant ist. Ebenfalls nicht empfohlen wird laut Spezifikation die Nutzung von Retained Messages.

Hier könnte über eine Transformation am Broker, zum Beispiel eine Erweiterung, nachgedacht werden. Allerdings ist die Anbindung über einen weiteren Sensor die wahrscheinlich einfachere Lösung. Mit dem Nutzen eines MQTT-fähigen Sensors, der an ein älteres Gerät angeschlossen ist, können Anwender gleichermaßen MQTT und Sparkplug verwenden. So können sie die Daten in der IT zentral und für alle Komponenten verfügbar machen. Eine bestehende Infrastruktur ist nicht einfach in kurzer Zeit zu ändern. Gerade wenn Unternehmen jedoch eine neue Infrastruktur für das IIoT aufbauen oder lediglich wenige Altgeräte vorhanden sind, kann die Entscheidung für den Einsatz von MQTT + Sparkplug in Produktionsumgebungen eine gute Option sein.

Literatur

[1] Elipse Sparkplug Working Group: Frequntly asked Questions. Eclipse Foundation. 2020. https://sparkplug.eclipse.org/about/faq/
[2] HiveMQ: Sparkplug InfluxDB Extension for HiveMQ. 2021. https://www.hivemq.com/extension/sparkplug-influxdb-extension/
[3] OPC Foundation: OPC 10000-14 - UA Specification Part 14 - PubSub 1.04.pdf. 2021. https://opcfoundation.org/developer-tools/specifications-unified-architecture/part-14-pubsub

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.