Alias de métriques Sparkplug : économiser de la bande passante dans les messages DATA

Les alias de métriques Sparkplug permettent à un edge node de remplacer de longs noms de métriques comme Line2/Filler/Motor/CurrentAmps par un petit entier dans chaque message DATA. Dans ce guide, vous verrez comment fonctionne la correspondance des alias entre messages BIRTH et DATA, quand les alias valent la complexité supplémentaire, et comment repérer et corriger les incohérences d'alias lorsque des valeurs décodées paraissent soudain fausses.

Pourquoi les noms de métriques coûtent cher

Les payloads Sparkplug B sont en Protobuf, déjà compact. Les nombres sont encodés en varint, les horodatages sont des entiers 64 bits et il n'y a aucune ponctuation JSON. La seule partie d'un payload que Protobuf ne peut pas réduire, c'est une chaîne de caractères, et les noms de métriques sont des chaînes.

Les conventions de nommage industrielles rendent ces chaînes longues. Un chemin de tag copié depuis le navigateur de tags d'un automate ou d'un SCADA contient souvent la zone, la machine, le sous-système et le signal : Packaging/Line2/Filler/Infeed/Motor1/Current. Lorsqu'un message DDATA signale une seule valeur modifiée, ce nom de 45 caractères peut peser plusieurs fois plus que la valeur et l'horodatage réunis.

Sur un réseau d'usine filaire, cela compte rarement. Sur des liaisons cellulaires, satellites, radio sous licence ou des réseaux partagés saturés, cela compte énormément. Chaque octet se paie, en argent ou en latence. Les alias de métriques Sparkplug sont la réponse de la spécification : envoyer le nom une fois, puis y faire référence par un numéro.

Comment fonctionnent les alias de métriques Sparkplug

Le mécanisme repose sur trois règles.

1. Dans le NBIRTH (pour les métriques de niveau nœud) ou le DBIRTH (pour les métriques de device), chaque métrique est envoyée avec son name et un alias, un entier non signé de 64 bits.
2. Dans les messages NDATA, DDATA, NCMD et DCMD suivants, la métrique n'est envoyée qu'avec son alias. Le champ name est omis.
3. Les alias doivent être uniques à l'échelle d'un edge node. Deux métriques d'un même edge node, même sur des devices différents, ne peuvent pas partager un alias.

Une application hôte primaire, ou tout autre consommateur, construit une table de correspondance à la réception du BIRTH. Dès lors, chaque métrique DATA qui arrive avec un alias est ramenée à son nom complet grâce à cette table.

Voici la même métrique dans les deux types de messages, présentée sous forme de structure Protobuf décodée :

DBIRTH  spBv1.0/plant1/DBIRTH/edge-07/filler-02
  metric { name: "Infeed/Motor1/Current"  alias: 12  datatype: Float  float_value: 4.81 }
  metric { name: "Infeed/Motor1/Running"  alias: 13  datatype: Boolean  boolean_value: true }

DDATA   spBv1.0/plant1/DDATA/edge-07/filler-02
  metric { alias: 12  datatype: Float  float_value: 4.93  timestamp: 1792137600123 }

La métrique DDATA ne porte aucun nom. Sans le DBIRTH, un consommateur dispose d'un float et du nombre 12, rien de plus.

Ce que les alias ne changent pas

Les alias ne remplacent que le nom. Le type de données, la valeur, l'horodatage, les propriétés de qualité et les métadonnées fonctionnent exactement comme avant. Les topics restent aussi les mêmes : ces alias n'ont rien à voir avec les topic aliases de MQTT 5, qui raccourcissent la chaîne du topic au niveau du protocole. Les deux peuvent coexister, mais ce sont des fonctionnalités indépendantes définies par des spécifications différentes. Pour la version au niveau MQTT, consultez la section sur les topic aliases de notre guide des fonctionnalités de MQTT 5.

Noms ou alias : les compromis

C'est la ligne sur le risque qui compte. Un mauvais nom saute aux yeux. Un mauvais alias, non : le consommateur écrit tranquillement un courant moteur dans un tag de température, et le chiffre paraît plausible.

Le cycle de vie des alias en pratique

Les alias ne sont valables que pendant la durée de vie d'un seul BIRTH. Comprendre quand cette durée prend fin évite la plupart des bugs.

