Sparkplug B vs JSON sur MQTT : quel payload choisir ?

Sparkplug B vs JSON : c'est l'une des premières décisions de conception de tout projet MQTT industriel, et la réponse est rarement « l'un ou l'autre pour toujours ». Dans ce comparatif, vous verrez en quoi les deux approches diffèrent en matière d'interopérabilité, de gestion d'état, de bande passante et d'outillage, quand chacune convient, et comment les combiner pour que les machines parlent Sparkplug pendant que les humains et les tableaux de bord lisent du JSON.

Deux philosophies différentes

MQTT lui-même ne se soucie pas du contenu d'un message. C'est à la fois sa force et la raison d'être de ce débat.

Le JSON classique sur MQTT signifie que vous concevez vos propres topics et payloads. Un capteur de température peut publier {"temp": 21.4, "unit": "C", "ts": 1792137600} sur plant1/hall2/sensor7/telemetry. Tout le monde peut le lire, tous les langages savent l'analyser, et vous pouvez démarrer en cinq minutes.

Sparkplug B est une spécification qui s'appuie sur MQTT. Elle fixe la structure des topics (spBv1.0/group/type/node/device), encode les payloads en Protobuf et ajoute un modèle d'état avec certificats birth et death, numéros de séquence et commandes. Vous renoncez à une part de liberté et gagnez l'interopérabilité avec n'importe quel SCADA ou application hôte compatible Sparkplug.

Voici la même mesure en JSON :

{
  "timestamp": 1792137600123,
  "spindleSpeed": 1462.3,
  "spindleRunning": true
}

En Sparkplug B, le payload DDATA équivalent est du Protobuf binaire. Une fois décodé, il ressemble à ceci, mais sur le réseau ce sont des octets compacts, avec des alias à la place des noms :

{
  "timestamp": 1792137600123,
  "seq": 17,
  "metrics": [
    { "alias": 3, "datatype": 10, "doubleValue": 1462.3 },
    { "alias": 4, "datatype": 11, "booleanValue": true }
  ]
}

Sparkplug B vs JSON côte à côte

Là où Sparkplug B l'emporte

Interopérabilité

Le principal argument en faveur de Sparkplug est qu'une passerelle d'un éditeur et un SCADA d'un autre peuvent fonctionner ensemble sans projet de mapping. L'hôte lit les births, découvre chaque métrique avec son type de données et commence à afficher les données. Avec JSON, chaque nouvelle source de données exige que quelqu'un s'accorde sur les noms de champs, les unités et les horodatages.

Gestion d'état

Sparkplug vous indique non seulement la dernière valeur, mais aussi si elle est toujours valide. Lorsqu'une passerelle perd son alimentation, le broker publie son NDEATH et chaque hôte marque les tags associés comme périmés. Avec JSON, vous pouvez vous en approcher grâce à un last will sur un topic de statut, mais il vous faut aussi des valeurs retained, une convention pour le statut au niveau des devices et de la logique dans chaque consommateur.

Bande passante

Le Protobuf avec alias de métriques est nettement plus compact qu'un JSON qui répète les noms de champs dans chaque message. Associé au report by exception, où seules les valeurs modifiées sont envoyées, Sparkplug convient bien aux liaisons cellulaires et satellites. Pour une poignée de capteurs sur l'Ethernet de l'usine, la différence compte rarement.

Là où JSON l'emporte

Simplicité et lisibilité

Vous pouvez déboguer du JSON avec mosquitto_sub et vos yeux. Les développeurs web, les data engineers et les équipes IT le connaissent déjà. Les outils low-code comme Node-RED le gèrent nativement.

Flexibilité

JSON vous permet de modéliser les topics selon la hiérarchie de votre usine, par exemple un arbre ISA-95, ce qui est la façon dont de nombreuses équipes structurent un Unified Namespace. L'espace de noms fixe de Sparkplug s'arrête au groupe, au nœud et au device.

Consommateurs non industriels

Applications mobiles, tableaux de bord web, fonctions cloud et notebooks d'analyse attendent généralement du JSON. Leur fournir du Sparkplug signifie que chacun d'eux a besoin du fichier proto et de la gestion des alias.

Essayer les deux sur un broker de test

Vous pouvez comparer vous-même la lisibilité sur le serveur MQTT public gratuit, réservé aux tests. Publiez du JSON :

mosquitto_pub -h broker.connectmq.com -p 1883 -i json-test-a81c \
  -t "connectmq/demo/a81c/line1/cnc1/telemetry" \
  -m '{"timestamp": 1792137600123, "spindleSpeed": 1462.3, "spindleRunning": true}'

