Modélisation des données IIoT : des tags aux modèles

La modélisation des données IIoT consiste à transformer des milliers de tags PLC obscurs en informations structurées et autodescriptives, qu'une application peut consommer sans avoir un tableur de tags à côté. Dans ce guide, vous découvrirez les trois couches d'un bon modèle de données industriel, la manière dont l'ISA-95, les templates Sparkplug B et OPC UA s'articulent, et comment publier un actif modélisé via MQTT pour que le résultat soit visible et testable en quelques minutes.

Pourquoi les tags à plat ne passent plus à l'échelle

Toute usine commence par des tags. Un PLC expose N7:42, DB10.DBW4 ou Line2_Mtr3_Amps, et quelqu'un tient à jour un tableur qui explique la signification de chacun. Cela fonctionne pour une IHM qui dialogue avec un contrôleur. Tout s'effondre dès que l'on ajoute un deuxième consommateur.

Les problèmes apparaissent de manière prévisible :

Le sens vit en dehors des données. Le tag T_204 est une température uniquement parce qu'un document le dit. L'unité, la plage valide et l'actif auquel il appartient ne figurent pas dans le payload.
Chaque intégration refait le mapping. L'équipe MES, l'équipe historian et l'équipe analytique reconstruisent chacune le même dictionnaire de tags, et chaque version dérive.
Des machines identiques semblent différentes. Cinq remplisseuses de trois fournisseurs exposent cinq schémas de nommage, si bien qu'un tableau de bord conçu pour l'une ne peut pas être réutilisé pour les autres.
Les changements cassent les consommateurs en silence. Quand un automaticien renomme un tag, rien n'en informe les applications en aval.

Un modèle de données règle ces problèmes en intégrant la structure, le contexte et l'identité dans les données elles-mêmes. C'est le socle d'un Unified Namespace, et c'est ce qui rend les données d'une usine réutilisables, et pas seulement disponibles.

Les trois couches d'un modèle de données IIoT

Une manière utile d'aborder la modélisation des données IIoT est de raisonner en trois couches. Chacune répond à une question différente, et chacune peut être conçue indépendamment.

Couche	Question à laquelle elle répond	Norme ou outil typique	Exemple
Emplacement (où)	À quels site, zone, ligne et cellule cet élément appartient-il ?	Hiérarchie des équipements ISA-95	`acme/berlin/packaging/line2/filler1`
Type (quoi)	De quel type d'actif s'agit-il et quels attributs possède-t-il toujours ?	Templates Sparkplug B, ObjectTypes OPC UA	`Filler` avec vitesse, état, compteur, rebuts
Données d'instance (valeur)	Quelle est la valeur courante, avec quelle unité, quelle qualité et quel horodatage ?	Schéma de payload (JSON ou Protobuf)	`{"value": 118.4, "unit": "bpm", "ts": ...}`

Emplacement : le chemin ISA-95

La couche emplacement donne à chaque point de données une adresse que les humains reconnaissent. L'ISA-95 définit une hiérarchie composée de l'entreprise, du site, de la zone, de la ligne de production ou du centre de travail, et de l'unité de travail. L'utiliser comme chemin de topic signifie que l'adresse d'une valeur indique aussi sa provenance physique. L'article sur la hiérarchie des équipements ISA-95 approfondit le choix des niveaux, et celui sur les topics MQTT ISA-95 montre comment ils se traduisent en niveaux de topic.

Gardez la couche emplacement stable. L'implantation physique change rarement, ce qui en fait une bonne colonne vertébrale. Évitez de placer dans le chemin des éléments volatils comme des codes produits ou des noms d'équipes.

Type : des définitions d'actifs réutilisables

La couche type est celle où se fait la véritable modélisation. Vous définissez une Pump une seule fois, avec ses attributs (débit, pression de refoulement, courant moteur, état de marche), ses unités et ses plages autorisées, et chaque instance de pompe suit cette définition, quel que soit le PLC ou le fournisseur sous-jacent.

Il existe deux façons courantes d'exprimer des types dans les systèmes MQTT industriels :

Les templates Sparkplug B permettent à un edge node de publier une définition de template dans son certificat de naissance, puis de publier des instances qui y font référence. Consultez le guide des templates Sparkplug pour la mécanique.
Les ObjectTypes OPC UA et les companion specifications définissent des types riches et normalisés pour de nombreuses classes de machines. Si vos machines parlent déjà OPC UA, réutilisez ces types au lieu d'en inventer de nouveaux. Le comparatif OPC UA vs MQTT explique comment les deux coexistent.

Si aucune des deux ne s'applique, un simple JSON Schema par type d'actif, stocké sous contrôle de version, suffit pour démarrer.

Données d'instance : un payload cohérent

