Sparkplug Primary Host Application und STATE-Nachrichten

Eine Sparkplug Primary Host Application ist der Hauptkonsument der Anlagendaten, typischerweise ein SCADA- oder MES-System, den Edge Nodes beobachten, bevor sie überhaupt etwas veröffentlichen. In diesem Leitfaden erfahren Sie, wie sich der Host mit STATE-Nachrichten ankündigt, wie Edge Nodes reagieren sollen, wenn er offline geht, und wie Sie dieses Verhalten mit einem kleinen Python-Host und einigen Kommandozeilenwerkzeugen durchgängig testen.

Was eine Host-Anwendung tut

Sparkplug definiert neben dem Broker zwei Arten von Teilnehmern. Edge Nodes veröffentlichen Daten. Host-Anwendungen konsumieren sie, verfolgen den Zustand jedes Nodes und Devices und senden Befehle wie Rebirth-Anforderungen oder Sollwert-Schreibvorgänge. Eine Anlage kann viele Host-Anwendungen haben: SCADA, ein MES, einen Historian, einen Analysedienst, eine Bridge in den Unified Namespace (UNS).

Gerade die UNS-Bridge verdient Aufmerksamkeit. Im UNS wird die ISA-95-Equipment-Hierarchie (Enterprise → Site → Area → Line → Cell) zur Topic-Struktur auf dem MQTT-Broker, etwa acme/werk-stuttgart/montage/linie-1/zelle-3/temperatur. Die Bridge abonniert den Sparkplug-Verkehr und veröffentlicht lesbare Werte in diesen Baum. Ob sie als Primary Host gilt oder nur mitliest, ist eine Architekturentscheidung, die Sie früh treffen sollten. Hintergründe liefert der Artikel Sparkplug B und Unified Namespace.

Eine Host-Anwendung hat mehrere Aufgaben:

• spBv1.0/# (oder die von ihr verwalteten Gruppen) abonnieren und ein Live-Modell aus Nodes, Devices und Metriken pflegen.
• Aus Birth-Zertifikaten Metriknamen, Aliase und Datentypen lernen.
• Daten als veraltet markieren, wenn ein NDEATH oder DDEATH eintrifft, und dabei über bdSeq Deaths aus alten Sessions verwerfen.
• Sequenznummern überwachen und bei einer Lücke ein Rebirth anfordern.
• Den eigenen STATE veröffentlichen, damit Edge Nodes wissen, ob sie zuhört.

Was einen Host zum Primary macht

Ein Host kann für eine Reihe von Edge Nodes als Primary Host Application festgelegt werden. Das wird am Edge Node konfiguriert, nicht am Broker: Der Node erhält die Host ID, von der er abhängt. Die Idee ist einfach. Ist das System, auf das sich die Bediener verlassen, nicht verbunden, wären jetzt veröffentlichte Daten für dieses System verloren. Der Edge Node sollte daher keine Live-Daten mehr veröffentlichen, sie lokal speichern, sofern er Store and Forward unterstützt, und warten.

Ohne konfigurierten Primary Host veröffentlicht ein Edge Node, sobald er mit dem Broker verbunden ist, unabhängig davon, wer zuhört. Für Monitoring und Dashboards ist das in Ordnung, für SCADA und MES, wo Lücken in der Historie zählen, etwa bei Chargenprotokollen in der Prozessindustrie oder bei OEE-Auswertungen, aber schwächer.

STATE-Nachrichten in Sparkplug 3.0

Der Host kündigt sich auf einem eigenen Topic außerhalb der Gruppenstruktur an:

spBv1.0/STATE/{host_id}

Weil die Nachricht retained ist, erfährt ein Edge Node, der sich zu einem beliebigen Zeitpunkt verbindet, sofort, ob der Host online ist. Über den gemeinsamen Zeitstempel können Nodes eine alte Nachricht ignorieren: Hat ein Node online mit dem Zeitstempel T2 gesehen, ist eine Offline-Nachricht mit dem älteren Zeitstempel T1 ein Überbleibsel einer früheren Session und darf keine Trennung auslösen.

