Bei industriellen IoT-Einsätzen reicht der reine Datentransport nicht aus — man braucht eine gemeinsame Semantik, die SPS, Edge-Gateways und SCADA-Systeme verschiedener Hersteller gleichermaßen verstehen. MQTT Sparkplug B ist eine offene Spezifikation der Eclipse Foundation, die dem leichtgewichtigen MQTT-Protokoll eine standardisierte Topic-Struktur, ein binäres Payload-Format und einen Mechanismus zur Geräte-Zustandsverwaltung hinzufügt. Dadurch gewinnt das industrielle IoT (IIoT) echte Plug-and-Play-Interoperabilität statt Dutzender proprietärer, inkompatibler Datenschemata.
Kurz gesagt: MQTT Sparkplug B ist eine Anwendungsschicht über MQTT, die einen einheitlichen Topic-Namensraum, ein kompaktes Google-Protocol-Buffers-Payload und Birth/Death-Nachrichten zur Zustandsverfolgung definiert — so tauschen Geräte verschiedener Hersteller im IIoT ohne manuelle Integration Daten aus.
Was ist MQTT Sparkplug B?
MQTT Sparkplug B ist eine Spezifikation, die definiert, wie man MQTT in industriellen Umgebungen einsetzt, und kein weiteres Transportprotokoll. Das Standard-MQTT-Protokoll mit QoS- und Last-Will-Mechanismen überträgt beliebige Bytes auf beliebigen Topics, sagt aber nichts über deren Struktur. Sparkplug B schließt diese Lücke, indem es gemeinsame Regeln vorgibt, sodass jeder Client die Daten sofort nach dem Verbinden versteht.
Die Spezifikation wird von der Eclipse-Sparkplug-Arbeitsgruppe entwickelt; die aktuelle Version 3.0 von 2023 präzisierte unter anderem die Behandlung der STATE-Nachricht für Host-Anwendungen. Sparkplug B wurde entworfen, um das von Industrieprotokollen wie Modbus, CAN oder RS-485 bekannte Polling durch ein Ereignis-Publikationsmodell zu ersetzen. Der Name Sparkplug spielt auf die Zündkerze an — ein Teil, das unabhängig vom Motorhersteller einfach passt und funktioniert, was die Idee der Interoperabilität gut einfängt.
Wie funktioniert MQTT Sparkplug B?
Sparkplug B organisiert die gesamte Kommunikation um einen festen Topic-Namensraum im Format spBv1.0/group_id/message_type/edge_node_id/device_id. Diese Hierarchie identifiziert Gruppe, Edge-Knoten und Gerät eindeutig, sodass Broker und Clients keine Namenskonvention aushandeln müssen.
Die wichtigsten Nachrichtentypen decken den Knoten- und Datenlebenszyklus ab:
- NBIRTH / DBIRTH — die „Geburt" eines Knotens und eines Geräts; sie veröffentlichen unmittelbar nach dem Verbinden den vollständigen Satz an Metriken und Definitionen.
- NDATA / DDATA — aktuelle Telemetriedaten, die nur bei einer Wertänderung gesendet werden (Report by Exception).
- NDEATH / DDEATH — der „Tod", vom Broker als Last Will and Testament registriert und signalisiert einen Verbindungsverlust.
- STATE — der Status der primären Host-Anwendung (z. B. SCADA), entscheidend für das Bewusstsein des Gesamtsystems.
Das Payload wird in Google Protocol Buffers kodiert, was kompakte, selbstbeschreibende Nachrichten mit Datentypen, Zeitstempeln und Sequenznummern ergibt. Die Sequenznummer ermöglicht es, verlorene Nachrichten zu erkennen und eine Resynchronisation zu erzwingen.
MQTT Sparkplug B vs. klassisches MQTT — worin liegen die Unterschiede?
Der Unterschied liegt in der semantischen Schicht: klassisches MQTT ist ein flexibler Transport, Sparkplug B ist ein fertiger Datenvertrag für das IIoT. Ohne Sparkplug B erstellen zwei Integrationsteams zwei unterschiedliche Topic- und Payload-Modelle für denselben Temperatursensor.
Sparkplug B führt drei Elemente ein, die im nackten MQTT fehlen: einen standardisierten Namensraum, Zustandsbewusstsein (Birth/Death) und ein definiertes, binäres Metrikformat. Das Ergebnis ist echte Interoperabilität — ein neues Gerät meldet seine Metriken in einer DBIRTH-Nachricht, und das übergeordnete System erkennt sie automatisch.
Warum spart Report by Exception Bandbreite?
Report by Exception (RBE) ist das Prinzip, dass ein Gerät einen Metrikwert nur dann veröffentlicht, wenn er sich tatsächlich ändert, statt ihn in einem festen Zyklus zu senden. In einer typischen Installation mit Tausenden Prozess-Tags reduziert RBE das Verkehrsvolumen um 80–95 % gegenüber klassischem Polling.
Diese Einsparung ist entscheidend für Mobilfunk- und Satellitenverbindungen, die nach Transfer abgerechnet werden, sowie für skalierbare Echtzeit-Telemetrie. Weniger Nachrichten bedeuten auch eine geringere Last für Broker und Backend, was sich direkt in Cloud-Kosten niederschlägt.
Wann sollte man MQTT Sparkplug B im IIoT einsetzen?
MQTT Sparkplug B bewährt sich überall dort, wo viele Geräte verschiedener Hersteller in einer ereignisgesteuerten Architektur Daten mit übergeordneten Systemen teilen müssen. Es ist die Standardwahl für moderne Unified-Namespace-(UNS-)Einführungen in Fabriken.
Typische Einsatzszenarien sind:
- Retrofit von Produktionslinien, bei dem ein Edge-Gateway Modbus/OPC UA in Sparkplug B übersetzt.
- SCADA/MES-Systeme, die Hunderte Knoten ohne manuelles Tag-Mapping konsolidieren.
- Predictive Maintenance, bei der DDATA-Ströme Analysemodelle speisen.
- Verteilte Energieanlagen und Smart Metering mit begrenzter Bandbreite.
Wie führt man MQTT Sparkplug B ein?
Die Einführung von Sparkplug B beginnt mit einem MQTT-3.1.1/5.0-konformen Broker (EMQX, HiveMQ, Mosquitto) und einer Client-Bibliothek, die Protobuf-Kodierung unterstützt, z. B. Eclipse Tahu für Java, Python, C oder C++. Der Broker muss Sparkplug nicht „verstehen" — die Zustandslogik liegt auf der Client- und Host-Anwendungsseite. Es lohnt sich zudem, im Voraus ein konsistentes Wörterbuch aus Metriken und Gruppen zu entwerfen, denn es bestimmt die Lesbarkeit des gesamten Unified Namespace.
In der Praxis sollte man auf die korrekte Last-Will-(NDEATH-)Konfiguration, konsistente Sequenznummern und TLS-1.3-Verschlüsselung mit Geräteauthentifizierung achten. FSS entwirft solche Systeme end-to-end — von der Edge-Knoten-Firmware bis zu Azure-nativen IoT-Backends, die Sparkplug-B-Ströme empfangen und an die Analyseschicht weitergeben.
Häufig gestellte Fragen (FAQ)
Worin unterscheidet sich MQTT Sparkplug B von reinem MQTT?
Reines MQTT ist nur Transport ohne definierte Datenstruktur — Topic-Namen und Payload-Format legt jeder Integrator einzeln fest. MQTT Sparkplug B fügt obendrauf einen standardisierten Topic-Namensraum, ein binäres Google-Protocol-Buffers-Format und einen Zustandsverwaltungsmechanismus (NBIRTH/NDEATH) hinzu, sodass sich Geräte verschiedener Hersteller sofort verstehen.
Benötigt MQTT Sparkplug B einen speziellen Broker?
Nein. Sparkplug B funktioniert auf jedem standardkonformen MQTT-3.1.1- oder -5.0-Broker, etwa EMQX, HiveMQ oder Mosquitto. Die Spezifikation definiert nur die Anwendungsschicht — Topics, Payload und Zustandssequenzen — sodass Sie Ihre bestehende Broker-Infrastruktur nicht ersetzen müssen.
Was sind die Hauptvorteile von Sparkplug B im IIoT?
Die zentralen Vorteile sind Plug-and-Play-Geräteinteroperabilität, Echtzeit-Zustandsbewusstsein dank Birth/Death-Nachrichten, Bandbreiteneinsparung durch Report by Exception und das kompakte Protobuf-Format. In der Praxis verkürzt das die Integration eines neuen Geräts von Tagen auf Stunden.
Fazit und wichtigste Erkenntnisse
MQTT Sparkplug B löst das schwierigste Problem des industriellen IoT — das Fehlen einer gemeinsamen Datensemantik — indem es dem bewährten MQTT einen standardisierten Namensraum, ein Protobuf-Format und Birth/Death-Zustandsverwaltung hinzufügt. Das Ergebnis sind Plug-and-Play-Interoperabilität, Echtzeit-Zustandsbewusstsein und deutliche Bandbreiteneinsparungen dank Report by Exception.
Als Team mit Erfahrung in Hardware, Firmware und Cloud entwerfen wir komplette IIoT-Systeme auf Basis von Sparkplug B — von Sensoren bis zu Dashboards. Entdecken Sie unsere Industrie- und Cloud-Integrationen und lassen Sie uns über eine Unified-Namespace-Einführung in Ihrer Anlage sprechen.