La couche valeur, c'est le payload. Quel que soit le format choisi, chaque valeur doit porter la même enveloppe : la valeur, l'unité physique, un horodatage issu de la source et un indicateur de qualité. Sans horodatage source, les consommateurs ne peuvent pas distinguer un message en retard d'une nouvelle mesure. Sans qualité, un capteur figé ressemble à un process stable.

Concevoir un modèle de données IIoT étape par étape

La checklist suivante fonctionne pour une première ligne ou une première classe de machines. Faites-la sur papier avant d'écrire la moindre configuration de passerelle.

Choisissez une classe d'actifs avec plusieurs instances. Pompes, moteurs ou remplisseuses sont de bons candidats, car la réutilisation est immédiatement rentable.
Listez les questions que posent les consommateurs. « Est-ce que ça tourne ? », « Combien a-t-on produit cette heure-ci ? », « Est-ce que ça dérive vers une panne ? » Le modèle doit y répondre directement.
Définissez le type. Nommez chaque attribut en langage clair, attribuez-lui une unité, un type de données et une plage attendue. Décidez quels attributs relèvent de la télémétrie (changent souvent), de l'état (changent sur événement) et des métadonnées (changent rarement).
Mappez les tags vers les attributs, par fournisseur. C'est le seul endroit où les noms de tags propres au fournisseur doivent apparaître, généralement dans la passerelle edge.
Fixez le chemin d'emplacement. Choisissez les niveaux ISA-95 dont vous avez besoin et consignez les noms autorisés pour chaque niveau.
Choisissez l'enveloppe du payload. Le JSON avec valeur, unité, horodatage et qualité est le plus simple à déboguer. Le Protobuf de Sparkplug B est plus compact et porte la sémantique de naissance et de mort.
Versionnez le modèle. Ajoutez un attribut modelVersion ou conservez les définitions de types dans un dépôt pour que les consommateurs puissent détecter les changements.
Publiez une instance et passez-la en revue avec les consommateurs avant de la déployer sur le reste du parc.

Publier un actif modélisé via MQTT

Voici un exemple Python minimal qui publie une remplisseuse modélisée : les métadonnées sous forme de retained message, la télémétrie sous forme de messages périodiques, le tout sous un chemin ISA-95. Il utilise le serveur MQTT public gratuit broker.connectmq.com : n'y envoyez donc pas de vraies données d'usine, l'espace public étant lisible par tous.

import json
import random
import time
import uuid

import paho.mqtt.client as mqtt

BROKER = "broker.connectmq.com"
RUN_ID = uuid.uuid4().hex[:8]
BASE = f"connectmq/demo/{RUN_ID}/berlin/line2/filler1"

# Définition du type : à quoi ressemble chaque Filler
FILLER_MODEL = {
    "type": "Filler",
    "modelVersion": "1.2.0",
    "attributes": {
        "speed": {"unit": "bpm", "dataType": "float", "min": 0, "max": 200},
        "state": {"dataType": "string", "enum": ["RUNNING", "IDLE", "FAULT"]},
        "goodCount": {"unit": "units", "dataType": "int"},
        "rejectCount": {"unit": "units", "dataType": "int"},
    },
    "metadata": {"vendor": "ExampleVendor", "serial": "F-2291", "commissioned": "2024-03-11"},
}


def on_connect(client, userdata, flags, reason_code, properties):
    print("connected:", reason_code)


client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id=f"model-demo-{RUN_ID}")
client.on_connect = on_connect
client.connect(BROKER, 1883, keepalive=60)
client.loop_start()

# Publier le modèle une seule fois, retenu, pour que les abonnés tardifs puissent le découvrir
client.publish(f"{BASE}/model", json.dumps(FILLER_MODEL), qos=1, retain=True)

good, rejects = 0, 0
try:
    while True:
        ts = int(time.time() * 1000)
        speed = round(random.gauss(120, 4), 1)
        good += int(speed / 60 * 5)
        rejects += 1 if random.random() < 0.05 else 0
        for name, value, unit in [
            ("speed", speed, "bpm"),
            ("goodCount", good, "units"),
            ("rejectCount", rejects, "units"),
        ]:
            payload = {"value": value, "unit": unit, "ts": ts, "quality": "GOOD"}
            client.publish(f"{BASE}/telemetry/{name}", json.dumps(payload), qos=0)
        client.publish(f"{BASE}/state", json.dumps({"value": "RUNNING", "ts": ts}), qos=1, retain=True)
        time.sleep(5)
except KeyboardInterrupt:
    client.loop_stop()
    client.disconnect()

Observez le résultat avec le client Mosquitto :

mosquitto_sub -h broker.connectmq.com -p 1883 -i watcher-$RANDOM -t "connectmq/demo/+/berlin/#" -v