Ältere 2.2-Systeme verwenden STATE/{host_id} mit einfachen Strings ONLINE und OFFLINE. Die Unterschiede fasst unser Vergleich zu Sparkplug 3.0 zusammen.

Wie Edge Nodes reagieren

Ein Edge Node mit konfiguriertem Primary Host folgt einem vorhersehbaren Muster:

1. Er verbindet sich mit dem Broker, wobei sein NDEATH als Will registriert ist.
2. Er abonniert spBv1.0/STATE/{primary_host_id} sowie seine eigenen NCMD- und DCMD-Topics.
3. Er wartet auf eine STATE-Nachricht mit "online": true.
4. Er veröffentlicht NBIRTH und DBIRTH, danach wie gewohnt Daten.
5. Wechselt STATE auf "online": false mit einem Zeitstempel, der mindestens so neu ist wie der zuletzt gesehene, veröffentlicht er NDEATH, trennt die Verbindung und puffert Daten, sofern unterstützt.
6. Er verbindet sich erneut (in einem Multi-Server-Setup eventuell mit einem anderen Broker) und wartet wieder darauf, dass der Host online ist.
7. Kehrt der Host zurück, veröffentlicht er frische Births und anschließend alle gepufferten historischen Daten, gekennzeichnet mit is_historical.

Schritt 7 zeigt, warum STATE wichtig ist: Births geben dem Host ein sauberes Modell, und die Historical-Kennzeichnung erlaubt ihm das Nachfüllen, ohne Live-Werte zu überschreiben. Die Mechanik von Birth und Death beschreibt Sparkplug Birth- und Death-Zertifikate.

Den Ablauf mit einem minimalen Python-Host testen

Dieses Skript übernimmt die Rolle eines Primary Hosts: Es registriert seinen Offline-Will, veröffentlicht seinen Online-Zustand und hört eine Gruppe ab. Es nutzt paho-mqtt 2.x und braucht kein Protobuf, weil STATE-Payloads JSON sind.

import json
import time
import uuid

import paho.mqtt.client as mqtt

BROKER = "broker.connectmq.com"
PORT = 1883
HOST_ID = "demo-host-" + uuid.uuid4().hex[:6]
GROUP = "demo-" + HOST_ID[-6:]
STATE_TOPIC = f"spBv1.0/STATE/{HOST_ID}"
SESSION_TS = int(time.time() * 1000)


def state(online):
    return json.dumps({"online": online, "timestamp": SESSION_TS})


def on_connect(client, userdata, flags, reason_code, properties):
    if reason_code.is_failure:
        print("connect failed:", reason_code)
        return
    client.subscribe(f"spBv1.0/{GROUP}/#", qos=1)
    client.subscribe(STATE_TOPIC, qos=1)
    client.publish(STATE_TOPIC, state(True), qos=1, retain=True)
    print(f"host {HOST_ID} online, watching group {GROUP}")


def on_message(client, userdata, msg):
    if msg.topic == STATE_TOPIC:
        print("STATE:", msg.payload.decode())
    else:
        print(f"{msg.topic} ({len(msg.payload)} bytes)")


client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2,
                     client_id=f"host-{uuid.uuid4().hex[:8]}",
                     clean_session=True)
client.on_connect = on_connect
client.on_message = on_message
client.will_set(STATE_TOPIC, state(False), qos=1, retain=True)
client.connect(BROKER, PORT, keepalive=15)

try:
    client.loop_forever()
except KeyboardInterrupt:
    client.publish(STATE_TOPIC, state(False), qos=1, retain=True).wait_for_publish()
    client.disconnect()

Starten Sie es, notieren Sie die ausgegebene Host ID und spielen Sie in einem zweiten Terminal den Edge Node, der diesen Host beobachtet:

mosquitto_sub -h broker.connectmq.com -p 1883 -i node-watch-91aa -q 1 -v \
  -t "spBv1.0/STATE/demo-host-xxxxxx"

