Sparkplug B vs. JSON über MQTT: Welchen Payload sollten Sie nutzen?

Sparkplug B vs. JSON ist eine der ersten Designentscheidungen in jedem industriellen MQTT-Projekt, und die Antwort lautet selten „für immer das eine oder das andere". In diesem Vergleich erfahren Sie, wie sich beide Ansätze bei Interoperabilität, Zustandserkennung, Bandbreite und Werkzeugen unterscheiden, wann welcher passt und wie Sie beide kombinieren, sodass Maschinen Sparkplug sprechen, während Menschen und Dashboards JSON lesen.

Zwei unterschiedliche Philosophien

MQTT selbst ist egal, was in einer Nachricht steckt. Das ist zugleich seine Stärke und der Grund, warum es diese Debatte gibt.

Reines JSON über MQTT bedeutet, dass Sie Ihre eigenen Topics und Payloads entwerfen. Ein Temperatursensor könnte {"temp": 21.4, "unit": "C", "ts": 1792137600} auf plant1/hall2/sensor7/telemetry veröffentlichen. Jeder kann es lesen, jede Sprache kann es parsen, und Sie können in fünf Minuten loslegen.

Sparkplug B ist eine Spezifikation auf MQTT-Basis. Sie legt die Topic-Struktur fest (spBv1.0/group/type/node/device), kodiert Payloads in Protobuf und ergänzt ein Zustandsmodell mit Birth- und Death-Zertifikaten, Sequenznummern und Befehlen. Sie geben Freiheit auf und gewinnen Interoperabilität mit jedem Sparkplug-fähigen SCADA-System oder jeder Host-Anwendung.

Hier derselbe Messwert als JSON:

{
  "timestamp": 1792137600123,
  "spindleSpeed": 1462.3,
  "spindleRunning": true
}

Als Sparkplug B ist der entsprechende DDATA-Payload binäres Protobuf. Dekodiert sieht er so aus, auf der Leitung sind es aber kompakte Bytes mit Aliasen statt Namen:

{
  "timestamp": 1792137600123,
  "seq": 17,
  "metrics": [
    { "alias": 3, "datatype": 10, "doubleValue": 1462.3 },
    { "alias": 4, "datatype": 11, "booleanValue": true }
  ]
}

Sparkplug B vs. JSON im direkten Vergleich

Wo Sparkplug B gewinnt

Interoperabilität

Das stärkste Argument für Sparkplug: Ein Gateway des einen Herstellers, etwa an einer Siemens S7 oder einem OPC-UA-Server, und ein SCADA-System eines anderen arbeiten ohne Mapping-Projekt zusammen. Der Host liest die Births, erkennt jede Metrik samt Datentyp und beginnt, Daten anzuzeigen. Bei JSON muss sich für jede neue Datenquelle jemand auf Feldnamen, Einheiten und Zeitstempel einigen.

Zustandserkennung

Sparkplug teilt Ihnen nicht nur den letzten Wert mit, sondern auch, ob er noch gültig ist. Fällt bei einem Gateway der Strom aus, veröffentlicht der Broker sein NDEATH, und jeder Host markiert die zugehörigen Tags als veraltet. Mit JSON können Sie das über einen Last Will auf einem Status-Topic annähern, benötigen aber zusätzlich Retained-Werte, eine Konvention für den Status auf Geräteebene und Logik in jedem Konsumenten.

Bandbreite

Protobuf mit Metrik-Aliasen ist deutlich kleiner als JSON, das Feldnamen in jeder Nachricht wiederholt. Zusammen mit Report by Exception, bei dem nur geänderte Werte gesendet werden, eignet sich Sparkplug gut für Mobilfunk- und Satellitenverbindungen. Bei einer Handvoll Sensoren im Werks-Ethernet spielt der Unterschied selten eine Rolle.

Wo JSON gewinnt

Einfachheit und Lesbarkeit

JSON können Sie mit mosquitto_sub und bloßem Auge debuggen. Webentwickler, Data Engineers und IT-Teams kennen es bereits. Low-Code-Werkzeuge wie Node-RED verarbeiten es nativ.

Flexibilität

Mit JSON können Sie Topics entlang Ihrer Anlagenhierarchie modellieren, etwa als ISA-95-Baum, und genau so strukturieren viele Teams einen Unified Namespace (UNS): Die ISA-95-Equipment-Hierarchie (Enterprise → Site → Area → Line → Cell) wird zur Topic-Struktur auf dem MQTT-Broker, zum Beispiel acme/werk-stuttgart/montage/linie-1/zelle-3/temperatur. Der feste Namespace von Sparkplug endet dagegen bei Gruppe, Node und Device.

Nicht-industrielle Konsumenten

Mobile Apps, Web-Dashboards, Cloud Functions und Analyse-Notebooks wollen in der Regel JSON. Bekommen sie Sparkplug, braucht jeder davon die Proto-Datei und eine Alias-Behandlung.

Beides auf dem öffentlichen MQTT-Broker ausprobieren

Die Lesbarkeit können Sie selbst auf dem öffentlichen MQTT-Broker vergleichen. Veröffentlichen Sie JSON:

mosquitto_pub -h broker.connectmq.com -p 1883 -i json-test-a81c \
  -t "connectmq/demo/a81c/line1/cnc1/telemetry" \
  -m '{"timestamp": 1792137600123, "spindleSpeed": 1462.3, "spindleRunning": true}'