Notez la profondeur : le serveur MQTT public gratuit autorise jusqu'à 8 niveaux de topic, la démo ne conserve donc que le site, la ligne et la machine sous le préfixe de démo (le topic le plus profond, .../filler1/telemetry/speed, compte exactement 8 niveaux). Dans votre propre namespace, vous ajouteriez aussi l'entreprise et la zone. En production sur un broker MQTT managé, vous utilisez vos propres identifiants et n'êtes pas limité à un préfixe de démo partagé.

Comment ConnectMQ vous aide à visualiser le modèle

Une fois les données modélisées en circulation, il faut pouvoir les vérifier. ConnectMQ détecte les topics de style ISA-95 et Unified Namespace et affiche dans le portail les appareils connectés regroupés par niveaux ISA-95, si bien qu'un niveau erroné ou un nom de ligne mal orthographié saute immédiatement aux yeux. L'explorateur de topics en direct affiche les messages retenus de modèle et d'état à côté de la télémétrie, ce qui permet de confirmer rapidement que l'enveloppe est cohérente d'une instance à l'autre.

Si vos edge nodes publient en Sparkplug B, ConnectMQ décode les payloads Protobuf et peut les republier dans des topics ISA-95 : par exemple, spBv1.0/factory1/DDATA/line1/cnc1 devient connectmq/factory1/production/line1/cnc1/telemetry. Vous bénéficiez ainsi d'un transport Sparkplug compact depuis l'edge et de topics lisibles et modélisés pour les consommateurs. L'article Sparkplug B et Unified Namespace détaille ce modèle.

Les pièges courants de la modélisation des données IIoT

Modéliser le PLC au lieu du process. Si votre attribut s'appelle DB10_Word4, vous n'avez fait que déplacer le tag. Modélisez ce dont parlent les opérateurs et les ingénieurs.
Trop de niveaux de hiérarchie. Chaque niveau supplémentaire est une source d'incohérence de nommage. Utilisez les niveaux qui diffèrent réellement dans votre usine et ignorez les autres.
Des unités dans les noms d'attributs. temperature_degC lie le nom à l'unité. Placez l'unité dans le payload ou dans la définition du type.
Pas d'horodatage source. L'heure d'arrivée au broker n'est pas l'heure de mesure, surtout quand les passerelles mettent en tampon pendant les coupures.
Mélanger état et télémétrie dans un même flux. Les changements d'état sont rares et doivent être retenus ; la télémétrie à haute fréquence ne doit généralement pas l'être.
Aucun responsable. Un modèle sans responsable dérive. Désignez une personne ou une équipe par type d'actif.

Et ensuite, que devient le modèle ?

Un bon modèle de données n'est pas une fin en soi. Il alimente l'historian, le MES, les tableaux de bord et le machine learning. Le guide de l'IoT industriel avec MQTT présente l'architecture d'ensemble, et si vous voulez comprendre comment les messages sont routés entre tous ces consommateurs, commencez par le rôle d'un broker MQTT. Lorsque vous dépassez le cadre d'une seule usine, un broker MQTT cloud permet à plusieurs sites de publier dans un namespace unique et cohérent.

Démarrez avec ConnectMQ

Modélisez une classe d'actifs, publiez-la et observez-la dans un vrai broker. Créez un broker Serverless gratuit sur app.connectmq.com, sans carte bancaire, puis pointez votre passerelle ou le script Python ci-dessus vers vos propres identifiants (YOUR_USERNAME, YOUR_PASSWORD, YOUR_CLIENT_ID) et utilisez la vue des appareils ISA-95 pour vérifier que votre hiérarchie correspond à ce que vous avez conçu.

Questions fréquentes

Qu'est-ce que la modélisation des données IIoT ?

La modélisation des données IIoT consiste à donner aux données industrielles une structure cohérente : un emplacement dans une hiérarchie d'actifs, un type qui définit les attributs d'un actif, et un format de payload avec unités, horodatages et qualité. Elle remplace les tableurs de tags par des données autodescriptives.

Faut-il utiliser les templates Sparkplug B ou les types OPC UA ?

Utilisez les types OPC UA si vos machines les exposent déjà ou s'il existe une companion specification pour votre classe d'équipements. Utilisez les templates Sparkplug B si votre architecture edge est nativement MQTT et que vous voulez la sémantique de naissance et de mort ; les deux peuvent alimenter le même namespace ISA-95.

Où doit se faire le mapping des tags vers le modèle ?

Dans la passerelle edge ou le connecteur le plus proche du PLC. Les noms propres aux fournisseurs restent ainsi à un seul endroit, et chaque consommateur situé au-dessus de la passerelle ne voit que le modèle propre.

Faut-il un modèle de données avant de lancer un Unified Namespace ?

Il vous faut au minimum la couche emplacement et une enveloppe de payload. Les types d'actifs peuvent être ajoutés classe par classe, mais s'accorder d'abord sur les chemins et l'enveloppe évite des renommages coûteux par la suite.

Modélisation des données IIoT : des tags à plat aux modèles d'information