Was ist Sparkplug B (Vor- und Nachteile des Standards)

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.

Level 2 – Mappings

Auf dieser Ebene werden spezifische Protokoll-Mappings festgelegt. Diese bestimmen, wie Daten innerhalb des gewählten Kommunikationsprotokolls strukturiert und übermittelt werden. Sparkplug definiert ein spezifisches Mapping für MQTT-Nachrichten, einschließlich der Nutzung von Topics und der Struktur der Nutzdaten (Payload). Dies umfasst Konventionen für Topic Namespaces, die es ermöglichen, die Art der Nachricht (z.B. DDATA für Device Nachrichten) zu identifizieren und effizient zu routen.

Level 3 – Encoding

Diese Ebene befasst sich mit der Art und Weise, wie Daten für die Übertragung über das Netzwerk kodiert werden. Dies umfasst die Wahl des Datenformats, das sowohl die Effizienz der Übertragung als auch die Kompatibilität zwischen unterschiedlichen Systemen definiert. Das Encoding beeinflusst direkt die Größe und damit die Übertragungsgeschwindigkeit der Nachrichten sowie die erforderliche Verarbeitungsleistung auf der Empfängerseite. Sparkplug B verwendet Protobuf für das Encoding von Nachrichten. Protobuf ist ein binäres Format von Google, das für die Serialisierung strukturierter Daten entwickelt wurde. Hierdurch können Nachrichten schnell verarbeitet und über Netzwerke mit potenziell begrenzter Bandbreite effektiv übertragen werden.

Level 4 – Values

Diese Ebene legt fest, welche Datentypen übertragen werden. Dabei ist eine klare Spezifikation von Datentypen essentiell für die korrekte Interpretation und Nutzung der Daten durch unterschiedliche Systeme. Sparkplug B definiert in Summe 19 Datentypen und umfasst sowohl einfache Datentypen wie Zahlen und Texte als auch komplexe Strukturen und benutzerdefinierte Typen.

Level 5 – Objects

Diese Ebene definiert Datenmodelle und -schemata, d.h. wie Daten als Objekte organisiert sind, einschließlich ihrer Attribute und Methoden. Dies ist insbesondere für die Anwendungslogik relevant. Sparkplug B definiert auf dieser Ebene keinen Standard.

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, kann aber für OT-Fachkräfte, die weniger mit diesem Kodierungsmechanismus 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.
- Begrenzungen in den Topic-Elementen: Sparkplug legt Beschränkungen für die Anzahl der Topic-Elemente fest, was seine Skalierbarkeit und Kompatibilität mit komplexen Organisationsstrukturen wie ISA-95 potenziell einschränken kann.

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 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 können potentiell zu Skalierungsproblemen führen.

Daher sollten Unternehmen ihre spezifischen Anforderungen sorgfältig prüfen, unter Berücksichtigung von Faktoren wie der bestehenden Organisationsstruktur, der Expertise ihrer Mitarbeiter und der Beschaffenheit ihrer Systeme.

Was ist Sparkplug B (Vor- und Nachteile des Standards)