Application hôte primaire Sparkplug et messages STATE

Une application hôte primaire Sparkplug est le principal consommateur des données d'usine, généralement un SCADA ou un MES, que les edge nodes surveillent avant de publier quoi que ce soit. Dans ce guide, vous verrez comment l'hôte s'annonce avec des messages STATE, comment les edge nodes sont censés réagir lorsqu'il se déconnecte, et comment tester ce comportement de bout en bout avec un petit hôte Python et quelques outils en ligne de commande.

Le rôle d'une application hôte

Sparkplug définit deux types de participants en plus du broker. Les edge nodes publient les données. Les applications hôtes les consomment, suivent l'état de chaque nœud et de chaque device, et envoient des commandes comme des demandes de rebirth ou des écritures de consigne. Une usine peut compter de nombreuses applications hôtes : SCADA, historian, service d'analyse, passerelle vers un Unified Namespace.

Une application hôte a plusieurs responsabilités :

• S'abonner à spBv1.0/# (ou aux groupes qu'elle gère) et maintenir un modèle en direct des nœuds, devices et métriques.
• Utiliser les certificats de birth pour apprendre les noms de métriques, les alias et les types de données.
• Marquer les données comme périmées à l'arrivée d'un NDEATH ou d'un DDEATH, en utilisant le bdSeq pour écarter les deaths d'anciennes sessions.
• Surveiller les numéros de séquence et demander un rebirth lorsqu'un trou apparaît.
• Publier son propre STATE pour que les edge nodes sachent si elle écoute.

Ce qui rend un hôte primaire

Un hôte peut être désigné comme application hôte primaire pour un ensemble d'edge nodes. Cela se configure sur l'edge node, pas sur le broker : on indique au nœud l'ID de l'hôte dont il dépend. L'idée est simple. Si le système sur lequel s'appuient les opérateurs n'est pas connecté, les données publiées à cet instant seraient perdues pour lui : l'edge node doit donc cesser de publier des données en direct, les stocker localement s'il prend en charge le store and forward, et attendre.

Sans hôte primaire configuré, un edge node publie dès qu'il est connecté au broker, quel que soit l'auditoire. C'est suffisant pour la supervision et les tableaux de bord, mais plus fragile pour un SCADA, où les trous dans l'historique comptent.

Les messages STATE dans Sparkplug 3.0

L'hôte s'annonce sur un topic dédié, en dehors de la structure des groupes :

spBv1.0/STATE/{host_id}

Le fait que le message soit retained signifie qu'un edge node qui se connecte à n'importe quel moment sait immédiatement si l'hôte est en ligne. L'horodatage partagé permet aux nœuds d'ignorer un ancien message : si un nœud a vu un état en ligne avec l'horodatage T2, un message hors ligne avec un horodatage plus ancien T1 est un reliquat d'une session précédente et ne doit pas déclencher de déconnexion.

Les anciens systèmes 2.2 utilisent STATE/{host_id} avec de simples chaînes ONLINE et OFFLINE. Les différences sont résumées dans notre comparatif Sparkplug 3.0.

La réaction des edge nodes

Un edge node configuré avec un hôte primaire suit un schéma prévisible :

1. Se connecter au broker avec son NDEATH enregistré comme will.
2. S'abonner à spBv1.0/STATE/{primary_host_id} ainsi qu'à ses propres topics NCMD et DCMD.
3. Attendre un message STATE avec "online": true.
4. Publier NBIRTH et DBIRTH, puis les données comme d'habitude.
5. Si STATE passe à "online": false avec un horodatage au moins aussi récent que le dernier vu, publier le NDEATH, se déconnecter et mettre les données en tampon si c'est pris en charge.
6. Se reconnecter (éventuellement à un autre broker dans une configuration multi-serveurs) et attendre à nouveau que l'hôte soit en ligne.
7. Au retour de l'hôte, publier de nouveaux births, puis les éventuelles données historiques mises en tampon, marquées avec is_historical.

