Sparkplug-Rebirth-Anforderungen: Wann und wie Sie sie auslösen

Ein Sparkplug Rebirth ist ein Befehl, den eine Host-Anwendung an einen Edge Node sendet, damit dieser seine NBIRTH- und DBIRTH-Nachrichten erneut veröffentlicht und der Host eine vollständige, aktuelle Sicht auf den Node wiederherstellen kann. In diesem Leitfaden erfahren Sie, welche Situationen ein Rebirth erfordern, wie Sie eines manuell senden, wie ein korrekter Edge Node antwortet und wie Sie das häufigste Problem in der Praxis diagnostizieren: Nodes, die immer und immer wieder ein Rebirth durchführen.

Was ein Rebirth bewirkt

Sparkplug-Konsumenten verlassen sich bei drei Dingen auf Birth-Nachrichten: die Liste der Metriken, die Zuordnung von Aliasen zu Namen und Datentypen sowie den aktuellen Wert jeder Metrik. Verpasst ein Host ein Birth oder verliert er den Überblick über die Sequenz, ist sein Modell des Nodes unvollständig. Ein Rebirth behebt das, ohne die MQTT-Verbindung zu trennen.

Der Befehl ist eine NCMD-Nachricht auf spBv1.0/{group}/NCMD/{edge_node} mit einer booleschen Metrik namens Node Control/Rebirth, die auf true gesetzt ist. Der Edge Node antwortet, indem er ein neues NBIRTH mit auf 0 zurückgesetztem seq und demselben bdSeq wie in seiner aktuellen Session veröffentlicht, gefolgt von einem DBIRTH für jedes Device. Ein separates Rebirth auf Device-Ebene gibt es nicht; ein Node-Rebirth veröffentlicht immer alle seine Devices neu.

Wann ein Host ein Rebirth anfordern sollte

Gut implementierte Host-Anwendungen senden diese automatisch. Wenn Sie einen eigenen Konsumenten schreiben, decken die ersten drei Auslöser die meisten realen Situationen ab.

Wie der Edge Node antworten sollte

1. Die NCMD empfangen und bestätigen, dass die Metrik Node Control/Rebirth true ist.
2. seq auf 0 zurücksetzen.
3. NBIRTH mit jeder Node-Metrik, ihrem aktuellen Wert, dem aktuellen bdSeq und der auf false zurückgesetzten Metrik Node Control/Rebirth veröffentlichen.
4. Für jedes aktuell verbundene Device ein DBIRTH veröffentlichen.
5. NDATA und DDATA wieder aufnehmen, wobei seq ab den Births weiterzählt.

Der bdSeq bleibt gleich, weil sich die MQTT-Session und damit der registrierte NDEATH-Will nicht geändert hat. Ein Node, der bdSeq beim Rebirth ohne Neuverbindung erhöht, verwirrt Hosts, die bdSeq prüfen, wenn später ein Death eintrifft. Die vollständigen Regeln für die Zertifikate erklärt Sparkplug Birth- und Death-Zertifikate.

Ein Rebirth manuell senden

Bei der Inbetriebnahme ist es nützlich, ein Rebirth selbst auszulösen. Dieses Python-Skript nutzt paho-mqtt 2.x und Klassen, die aus der Datei sparkplug_b.proto von Eclipse Tahu generiert wurden (den einmaligen Generierungsschritt zeigt unser Tutorial zum Dekodieren von Sparkplug B in Python):

import sys
import time
import uuid

import paho.mqtt.client as mqtt
import sparkplug_b_pb2 as spb

if len(sys.argv) != 3:
    sys.exit("usage: python rebirth.py <group_id> <edge_node_id>")

group, node = sys.argv[1], sys.argv[2]

payload = spb.Payload()
payload.timestamp = int(time.time() * 1000)
metric = payload.metrics.add()
metric.name = "Node Control/Rebirth"
metric.timestamp = payload.timestamp
metric.datatype = 11  # Boolean
metric.boolean_value = True

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2,
                     client_id=f"rebirth-{uuid.uuid4().hex[:8]}")
client.connect("broker.connectmq.com", 1883, keepalive=30)
client.loop_start()
info = client.publish(f"spBv1.0/{group}/NCMD/{node}", payload.SerializeToString(), qos=0)
info.wait_for_publish()
client.disconnect()
client.loop_stop()
print(f"rebirth sent to {group}/{node}")

Führen Sie es gegen einen Simulator auf dem öffentlichen MQTT-Broker aus, der für Tests und Prototypen gedacht ist, zum Beispiel python rebirth.py demo-3f9a1c line1, und beobachten Sie dabei die Gruppe:

mosquitto_sub -h broker.connectmq.com -p 1883 -i rebirth-watch-77d2 -v \
  -t "spBv1.0/demo-3f9a1c/#"

Sie sollten die NCMD sehen und kurz darauf ein NBIRTH und DBIRTH. Auf einem Produktiv-Broker verbinden Sie sich über Port 8883 mit TLS und Ihren Zugangsdaten aus dem Portal. Denken Sie daran, dass nur autorisierte Host-Anwendungen Befehle an echte Anlagen senden sollten.

Ablauf zur Fehlersuche

Wenn ein Host veraltete oder fehlende Metriken anzeigt, gehen Sie diese Schritte der Reihe nach durch:

