MQTT Sparkplug B ist eine Spezifikation, die MQTT für industrielle und SCADA-Anwendungsfälle produktionsreif macht. MQTT selbst ist ein leichtgewichtiges Publish-Subscribe-Protokoll – aber ohne zusätzliche Konventionen weiß ein Empfänger nicht, ob ein Datenpunkt aktuell, vollständig oder veraltet ist. Sparkplug B löst genau dieses Problem: Es standardisiert Topic-Namespace, Payload-Struktur und vor allem das Zustandsmanagement von Knoten und Geräten.
Das Kernprinzip: Birth und Death statt beliebiger Topics
Der entscheidende Mechanismus in Sparkplug B ist die Unterscheidung zwischen Birth Certificates und Death Certificates.
Ein Birth Certificate wird publiziert, wenn ein Edge Node oder Device online geht. Es enthält die vollständige Liste der verfügbaren Datenpunkte inklusive Metadaten – Subscriber wissen damit sofort, was sie erwarten können.
Ein Death Certificate wird ausgelöst, wenn die Verbindung unterbrochen wird, über den MQTT Last-Will-Mechanismus. Alle Subscriber wissen sofort: Die Daten dieses Knotens sind nicht mehr vertrauenswürdig.
Genau deshalb wird Sparkplug B oft als „stateful MQTT für OT" beschrieben – der Zustand ist explizit, nicht implizit.
Topic-Namespace und Message Types
Sparkplug B definiert einen festen Topic-Aufbau: spBv1.0/<group_id>/<message_type>/<edge_node_id>/<device_id>. Die device_id ist optional und wird nur angegeben, wenn eine Nachricht ein konkretes Device unter einem Edge Node betrifft.
Die in der Praxis relevantesten Message Types sind NBIRTH und NDEATH für Edge-Node-Zustand, DBIRTH und DDEATH für Device-Zustand, NDATA und DDATA für Nutzdaten und Telemetrie sowie NCMD und DCMD für Kommandos wie das Auslösen eines Rebirth.
Warum Sparkplug mehr ist als Topic-Standardisierung
Sparkplug B standardisiert auch die Payload-Struktur: welche Felder existieren, wie Metriken beschrieben werden, wie Metric Aliases und Sequence Numbers für effiziente und robuste Übertragung sorgen. Empfänger erhalten dadurch Konsistenz über Herstellergrenzen hinweg – ohne für jeden Publisher eigene Parsing-Logik zu entwickeln.
Typische Use Cases in der Fertigung
Sparkplug B wird eingesetzt, wenn ein Edge Gateway oder IoT Gateway Daten aus SPS, Modbus oder OPC-UA-Quellen einsammelt und standardisiert über MQTT publiziert – mehrere Systeme wie Historian, SCADA und Analytics konsumieren parallel, ohne dass der Publisher davon wissen muss.
Es ist außerdem ein häufiger Baustein in Unified-Namespace-Architekturen (UNS), weil Topics und State klar definiert sind. Und es löst ein klassisches OT-Problem: Der Online-/Offline-Zustand eines Geräts ist sofort sichtbar – nicht erst nach 30 Minuten ohne Datenpunkte.
Für Cloud-native MES-Plattformen, die Maschinendaten ohne schwere on-premise Middleware integrieren wollen, ist Sparkplug B ein relevanter Baustein: Es reduziert den Integrationsaufwand am Edge, weil Struktur und State standardisiert sind – statt für jede Maschinenquelle eigene Adapter-Logik zu bauen.
Vorteile gegenüber freiem MQTT
Gegenüber einem unstrukturierten MQTT-Einsatz bringt Sparkplug B drei harte Vorteile: Interoperabilität durch einheitliche Topic- und Payload-Standards, State Awareness durch Birth/Death-Mechanismus und Skalierbarkeit durch das Publish-Subscribe-Modell ohne Consumer-spezifische Speziallogik.
Typische Fehler
Wer Sparkplug-Topics nutzt, aber Birth und Death nicht korrekt implementiert, bricht das State-Management – der wesentliche Vorteil gegenüber freiem MQTT entfällt. Ohne klare group_id-Strategie wird ein Unified Namespace schnell chaotisch. Und reines Username/Passwort-Auth reicht in OT/IT-Netzen nicht aus – TLS, Netzsegmentierung und granulare Broker-Berechtigungen sind Pflicht.
FAQ
Was ist der Unterschied zwischen MQTT und Sparkplug B? MQTT ist das Transportprotokoll. Sparkplug B ist eine Spezifikation, die auf MQTT aufsetzt und standardisiert, wie Topics strukturiert, Payloads aufgebaut und Gerätezustände kommuniziert werden. MQTT ohne Sparkplug ist flexibel, aber ohne gemeinsame Semantik über Systeme hinweg.
Wann nimmt man Sparkplug B, wann OPC UA? Beide lösen das OT-Datenintegrationsproblem, aber mit unterschiedlichem Schwerpunkt. OPC UA ist stärker bei komplexen Informationsmodellen, direkter Maschine-zu-Maschine-Kommunikation und etablierten Industriestandards. Sparkplug B ist stärker bei leichtgewichtiger, broker-basierter Architektur mit vielen Quellen und Consumern. In der Praxis ergänzen sie sich: OPC UA am Gerät, Sparkplug B für den Edge-to-Cloud-Transport.
Ist Sparkplug B ein offizieller Standard? Ja. Sparkplug B wird unter dem Eclipse Specification Process als formaler Standard weiterentwickelt (aktuell Sparkplug 3.0). Die Referenzimplementierung ist Eclipse Tahu.
Funktioniert Sparkplug B mit jedem MQTT-Broker? Grundsätzlich ja, da Sparkplug auf Standard-MQTT aufsetzt. Allerdings unterstützen einige Broker Sparkplug-spezifische Features wie State-Management und Sparkplug-aware Routing nativ – was Betrieb und Debugging vereinfacht.
