Sparkplug B et le Unified Namespace sont les deux notions qui reviennent dans presque tous les projets d'IoT industriel basés sur MQTT. Dans cet article, vous verrez ce qu'est un Unified Namespace, comment la hiérarchie ISA-95 se traduit en structure de topics, comment fonctionnent le namespace de topics et le payload de Sparkplug B, et en quoi les deux approches se complètent. Au passage, vous publierez de vrais messages ISA-95 et Sparkplug B sur broker.connectmq.com.
Si les bases de MQTT sont nouvelles pour vous, lisez d'abord ce qu'est un broker MQTT.
Le problème : le plat de spaghettis point à point
Une usine typique compte des automates, un SCADA, un MES, un historian, un système qualité et un ERP. Traditionnellement, chaque système dialogue avec les autres par sa propre connexion point à point. Ajoutez un nouveau tableau de bord et il vous faut trois nouvelles intégrations. Modifiez une variable d'automate et quelque chose casse en aval.
MQTT règle la question du transport : chaque producteur publie vers un broker, chaque consommateur s'abonne. Ce que MQTT ne décide pas pour vous, c'est la façon de nommer les topics et de formater les payloads. C'est précisément le vide que comblent le Unified Namespace et Sparkplug B.
Qu'est-ce qu'un Unified Namespace ?
Un Unified Namespace (UNS) est une vue unique, événementielle et hiérarchique de l'état courant de toute l'entreprise. Au lieu d'interroger chaque système pour obtenir des données, chaque système publie ce qu'il sait dans une même arborescence de topics partagée sur le broker, et chaque consommateur s'abonne à la partie dont il a besoin. C'est aussi une base naturelle pour alimenter un jumeau numérique de l'usine.
Trois propriétés définissent un bon UNS :
- Une source unique de vérité. La dernière valeur de chaque machine, ligne et commande se trouve au même endroit.
- Une structure calquée sur l'entreprise. Les topics suivent la hiérarchie physique et organisationnelle, ce qui permet de trouver les données sans liste de variables.
- Un reporting par exception. Les producteurs publient lorsque quelque chose change, et les retained messages fournissent immédiatement l'état courant aux nouveaux abonnés.
ISA-95 comme structure de topics
La façon la plus courante de structurer un UNS est la hiérarchie d'équipements ISA-95. Chaque niveau devient un niveau de topic :
Enterprise / Site / Area / Line / WorkCell / <data class>
acme / izmir / machining / line1 / cnc1 / telemetry
Tableau de conception des topics
| Niveau ISA-95 | Exemple de valeur | Niveau de topic | Conseil de conception |
|---|---|---|---|
| Enterprise (entreprise) | acme | 1 | Identifiant d'entreprise court et fixe |
| Site | izmir | 2 | Un par usine ou par implantation |
| Area (zone) | machining | 3 | Service ou zone de production |
| Line (ligne) | line1 | 4 | Ligne de production ou cellule de process |
| WorkCell (cellule) | cnc1 | 5 | Machine, robot ou poste |
| Classe de données | telemetry, state, alarms, cmd | 6 | Sépare les données rapides des événements et des commandes |
Quelques règles pratiques :
- Utilisez de l'ASCII en minuscules, sans espaces, et des identifiants stables plutôt que des noms d'affichage.
- Gardez une profondeur prévisible. Les consommateurs s'appuient sur des wildcards comme
acme/izmir/+/+/+/alarmspour récupérer toutes les alarmes d'un site. - Placez les commandes sur leur propre branche (
cmd) pour pouvoir les sécuriser et les auditer séparément de la télémétrie. - Publiez les messages d'état en retained pour qu'un nouveau tableau de bord voie immédiatement la valeur courante.
Essayez : publier un message JSON ISA-95
La zone publique du serveur MQTT public gratuit broker.connectmq.com, réservé aux tests et aux prototypes, autorise jusqu'à 8 niveaux de topic : utilisez donc un préfixe aléatoire court plutôt qu'un préfixe long. Abonnez-vous dans un terminal :
mosquitto_sub -h broker.connectmq.com -p 1883 -i uns-a1b2-sub \
-t "a1b2/acme/#" -v
Publiez une mesure machine depuis un autre terminal :
mosquitto_pub -h broker.connectmq.com -p 1883 -i uns-a1b2-cnc1 -q 1 \
-t "a1b2/acme/izmir/machining/line1/cnc1/telemetry" \
-m '{"spindleSpeed":12000,"temperature":41.7,"status":"RUNNING"}'
L'abonné affiche le topic et le payload JSON. Tout ce qui se trouve dans la zone publique est lisible par n'importe qui : n'y publiez jamais de vraies données de production.
Qu'est-ce que Sparkplug B ?
Sparkplug B est une spécification ouverte, maintenue par la fondation Eclipse, qui définit trois éléments que MQTT laisse ouverts : un namespace de topics fixe, un format de payload binaire et un modèle de gestion d'état. Elle a été conçue pour que les SCADA et les applications hôtes puissent découvrir automatiquement les appareils et sachent toujours si les données sont à jour ou obsolètes.
Le namespace de topics Sparkplug B
Chaque topic Sparkplug B suit ce modèle :
spBv1.0/{group_id}/{message_type}/{edge_node_id}/{device_id}
group_id regroupe des edge nodes (par exemple une usine), edge_node_id désigne la passerelle ou l'équipement edge, et le device_id facultatif désigne un automate ou un capteur situé derrière cet edge node.
| Type de message | Envoyé par | Rôle |
|---|---|---|
| NBIRTH | Edge node | Le nœud passe en ligne et déclare toutes ses métriques |
| NDEATH | Broker (en tant que Will) | Le nœud s'est déconnecté de manière inattendue |
| DBIRTH | Edge node | Un appareil derrière le nœud passe en ligne avec ses métriques |
| DDEATH | Edge node | Un appareil s'est déconnecté |
| NDATA / DDATA | Edge node | Valeurs de métriques modifiées pour le nœud ou l'appareil |
| NCMD / DCMD | Application hôte | Commandes d'écriture vers un nœud ou un appareil |
| STATE | Application hôte | Annonce si l'hôte principal est en ligne |
Le message NDEATH est enregistré comme Last Will MQTT lorsque l'edge node se connecte : le broker le publie donc automatiquement si la connexion tombe. Les consommateurs marquent alors toutes les données de ce nœud comme obsolètes.
Payload : Protobuf, alias et numéros de séquence
Les payloads Sparkplug B sont encodés avec Google Protocol Buffers. Un payload contient un horodatage, un numéro de séquence et une liste de métriques ; chaque métrique possède un nom, un alias numérique facultatif, un type de données, un horodatage et une valeur.
Mécanismes clés :
- Certificats de naissance. NBIRTH et DBIRTH contiennent chaque métrique avec son nom complet et son type de données. Les messages DDATA suivants peuvent n'envoyer que l'alias numérique et la nouvelle valeur, ce qui garde des paquets compacts.
- Numéros de séquence. Chaque message d'un edge node porte une valeur
seqde 0 à 255 qui reboucle. Si un hôte constate un trou, il sait qu'un message a été perdu et peut envoyer une commande de rebirth (NCMD) pour demander de nouveaux certificats de naissance. - bdSeq. Un numéro de séquence naissance/mort relie chaque NDEATH au NBIRTH de la même session, de sorte qu'un ancien certificat de décès ne puisse pas effacer une session plus récente.
Voici la même mesure que ci-dessus, présentée sous la forme de la représentation JSON d'un payload DDATA Sparkplug B :
{
"timestamp": 1760600000000,
"seq": 1,
"metrics": [
{ "name": "temperature", "timestamp": 1760600000000, "dataType": "Double", "value": 41.7 }
]
}
Sparkplug B et Unified Namespace : complémentaires, pas concurrents
| Aspect | Sparkplug B | Unified Namespace ISA-95 |
|---|---|---|
| Structure des topics | Fixe : spBv1.0/group/type/node/device |
Libre, calquée sur la hiérarchie de l'entreprise |
| Payload | Protobuf avec métriques typées | Généralement JSON, défini par vous |
| Connaissance de l'état | Intégrée (birth, death, STATE) | Par convention, généralement via des retained messages |
| Lisibilité | Nécessite un décodeur | Topics et payloads lisibles par un humain |
| Idéal pour | Liaison edge-SCADA, découverte des appareils, état fiable | Accès à l'échelle de l'entreprise, analytique, consommateurs IT |
En pratique, de nombreuses usines utilisent les deux. Les edge nodes parlent Sparkplug B, car il apporte un état fiable et des payloads efficaces au plus près des machines. Les données sont ensuite republiées dans un namespace structuré selon ISA-95, en JSON lisible, où le MES, les tableaux de bord et les applications IT les consomment sans jamais toucher au Protobuf. La partie difficile, c'est cette couche de traduction, et c'est là que le broker peut vous aider.
Comment ConnectMQ gère Sparkplug B et les topics ISA-95
ConnectMQ est un broker MQTT managé qui intègre la prise en charge de l'IoT industriel :
- Détection ISA-95. Il reconnaît les structures de topics ISA-95 et Unified Namespace dans votre trafic.
- Décodage Sparkplug B. Il détecte les messages Sparkplug B et décode aussi bien les payloads Protobuf que JSON.
- Republication vers ISA-95. Les données Sparkplug B peuvent être republiées dans une structure ISA-95 ; par exemple,
spBv1.0/factory1/DDATA/line1/cnc1devientconnectmq/factory1/production/line1/cnc1/telemetry, avec un payload JSON à plat que n'importe quel abonné peut lire. - Vues du portail. La vue Appareils du portail organise vos équipements selon les niveaux ISA-95, et des règles d'alerte à seuil accompagnées d'un journal des alertes vous permettent de réagir lorsque, par exemple, la température d'une broche dépasse une limite.
Essayez : du Sparkplug B en entrée, de la télémétrie lisible en sortie
Utilisez un group ID unique comme a1b2plant. Abonnez-vous d'abord à la fois au topic Sparkplug et à la branche republiée :
mosquitto_sub -h broker.connectmq.com -p 1883 -i spb-a1b2-sub -v \
-t "spBv1.0/a1b2plant/#" -t "connectmq/a1b2plant/#"
Publiez ensuite un message DDATA avec un payload Sparkplug B en JSON :
mosquitto_pub -h broker.connectmq.com -p 1883 -i spb-a1b2-edge -q 1 \
-t "spBv1.0/a1b2plant/DDATA/line1/cnc1" \
-m '{"timestamp":1760600000000,"seq":1,"metrics":[{"name":"temperature","timestamp":1760600000000,"dataType":"Double","value":41.7}]}'
Lorsque nous l'avons testé sur broker.connectmq.com, l'abonné a reçu le message Sparkplug B d'origine ainsi qu'un second message sous connectmq/a1b2plant/.../line1/cnc1/telemetry avec le payload {"temperature":41.7,"timestamp":1760600000000}. Les outils en aval peuvent désormais s'abonner à connectmq/a1b2plant/+/+/+/telemetry et obtenir un JSON propre par machine.
En production, créez un broker dédié dans le portail et connectez-vous avec YOUR_USERNAME, YOUR_PASSWORD et YOUR_CLIENT_ID en TLS sur le port 8883. Les topics de chaque tenant sont isolés des autres tenants et de la zone publique. Consultez Sécurité MQTT : les bonnes pratiques pour les recommandations sur les identifiants et le TLS.
Checklist de conception pour votre premier UNS
- Mettez-vous d'accord sur les niveaux ISA-95 et les règles de nommage avant la connexion du premier appareil.
- Déterminez les classes de données dont vous avez besoin (
telemetry,state,alarms,cmd) et gardez-les cohérentes. - Utilisez Sparkplug B en périphérie (edge) là où vous avez besoin de la gestion naissance/mort, et une branche ISA-95 lisible pour tous les autres.
- Utilisez la QoS 1 pour les états et les alarmes ; consultez Les niveaux de QoS MQTT expliqués pour les compromis.
- Utilisez des retained messages pour l'état courant, et gardez des payloads compacts et typés.
- Choisissez un broker capable de grandir avec vous ; comment choisir un broker MQTT pour l'IoT détaille les critères.
Démarrer avec ConnectMQ
Vous pouvez essayer dès maintenant les deux exemples ci-dessus sur le serveur MQTT public gratuit. Pour construire un vrai Unified Namespace avec des topics isolés, des vues d'appareils ISA-95 et des alertes à seuil, inscrivez-vous sur app.connectmq.com. L'offre Serverless est gratuite, ne demande pas de carte bancaire, et vous pourrez passer à Dedicated, BYOC ou Self Managed Enterprise lors de la mise en service de votre usine.
Questions fréquentes
Sparkplug B est-il la même chose qu'un Unified Namespace ?
Non. Sparkplug B est une spécification qui définit les topics, les payloads et l'état des sessions sur MQTT, tandis qu'un Unified Namespace est un modèle d'architecture qui organise toutes les données de l'entreprise dans une seule hiérarchie. Les deux fonctionnent très bien ensemble.
Puis-je lire des messages Sparkplug B sans décodeur Protobuf ?
Pas directement, car le payload est binaire. ConnectMQ décode les payloads Sparkplug B Protobuf et JSON et peut les republier en JSON lisible dans une structure de topics ISA-95.
Quelle profondeur donner à une hiérarchie de topics ISA-95 ?
Enterprise, Site, Area, Line et WorkCell, plus une classe de données, donnent six niveaux, ce qui convient à la plupart des usines. Gardez une profondeur cohérente pour que les abonnements avec wildcards fonctionnent de manière prévisible.
Sparkplug B nécessite-t-il MQTT 5 ?
Non. Sparkplug B fonctionne sur MQTT 3.1.1 et est couramment déployé ainsi. ConnectMQ prend en charge MQTT 3.1.1 et MQTT 5.0 : les edge nodes Sparkplug et les clients plus récents peuvent donc partager le même broker.