Starten Sie dann einen Sparkplug-Simulator, etwa den aus unserem Leitfaden zu Sparkplug Birth- und Death-Zertifikaten, und abonnieren Sie beides mit ausführlicher Ausgabe. Das JSON erscheint sauber; die Sparkplug-Nachrichten erscheinen als teilweise binärer Text, bis Sie sie dekodieren. Der öffentliche MQTT-Broker ist für alle lesbar und nur für Tests und Prototypen gedacht, verwenden Sie also zufällige IDs und keine echten Produktionsdaten.

Das hybride Muster: Sparkplug an der Edge, JSON für Konsumenten

Viele Werke landen bei beidem. Edge Nodes und SCADA sprechen Sparkplug B für einen zuverlässigen, zustandsbewussten Transport, und eine Übersetzungsschicht veröffentlicht lesbares JSON in einen ISA-95-Topic-Baum für Dashboards, Analysen, MES und ERP. Dieser Baum ist der UNS: die zentrale, für alle lesbare Sicht auf Werk, Linien und Maschinen. Mehr dazu im Artikel Sparkplug B und Unified Namespace.

Diese Übersetzungsschicht können Sie selbst bauen: ein Python-Dienst, der spBv1.0/# abonniert, Protobuf dekodiert, Aliase auflöst und JSON erneut veröffentlicht. Unser Tutorial zum Dekodieren von Sparkplug B in Python ist ein solider Ausgangspunkt.

Alternativ überlassen Sie das dem Broker. ConnectMQ dekodiert Sparkplug B und kann es in ISA-95-Topics erneut veröffentlichen, sodass spBv1.0/factory1/DDATA/line1/cnc1 als connectmq/factory1/production/line1/cnc1/telemetry erscheint. Dashboards, Node-RED-Flows und Telegraf-Agenten abonnieren die lesbaren Topics als gewöhnliche MQTT-Clients, während Ihre Sparkplug-Hosts weiterhin den ursprünglichen Namespace nutzen. Das Portal zeigt die dekodierte Sparkplug-Ansicht außerdem im Topic-Explorer, sodass Ingenieure Metriknamen statt Bytes sehen.

Checkliste für die Entscheidung

1. Haben Sie ein Sparkplug-fähiges SCADA-System oder eine Host-Anwendung, oder planen Sie die Anschaffung? Wenn ja, tendieren Sie zu Sparkplug.
2. Müssen Bediener wissen, wann Werte veraltet sind? Sparkplug liefert das ohne eigenen Code.
3. Sind die Verbindungen volumenbasiert abgerechnet oder schmalbandig? Sparkplug mit Aliasen und Report by Exception hilft.
4. Besteht das Team überwiegend aus Web- und IT-Entwicklern mit wenigen Sensoren? Mit JSON kommen Sie schneller voran.
5. Möchten Sie Topics nach ISA-95-Ebenen organisieren? JSON passt dazu natürlich, oder Sie nutzen das hybride Muster.
6. Werden viele nicht-industrielle Anwendungen die Daten konsumieren? Stellen Sie JSON bereit, nativ oder per Übersetzung.
7. Mischen Sie Hersteller an der Edge? Sparkplug reduziert den Mapping-Aufwand.

Wenn Sie Punkte von beiden Seiten mit Ja beantwortet haben, ist der hybride Ansatz meist der richtige.

Der Broker ist in beiden Fällen derselbe

Beide Payloads laufen auf jedem standardkonformen MQTT Broker, Sie legen sich mit dieser Entscheidung also nicht auf eine Infrastruktur fest. Was sich ändert, ist die Transparenz. Ein verwalteter MQTT-Broker, der Sparkplug- und ISA-95-Topics versteht, macht die binäre Seite so zugänglich wie die JSON-Seite. Für die übergreifende Architektur lesen Sie MQTT, Sparkplug B und der Unified Namespace und den Leitfaden zu Industrial IoT mit MQTT.

Starten Sie mit ConnectMQ

Erstellen Sie unter app.connectmq.com einen kostenlosen Serverless-Broker, ganz ohne Kreditkarte. Veröffentlichen Sie JSON und Sparkplug B nebeneinander und lesen Sie beides im ConnectMQ Topic-Explorer, wobei Sparkplug-Daten zusätzlich in ISA-95-Topics veröffentlicht werden.

Häufig gestellte Fragen

Ist Sparkplug B für Industrial IoT immer besser als JSON?

Nein. Sparkplug B ist besser für die Interoperabilität mit SCADA und für integrierte Zustandserkennung. JSON ist einfacher und flexibler und für kleine Projekte oder IT-nahe Konsumenten oft die bessere Wahl.

Kann Sparkplug JSON statt Protobuf verwenden?

Die Sparkplug-B-Spezifikation definiert die Protobuf-Kodierung. Einige Werkzeuge bieten eine JSON-Darstellung für Debugging oder Bridging an, und ConnectMQ kann beide Formen dekodieren.

Kann ich Sparkplug B und JSON auf demselben Broker mischen?

Ja. Sie nutzen unterschiedliche Topics und koexistieren daher konfliktfrei. Viele Werke betreiben Sparkplug unter spBv1.0 und JSON unter einem ISA-95-Baum auf demselben Broker.

Unterstützt JSON über MQTT einen Online-Status für Geräte?

Nicht von sich aus. Sie können ihn mit einer retained Last-Will-Nachricht auf einem Status-Topic umsetzen, müssen die Konvention aber selbst definieren und durchsetzen.