• Le NBIRTH réinitialise tout. Lorsqu'un edge node publie un nouveau NBIRTH, toutes les tables d'alias de ce nœud sont abandonnées et reconstruites à partir du nouveau NBIRTH et des DBIRTH qui suivent. Un edge node peut attribuer des numéros d'alias différents après un rebirth : un consommateur ne doit donc jamais conserver d'alias en cache d'un birth à l'autre.
• Le NDEATH invalide la table. Lorsque le broker publie le will NDEATH de l'edge node, les consommateurs doivent marquer les métriques du nœud comme périmées et cesser de se fier à la table d'alias jusqu'au prochain NBIRTH.
• Un DBIRTH peut ajouter des métriques de device. Un device peut faire l'objet d'un rebirth isolé, et les alias de ses métriques doivent rester uniques sur l'ensemble de l'edge node.
• Les demandes de rebirth restaurent l'état perdu. Un hôte qui voit un alias inconnu doit envoyer un NCMD avec la métrique Node Control/Rebirth à true plutôt que de deviner. Notre article sur le rebirth Sparkplug détaille ce flux.

Le numéro de séquence aide aussi. Chaque message Sparkplug d'un edge node porte un seq de 0 à 255 qui reboucle. Si un consommateur constate un trou, il a peut-être manqué un BIRTH et doit demander un rebirth avant de se fier de nouveau aux alias. Les règles des messages BIRTH et DEATH sont expliquées dans certificats birth et death Sparkplug.

Décoder des données avec alias en Python

Le script suivant s'abonne à tout le trafic Sparkplug d'un groupe, construit les tables d'alias à partir des messages NBIRTH et DBIRTH, et ramène les métriques DATA à leurs noms. Il utilise sparkplug_b_pb2.py, le module Protobuf généré issu du projet Eclipse Tahu ; copiez-le à côté du script et installez les dépendances avec pip install paho-mqtt protobuf.

import paho.mqtt.client as mqtt
import sparkplug_b_pb2

BROKER = "broker.connectmq.com"
GROUP = "demo-7f3k2"          # utilisez votre propre group ID unique sur le broker public
alias_tables = {}             # edge_node_id -> {alias: name}

def on_connect(client, userdata, flags, reason_code, properties):
    print("connected:", reason_code)
    client.subscribe(f"spBv1.0/{GROUP}/#", qos=0)

def on_message(client, userdata, msg):
    parts = msg.topic.split("/")
    if len(parts) < 4:
        return
    msg_type, edge_node = parts[2], parts[3]
    device = parts[4] if len(parts) > 4 else None

    payload = sparkplug_b_pb2.Payload()
    payload.ParseFromString(msg.payload)

    if msg_type == "NBIRTH":
        alias_tables[edge_node] = {}          # un nouveau NBIRTH réinitialise tous les alias
    if msg_type in ("NBIRTH", "DBIRTH"):
        table = alias_tables.setdefault(edge_node, {})
        for m in payload.metrics:
            if m.HasField("alias"):
                if m.alias in table and table[m.alias] != m.name:
                    print(f"WARNING duplicate alias {m.alias} on {edge_node}")
                table[m.alias] = m.name
        print(f"{msg_type} {edge_node}/{device or ''}: {len(alias_tables[edge_node])} aliases")
        return

    if msg_type == "NDEATH":
        alias_tables.pop(edge_node, None)
        print(f"NDEATH {edge_node}: alias table cleared")
        return

    if msg_type in ("NDATA", "DDATA"):
        table = alias_tables.get(edge_node)
        for m in payload.metrics:
            name = m.name
            if not name and m.HasField("alias"):
                if table is None or m.alias not in table:
                    print(f"UNKNOWN alias {m.alias} from {edge_node}, request a rebirth")
                    continue
                name = table[m.alias]
            value = getattr(m, m.WhichOneof("value")) if m.WhichOneof("value") else None
            print(f"{edge_node}/{device or ''} {name} = {value} (seq {payload.seq})")

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="alias-decoder-7f3k2")
client.on_connect = on_connect
client.on_message = on_message
client.connect(BROKER, 1883, keepalive=60)
client.loop_forever()

Pour produire du trafic de test avec alias, associez-le à l'éditeur de notre tutoriel simulateur d'edge node Sparkplug B. Les deux scripts fonctionnent avec le serveur MQTT public gratuit sur broker.connectmq.com. Rappelez-vous que ce serveur public, destiné aux tests, est lisible par tous : utilisez un group ID aléatoire et n'y publiez jamais de vraies données d'usine.

Déboguer les incohérences d'alias

La plupart des problèmes d'alias relèvent de quelques schémas. Utilisez cette checklist lorsque des valeurs décodées paraissent fausses.

