Sparkplug 3.0 ist die erste Version der Sparkplug-Spezifikation, die unter der Sparkplug Working Group der Eclipse Foundation veröffentlicht wurde, und sie präzisiert vor allem Verhalten, das 2.2 offen für Interpretationen ließ. In diesem Vergleich erfahren Sie genau, was sich zwischen 2.2 und 3.0 geändert hat, welche Änderungen die Interoperabilität in einer gemischten Flotte brechen können und wie Sie ein Upgrade von Edge Nodes und Host-Anwendungen ohne Überraschungen planen.
Die Kurzfassung
Sparkplug 3.0 hat das Protokoll nicht neu erfunden. Der Topic-Namespace ist weiterhin spBv1.0, der Protobuf-Payload ist weiterhin das Sparkplug-B-Schema, und Birth- und Death-Zertifikate funktionieren wie bisher. Geändert hat sich die Präzision. Version 2.2 beschrieb das Verhalten in Fließtext, den verschiedene Hersteller unterschiedlich lasen. Version 3.0 hat das Dokument als formale Spezifikation mit nummerierten normativen Aussagen neu geschrieben und es mit einem Technology Compatibility Kit (TCK) untermauert, das Implementierungen gegen diese Aussagen testet. Sparkplug 3.0 wurde zudem als internationaler Standard ISO/IEC 20237 veröffentlicht, was in Ausschreibungen und Lastenheften im DACH-Raum ein nützlicher Bezugspunkt ist.
Die eine Änderung, die für fast alle auf der Leitung sichtbar ist, betrifft die STATE-Nachricht der Host-Anwendung. Die meisten anderen Änderungen betreffen Randfälle: Wiederverbindungen, verspätete Wills, Session-Verwaltung und die Kodierung von Datentypen.
Sparkplug 3.0 vs. 2.2 im Überblick
| Bereich | Sparkplug 2.2 | Sparkplug 3.0 |
|---|---|---|
| Dokumentstil | Beschreibender Fließtext | Normative, testbare Aussagen |
| Konformität | Keine offizielle Testsuite | TCK mit Compliance-Profilen |
| Topic-Namespace | spBv1.0/... |
Unverändert |
| Payload-Schema | Sparkplug B Protobuf | Unverändert, Kodierungsregeln präzisiert |
| STATE-Topic | STATE/{host_id} |
spBv1.0/STATE/{host_id} |
| STATE-Payload | String ONLINE / OFFLINE |
JSON {"online": true, "timestamp": ...} |
| bdSeq | Vage beschrieben | Muss zwischen NBIRTH und NDEATH übereinstimmen, Regeln zum Hochzählen |
| QoS des NDEATH-Wills | Nicht einheitlich festgelegt | QoS 1, nicht retained |
| MQTT-Session | Implizit | Edge Nodes und Hosts verwenden Clean Sessions |
| Terminologie | SCADA/IIoT-Host, Primary Application | Host Application, Primary Host Application |
| Array-Datentypen | Aufgeführt, Kodierung unklar | Kodierung definiert |
Die wichtigsten Änderungen
Der neue STATE-Topic und Payload
In 2.2 veröffentlichte ein Primary Host einen retained String ONLINE auf STATE/{host_id} und registrierte OFFLINE als seinen Will. Dieser Topic lag außerhalb des spBv1.0-Namespace, was Berechtigungen erschwerte, und ein einfacher String bot keine Möglichkeit, eine alte von einer neuen Nachricht zu unterscheiden.
In 3.0 wandert der Topic nach spBv1.0/STATE/{host_id}, und der Payload wird zu JSON:
{ "online": true, "timestamp": 1792137600000 }
Der Host veröffentlicht ihn nach dem Verbinden retained mit QoS 1 und registriert einen Will mit "online": false und demselben Zeitstempel, den er in der Birth-Nachricht verwendet hat. Edge Nodes vergleichen Zeitstempel und ignorieren eine STATE-Nachricht, die älter ist als die bereits gesehene. Damit schließt sich eine Race Condition, bei der ein verspäteter OFFLINE-Will aus einer früheren Host-Session alle Edge Nodes zum Trennen bringen konnte, obwohl der Host längst wieder da war. Den vollständigen Ablauf beschreibt unser Artikel zur Sparkplug Primary Host Application.
Das ist eine inkompatible Änderung. Ein 2.2-Edge-Node, der STATE/scada1 beobachtet, wird einen 3.0-Host nie sehen, und ein 3.0-Node, der auf spBv1.0/STATE/scada1 wartet, wartet hinter einem 2.2-Host ewig. Manche Produkte unterstützen während einer Übergangsphase beide Formen; prüfen Sie Ihre, bevor Sie irgendetwas aktualisieren.
bdSeq-Regeln
Die Metrik bdSeq verknüpft ein NBIRTH mit dem NDEATH, das für dieselbe MQTT-Session registriert wurde. Version 3.0 macht die Regeln explizit: Der NDEATH-Will muss einen bdSeq enthalten, das folgende NBIRTH muss denselben Wert tragen, und der Wert ändert sich bei jeder neuen Verbindung. Hosts nutzen die Übereinstimmung, um ein Death-Zertifikat zu verwerfen, das zu einer älteren Session gehört. Wenn Sie Ihren eigenen Edge Node gegen 2.2 geschrieben haben, sollten Sie das als Erstes prüfen. Unser Leitfaden zu Sparkplug Birth- und Death-Zertifikaten zeigt eine funktionierende Implementierung.
Session- und QoS-Verhalten
Version 3.0 schreibt für Edge Nodes und Host-Anwendungen eine Clean Session vor (clean session true in MQTT 3.1.1 bzw. clean start mit einer Session Expiry von null in MQTT 5). Andernfalls könnten eingereihte Nachrichten aus einer alten Session nach einem neuen Birth eintreffen und das Zustandsmodell durcheinanderbringen. Der NDEATH-Will verwendet QoS 1 und ist nicht retained; auch Births und Daten sind nicht retained. Nur die STATE-Nachricht des Hosts ist retained.
Klarere Datentypen und Aliase
Der Datentyp muss in Birth-Nachrichten für jede Metrik angegeben sein. Aliase müssen pro Edge Node eindeutig sein. Array-Typen wie Int32Array oder BooleanArray haben eine definierte Byte-Kodierung, sodass Hersteller, die beide Array-Unterstützung angeben, tatsächlich Arrays austauschen können. Die Referenz zu den Sparkplug B Datentypen listet jeden Code auf.
Compliance-Profile
Das TCK definiert Profile für einen Edge Node, eine Host Application, einen MQTT Server und einen optionalen Sparkplug Aware MQTT Server. Jeder MQTT-3.1.1-Broker, der QoS 0 und 1, Retained Messages und Wills unterstützt, kann Sparkplug-Verkehr transportieren. Das Aware-Profil ergänzt optionale brokerseitige Funktionen, die in der Spezifikation definiert sind. Wenn ein Hersteller angibt, Sparkplug-3.0-kompatibel zu sein, fragen Sie nach dem Profil und ob er das TCK bestanden hat.
Was Sparkplug 3.0 für Ihren Broker bedeutet
Da der Payload für das Routing undurchsichtig ist, ändert sich die Aufgabe des Brokers kaum. Er braucht eine zuverlässige Last-Will-Behandlung, Retained Messages für STATE, QoS 1 und genügend Verbindungskapazität für jeden Node und Host. Ein verwalteter MQTT-Broker wie ConnectMQ unterstützt MQTT 3.1.1 und 5.0 auf denselben Endpunkten, sodass sich 2.2- und 3.0-Nodes während der Migration parallel verbinden können. ConnectMQ dekodiert außerdem Sparkplug B Payloads und zeigt sie im Topic-Explorer des Portals an. So prüfen Sie während einer Migration einfach, ob Births Datentypen enthalten, ob die bdSeq-Werte übereinstimmen und ob der neue STATE-Topic mit dem erwarteten JSON retained ist.
Bevor Sie die Produktion anfassen, können Sie auf dem öffentlichen MQTT-Broker mit einer zufälligen Group ID proben; er ist für Tests und Prototypen gedacht, nicht für Produktionsdaten. Veröffentlichen und lesen Sie zum Beispiel eine STATE-Nachricht nach 3.0:
mosquitto_pub -h broker.connectmq.com -p 1883 -i host-test-4e1b -r -q 1 \
-t "spBv1.0/STATE/demo-host-4e1b" -m '{"online": true, "timestamp": 1792137600000}'
mosquitto_sub -h broker.connectmq.com -p 1883 -i host-watch-4e1b -t "spBv1.0/STATE/demo-host-4e1b" -v
Löschen Sie die Retained Message anschließend, indem Sie einen leeren retained Payload auf denselben Topic veröffentlichen, denn der öffentliche MQTT-Broker wird geteilt.
Sparkplug 3.0 und der Unified Namespace (UNS)
In vielen Industrie-4.0-Projekten ist Sparkplug B nicht das Ziel, sondern ein Baustein eines UNS. Der UNS legt die ISA-95-Hierarchie (Enterprise → Site → Area → Line → Cell) als Topic-Struktur auf den Broker, etwa acme/werk-stuttgart/montage/linie-1/zelle-3/temperatur, während Sparkplug den Namespace spBv1.0/{group_id}/{message_type}/{edge_node_id}/{device_id} mit binären Payloads nutzt. Bewährt hat sich, Group ID und Edge Node ID so zu wählen, dass sie eindeutig auf Werk, Bereich und Linie abbildbar sind, und die dekodierten Metriken anschließend durch ein Gateway oder einen Konsumenten in den lesbaren UNS zu übertragen. Die strengeren Regeln von 3.0 für bdSeq und STATE helfen dabei, denn sie machen den Zustand jedes Edge Nodes eindeutig, den der UNS widerspiegeln soll. Die Abwägungen beider Konventionen erklärt der Beitrag Sparkplug B und Unified Namespace.
Upgrade-Checkliste von 2.2 auf 3.0
- Erfassen Sie alle Edge Nodes und Hosts und notieren Sie, welche Sparkplug-Version jeweils unterstützt wird.
- Legen Sie die STATE-Topic-Strategie fest: Hosts und Nodes gemeinsam aktualisieren oder Produkte nutzen, die während des Übergangs beide Formen unterstützen.
- Prüfen Sie, dass jeder Edge Node vor dem Verbinden einen NDEATH-Will mit bdSeq registriert und diesen bdSeq im NBIRTH wiederholt.
- Bestätigen Sie die Clean-Session-Einstellungen auf Nodes und Hosts.
- Stellen Sie sicher, dass Birth-Nachrichten für jede Metrik einen Datentyp enthalten und Aliase pro Node eindeutig sind.
- Testen Sie Array- und Template-Metriken zwischen Herstellern, falls Sie diese nutzen.
- Betreiben Sie den neuen Host parallel gegen eine Testgruppe und beobachten Sie dekodierte Births und STATE in einem Topic-Explorer.
- Stellen Sie Gruppe für Gruppe um und halten Sie für den Host einen Rollback-Plan bereit.
Sollten Sie upgraden?
Für neue Projekte beginnen Sie mit 3.0. Werkzeuge auf Basis aktueller Eclipse-Tahu-Releases folgen dieser Version, und das TCK gibt Ihnen ein Mittel an die Hand, Hersteller an der Spezifikation zu messen. Bei bestehenden 2.2-Anlagen, die funktionieren, upgraden Sie, wenn Sie Host-Anwendungen ersetzen oder hinzufügen, denn die STATE-Änderung erzwingt eine Abstimmung. Edge Nodes, die bdSeq bereits korrekt behandeln, benötigen oft nur ein Firmware- oder Konfigurationsupdate. Für den größeren architektonischen Kontext lesen Sie den Leitfaden zu Industrial IoT mit MQTT. Den offiziellen Text finden Sie auf der Eclipse-Sparkplug-Website.
Starten Sie mit ConnectMQ
Erstellen Sie unter app.connectmq.com einen kostenlosen Serverless-Broker, ganz ohne Kreditkarte. Verbinden Sie Ihre Sparkplug-3.0-Edge-Nodes und Ihren Host über TLS auf Port 8883 und prüfen Sie Births, Deaths und STATE-Nachrichten dekodiert im ConnectMQ-Portal, bevor Sie die Produktion migrieren.
Häufig gestellte Fragen
Ist Sparkplug 3.0 abwärtskompatibel mit 2.2?
Payload und spBv1.0-Topic-Namespace sind kompatibel. Topic und Payload von STATE haben sich geändert, daher erkennen 2.2-Nodes und 3.0-Hosts (oder umgekehrt) den Host-Zustand der jeweils anderen Seite ohne Kompatibilitätsmodus nicht.
Setzt Sparkplug 3.0 MQTT 5 voraus?
Nein. Sparkplug funktioniert über MQTT 3.1.1, und MQTT-5-Broker können es mit gleichwertigen Session-Einstellungen transportieren. Ein Broker, der beide Versionen unterstützt, ermöglicht eine schrittweise Migration.
Ist der Topic in Sparkplug 3.0 weiterhin spBv1.0?
Ja. Der Namespace kennzeichnet das Sparkplug-B-Payload-Format, das sich nicht geändert hat, daher bleiben die Topics spBv1.0/.... Nur STATE ist in diesen Namespace umgezogen.
Was ist das Sparkplug TCK?
Das Technology Compatibility Kit ist eine Testsuite des Eclipse-Sparkplug-Projekts, die Implementierungen gegen die normativen Aussagen der 3.0-Spezifikation prüft, jeweils pro Profil wie Edge Node oder Host Application.
