Was ist Sparkplug B (Vor- und Nachteile, einfach erklärt)

Im Bereich des Industrial IoT spielen Standards eine immer entscheidendere Rolle, um die Interoperabilität zwischen Geräten verschiedener Hersteller zu gewährleisten. Ein solcher Standard ist Sparkplug B. Dieser zielt darauf ab, die Kommunikation in MQTT-basierten Netzwerken zu definieren. Welche Vor- und Nachteile Sparkplug B in MQTT Netzwerken mit sich bringt, wird in folgendem Artikel beleuchtet.

Was ist Sparkplug B?

Sparkplug B ist ein offener Standard der Eclipse Foundation und umfasst eine Spezifikation. Die Entstehung von Sparkplug B ist auf die bewusste Entscheidung von MQTT zurückführen, keine Standards für die Strukturierung von MQTT Nachrichten zu definieren. Durch diese Offenheit hat das Protokoll zwar große Beliebtheit in der IoT-Welt erlangt. Allerdings führt diese Flexibilität auch zu Problemen, insbesondere bei der Interoperabilität zwischen verschiedenen Systemen. Dabei können Schwierigkeiten entstehen, wenn unterschiedliche Geräte und Anwendungen nahtlos über MQTT kommunizieren sollen. Genau diese Lücke schließt Sparkplug mit dem Fokus auf SCADA Umgebungen. Hierfür definiert der Standard eine einheitliche Datenformatierung und ein einheitliches State Management innerhalb von MQTT.

Eine Weiterentwicklung von Sparkplug A: Sparkplug B baut auf den Prinzipien von Sparkplug A auf. Sparkplug A ist eine frühere Initiative zur Erweiterung des MQTT Standards, die sich jedoch nicht durchgesetzt hat. Mit Sparkplug B wurden die Konzepte und Ziele von Sparkplug A weiterentwickelt und in eine robuste Spezifikation überführt. Diese adressiert Anforderungen moderner Infrastrukturen und hat so eine größere Akzeptanz in der Industrie gefunden.

Terminologie und Architektur

Sparkplug definiert eine klare Terminologie und Architektur für die Organisation von Nachrichten, um die Eindeutigkeit und Effizienz der Datenübertragung zu gewährleisten.

Dabei besteht Architektur von Sparkplug besteht aus mehreren Schlüsselkomponenten:

• MQTT Server (Broker) als Kernstück der Sparkplug Architektur. Dieser dient als Knotenpunkt für die Nachrichtenübertragung zwischen Edge Nodes und der Primary Host Application.
• Edge Node befinden sich am Rand des Netzwerks (z.B. IPCs, Gateways, PLCs). Diese sammeln Daten von Sensoren und Aktuatoren und leiten sie an den Broker weiter.
• Edge Device als physisches Gerät, das Daten erfasst (Sensor) oder erzeugt (Aktuator).
• Primary Host Application: Die zentrale Anwendung, die die Daten verarbeitet. Zum Beispiel ein SCADA System, welches für die Überwachung, Steuerung und Optimierung der Produktionsprozesse verantwortlich ist.

Sparkplug B vs. MQTT

Um den Mehrwert von Sparkplug zu verdeutlichen, ist im Folgenden Level 0 bis Level 5 des „Data Access Model“ (Quelle: Matthew Parris) dargestellt. Das Data Access Model dient hierbei als ein Rahmenwerk für den Datenzugriff. Es skizziert die wesentlichen Ebenen (Level), welche für die Interoperabilität zwischen Datenquellen und -konsumenten im industriellen Kontext entscheidend sind. Dabei begünstigen undefinierte Ebenen die Flexibilität auf Kosten eines höheren Integrationsaufwands, da jede Implementierung individuell interpretiert und integriert werden muss. Sparkplug B ergänzt den MQTT Standard wie folgt.

Sparkplug B Topic Namespace

Der Standard definiert den Topic Namespace und damit eine klare MQTT-Topic-Struktur wie folgt: spBv1.0/group_id/message_type/edge_node_id/[device_id]. Dieser Aufbau ermöglicht die Identifizierung und Gruppierung von Datenströmen in einem IIoT-Netzwerk und besteht aus den folgenden Komponenten:

• spBv1.0 signalisiert den Einsatz des Sparkplug Encodings.
• Group ID ermöglicht es, Edge Nodes logisch zu gruppieren (z.B. nach geografischen Standorten oder funktionalen Einheiten).
• Message Type unterscheidet zwischen verschiedenen Arten von MQTT-Nachrichten (z.B. DDATA für Device Nachrichten)
• Edge Node ID und Device ID für eine eindeutige Identifikatoren für Edge-Geräte, was eine direkte Kommunikation und eindeutige Zuordnung von Datenströmen ermöglicht.

Ein praxisnahes Beispiel für ein produzierendes Unternehmen mit einem Standort in Prag wäre die Struktur: spBv1.0/ExampleCompany:Prague/DDATA/MillingArea1:Line1/Cell1

Art von Nachrichten (Message Types)

Sparkplug definiert verschiedene Arten von MQTT Nachrichten (Message Types), welche im Topic Namespace spezifiziert werden und spezielle Funktionen erfüllen:

