Sparkplug 3.0 est la première version de la spécification Sparkplug publiée sous l'égide du Sparkplug Working Group de la Fondation Eclipse, et elle clarifie surtout des comportements que la 2.2 laissait ouverts à l'interprétation. Dans ce comparatif, vous verrez précisément ce qui a changé entre la 2.2 et la 3.0, quels changements peuvent casser l'interopérabilité dans un parc mixte, et comment planifier la migration des edge nodes et des applications hôtes sans mauvaise surprise.
En bref
Sparkplug 3.0 n'a pas réinventé le protocole. L'espace de noms des topics est toujours spBv1.0, le payload Protobuf reste le schéma Sparkplug B, et les certificats birth et death fonctionnent toujours de la même manière. Ce qui a changé, c'est la précision. La version 2.2 décrivait les comportements dans une prose que les différents éditeurs interprétaient différemment. La version 3.0 a réécrit le document sous forme de spécification formelle avec des énoncés normatifs numérotés, et l'a adossée à un Technology Compatibility Kit (TCK) qui teste les implémentations au regard de ces énoncés.
Le seul changement visible sur le réseau pour presque tout le monde est le message STATE de l'application hôte. La plupart des autres changements concernent des cas limites : reconnexions, wills tardifs, gestion des sessions et encodage des types de données.
Sparkplug 3.0 vs 2.2 en un coup d'œil
| Domaine | Sparkplug 2.2 | Sparkplug 3.0 |
|---|---|---|
| Style du document | Prose descriptive | Énoncés normatifs, testables |
| Conformité | Pas de suite de tests officielle | TCK avec profils de conformité |
| Espace de noms des topics | spBv1.0/... |
Inchangé |
| Schéma du payload | Sparkplug B Protobuf | Inchangé, règles d'encodage clarifiées |
| Topic STATE | STATE/{host_id} |
spBv1.0/STATE/{host_id} |
| Payload STATE | Chaîne ONLINE / OFFLINE |
JSON {"online": true, "timestamp": ...} |
| bdSeq | Décrit de façon approximative | Doit correspondre entre NBIRTH et NDEATH, règles d'incrémentation |
| QoS du will NDEATH | Spécifiée de façon incohérente | QoS 1, non retained |
| Session MQTT | Implicite | Edge nodes et hôtes utilisent des clean sessions |
| Terminologie | Hôte SCADA/IIoT, application primaire | Host Application, Primary Host Application |
| Types tableaux | Listés, encodage flou | Encodage défini |
Les changements les plus importants
Le nouveau topic STATE et son payload
En 2.2, un hôte primaire publiait une chaîne retained ONLINE sur STATE/{host_id} et enregistrait OFFLINE comme will. Ce topic se trouvait en dehors de l'espace de noms spBv1.0, ce qui compliquait les permissions, et une simple chaîne ne permettait pas de distinguer un ancien message d'un nouveau.
En 3.0, le topic passe à spBv1.0/STATE/{host_id} et le payload devient du JSON :
{ "online": true, "timestamp": 1792137600000 }
L'hôte le publie en retained avec la QoS 1 après sa connexion, et enregistre un will avec "online": false et le même horodatage que celui utilisé dans le birth. Les edge nodes comparent les horodatages et ignorent un message STATE plus ancien que celui qu'ils ont déjà vu. Cela élimine une situation de concurrence où un will OFFLINE retardé, issu d'une session précédente de l'hôte, pouvait déconnecter tous les edge nodes alors que l'hôte était déjà revenu. Le flux complet est détaillé dans notre article sur l'application hôte primaire Sparkplug.
C'est un changement incompatible. Un edge node 2.2 qui surveille STATE/scada1 ne verra jamais un hôte 3.0, et un nœud 3.0 qui attend spBv1.0/STATE/scada1 attendra indéfiniment derrière un hôte 2.2. Certains produits prennent en charge les deux formes pendant une transition ; vérifiez les vôtres avant de mettre quoi que ce soit à niveau.
Les règles du bdSeq
La métrique bdSeq relie un NBIRTH au NDEATH enregistré pour la même session MQTT. La version 3.0 rend les règles explicites : le will NDEATH doit contenir un bdSeq, le NBIRTH qui suit doit porter la même valeur, et cette valeur change à chaque nouvelle connexion. Les hôtes s'appuient sur cette correspondance pour écarter un certificat de death appartenant à une session plus ancienne. Si vous avez écrit votre propre edge node d'après la 2.2, c'est la première chose à vérifier. Notre guide sur les certificats birth et death Sparkplug présente une implémentation fonctionnelle.
Comportement des sessions et de la QoS
La version 3.0 impose une clean session aux edge nodes et aux applications hôtes (clean session à true en MQTT 3.1.1, ou clean start avec une expiration de session à zéro en MQTT 5). Sinon, des messages en file d'attente d'une ancienne session pourraient arriver après un nouveau birth et perturber le modèle d'état. Le will NDEATH utilise la QoS 1 et n'est pas retained ; les births et les données ne le sont pas non plus. Seul le message STATE de l'hôte est retained.
Types de données et alias clarifiés
Le type de données doit être présent pour chaque métrique dans les messages de birth. Les alias doivent être uniques par edge node. Les types tableaux comme Int32Array ou BooleanArray ont un encodage binaire défini : des éditeurs qui revendiquent tous deux la prise en charge des tableaux peuvent donc réellement en échanger. La référence des types de données Sparkplug B liste tous les codes.
Profils de conformité
Le TCK définit des profils pour un Edge Node, une Host Application, un MQTT Server et un Sparkplug Aware MQTT Server optionnel. N'importe quel broker MQTT 3.1.1 prenant en charge les QoS 0 et 1, les retained messages et les wills peut transporter du trafic Sparkplug. Le profil « aware » ajoute des fonctionnalités optionnelles côté broker définies dans la spécification. Lorsqu'un éditeur se dit compatible Sparkplug 3.0, demandez-lui quel profil et s'il a passé le TCK.
Ce que Sparkplug 3.0 implique pour votre broker
Comme le payload est opaque pour le routage, le rôle du broker change à peine. Il lui faut une gestion fiable du last will, des retained messages pour STATE, la QoS 1 et une capacité de connexion suffisante pour chaque nœud et chaque hôte. Un broker MQTT managé comme ConnectMQ prend en charge MQTT 3.1.1 et 5.0 sur les mêmes endpoints : des nœuds 2.2 et 3.0 peuvent donc se connecter côte à côte pendant la migration. ConnectMQ décode aussi les payloads Sparkplug B et les affiche dans l'explorateur de topics du portail, ce qui permet de vérifier facilement pendant une migration que les births portent bien les types de données, que les valeurs bdSeq correspondent et que le nouveau topic STATE est retained avec le JSON attendu.
Avant de toucher à la production, vous pouvez faire une répétition sur le serveur MQTT public gratuit avec un group ID aléatoire. Par exemple, publiez puis lisez un message STATE 3.0 :
mosquitto_pub -h broker.connectmq.com -p 1883 -i host-test-4e1b -r -q 1 \
-t "spBv1.0/STATE/demo-host-4e1b" -m '{"online": true, "timestamp": 1792137600000}'
mosquitto_sub -h broker.connectmq.com -p 1883 -i host-watch-4e1b -t "spBv1.0/STATE/demo-host-4e1b" -v
Effacez ensuite le retained message en publiant un payload retained vide sur le même topic, puisque l'espace public est partagé.
Checklist de migration de la 2.2 vers la 3.0
- Inventoriez chaque edge node et chaque hôte, et notez la version de Sparkplug que chacun prend en charge.
- Choisissez la stratégie pour le topic STATE : mettre à niveau hôtes et nœuds ensemble, ou utiliser des produits qui gèrent les deux formes pendant la transition.
- Vérifiez que chaque edge node enregistre un will NDEATH avec bdSeq avant de se connecter et reprend ce bdSeq dans le NBIRTH.
- Confirmez les paramètres de clean session sur les nœuds et les hôtes.
- Vérifiez que les messages de birth incluent un type de données pour chaque métrique et que les alias sont uniques par nœud.
- Testez les métriques tableaux et templates entre éditeurs si vous les utilisez.
- Faites tourner le nouvel hôte en parallèle sur un groupe de test, en surveillant les births décodés et STATE dans un explorateur de topics.
- Basculez un groupe à la fois et gardez un plan de retour arrière pour l'hôte.
Faut-il migrer ?
Pour les nouveaux projets, partez sur la 3.0. Les outils basés sur les versions actuelles d'Eclipse Tahu la suivent, et le TCK vous donne un moyen d'exiger des éditeurs qu'ils respectent la spécification. Pour les usines existantes en 2.2 qui fonctionnent, migrez lorsque vous remplacez ou ajoutez des applications hôtes, car le changement de STATE impose une coordination. Les edge nodes qui gèrent déjà correctement le bdSeq n'ont souvent besoin que d'une mise à jour de firmware ou de configuration. Pour le contexte architectural plus large, lisez le guide de l'IoT industriel avec MQTT. Le texte officiel se trouve sur le site Eclipse Sparkplug.
Démarrer avec ConnectMQ
Créez un broker Serverless gratuit sur app.connectmq.com, sans carte bancaire. Connectez vos edge nodes et votre hôte Sparkplug 3.0 via TLS sur le port 8883, et vérifiez les births, deaths et messages STATE décodés dans le portail ConnectMQ avant de migrer la production.
Questions fréquentes
Sparkplug 3.0 est-il rétrocompatible avec la 2.2 ?
Le payload et l'espace de noms des topics spBv1.0 sont compatibles. Le topic et le payload STATE de l'hôte ont changé : des nœuds 2.2 et des hôtes 3.0 (ou l'inverse) ne reconnaîtront pas l'état de l'hôte sans un mode de compatibilité.
Sparkplug 3.0 exige-t-il MQTT 5 ?
Non. Sparkplug fonctionne sur MQTT 3.1.1, et les brokers MQTT 5 peuvent le transporter avec des paramètres de session équivalents. Un broker qui prend en charge les deux versions vous permet de migrer progressivement.
Le topic est-il toujours spBv1.0 dans Sparkplug 3.0 ?
Oui. L'espace de noms identifie le format de payload Sparkplug B, qui n'a pas changé : les topics restent donc spBv1.0/.... Seul STATE a été intégré à cet espace de noms.
Qu'est-ce que le TCK Sparkplug ?
Le Technology Compatibility Kit est une suite de tests du projet Eclipse Sparkplug qui vérifie les implémentations au regard des énoncés normatifs de la spécification 3.0, par profil, par exemple edge node ou application hôte.