Lancez ensuite un simulateur Sparkplug, comme celui de notre guide sur les certificats birth et death Sparkplug, et abonnez-vous aux deux en mode verbeux. Le JSON s'affiche proprement ; les messages Sparkplug apparaissent sous forme de texte partiellement binaire tant que vous ne les décodez pas. L'espace public est lisible par tous : utilisez des ID aléatoires et aucune donnée réelle.

Le modèle hybride : Sparkplug sur le terrain, JSON pour les consommateurs

Beaucoup d'usines finissent par utiliser les deux. Les edge nodes et le SCADA parlent Sparkplug B pour un transport fiable et conscient de l'état, et une couche de traduction publie du JSON lisible dans un arbre de topics ISA-95 pour les tableaux de bord, l'analyse et les systèmes IT.

Vous pouvez construire cette couche de traduction vous-même : un service Python qui s'abonne à spBv1.0/#, décode le Protobuf, résout les alias et republie du JSON. Notre tutoriel pour décoder Sparkplug B en Python constitue un solide point de départ.

Vous pouvez aussi laisser le broker s'en charger. ConnectMQ décode Sparkplug B et peut le republier dans des topics ISA-95 : spBv1.0/factory1/DDATA/line1/cnc1 apparaît ainsi sous connectmq/factory1/production/line1/cnc1/telemetry. Tableaux de bord, flows Node-RED et agents Telegraf s'abonnent aux topics lisibles comme des clients MQTT ordinaires, tandis que vos hôtes Sparkplug continuent d'utiliser l'espace de noms d'origine. Le portail affiche aussi la vue Sparkplug décodée dans son explorateur de topics, pour que les ingénieurs voient des noms de métriques au lieu d'octets.

Checklist de décision

1. Disposez-vous, ou prévoyez-vous d'acheter, un SCADA ou une application hôte compatible Sparkplug ? Si oui, penchez pour Sparkplug.
2. Les opérateurs doivent-ils savoir quand les valeurs sont périmées ? Sparkplug vous l'offre sans code sur mesure.
3. Les liaisons sont-elles facturées au volume ou à faible débit ? Sparkplug avec alias et report by exception aide.
4. L'équipe est-elle surtout composée de développeurs web et IT, avec quelques capteurs ? JSON vous fera avancer plus vite.
5. Voulez-vous des topics organisés selon les niveaux ISA-95 ? JSON s'y prête naturellement, ou utilisez le modèle hybride.
6. De nombreuses applications non industrielles vont-elles consommer les données ? Fournissez du JSON, nativement ou par traduction.
7. Mélangez-vous des éditeurs sur le terrain ? Sparkplug réduit le travail de mapping.

Si vous avez répondu oui à des points des deux côtés, l'approche hybride est généralement la bonne.

Le broker reste le même dans les deux cas

Les deux payloads fonctionnent sur n'importe quel broker MQTT conforme aux standards : cette décision ne vous enferme donc pas dans une infrastructure. Ce qui change, c'est le niveau de visibilité. Un broker MQTT managé qui comprend Sparkplug et les topics ISA-95 rend le côté binaire aussi accessible que le côté JSON. Pour l'architecture d'ensemble, lisez MQTT, Sparkplug B et le Unified Namespace ainsi que le guide de l'IoT industriel avec MQTT.

Démarrer avec ConnectMQ

Créez un broker Serverless gratuit sur app.connectmq.com, sans carte bancaire. Publiez du JSON et du Sparkplug B côte à côte, et voyez les deux de façon lisible dans l'explorateur de topics de ConnectMQ, avec les données Sparkplug republiées dans des topics ISA-95.

Questions fréquentes

Sparkplug B est-il toujours meilleur que JSON pour l'IoT industriel ?

Non. Sparkplug B est meilleur pour l'interopérabilité avec les SCADA et pour la gestion d'état intégrée. JSON est plus simple et plus flexible, et c'est souvent le meilleur choix pour les petits projets ou les consommateurs côté IT.

Sparkplug peut-il utiliser JSON au lieu de Protobuf ?

La spécification Sparkplug B définit l'encodage Protobuf. Certains outils proposent une représentation JSON pour le débogage ou les passerelles, et ConnectMQ sait décoder les deux formes.

Puis-je mélanger Sparkplug B et JSON sur le même broker ?

Oui. Ils utilisent des topics différents et coexistent donc sans conflit. Beaucoup d'usines font circuler Sparkplug sous spBv1.0 et JSON sous un arbre ISA-95 sur le même broker.

Le JSON sur MQTT gère-t-il l'état en ligne des devices ?

Pas par lui-même. Vous pouvez l'implémenter avec un message last will retained sur un topic de statut, mais il vous faut définir et faire respecter la convention vous-même.