Der Sparkplug Topic-Namespace ist die feste Struktur, die jede Sparkplug-B-Nachricht verwendet: spBv1.0/group_id/message_type/edge_node_id/device_id. In diesem Leitfaden erfahren Sie, was jedes Element bedeutet, wie Sie Gruppen, Nodes und Devices so benennen, dass sie überschaubar bleiben, und welche Wildcard-Subscriptions Sie für Monitoring, Befehle und Fehlersuche brauchen.
Warum Sparkplug die Topic-Struktur festlegt
Reines MQTT erlaubt Ihnen jede beliebige Topic-Hierarchie. Diese Freiheit ist in einem Einzelprojekt großartig, in einem ganzen Werk aber mühsam, wenn jeder Integrator ein anderes Schema wählt. Sparkplug nimmt Ihnen diese Wahl ab. Topics folgen einem einzigen Muster, sodass jede Sparkplug-fähige Host-Anwendung alle Edge Nodes und Devices ohne standortspezifische Konfiguration erkennen kann.
Der Kompromiss: Über Gruppe, Node und Device hinaus beschreibt der Topic Ihre Anlagenhierarchie nicht. Standort, Bereich und Linie stecken entweder in den Group- und Node-IDs oder in den Metriknamen. Diese Unterscheidung ist wichtig, wenn Sie einen Unified Namespace (UNS) entwerfen; wir kommen weiter unten darauf zurück.
Der Sparkplug Topic-Namespace Element für Element
spBv1.0/{group_id}/{message_type}/{edge_node_id}/{device_id}
| Element | Beispiel | Bedeutung | Erforderlich |
|---|---|---|---|
| Namespace | spBv1.0 |
Kennzeichnet die Sparkplug-B-Payload-Version | Immer |
| group_id | factory1 |
Logische Gruppierung von Edge Nodes | Immer |
| message_type | DDATA |
Art der Nachricht | Immer |
| edge_node_id | line1 |
Das Gateway bzw. der Edge Node | Immer |
| device_id | cnc1 |
Ein Device hinter dem Edge Node | Nur bei D-Nachrichten |
Namespace: spBv1.0
Die erste Ebene ist immer die feste Zeichenkette spBv1.0. Sie teilt Konsumenten mit, dass der Payload Sparkplug-B-Protobuf ist. Das ältere Sparkplug A verwendete spAv1.0 und ist veraltet. Beginnt ein Topic mit etwas anderem, handelt es sich nicht um Sparkplug B, selbst wenn der Payload zufällig Protobuf ist.
group_id
Die Group ID fasst Edge Nodes logisch zusammen. Viele Teams verwenden einen Standort oder Bereich, zum Beispiel werk-muenchen oder packaging. Host-Anwendungen abonnieren oft pro Gruppe, wählen Sie Gruppen also so, wie Sie Monitoring und Berechtigungen aufteilen möchten.
message_type
Das ist das Herzstück des Namespace. Der Nachrichtentyp sagt dem Konsumenten, wie er den Payload behandeln soll:
| Typ | Sender | Zweck |
|---|---|---|
| NBIRTH | Edge Node | Node ist online, kündigt alle Node-Metriken an |
| NDEATH | Broker (Will) oder Node | Node ist offline |
| DBIRTH | Edge Node | Device ist online, kündigt Device-Metriken an |
| DDEATH | Edge Node | Device ist offline |
| NDATA | Edge Node | Geänderte Werte von Node-Metriken |
| DDATA | Edge Node | Geänderte Werte von Device-Metriken |
| NCMD | Host-Anwendung | Befehl an den Edge Node, zum Beispiel Rebirth |
| DCMD | Host-Anwendung | Befehl an ein Device, zum Beispiel das Schreiben eines Sollwerts |
| STATE | Host-Anwendung | Online-/Offline-Status des Hosts |
Die Birth- und Death-Typen tragen das Zustandsmodell, das Sparkplug zuverlässig macht. Unser Leitfaden zu Sparkplug Birth- und Death-Zertifikaten erklärt den vollständigen Lebenszyklus.
edge_node_id
Die Edge Node ID identifiziert das Gateway, die SPS oder die Software, die die MQTT-Verbindung hält. Sie muss innerhalb ihrer Gruppe eindeutig sein. Zwei Nodes mit derselben ID überschreiben gegenseitig ihre Births und bringen die Sequenznummern durcheinander, einer der häufigsten Fehler bei der Inbetriebnahme.
device_id
Devices sitzen hinter einem Edge Node: eine CNC-Maschine, ein Antrieb, ein Modbus-Zähler. Nachrichten auf Device-Ebene (DBIRTH, DDEATH, DDATA, DCMD) fügen die Device ID als fünfte Ebene hinzu. Nachrichten auf Node-Ebene enden bei der Edge Node ID.
Der STATE-Topic
Die STATE-Nachricht ist die Ausnahme vom Muster. In Sparkplug 3.0 lautet sie spBv1.0/STATE/{host_id} mit einem kleinen JSON-Payload und wird von der Sparkplug Primary Host Application als Retained Message veröffentlicht. Ältere 2.2-Implementierungen verwendeten STATE/{host_id} ohne Namespace-Präfix. Wenn Sie gemischte Versionen betreiben, prüfen Sie, welche Form Ihr Host und Ihre Nodes erwarten.
Namensregeln, die Ihnen später Ärger ersparen
Die Spezifikation verbietet die MQTT-Sonderzeichen +, # und / in Group-, Node- und Device-IDs, weil sie die Topic-Ebenen zerstören würden. Darüber hinaus helfen einige Konventionen:
- Verwenden Sie nur Kleinbuchstaben, Ziffern und Bindestriche. Gemischte Groß- und Kleinschreibung führt zu Abweichungen zwischen Systemen.
- Halten Sie IDs stabil. Wird ein Edge Node umbenannt, entsteht aus Sicht des Hosts ein neuer Node, und die Historie kann sich aufspalten.
- Kodieren Sie keine veränderlichen Werte wie Firmware-Version oder IP-Adresse in einer ID.
- Legen Sie tiefere Hierarchien in Metriknamen ab, zum Beispiel
Spindle/Speed, statt zusätzliche Topic-Ebenen zu erzwingen. - Dokumentieren Sie die Bedeutung jeder Gruppe, damit neue Integratoren Nodes korrekt einordnen.
- Halten Sie IDs kurz. Sie wiederholen sich in jedem Topic und erscheinen in jedem Log.
Nützliche Subscriptions
Die feste Struktur macht Wildcard-Subscriptions vorhersehbar. Diese Muster werden Sie am häufigsten nutzen:
spBv1.0/# everything Sparkplug on the broker
spBv1.0/factory1/# everything in one group
spBv1.0/+/NBIRTH/# every node birth, all groups
spBv1.0/+/DDATA/+/+ every device data message
spBv1.0/factory1/+/line1/# everything from one edge node
spBv1.0/factory1/DDATA/line1/cnc1 one device's data
spBv1.0/STATE/+ host application status
Sie können diese Muster am öffentlichen MQTT-Broker ausprobieren. Er ist für Tests und Prototypen gedacht und für alle lesbar, verwenden Sie also eine zufällige Group ID und veröffentlichen Sie dort niemals echte Anlagendaten:
mosquitto_sub -h broker.connectmq.com -p 1883 -i ns-explorer-5c21 -t "spBv1.0/demo-5c21/#" -v
Veröffentlichen Sie in einem zweiten Terminal eine Testnachricht auf einem Device-Daten-Topic. Der Payload ist hier reiner Text, nur um das Routing zu prüfen; ein echter Node sendet Protobuf:
mosquitto_pub -h broker.connectmq.com -p 1883 -i ns-pub-5c21 -t "spBv1.0/demo-5c21/DDATA/line1/cnc1" -m "routing test"
Sparkplug-Topics nutzen auf dem öffentlichen MQTT-Broker fünf Ebenen und liegen damit bequem innerhalb des Limits von acht Ebenen. Ein Sparkplug-Simulator funktioniert dort also unverändert.
Den Namespace im Topic-Explorer durchsuchen
Ein Namespace ist viel leichter zu verstehen, wenn Sie ihn als Baum sehen. In ConnectMQ zeigt der Topic-Explorer im Portal spBv1.0-Topics an, sobald sie eintreffen. Da der Broker Sparkplug B dekodiert, können Sie auf einen DDATA-Topic klicken und dessen Metriken statt Rohbytes lesen. So beantworten Sie Fragen bei der Inbetriebnahme schnell, etwa ob ein neuer Edge Node sein Birth veröffentlicht hat oder welche Devices unter einem bestimmten Node liegen.
ConnectMQ kann Sparkplug-Daten außerdem in ISA-95-Topics erneut veröffentlichen. Eine Nachricht auf spBv1.0/factory1/DDATA/line1/cnc1 wird dann auf connectmq/factory1/production/line1/cnc1/telemetry verfügbar, was für Dashboards und Werkzeuge, die eine Anlagenhierarchie erwarten, angenehmer ist.
Sparkplug-Topics und der Unified Namespace
Der Sparkplug Topic-Namespace ist bewusst flach: Gruppe, Node, Device. Ein UNS folgt meist ISA-95 (IEC 62264): Die Equipment-Hierarchie Enterprise → Site → Area → Line → Cell wird zur Topic-Struktur auf dem MQTT-Broker, etwa acme/werk-stuttgart/montage/linie-1/zelle-3/temperatur. In vielen Architekturen existieren beide Sichten nebeneinander, und der UNS ist dabei das führende Modell. Sparkplug sorgt für einen zuverlässigen, zustandsbewussten Transport von der Edge, und der ISA-95-Baum bietet Menschen, MES, ERP und Analytics ein navigierbares Modell des gesamten Unternehmens. Die Designüberlegungen finden Sie in MQTT, Sparkplug B und der Unified Namespace, den größeren Kontext im Leitfaden zu Industrial IoT mit MQTT.
Fehlersuche bei Topic-Problemen
| Symptom | Wahrscheinliche Ursache | Was Sie prüfen sollten |
|---|---|---|
| Host sieht einen Node nie | Tippfehler im Topic oder falsche Schreibweise von spBv1.0 |
Exakte Namespace-Zeichenkette, Groß-/Kleinschreibung beachten |
| Zwei Nodes führen ständig Rebirths aus | Doppelte Edge Node ID in einer Gruppe | Eindeutige IDs pro Gruppe |
| Befehle kommen nicht an | Node hat seine NCMD/DCMD-Topics nicht abonniert | Node abonniert spBv1.0/group/NCMD/node und DCMD |
| Device-Daten werden ignoriert | DDATA vor DBIRTH gesendet | Device muss zuerst DBIRTH veröffentlichen |
| Host-Status fehlt | Host und Nodes erwarten unterschiedliche STATE-Topic-Formate | STATE-Topic nach 2.2 oder 3.0 |
Wenn Sie ein Topic-Problem vermuten, abonnieren Sie spBv1.0/your-group/# mit ausführlicher Ausgabe und beobachten Sie die Reihenfolge der Nachrichten beim Start. Zuerst sollten Births eintreffen, danach Daten.
Wo Sie Sparkplug betreiben
Sparkplug-Verkehr funktioniert auf jedem konformen MQTT Broker, doch Produktionsanlagen brauchen Zugangsdaten, TLS und jemanden, der für die Verfügbarkeit verantwortlich ist. Ein verwalteter MQTT-Broker übernimmt die Infrastruktur, damit sich Ihr Team auf Benennung, Modellierung und Integration konzentrieren kann. Sobald Births und Daten fließen, ist der nächste Schritt das Lesen der Payloads selbst, das in unserem Leitfaden zum Sparkplug B Payload behandelt wird.
Starten Sie mit ConnectMQ
Erstellen Sie unter app.connectmq.com einen kostenlosen Serverless-Broker, ganz ohne Kreditkarte. Verbinden Sie Ihren Edge Node mit den generierten Zugangsdaten über TLS auf Port 8883 und durchsuchen Sie Ihren Sparkplug Topic-Namespace dekodiert und übersichtlich im ConnectMQ Topic-Explorer.
Häufig gestellte Fragen
Kann ich einem Sparkplug-Topic weitere Ebenen hinzufügen?
Nein. Der Sparkplug Topic-Namespace ist für Node-Nachrichten auf vier und für Device-Nachrichten auf fünf Ebenen festgelegt. Legen Sie zusätzliche Hierarchie in Metriknamen ab oder bilden Sie die Daten auf einen ISA-95-Baum ab.
Ist die Group ID dasselbe wie ein Standort?
Das kann sie sein, die Spezifikation definiert sie aber nur als logische Gruppierung von Edge Nodes. Viele Teams verwenden eine Gruppe pro Standort oder pro Bereich, je nachdem, wie Host-Anwendungen zugeschnitten sind.
Warum sieht der STATE-Topic anders aus?
STATE-Nachrichten stammen von Host-Anwendungen, nicht von Edge Nodes, und folgen daher nicht dem Node- und Device-Muster. In Sparkplug 3.0 lautet der Topic spBv1.0/STATE/{host_id}.
Unterscheiden Sparkplug-Topics zwischen Groß- und Kleinschreibung?
Ja. MQTT-Topics sind case-sensitiv, daher sind spBv1.0 und SPBV1.0 verschiedene Topics, ebenso Line1 und line1.