1. Ist der Node verbunden? Prüfen Sie seine Verbindung. Bei ConnectMQ abonnieren Sie $SYS/broker/connection/{clientId}/state für die Client ID des Nodes oder sehen im Portal nach.
2. Hat der Node Births veröffentlicht? Suchen Sie nach NBIRTH und DBIRTH auf seinen Topics. Erscheinen nach dem Verbinden keine, wartet er möglicherweise auf eine Primary Host Application, deren STATE er nicht sieht.
3. Abonniert der Node NCMD? Senden Sie ein manuelles Rebirth. Passiert nichts, hat der Node spBv1.0/{group}/NCMD/{node} nicht abonniert oder implementiert Rebirth nicht.
4. Enthalten die Births alle Metriken? Vergleichen Sie das dekodierte DBIRTH mit den erwarteten Tags. Fehlende Metriken sind ein Konfigurationsproblem des Nodes, kein Transportproblem.
5. Ist seq lückenlos? Beobachten Sie mehrere Datennachrichten nach dem Birth. Lücken deuten auf Nachrichtenverlust oder einen zweiten Client mit derselben Edge Node ID hin.
6. Werden Aliase aufgelöst? Jeder Alias in NDATA oder DDATA muss im letzten Birth vorkommen. Ist das nicht der Fall, sendet der Node Aliase, die er nie deklariert hat.
7. Verarbeitet der Host Births korrekt? Zeigt der Broker korrekte Births, der Host aber weiterhin veraltete Daten, liegt das Problem auf Host-Seite.

Dekodierte Payloads beschleunigen die Schritte 2, 4, 5 und 6 erheblich. ConnectMQ dekodiert Sparkplug B im Topic-Explorer des Portals, sodass Sie die Metrikliste eines Births lesen, seq-Werte prüfen und Aliase erkennen können, ohne einen Decoder zu schreiben.

Rebirth-Stürme und wie Sie sie stoppen

Ein Rebirth-Sturm ist eine Schleife, in der ein Node fortlaufend Rebirths durchführt und Broker und Host mit Birth-Nachrichten überflutet. Typische Ursachen:

Die letzte Zeile verdient auf geteilter Infrastruktur besondere Aufmerksamkeit. Der öffentliche MQTT-Broker erlaubt 10 Nachrichten pro Sekunde und Client sowie 64 KB pro Nachricht, und Serverless-Pläne haben eigene Größenlimits für Nachrichten. Ein Node mit Tausenden von Metriken kann ein großes Birth erzeugen. Prüfen Sie daher die Größen, wenn Sie vom Simulator auf echte Anlagen umsteigen.

Hosts sollten auch ihre eigenen Anforderungen drosseln. Eine einfache Regel: höchstens ein offenes Rebirth pro Node, das beim Eintreffen des NBIRTH gelöscht wird, mit Backoff, falls das Birth nie kommt.

Checkliste zur Vorbeugung

1. Eindeutige Edge Node IDs pro Gruppe und eindeutige MQTT-Client-IDs pro Verbindung.
2. Births immer vor Daten veröffentlichen, mit jeder deklarierten Metrik und jedem Alias.
3. seq bei jedem NBIRTH auf 0 zurücksetzen; bdSeq beim Rebirth unverändert lassen.
4. Lückenerkennung im Host, die den Umlauf von 255 auf 0 berücksichtigt.
5. Im Produktivbetrieb darf nur ein festgelegter Host Befehle senden.
6. Birth-Größen gegen die Broker-Limits prüfen.

Den Transport zuverlässig halten

Die meisten Rebirths sind ein Symptom für etwas weiter vorne: abgebrochene Verbindungen, doppelte IDs oder ein Host-Neustart. Ein stabiler Broker reduziert die erste Kategorie. Ein verwalteter MQTT-Broker oder ein Cloud-MQTT-Broker nimmt Ihnen Patchen, Zertifikate und Monitoring ab.

Rebirths betreffen nicht nur SCADA. Speist Ihr Sparkplug-Verkehr einen Unified Namespace (UNS), in dem die ISA-95-Equipment-Hierarchie (Enterprise → Site → Area → Line → Cell) die Topic-Struktur auf dem MQTT-Broker bildet, etwa acme/werk-stuttgart/montage/linie-1/zelle-3/temperatur, dann muss auch die Bridge in den UNS ihre Alias-Tabellen nach jedem Rebirth neu aufbauen. Sonst landen Werte im falschen Zweig, und MES oder OEE-Dashboards rechnen mit falschen Zahlen. Wie Sparkplug und UNS zusammenspielen, erklärt Sparkplug B und Unified Namespace. Für das Gesamtbild von Sparkplug in Anlagenarchitekturen lesen Sie den Leitfaden zu Industrial IoT mit MQTT.

Starten Sie mit ConnectMQ

Erstellen Sie unter app.connectmq.com einen kostenlosen Serverless-Broker, ganz ohne Kreditkarte. Verbinden Sie Ihre Edge Nodes und Ihren Host, lösen Sie mit dem obigen Skript ein Rebirth aus und prüfen Sie die dekodierten Births im ConnectMQ Topic-Explorer.

Häufig gestellte Fragen

Trennt ein Sparkplug Rebirth die Verbindung des Edge Nodes?

Nein. Der Node bleibt verbunden und veröffentlicht seine Births in derselben MQTT-Session erneut. Deshalb ändert sich bdSeq während eines Rebirths nicht.

Kann ich ein Rebirth für ein einzelnes Device anfordern?

Nein. Der Rebirth-Befehl richtet sich an den Edge Node, der daraufhin sein NBIRTH und ein DBIRTH für jedes verbundene Device erneut veröffentlicht.

Warum fordert mein Host ständig Rebirths an?

Die häufigsten Ursachen sind doppelte Edge Node IDs, Aliase, die nicht in Births deklariert sind, oder eine Host-Logik, die den normalen seq-Umlauf von 255 auf 0 als Lücke wertet.

Sollten Births retained sein, um Rebirths zu vermeiden?

Nein. Sparkplug-Births sind niemals retained. Ein später startender Host fordert ein Rebirth an, damit er immer aktuelle Werte erhält.