L'étape 7 montre pourquoi STATE est important : les births donnent à l'hôte un modèle propre, et les indicateurs historiques lui permettent de combler les trous sans écraser les valeurs en direct. La mécanique des births et deaths est détaillée dans certificats birth et death Sparkplug.

Tester le flux avec un hôte Python minimal

Ce script joue le rôle d'un hôte primaire : il enregistre son will hors ligne, publie son état en ligne et écoute un groupe. Il utilise paho-mqtt 2.x et n'a pas besoin de Protobuf, puisque les payloads STATE sont en JSON.

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()

Lancez-le, notez l'ID d'hôte qu'il affiche, et dans un second terminal jouez le rôle de l'edge node qui surveille cet hôte :

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

Vous recevez immédiatement le message retained en ligne. Tuez maintenant le processus Python sans Ctrl+C (fermez le terminal ou terminez la tâche). Une fois la fenêtre de keepalive écoulée, le broker publie le will et l'observateur affiche "online": false avec le même horodatage. Redémarrez l'hôte et vous verrez un nouveau message en ligne avec un horodatage plus récent. C'est exactement le signal qu'utilise un edge node pour décider quand publier ses births.

Une fois terminé, effacez l'état retained pour que le serveur MQTT public gratuit, qui est partagé et réservé aux tests (jamais aux données de production), ne le conserve pas :

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

Surveiller l'état de l'hôte dans un explorateur de topics

Pendant la mise en service, on veut voir l'état de l'hôte et les births des nœuds sur un seul écran. ConnectMQ affiche les messages STATE retained dans l'explorateur de topics de son portail, à côté des births et données Sparkplug décodés, et expose l'état de connexion des clients sur $SYS/broker/connection/{clientId}/state. S'abonner à ce topic pour le client ID de votre hôte est une vérification croisée rapide : si l'état de connexion indique déconnecté mais que STATE indique toujours en ligne, le will ne s'est pas encore déclenché parce que la fenêtre de keepalive n'a pas expiré.

Problèmes courants

Concevoir pour la disponibilité de l'hôte

Comme les edge nodes cessent de publier lorsque l'hôte primaire est hors ligne, l'hôte et sa connexion au broker deviennent critiques. Exécutez l'hôte sur une infrastructure fiable, utilisez un keepalive court pour détecter rapidement les pannes, et assurez-vous que le broker lui-même n'est pas le maillon faible. Un broker MQTT managé ou un broker MQTT cloud vous décharge des mises à jour et de la surveillance du broker. Si un nœud perd sa connexion, c'est le processus de rebirth Sparkplug qui permet à l'hôte de retrouver une vue cohérente. Pour une vue complète de l'IIoT, consultez l'IoT industriel avec MQTT.

Démarrer avec ConnectMQ

Créez un broker Serverless gratuit sur app.connectmq.com, sans carte bancaire. Lancez le script hôte avec vos identifiants générés via TLS sur le port 8883, connectez un edge node configuré avec cet ID d'hôte, et suivez STATE, births et données dans le portail ConnectMQ.

Questions fréquentes

Peut-il y avoir plusieurs applications hôtes primaires ?

Chaque edge node est configuré avec un seul ID d'hôte primaire. Différents groupes de nœuds peuvent dépendre d'hôtes différents, et un nombre quelconque d'applications hôtes non primaires peut consommer les données en même temps.

Le message STATE est-il retained ?

Oui. Le message en ligne comme le will hors ligne sont publiés en retained avec la QoS 1 : tout edge node qui se connecte plus tard connaît donc immédiatement l'état actuel de l'hôte.

Le broker a-t-il besoin d'une prise en charge spécifique de Sparkplug pour STATE ?

Non. STATE repose sur des fonctionnalités MQTT standard : retained messages, QoS 1 et last will. N'importe quel broker conforme peut le transporter.

Que deviennent les données pendant que l'hôte primaire est hors ligne ?

Les edge nodes cessent de publier les données en direct. Les nœuds qui prennent en charge le store and forward les mettent en tampon et les envoient plus tard sous forme de métriques historiques, après de nouveaux births.