Sparkplug B est une spécification ouverte qui repose sur MQTT et définit exactement comment les équipements industriels s'annoncent, décrivent leurs données et signalent quand ils se déconnectent, transformant un canal de messages générique en une norme de télémétrie autodécrite et à gestion d'état.
Le MQTT "nu" est un transport léger de type publication/abonnement: il déplace des octets d'un éditeur vers n'importe quel abonné, mais il ne dit rien sur la signification de ces octets, sur les unités qu'ils portent, ni même si l'expéditeur est toujours en ligne. Sparkplug B comble cette lacune.
Créé sous l'égide de l'Eclipse Foundation et désormais maintenu comme norme ouverte, il définit pour chaque balise un type de données, une structure de topic connue et un cycle de vie afin que tout consommateur, d'un tableau de bord OEE à un historien, puisse interpréter une charge utile sans carte d'intégration faite à la main.
MQTT a été conçu pour des réseaux contraints et peu fiables, ce qui explique précisément pourquoi il prospère en production. Mais livré tel quel, il laisse trois problèmes difficiles non résolus.
Primo, les espaces de noms des topics sont un far west: un intégrateur publie sur plant1/line3/oven/temp , un autre sur Oven_Temp_C , et rien n'impose de cohérence.
Secundo, les payloads sont opaques; une valeur "72" peut être des degrés Celsius, Fahrenheit ou un code d'erreur, et l'abonné n'a aucun moyen de le savoir. Tertio, MQTT n'a pas de concept intégré de fraîcheur.
Si une passerelle perd l'alimentation, sa dernière valeur publiée reste sur le broker, et un tableau de bord continue d'afficher une lecture obsolète comme si la machine fonctionnait correctement.
Sur un plancher d'usine, ces lacunes ne sont pas académiques. Des données obsolètes ou mal étiquetées corrompent les calculs de disponibilité et de performance, c'est pourquoi les équipes soucieuses de l'efficacité globale des équipements ne peuvent pas se fier au MQTT brut. Sparkplug B a été écrit spécifiquement pour colmater ces brèches pour les technologies opérationnelles.
La caractéristique signature de Sparkplug B est le cycle de vie des certificats. Lorsqu'un nœud edge ou un appareil se connecte, il publie un certificat de naissance (un NBIRTH pour un nœud, un DBIRTH pour un appareil). Ce message n'est pas qu'un simple bonjour.
Il contient la liste complète de chaque métrique que l'appareil publiera un jour, chacune avec son nom, son type de données et sa valeur initiale. Un abonné qui reçoit le certificat de naissance connaît immédiatement tout le schéma, sans fichier de configuration externe requis.
Le certificat de décès en est l'image miroir. Chaque client Sparkplug enregistre une Dernière Volonté et Testament auprès du broker au moment de la connexion. Si l'appareil disparaît du réseau de manière non contrôlée, le broker publie lui-même le NDEATH préenregistré au nom de l'appareil.
Les consommateurs apprennent instantanément que la source est hors ligne et peuvent marquer ses données comme obsolètes plutôt que de faire confiance à une dernière valeur figée.
C'est une véritable prise en compte de l'état: le système sait faire la différence entre « la valeur est légitimement stable » et « l'émetteur a disparu ».
Pour quiconque calcule des indicateurs de fiabilité comme le MTBF et le MTTR , distinguer un arrêt réel d'une perte de communication fait la différence entre un chiffre digne de confiance et un chiffre fictif.
Les payloads Sparkplug B sont encodés avec Google Protocol Buffers, un format binaire compact. Chaque payload transporte un horodatage, un numéro de séquence et un tableau de métriques. Une métrique est un objet nommé et typé, ainsi une mesure de température circule en tant qu'unité structurée avec un type explicite Int, Float ou Boolean plutôt qu'une chaîne ambiguë.
L'espace de noms des topics est tout aussi cadré. Chaque topic Sparkplug suit le schéma fixe spBv1.0/group_id/message_type/edge_node_id/device_id . Parce que la structure est standardisée, tout outil peut s'abonner avec un seul wildcard et découvrir automatiquement chaque groupe, nœud et appareil sur le réseau.
Ce modèle de rapport par exception est également important: après le certificat de naissance, les appareils publient seulement les valeurs qui ont changé (messages NDATA et DDATA), ce qui réduit fortement la bande passante sur les liaisons contraintes courantes en usine.
Le caractère autodécrit fait que la fondation de données reste suffisamment propre pour alimenter l'analyse en aval, des graphiques de contrôle statistique de procédé aux analyses de Pareto des causes d'arrêts.
Considérez une ligne d'embouteillage avec 40 capteurs, chacun rapportant une valeur en virgule flottante. Dans un schéma de sondage naïf, vous pourriez publier les 40 valeurs chaque seconde : 40 messages par seconde, soit 3 456 000 messages par jour.
Avec Sparkplug B en rapport par exception, supposons que seules 5 des 40 métriques changent effectivement au cours d'une seconde donnée (la température dérive lentement, la plupart des états sont stables).
Cela équivaut à environ 5 messages DDATA par seconde plus un certificat de naissance au démarrage: environ 432 000 messages par jour, une réduction d'environ 87 % du volume de messages. Sur une liaison cellulaire ou partagée en usine, c'est la différence entre un tuyau saturé et une marge disponible.
Passez maintenant au bénéfice OEE. Disons que les certificats de naissance et de décès de la ligne montrent qu'elle a été réellement connectée et en fonctionnement pendant 400 minutes sur un quart de travail de 480 minutes. La disponibilité est 400 / 480 = 83,3 % .
Les métriques de comptage indiquent 9 000 unités contre un débit idéal de 25 unités par minute sur ces 400 minutes (10 000 idéal), donc la performance est 9 000 / 10 000 = 90 % .
Les métriques de qualité montrent 8 730 unités conformes, donc la qualité est 8 730 / 9 000 = 97 % . Multipliez-les: 0,833 x 0,90 x 0,97 = 72,7 % d'OEE .
Chaque donnée de ce calcul provenait de métriques Sparkplug autodécrites et conscientes de l'état, sans approximation sur la réalité d'un arrêt ou la simple obsolescence d'une lecture.
Sparkplug B est souvent associé à une architecture de namespace unifiée, où un broker unique devient la source de vérité en temps réel et chaque application publie et consomme à partir de celui-ci.
Il complète plutôt qu'il ne remplace les systèmes existants: les données peuvent provenir de PLC, de couches SCADA ou de passerelles edge indépendantes, puis transiter vers un GMAO pour des déclencheurs de maintenance ou vers des tableaux de bord de surveillance pour la visibilité de la production en direct.
Parce que le format est ouvert et autodécrit, il soutient aussi des stratégies de maintenance conditionnelle qui dépendent de flux continus et fiables de capteurs plutôt que de contrôles manuels périodiques.
Fabrico est la fondation de données temps réel qui transforme la télémétrie propre de l'atelier en actions.
Il fournit la surveillance OEE et de production en temps réel, et une GMAO prête pour le terrain avec ordres de travail, actifs, planification préventive et gestion des pièces détachées, le tout conçu dans l'UE avec résidence des données dans l'UE.
Lorsqu'une machine n'a pas de PLC ou de tag réseau accessible pour alimenter un flux Sparkplug, la vision par ordinateur de Fabrico lit l'équipement directement, de sorte que même les actifs hérités contribuent à vos indicateurs de disponibilité et de performance.
La philosophie consciente de l'état et autodécrite qui sous-tend Sparkplug B est précisément la discipline que Fabrico applique aux données OEE : savoir ce que signifie chaque signal, et savoir quand on peut lui faire confiance, avant même qu'il n'arrive dans un rapport.
Non. Sparkplug B fonctionne au-dessus du MQTT standard et utilise un broker conforme. Il ajoute un espace de noms de topics défini, un format de payload avec Protocol Buffers et le cycle de vie des certificats de naissance/décès. Vous avez toujours besoin d'un broker MQTT en dessous ; Sparkplug B est la couche de convention qui rend les messages interopérables et autodécrits.
Un certificat de naissance (NBIRTH ou DBIRTH) est publié une seule fois lors de la connexion d'un appareil et contient le schéma complet: chaque nom de métrique, type de données et valeur initiale.
Les messages de données normaux (NDATA ou DDATA) sont publiés ensuite par exception et ne transportent que les valeurs qui ont changé. Les consommateurs utilisent le certificat de naissance pour interpréter chaque message de données ultérieur sans aucun mappage externe.
Indirectement mais de façon significative. En rendant l'état explicite via les certificats de décès, il permet aux systèmes de distinguer une valeur stable genuine d'un capteur hors ligne, ce qui évite que des lectures obsolètes gonflent la disponibilité. En typant chaque métrique, il élimine l'ambiguïté d'unité et de format des entrées performance et qualité.
Des entrées plus propres et conscientes de l'état signifient que le chiffre OEE que vous calculez reflète la réalité.
Envie de voir une télémétrie autodécrite et consciente de l'état piloter l'OEE en direct sans intégration personnalisée pour chaque machine ? Réservez une démo Fabrico et regardez vos données de production réelles devenir une base digne de confiance.
Connexion
Blog
