Sparkplug B und der Unified Namespace (UNS) sind die beiden Konzepte, die in fast jedem Industrie-4.0-Projekt auf MQTT-Basis zur Sprache kommen, vom Mittelständler im Maschinenbau bis zum Konzern der Prozessindustrie. In diesem Artikel erfahren Sie, was ein UNS ist, wie aus der ISA-95-Hierarchie eine Topic-Struktur wird, wie Topic Namespace und Payload von Sparkplug B funktionieren und wie sich beide Ansätze ergänzen. Dabei veröffentlichen Sie echte ISA-95- und Sparkplug-B-Nachrichten an broker.connectmq.com.
Wenn die MQTT-Grundlagen neu für Sie sind, lesen Sie zuerst Was ist ein MQTT Broker?.
Das Problem: Punkt-zu-Punkt-Spaghetti
Eine typische Anlage hat SPSen (etwa Siemens S7), OPC-UA-Server, SCADA, ein MES, einen Historian, ein Qualitätssystem und ein ERP. Traditionell spricht jedes System über eine eigene Punkt-zu-Punkt-Verbindung mit den anderen. Kommt ein neues Dashboard hinzu, brauchen Sie drei neue Integrationen. Ändert sich ein SPS-Tag, geht weiter hinten etwas kaputt.
MQTT löst die Transportseite: Jeder Erzeuger veröffentlicht an einen Broker, jeder Verbraucher abonniert. Was MQTT nicht für Sie entscheidet, ist, wie Topics benannt und Payloads formatiert werden. Genau diese Lücke schließen ein Unified Namespace und Sparkplug B.
Was ist ein Unified Namespace?
Ein Unified Namespace (UNS) ist eine einzige, ereignisgesteuerte, hierarchische Sicht auf den aktuellen Zustand des gesamten Unternehmens. Statt jedes System einzeln nach Daten zu fragen, veröffentlicht jedes System, was es weiß, in einen gemeinsamen Topic-Baum auf dem Broker, und jeder Verbraucher abonniert den Teil, den er braucht.
Drei Eigenschaften kennzeichnen einen guten UNS:
- Single Source of Truth. Der aktuelle Wert jeder Maschine, jeder Linie und jedes Auftrags liegt an einem Ort.
- Nach dem Unternehmen strukturiert. Topics folgen der physischen und organisatorischen Hierarchie, sodass man Daten ohne Tag-Liste findet.
- Report by Exception. Erzeuger veröffentlichen, wenn sich etwas ändert, und Retained Messages liefern neuen Subscribern sofort den aktuellen Zustand.
ISA-95 als Topic-Struktur
Am häufigsten wird ein UNS nach der Equipment-Hierarchie von ISA-95 (international als IEC 62264 genormt) strukturiert. Diese Hierarchie kennen MES- und ERP-Teams bereits, deshalb verstehen IT und OT dieselbe Struktur. Jede Ebene wird zu einer Topic-Ebene:
Enterprise / Site / Area / Line / WorkCell / <data class>
acme / werk-stuttgart / machining / line1 / cnc1 / telemetry
Tabelle zum Topic-Design
| ISA-95-Ebene | Beispielwert | Topic-Ebene | Design-Tipp |
|---|---|---|---|
| Enterprise | acme | 1 | Feste, kurze Unternehmenskennung |
| Site | werk-stuttgart | 2 | Eine pro Werk oder Standort |
| Area | machining | 3 | Abteilung oder Produktionsbereich |
| Line | line1 | 4 | Produktionslinie oder Prozesszelle |
| WorkCell | cnc1 | 5 | Maschine, Roboter oder Station |
| Datenklasse | telemetry, state, alarms, cmd | 6 | Trennt schnelle Daten von Ereignissen und Befehlen |
Einige praktische Regeln:
- Verwenden Sie ASCII in Kleinbuchstaben, keine Leerzeichen und stabile IDs statt Anzeigenamen.
- Halten Sie die Tiefe vorhersagbar. Verbraucher nutzen Wildcards wie
acme/werk-stuttgart/+/+/+/alarms, um alle Alarme eines Standorts zu erhalten. - Legen Sie Befehle in einen eigenen Zweig (
cmd), damit sie getrennt von der Telemetrie abgesichert und auditiert werden können. - Veröffentlichen Sie Zustandsnachrichten als retained, damit ein neues Dashboard sofort den aktuellen Wert sieht.
Ausprobieren: Eine ISA-95-Nachricht als JSON veröffentlichen
Der öffentliche MQTT-Broker unter broker.connectmq.com erlaubt bis zu 8 Topic-Ebenen. Verwenden Sie daher ein kurzes Zufallspräfix statt eines langen. Abonnieren Sie in einem Terminal:
mosquitto_sub -h broker.connectmq.com -p 1883 -i uns-a1b2-sub \
-t "a1b2/acme/#" -v
Veröffentlichen Sie aus einem anderen Terminal einen Maschinenwert:
mosquitto_pub -h broker.connectmq.com -p 1883 -i uns-a1b2-cnc1 -q 1 \
-t "a1b2/acme/werk-stuttgart/machining/line1/cnc1/telemetry" \
-m '{"spindleSpeed":12000,"temperature":41.7,"status":"RUNNING"}'
Der Subscriber gibt das Topic und die JSON-Payload aus. Alles auf dem öffentlichen MQTT-Broker ist für jeden lesbar; er ist für Tests und Prototypen gedacht, veröffentlichen Sie dort also niemals echte Produktionsdaten.
Was ist Sparkplug B?
Sparkplug B ist eine offene Spezifikation unter dem Dach der Eclipse Foundation, die drei Dinge festlegt, die MQTT offenlässt: einen festen Topic Namespace, ein binäres Payload-Format und ein Modell zur Zustandsverwaltung. Sie wurde so entworfen, dass SCADA- und Host-Anwendungen Geräte automatisch erkennen und jederzeit wissen, ob Daten aktuell oder veraltet sind.
Der Topic Namespace von Sparkplug B
Jedes Sparkplug-B-Topic folgt diesem Muster:
spBv1.0/{group_id}/{message_type}/{edge_node_id}/{device_id}
group_id gruppiert Edge Nodes (zum Beispiel ein Werk), edge_node_id ist das Gateway oder Edge-Gerät, und die optionale device_id ist eine SPS oder ein Sensor hinter diesem Edge Node.
| Nachrichtentyp | Gesendet von | Zweck |
|---|---|---|
| NBIRTH | Edge Node | Node geht online und deklariert alle seine Metriken |
| NDEATH | Broker (als Will) | Node ist unerwartet offline gegangen |
| DBIRTH | Edge Node | Ein Gerät hinter dem Node geht mit seinen Metriken online |
| DDEATH | Edge Node | Ein Gerät ist offline gegangen |
| NDATA / DDATA | Edge Node | Geänderte Metrikwerte für Node oder Gerät |
| NCMD / DCMD | Host-Anwendung | Schreibbefehle an einen Node oder ein Gerät |
| STATE | Host-Anwendung | Meldet, ob der primäre Host online ist |
Die NDEATH-Nachricht wird beim Verbinden des Edge Nodes als MQTT Last Will hinterlegt, sodass der Broker sie bei einem Verbindungsabbruch automatisch veröffentlicht. Verbraucher markieren daraufhin alle Daten dieses Nodes als veraltet.
Payload: Protobuf, Aliases und Sequenznummern
Sparkplug-B-Payloads werden mit Google Protocol Buffers codiert. Eine Payload enthält einen Zeitstempel, eine Sequenznummer und eine Liste von Metriken; jede Metrik hat einen Namen, einen optionalen numerischen Alias, einen Datentyp, einen Zeitstempel und einen Wert.
Die wichtigsten Mechanismen:
- Birth Certificates. NBIRTH und DBIRTH enthalten jede Metrik mit vollständigem Namen und Datentyp. Spätere DDATA-Nachrichten können nur noch den numerischen Alias und den neuen Wert senden, was die Pakete klein hält.
- Sequenznummern. Jede Nachricht eines Edge Nodes trägt einen
seq-Wert von 0 bis 255, der danach wieder von vorn beginnt. Erkennt ein Host eine Lücke, weiß er, dass eine Nachricht verloren ging, und kann mit einem Rebirth-Befehl (NCMD) neue Birth Certificates anfordern. - bdSeq. Eine Birth/Death-Sequenznummer verknüpft jedes NDEATH mit dem NBIRTH derselben Session, sodass ein altes Death Certificate keine neuere Session auslöschen kann.
Hier derselbe Messwert wie oben, dargestellt als JSON-Repräsentation einer Sparkplug-B-DDATA-Payload:
{
"timestamp": 1760600000000,
"seq": 1,
"metrics": [
{ "name": "temperature", "timestamp": 1760600000000, "dataType": "Double", "value": 41.7 }
]
}
Sparkplug B vs. Unified Namespace: Ergänzung statt Konkurrenz
| Aspekt | Sparkplug B | Unified Namespace nach ISA-95 |
|---|---|---|
| Topic-Struktur | Fest: spBv1.0/group/type/node/device |
Frei, nach der Unternehmenshierarchie modelliert |
| Payload | Protobuf mit typisierten Metriken | Meist JSON, von Ihnen definiert |
| Zustandsbewusstsein | Integriert (Birth, Death, STATE) | Konvention, typischerweise Retained Messages |
| Lesbarkeit | Benötigt einen Decoder | Menschenlesbare Topics und Payloads |
| Ideal für | Edge-zu-SCADA, Geräteerkennung, verlässlicher Zustand | Unternehmensweiter Zugriff, Analytics, IT-Verbraucher |
In der Praxis nutzen viele Werke beides. Edge Nodes sprechen Sparkplug B, weil es nahe an den Maschinen verlässlichen Zustand und effiziente Payloads bietet. Die Daten werden dann als lesbares JSON in einen nach ISA-95 strukturierten Namespace republiziert, wo MES, Dashboards und IT-Anwendungen sie nutzen, ohne je mit Protobuf in Berührung zu kommen. Der UNS bleibt dabei das führende Konzept: Sparkplug B ist der zuverlässige Transport an der Edge, der ISA-95-Topic-Baum die gemeinsame Sprache für alle Systeme von der Werkshalle bis zum ERP. Die eigentliche Herausforderung ist diese Übersetzungsschicht – und genau hier kann der Broker helfen.
Wie ConnectMQ mit Sparkplug B und ISA-95-Topics umgeht
ConnectMQ ist ein verwalteter MQTT-Broker mit integrierter Unterstützung für Industrial IoT:
- ISA-95-Erkennung. Er erkennt ISA-95- und Unified-Namespace-Topic-Strukturen in Ihrem Datenverkehr.
- Sparkplug-B-Dekodierung. Er erkennt Sparkplug-B-Nachrichten und dekodiert sowohl Protobuf- als auch JSON-Payloads.
- Republizieren nach ISA-95. Sparkplug-B-Daten können in eine ISA-95-Struktur republiziert werden – so wird zum Beispiel aus
spBv1.0/factory1/DDATA/line1/cnc1das Topicconnectmq/factory1/production/line1/cnc1/telemetry, mit einer flachen JSON-Payload, die jeder Subscriber lesen kann. - Ansichten im Portal. Die Geräteansicht des Portals gliedert Ihre Anlagen nach ISA-95-Ebenen, und mit Schwellwert-Alarmregeln samt Alarmprotokoll können Sie reagieren, wenn etwa die Temperatur einer Spindel einen Grenzwert überschreitet.
Ausprobieren: Sparkplug B rein, lesbare Telemetrie raus
Verwenden Sie eine eindeutige Group ID wie a1b2plant. Abonnieren Sie zuerst sowohl das Sparkplug-Topic als auch den republizierten Zweig:
mosquitto_sub -h broker.connectmq.com -p 1883 -i spb-a1b2-sub -v \
-t "spBv1.0/a1b2plant/#" -t "connectmq/a1b2plant/#"
Veröffentlichen Sie dann eine DDATA-Nachricht mit einer Sparkplug-B-Payload im JSON-Format:
mosquitto_pub -h broker.connectmq.com -p 1883 -i spb-a1b2-edge -q 1 \
-t "spBv1.0/a1b2plant/DDATA/line1/cnc1" \
-m '{"timestamp":1760600000000,"seq":1,"metrics":[{"name":"temperature","timestamp":1760600000000,"dataType":"Double","value":41.7}]}'
Als wir das auf broker.connectmq.com getestet haben, erhielt der Subscriber die ursprüngliche Sparkplug-B-Nachricht und eine zweite Nachricht unter connectmq/a1b2plant/.../line1/cnc1/telemetry mit der Payload {"temperature":41.7,"timestamp":1760600000000}. Nachgelagerte Tools können nun connectmq/a1b2plant/+/+/+/telemetry abonnieren und erhalten sauberes JSON pro Maschine.
Für die Produktion legen Sie im Portal einen eigenen Broker an und verbinden sich mit YOUR_USERNAME, YOUR_PASSWORD und YOUR_CLIENT_ID über TLS auf Port 8883. Die Topics jedes Mandanten sind von anderen Mandanten und vom öffentlichen MQTT-Broker isoliert. Hinweise zu Zugangsdaten und TLS finden Sie in MQTT-Sicherheit: Best Practices.
Design-Checkliste für Ihren ersten UNS
- Legen Sie die ISA-95-Ebenen und Namensregeln fest, bevor sich das erste Gerät verbindet.
- Entscheiden Sie, welche Datenklassen Sie brauchen (
telemetry,state,alarms,cmd), und halten Sie sie konsistent. - Setzen Sie Sparkplug B am Edge ein, wo Sie Birth/Death-Bewusstsein brauchen, und einen lesbaren ISA-95-Zweig für alle anderen.
- Verwenden Sie QoS 1 für Zustände und Alarme; die Abwägungen erklärt MQTT QoS-Stufen erklärt.
- Nutzen Sie Retained Messages für den aktuellen Zustand und halten Sie Payloads klein und typisiert.
- Wählen Sie einen Broker, der mit Ihnen wachsen kann; die Kriterien behandelt IoT MQTT Broker auswählen.
Starten Sie mit ConnectMQ
Beide Beispiele oben können Sie sofort auf dem öffentlichen MQTT-Broker ausprobieren. Um einen echten Unified Namespace mit isolierten Topics, ISA-95-Geräteansichten und Schwellwert-Alarmen aufzubauen, registrieren Sie sich unter app.connectmq.com. Der Serverless-Plan ist kostenlos und benötigt keine Kreditkarte, und wenn Ihr Werk live geht, können Sie auf Dedicated, BYOC oder Self Managed Enterprise skalieren.
Häufig gestellte Fragen
Ist Sparkplug B dasselbe wie ein Unified Namespace?
Nein. Sparkplug B ist eine Spezifikation für Topics, Payloads und Session-Zustand auf MQTT, während ein Unified Namespace ein Architekturmuster ist, um alle Unternehmensdaten in einer Hierarchie zu organisieren. Beide arbeiten gut zusammen.
Kann ich Sparkplug-B-Nachrichten ohne Protobuf-Decoder lesen?
Nicht direkt, denn die Payload ist binär. ConnectMQ dekodiert Sparkplug-B-Payloads in Protobuf und JSON und kann sie als lesbares JSON in eine ISA-95-Topic-Struktur republizieren.
Wie tief sollte eine ISA-95-Topic-Hierarchie sein?
Enterprise, Site, Area, Line und WorkCell plus eine Datenklasse ergeben sechs Ebenen, was für die meisten Werke passt. Halten Sie die Tiefe konsistent, damit Wildcard-Abonnements vorhersagbar funktionieren.
Erfordert Sparkplug B MQTT 5?
Nein. Sparkplug B funktioniert über MQTT 3.1.1 und wird häufig so eingesetzt. ConnectMQ unterstützt MQTT 3.1.1 und MQTT 5.0, sodass sich Sparkplug-Edge-Nodes und neuere Clients denselben Broker teilen können.