Sie erhalten sofort die retained Online-Nachricht. Beenden Sie nun den Python-Prozess ohne Strg+C (Terminal schließen oder Task beenden). Nach Ablauf des Keepalive-Fensters veröffentlicht der Broker den Will, und der Beobachter gibt "online": false mit demselben Zeitstempel aus. Starten Sie den Host neu, sehen Sie eine neue Online-Nachricht mit einem neueren Zeitstempel. Genau dieses Signal nutzt ein Edge Node, um zu entscheiden, wann er Births veröffentlicht.

Wenn Sie fertig sind, löschen Sie den retained Zustand, damit der geteilte öffentliche MQTT-Broker, der nur für Tests und Prototypen gedacht ist, ihn nicht behält:

mosquitto_pub -h broker.connectmq.com -p 1883 -i cleanup-91aa -r -n -t "spBv1.0/STATE/demo-host-xxxxxx"

Den Host-Zustand im Topic-Explorer beobachten

Bei der Inbetriebnahme möchten Sie Host-Zustand und Node-Births auf einem Bildschirm sehen. ConnectMQ zeigt retained STATE-Nachrichten im Topic-Explorer des Portals neben dekodierten Sparkplug-Births und -Daten an und stellt den Verbindungszustand der Clients unter $SYS/broker/connection/{clientId}/state bereit. Diesen Topic für die Client ID Ihres Hosts zu abonnieren, ist eine schnelle Gegenprobe: Meldet der Verbindungszustand getrennt, STATE aber noch online, wurde der Will noch nicht ausgelöst, weil das Keepalive-Fenster noch nicht abgelaufen ist.

Häufige Probleme

Auf Host-Verfügbarkeit auslegen

Da Edge Nodes nicht mehr veröffentlichen, wenn der Primary Host offline ist, werden der Host und seine Broker-Verbindung kritisch. Betreiben Sie den Host auf zuverlässiger Infrastruktur, verwenden Sie ein kurzes Keepalive, damit Ausfälle schnell erkannt werden, und sorgen Sie dafür, dass der Broker selbst nicht das schwache Glied ist. Ein verwalteter MQTT-Broker oder ein Cloud-MQTT-Broker nimmt Ihnen das Patchen und Überwachen des Brokers ab. Verliert ein Node seine Verbindung, bringt der Sparkplug-Rebirth-Prozess den Host zurück zu einer konsistenten Sicht. Für das vollständige IIoT-Bild lesen Sie Industrial IoT mit MQTT.

Starten Sie mit ConnectMQ

Erstellen Sie unter app.connectmq.com einen kostenlosen Serverless-Broker, ganz ohne Kreditkarte. Führen Sie das Host-Skript mit Ihren generierten Zugangsdaten über TLS auf Port 8883 aus, verbinden Sie einen Edge Node, der mit dieser Host ID konfiguriert ist, und beobachten Sie STATE, Births und Daten im ConnectMQ-Portal.

Häufig gestellte Fragen

Kann es mehr als eine Primary Host Application geben?

Jeder Edge Node wird mit genau einer Primary Host ID konfiguriert. Verschiedene Gruppen von Nodes können von verschiedenen Hosts abhängen, und beliebig viele weitere Host-Anwendungen können gleichzeitig Daten konsumieren.

Ist die STATE-Nachricht retained?

Ja. Sowohl die Online-Nachricht als auch der Offline-Will werden retained mit QoS 1 veröffentlicht, sodass jeder später verbundene Edge Node den aktuellen Host-Zustand sofort erfährt.

Braucht der Broker spezielle Sparkplug-Unterstützung für STATE?

Nein. STATE beruht auf Standard-MQTT-Funktionen: Retained Messages, QoS 1 und dem Last Will. Jeder konforme Broker kann es transportieren.

Was passiert mit Daten, während der Primary Host offline ist?

Edge Nodes veröffentlichen keine Live-Daten mehr. Nodes mit Store-and-Forward-Unterstützung puffern sie und senden sie später nach neuen Births als historische Metriken.