• NBIRTH – Birth certificate für Sparkplug Edge Nodes. Wird verwendet, um die Erstregistrierung eines Edge Nodes im Netzwerk anzukündigen und dessen Metadaten zu übermitteln.
• NDEATH – Death certificate für Sparkplug Edge Nodes. Dient dazu, das Netzwerk über das geordnete Herunterfahren oder einen unerwarteten Ausfall eines Edge Nodes zu informieren.
• DBIRTH – Birth certificate für Devices. Ähnlich wie NBIRTH, aber für einzelne Geräte, um deren Anwesenheit und Konfiguration dem Netzwerk zu melden.
• DDEATH – Death certificate für Devices. Informiert das Netzwerk über das Ausscheiden eines Geräts, sei es durch geplantes Herunterfahren oder einen Fehler.
• NDATA – Edge Node data message. Überträgt die tatsächlichen Betriebsdaten von einem Edge Node, beispielsweise Messwerte oder Zustandsinformationen.
• DDATA – Device data message. Übermittelt Betriebsdaten von einzelnen Geräten, wie Messwerte oder Sensordaten, an das Netzwerk.
• NCMD – Edge Node command message. Ermöglicht die Übertragung von Steuerbefehlen an einen Edge Node, um bestimmte Aktionen auszulösen oder Konfigurationen zu ändern.
• DCMD – Device command message. Wie NCMD, jedoch speziell für das Senden von Befehlen an einzelne Geräte konzipiert.
• STATE – Sparkplug Host Application state message. Übermittelt den Zustand der Sparkplug Host Application, einschließlich Verfügbarkeit und Gesundheitsstatus, an das Netzwerk.

Sparkplug B Payload

Sparkplug-Payloads nutzen Google Protocol Buffers, um eine kompakte Methode zur Datenübermittlung bereitzustellen. Diese Payloads beinhalten Metriken, Metadaten und Zustandsinformationen, die es ermöglichen, Updates über den Zustand von Geräten und Sensoren zu liefern. Dabei folgt jeder Payload einer definierten Struktur, die das Lesen und Schreiben von Daten standardisiert. In folgendem Beispiel ist eine NDATA-Nachricht dargestellt, welche im Topic spBv1.0/ExampleCompany:Prague/DDATA/MillingArea1:Line1/Cell1 veröffentlicht wird. Diese Konfiguration führt dazu, dass die Host-Applikation den Wert des Supply Voltage, CNCOperationMode und ActFeedrate aktualisiert.

Vor- und Nachteile von Sparkplug B

Sparkplug B präsentiert sowohl signifikante Vorteile als auch Herausforderungen im industriellen Kontext, die es sorgfältig abzuwägen gilt.

Vorteile

• Payload-Definition und Interoperabilität: Durch die Nutzung konsistent interpretierter Datentypen über das MQTT Ökosystem hinweg führt Sparkplug B zu einer höheren Interoperabilität.
• Session Management: Es bietet einen Standard für das Management des Sitzungszustands aller verbundenen Komponenten, was die Koordination und Synchronisation erleichtert.
• Definierte Topic-Namensgebung: Durch die Strukturierung des MQTT-Topic-Namensraums fördert Sparkplug Klarheit und Konsistenz in der Kommunikation.

Nachteile

• Komplexität: Die Abhängigkeit von ProtoBuf mag für IT-Professionals geläufig sein. Allerdings kann ProtoBuf für OT-Fachkräfte, die weniger mit diesem Encoding vertraut sind, eine zusätzliche Komplexität darstellen.
• Bandbreiteneinsparungen vs. Komplexität: Für mit Ethernet-Kabeln verbundene Fertigungssysteme mögen die Bandbreiteneinsparungen, die Sparkplug B mit sich bringt, die erhöhte Komplexität nicht rechtfertigen.
• Primary Application: Das Konzept der „Primary Application“ kann zu Problemen führen. Fällt die Primary Application aus, stoppen Maschinen die Datenübertragung. Dies ist insbesondere im Kontext eines Unified Namespace (UNS) wenig sinnvoll.
• Begrenzungen in den Topic-Elementen: Sparkplug begrenzt die Anzahl der Topic-Elemente. Dies schränkt die Skalierbarkeit und Kompatibilität mit komplexen Organisationsstrukturen wie ISA-95 ein. Einschränkungen betreffen die Nutzung von Wildcards (z. B. keine Subscription auf alle Nachrichten einer Produktionslinie) sowie die Möglichkeit zur selektiven Abonnierung von Teilinhalten der Data Payloads.
• QoS 0: Sparkplug B zwingt alle Datenübertragungen auf das Quality-of-Service (QoS) Level 0. Bei diesem QoS Level überträgt der Broker die Nachrichten lediglich nach dem Prinzip „at most once“. D.h. Nachrichten können verloren gehen (weitere Infos zu QoS finden Sie hier). Dies schränkt die Zuverlässigkeit der Datenübertragung erheblich ein und macht Sparkplug B für viele Use-Cases ungeeignet.
• Keine Retained Messages: Sparkplug B erlaubt nicht die Verwendung des Retain-Flags für Daten- oder Birth Nachrichten. Dadurch kann der „Current State“ nicht im Broker gespeichert werden, was Sparkplug B für viele Use-Cases ungeeignet macht (weitere Infos zu Retained Messages finden Sie hier).

Fazit

Sparkplug B adressiert wesentliche Herausforderungen bei der Skalierung einer MQTT basierten Infrastruktur in Industrial IoT Umgebungen. Die Definition eines Standards für Topic Namespace, Payloads und Session Management kann erhebliche Vorteile insbesondere in SCADA Umgebungen (Szenario: n:1 Integration) mit sich bringen. Allerdings bringt der Standard auch wesentliche Einschränkungen mit sich, darunter die Abweichung vom weit verbreiteten ISA-95-Modell, die Abhängigkeit von ProtoBuf und Einschränkungen bei den Topic-Elementen. Diese führen zu Problemen, insbesondere im Rahmen einer Unified Namepace (UNS) Architektur (Szenario: n:m Integration).

Daher sollten Unternehmen ihre spezifischen Anforderungen sorgfältig prüfen, unter Berücksichtigung von Faktoren wie der bestehenden Organisationsstruktur, der Expertise ihrer Mitarbeiter und des Anwendungsfalls (n:1 vs. n:m Integration).