1. Consommateur démarré après le BIRTH. Les messages BIRTH ne sont pas retained dans Sparkplug : un consommateur qui se connecte plus tard ne voit que des DATA avec alias. La solution est une demande de rebirth, ou une application hôte primaire qui déclenche automatiquement les rebirths.
2. Cache périmé après un rebirth. Si un consommateur conserve son ancienne table après un nouveau NBIRTH, les valeurs atterrissent sur les mauvais noms. Réinitialisez à chaque NBIRTH, comme le fait le script ci-dessus.
3. Alias dupliqués entre devices. Certaines configurations edge numérotent les alias par device à partir de 1. Deux devices revendiquent alors tous deux l'alias 1, ce qui viole la règle d'unicité et corrompt tout consommateur qui indexe ses tables par edge node.
4. Alias zéro traité comme absent. En Protobuf, un champ positionné à sa valeur par défaut peut être impossible à distinguer d'un champ absent selon la façon dont le code le vérifie. Commencer les alias à 1 évite toute une catégorie de bugs.
5. Noms et alias mélangés. Une métrique DATA peut légalement inclure à la fois un nom et un alias. Les consommateurs doivent privilégier le nom lorsqu'il est présent, et les edge nodes doivent rester cohérents.
6. Plusieurs éditeurs utilisant le même edge node ID. Deux passerelles configurées avec les mêmes groupe et edge node ID écrasent mutuellement leurs births. Le symptôme : des alias qui changent de signification.

L'inspection visuelle accélère le travail. ConnectMQ décode les payloads Sparkplug B, en Protobuf ou en JSON : dans l'explorateur de topics en direct du portail, vous pouvez ouvrir côte à côte le BIRTH et les messages DATA et vérifier que l'alias 12 correspond bien à la métrique attendue. ConnectMQ peut aussi republier les données Sparkplug B dans des topics ISA-95 lisibles, par exemple spBv1.0/factory1/DDATA/line1/cnc1 vers connectmq/factory1/production/line1/cnc1/telemetry, ce qui offre aux consommateurs non Sparkplug un chemin qui ne dépend absolument pas des tables d'alias.

Quand activer les alias ?

Les alias sont optionnels. Activez-les lorsque la liaison entre le terrain et le broker est facturée ou contrainte, lorsque le nombre de tags est élevé et les noms longs, ou lorsqu'une seule passerelle publie de nombreuses métriques à cadence rapide. Gardez des noms en clair lorsque vous prototypez, lorsque de nombreux consommateurs légers s'abonnent directement sans hôte primaire, ou lorsque la facilité de débogage compte plus que les octets.

Une voie médiane convient à beaucoup d'équipes : développer et mettre en service avec des noms, mesurer la taille des payloads sous une charge réaliste, puis n'activer les alias que sur les sites dont les liaisons l'exigent. Comme les alias sont entièrement négociés dans le BIRTH, les consommateurs qui implémentent correctement la correspondance n'ont besoin d'aucun changement de configuration lorsque vous basculez.

Pour mieux situer Sparkplug dans une architecture d'usine, notre guide de l'IoT industriel avec MQTT présente la vue d'ensemble, et l'article sur le payload Sparkplug B explique chaque champ visible dans la sortie décodée ci-dessus. La définition qui fait autorité sur le comportement des alias est la spécification Eclipse Sparkplug.

Tester les alias Sparkplug sur ConnectMQ

Faire tourner edge nodes et applications hôtes sur un broker que vous maîtrisez est le moyen le plus rapide de valider la gestion des alias avant la production. ConnectMQ est un broker MQTT managé avec MQTT 3.1.1 et 5.0, TLS sur le port 8883 et un décodage Sparkplug B intégré au portail. Créez un broker avec l'offre Serverless gratuite sur app.connectmq.com, sans carte bancaire, puis pointez votre edge node vers lui avec le nom d'utilisateur, le mot de passe et le client ID générés.

Questions fréquentes

Les alias de métriques Sparkplug sont-ils obligatoires ?

Non. Les alias sont optionnels dans Sparkplug B. Un edge node peut envoyer les noms complets des métriques dans chaque message DATA, et les consommateurs doivent gérer les deux formes.

Les numéros d'alias peuvent-ils changer d'un birth à l'autre ?

Oui. Les alias ne sont valables que jusqu'au prochain NBIRTH de cet edge node. Les consommateurs doivent reconstruire leurs tables à chaque NBIRTH et ne jamais conserver d'alias d'une session à l'autre.

Que doit faire un hôte face à un alias inconnu ?

Il ne doit pas deviner. La bonne réponse consiste à envoyer un NCMD avec Node Control/Rebirth à true pour que l'edge node republie ses messages BIRTH et la correspondance complète des alias.

Les alias Sparkplug sont-ils identiques aux topic aliases de MQTT 5 ?

Non. Les alias de métriques Sparkplug remplacent les noms de métriques à l'intérieur du payload, tandis que les topic aliases de MQTT 5 remplacent la chaîne du topic au niveau du protocole. Ils sont indépendants et peuvent être utilisés ensemble.