L'espace de noms des topics Sparkplug est la structure fixe utilisée par chaque message Sparkplug B : spBv1.0/group_id/message_type/edge_node_id/device_id. Dans ce guide, vous verrez ce que signifie chaque élément, comment nommer groupes, nœuds et devices pour qu'ils restent gérables, et de quels abonnements à wildcards vous avez besoin pour la supervision, les commandes et le débogage.
Pourquoi Sparkplug impose la structure des topics
MQTT seul vous laisse inventer n'importe quelle hiérarchie de topics. Cette liberté est idéale pour un projet isolé et pénible à l'échelle d'une usine, où chaque intégrateur choisit un schéma différent. Sparkplug supprime ce choix. Les topics suivent un seul modèle, si bien que n'importe quelle application hôte compatible Sparkplug peut découvrir tous les edge nodes et devices sans configuration propre à chaque site.
La contrepartie : le topic ne décrit pas la hiérarchie de votre usine au-delà du groupe, du nœud et du device. Le site, la zone et la ligne se retrouvent soit dans les ID de groupe et de nœud, soit dans les noms de métriques. Cette distinction compte lorsque vous concevez un Unified Namespace, et nous y reviendrons plus bas.
L'espace de noms des topics Sparkplug, élément par élément
spBv1.0/{group_id}/{message_type}/{edge_node_id}/{device_id}
| Élément | Exemple | Signification | Obligatoire |
|---|---|---|---|
| Namespace | spBv1.0 |
Identifie la version du payload Sparkplug B | Toujours |
| group_id | factory1 |
Regroupement logique d'edge nodes | Toujours |
| message_type | DDATA |
Nature du message | Toujours |
| edge_node_id | line1 |
La passerelle ou l'edge node | Toujours |
| device_id | cnc1 |
Un device derrière l'edge node | Uniquement pour les messages D |
Namespace : spBv1.0
Le premier niveau est toujours la chaîne littérale spBv1.0. Elle indique aux consommateurs que le payload est du Sparkplug B en Protobuf. L'ancien Sparkplug A utilisait spAv1.0 et est obsolète. Si vous voyez un topic qui commence par autre chose, ce n'est pas du Sparkplug B, même si le payload se trouve être du Protobuf.
group_id
Le group ID regroupe logiquement les edge nodes. Beaucoup d'équipes utilisent un site ou une zone, par exemple plant-izmir ou packaging. Une application hôte s'abonne souvent groupe par groupe : choisissez donc des groupes qui correspondent à la façon dont vous voulez répartir la supervision et les permissions.
message_type
C'est le cœur de l'espace de noms. Il indique au consommateur comment traiter le payload :
| Type | Émetteur | Rôle |
|---|---|---|
| NBIRTH | Edge node | Le nœud est en ligne et annonce toutes ses métriques |
| NDEATH | Broker (will) ou nœud | Le nœud est hors ligne |
| DBIRTH | Edge node | Le device est en ligne et annonce ses métriques |
| DDEATH | Edge node | Le device est hors ligne |
| NDATA | Edge node | Valeurs modifiées des métriques du nœud |
| DDATA | Edge node | Valeurs modifiées des métriques du device |
| NCMD | Application hôte | Commande à l'edge node, par exemple un rebirth |
| DCMD | Application hôte | Commande à un device, par exemple l'écriture d'une consigne |
| STATE | Application hôte | État en ligne/hors ligne de l'hôte |
Les types birth et death portent le modèle d'état qui rend Sparkplug fiable. Notre guide sur les certificats birth et death Sparkplug détaille le cycle de vie complet.
edge_node_id
L'edge node ID identifie la passerelle, l'automate ou le logiciel qui détient la connexion MQTT. Il doit être unique au sein de son groupe. Deux nœuds partageant le même ID écrasent mutuellement leurs births et corrompent les numéros de séquence : c'est l'un des bugs de mise en service les plus fréquents.
device_id
Les devices se trouvent derrière un edge node : une CNC, un variateur, un compteur Modbus. Les messages de niveau device (DBIRTH, DDEATH, DDATA, DCMD) ajoutent le device ID en cinquième niveau. Les messages de niveau nœud s'arrêtent à l'edge node ID.
Le topic STATE
Le message STATE fait exception au modèle. Dans Sparkplug 3.0, il s'agit de spBv1.0/STATE/{host_id} avec un petit payload JSON, publié en retained par l'application hôte primaire Sparkplug. Les anciennes implémentations 2.2 utilisaient STATE/{host_id} sans le préfixe de namespace. Si vous exploitez des versions mixtes, vérifiez quelle forme attendent votre hôte et vos nœuds.
Des règles de nommage qui vous épargneront des soucis
La spécification interdit les caractères spéciaux MQTT +, # et / dans les ID de groupe, de nœud et de device, car ils casseraient les niveaux du topic. Au-delà, quelques conventions aident :
- N'utilisez que des minuscules, des chiffres et des tirets. La casse mixte favorise les incohérences entre systèmes.
- Gardez des ID stables. Renommer un edge node crée un nouveau nœud du point de vue de l'hôte, et l'historique peut se retrouver scindé.
- N'encodez pas dans un ID des valeurs qui changent, comme la version du firmware ou l'adresse IP.
- Placez la hiérarchie plus fine dans les noms de métriques, par exemple
Spindle/Speed, plutôt que d'essayer d'ajouter des niveaux de topic. - Documentez la signification de chaque groupe pour que les nouveaux intégrateurs placent correctement les nœuds.
- Gardez des ID courts. Ils sont répétés dans chaque topic et visibles dans chaque log.
Abonnements utiles
La structure fixe rend les abonnements à wildcards prévisibles. Voici les modèles que vous utiliserez le plus :
spBv1.0/# tout le trafic Sparkplug du broker
spBv1.0/factory1/# tout ce qui concerne un groupe
spBv1.0/+/NBIRTH/# tous les births de nœuds, tous groupes
spBv1.0/+/DDATA/+/+ tous les messages de données de devices
spBv1.0/factory1/+/line1/# tout ce qui vient d'un edge node
spBv1.0/factory1/DDATA/line1/cnc1 les données d'un seul device
spBv1.0/STATE/+ état des applications hôtes
Vous pouvez les essayer sur le serveur MQTT public gratuit. L'espace public est lisible par tous : utilisez un group ID aléatoire et n'y publiez jamais de vraies données d'usine :
mosquitto_sub -h broker.connectmq.com -p 1883 -i ns-explorer-5c21 -t "spBv1.0/demo-5c21/#" -v
Dans un second terminal, publiez un message de test sur un topic de données de device. Le payload est ici du texte brut, simplement pour vérifier le routage ; un vrai nœud envoie du Protobuf :
mosquitto_pub -h broker.connectmq.com -p 1883 -i ns-pub-5c21 -t "spBv1.0/demo-5c21/DDATA/line1/cnc1" -m "routing test"
Notez que les topics Sparkplug sur le broker public utilisent cinq niveaux, bien en deçà de sa limite de huit niveaux : un simulateur Sparkplug y fonctionne donc sans modification.
Parcourir l'espace de noms dans un explorateur de topics
Un espace de noms est bien plus facile à comprendre lorsqu'on peut le voir sous forme d'arbre. Dans ConnectMQ, l'explorateur de topics du portail affiche les topics spBv1.0 au fur et à mesure de leur arrivée, et comme le broker décode Sparkplug B, vous pouvez cliquer sur un topic DDATA et lire ses métriques plutôt que des octets bruts. Il devient alors rapide de répondre aux questions de mise en service, par exemple savoir si un nouvel edge node a publié son birth, ou quels devices se trouvent sous un nœud donné.
ConnectMQ peut aussi republier les données Sparkplug dans des topics ISA-95. Un message sur spBv1.0/factory1/DDATA/line1/cnc1 devient disponible sur connectmq/factory1/production/line1/cnc1/telemetry, ce qui convient mieux aux tableaux de bord et aux outils qui attendent une hiérarchie d'usine.
Topics Sparkplug et Unified Namespace
L'espace de noms des topics Sparkplug est plat par conception : groupe, nœud, device. Un Unified Namespace suit généralement ISA-95 : entreprise, site, zone, ligne, cellule. Ces deux vues coexistent dans de nombreuses architectures. Sparkplug assure un transport fiable et conscient de l'état depuis le terrain, tandis qu'un arbre ISA-95 offre aux humains et aux applications un modèle navigable. Pour le raisonnement de conception, lisez MQTT, Sparkplug B et le Unified Namespace, et pour le contexte plus large, consultez le guide de l'IoT industriel avec MQTT.
Dépanner les problèmes de topics
| Symptôme | Cause probable | À vérifier |
|---|---|---|
| L'hôte ne voit jamais un nœud | Faute de frappe ou mauvaise casse dans spBv1.0 |
Chaîne de namespace exacte, sensible à la casse |
| Deux nœuds font des rebirths en boucle | Edge node ID dupliqué dans un groupe | ID uniques par groupe |
| Commandes non reçues | Le nœud n'est pas abonné à ses topics NCMD/DCMD | Le nœud s'abonne à spBv1.0/group/NCMD/node et à DCMD |
| Données de device ignorées | DDATA envoyé avant le DBIRTH | Le device doit publier son DBIRTH d'abord |
| État de l'hôte absent | Hôte et nœuds en désaccord sur le format du topic STATE | Topic STATE 2.2 ou 3.0 |
Si vous soupçonnez un problème de topic, abonnez-vous à spBv1.0/your-group/# en mode verbeux et observez l'ordre des messages au démarrage. Les births doivent arriver en premier, puis les données.
Choisir où l'exécuter
Le trafic Sparkplug fonctionne sur n'importe quel broker MQTT conforme, mais une usine en production a besoin d'identifiants, de TLS et de quelqu'un responsable de la disponibilité. Un broker MQTT managé prend en charge l'infrastructure pour que votre équipe se concentre sur le nommage, la modélisation et l'intégration. Une fois que births et données circulent, l'étape suivante consiste à lire les payloads eux-mêmes, ce que couvre notre guide du payload Sparkplug B.
Démarrer avec ConnectMQ
Créez un broker Serverless gratuit sur app.connectmq.com, sans carte bancaire. Connectez votre edge node avec les identifiants générés via TLS sur le port 8883, et parcourez l'espace de noms de vos topics Sparkplug, décodé et organisé, dans l'explorateur de topics de ConnectMQ.
Questions fréquentes
Puis-je ajouter des niveaux à un topic Sparkplug ?
Non. L'espace de noms des topics Sparkplug est fixé à quatre niveaux pour les messages de nœud et cinq pour les messages de device. Placez la hiérarchie supplémentaire dans les noms de métriques ou projetez les données dans un arbre ISA-95.
Le group ID correspond-il à un site ?
C'est possible, mais la spécification le définit seulement comme un regroupement logique d'edge nodes. Beaucoup d'équipes utilisent un groupe par site ou par zone, selon le périmètre des applications hôtes.
Pourquoi le topic STATE est-il différent ?
Les messages STATE proviennent des applications hôtes, pas des edge nodes, et ne suivent donc pas le modèle nœud/device. Dans Sparkplug 3.0, le topic est spBv1.0/STATE/{host_id}.
Les topics Sparkplug sont-ils sensibles à la casse ?
Oui. Les topics MQTT sont sensibles à la casse : spBv1.0 et SPBV1.0 sont deux topics différents, tout comme Line1 et line1.
