Comment construire un Unified Namespace étape par étape

Savoir construire un Unified Namespace transforme un mot à la mode en architecture opérationnelle : un seul broker MQTT où chaque machine, chaque ligne et chaque système publie son état courant sous un topic prévisible, fondé sur une hiérarchie. Dans ce tutoriel, vous allez modéliser votre usine, choisir un broker, publier des données edge retenues avec Python, ajouter un consommateur qui lit l'état complet de l'usine et mettre en place la gouvernance qui garde le namespace exploitable à mesure qu'il grandit.

Ce que vous allez construire

Un Unified Namespace (UNS) n'est pas un produit. C'est un accord : tous les producteurs publient dans un hub unique piloté par les événements, organisé selon une structure partagée, et tous les consommateurs s'abonnent à ce dont ils ont besoin au lieu de construire des intégrations point à point. En pratique, ce hub est un broker MQTT et la structure est généralement la hiérarchie des équipements ISA-95.

L'architecture finale comporte quatre couches :

La propriété clé est le découplage. L'historian ne sait pas que le PLC existe, et la passerelle PLC ne sait pas qui écoute. Chacun se connecte une seule fois, au broker.

Étape 1 : modéliser la hiérarchie de votre usine

Avant d'écrire la moindre ligne de code, décidez comment l'usine est organisée dans le namespace. La hiérarchie des équipements ISA-95 offre un point de départ éprouvé : entreprise, site, zone, ligne (ou cellule de process) et cellule ou machine. Notre guide sur la hiérarchie des équipements ISA-95 explique chaque niveau avec des exemples d'usine.

Travaillez sur une courte liste pour une zone pilote :

1. Listez les sites concernés et donnez à chacun un identifiant court, stable et en minuscules (dallas, izmir).
2. Au sein d'un site, listez les zones (packaging, utilities, machining).
3. Au sein d'une zone, listez les lignes et leurs machines (line2/filler, line2/capper).
4. Décidez de ce qui se trouve sous chaque machine : un objet telemetry unique, des topics individuels par mesure, ou les deux.
5. Consignez le résultat sous forme d'arborescence de topics et faites-la valider par l'exploitation, l'ingénierie et l'IT.

Une première arborescence pilote pourrait ressembler à ceci :

acme/dallas/packaging/line2/filler/telemetry
acme/dallas/packaging/line2/filler/state
acme/dallas/packaging/line2/capper/telemetry
acme/dallas/utilities/compressors/comp1/telemetry

Prenez votre temps ici. Renommer un topic dont vingt consommateurs dépendent est pénible. Nos guides sur les topics MQTT ISA-95 et la structure des topics UNS contiennent des arborescences prêtes à l'emploi et les pièges à éviter.

Étape 2 : choisir le broker central

Le broker devient le logiciel le plus important de l'usine, alors choisissez-le de manière réfléchie. Il doit prendre en charge MQTT 3.1.1 pour les anciennes passerelles et MQTT 5 pour les clients plus récents, les retained messages pour l'état courant, TLS avec des identifiants par client, et suffisamment de connexions pour toutes les passerelles et tous les consommateurs que vous prévoyez d'ajouter. Pour une checklist complète, consultez comment choisir un broker MQTT IoT.

Vous pouvez exploiter le broker vous-même sur un serveur dans l'usine ou utiliser un broker MQTT cloud opéré par un tiers. Les usines commencent souvent par un broker MQTT managé pour le pilote, car cela retire les correctifs et la supervision du serveur du chemin critique. ConnectMQ, par exemple, fournit à chaque broker MQTT 3.1.1 et 5.0, TLS sur le port 8883, un explorateur de topics en direct et une vue des appareils qui regroupe les appareils connectés par niveaux ISA-95, exactement ce que vous voulez voir pendant que le namespace prend forme.

Pour ce tutoriel, vous pouvez utiliser le serveur MQTT public gratuit broker.connectmq.com. Il ne nécessite aucun compte, mais il est réservé aux tests et aux prototypes, et tout ce qui y est publié est lisible par n'importe qui : nous préfixons donc les topics par connectmq/demo/<random-id>/ et ne publions que des valeurs simulées. Le serveur public autorise jusqu'à 8 niveaux de topic, ce qui correspond exactement à connectmq/demo/k4p9/dallas/packaging/line2/filler/telemetry.

Étape 3 : publier les données edge sous forme d'état retenu

La couche edge lit les machines et publie leur état courant. Les déploiements réels utilisent des drivers OPC UA, Modbus ou PLC ; ici, un script Python joue le rôle de passerelle pour que vous voyiez clairement les règles de publication. Installez le client avec pip install "paho-mqtt>=2.0".

import json
import random
import time
from datetime import datetime, timezone

import paho.mqtt.client as mqtt

BROKER = "broker.connectmq.com"
PREFIX = "connectmq/demo/k4p9"     # remplacez k4p9 par votre propre ID aléatoire
MACHINES = [
    ("dallas", "packaging", "line2", "filler"),
    ("dallas", "packaging", "line2", "capper"),
]

def on_connect(client, userdata, flags, reason_code, properties):
    print("gateway connected:", reason_code)
    for site, area, line, machine in MACHINES:
        state_topic = f"{PREFIX}/{site}/{area}/{line}/{machine}/state"
        client.publish(state_topic, "online", qos=1, retain=True)

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="uns-gateway-k4p9")
client.on_connect = on_connect
# Si la passerelle tombe, le broker marque la première machine hors ligne pour tout le monde
client.will_set(f"{PREFIX}/dallas/packaging/line2/filler/state", "offline", qos=1, retain=True)
client.connect(BROKER, 1883, keepalive=30)
client.loop_start()

counts = {m[3]: 0 for m in MACHINES}
try:
    while True:
        for site, area, line, machine in MACHINES:
            counts[machine] += random.randint(4, 6)
            payload = {
                "timestamp": datetime.now(timezone.utc).isoformat(),
                "speed_bpm": round(random.uniform(110, 125), 1),
                "temperature_c": round(random.uniform(38, 44), 1),
                "good_count": counts[machine],
            }
            topic = f"{PREFIX}/{site}/{area}/{line}/{machine}/telemetry"
            client.publish(topic, json.dumps(payload), qos=1, retain=True)
        time.sleep(5)
except KeyboardInterrupt:
    client.loop_stop()
    client.disconnect()

Trois règles font de ce script un publicateur UNS plutôt qu'un simple émetteur de données. Chaque message est retenu, si bien qu'un nouveau consommateur obtient immédiatement la valeur courante. Les payloads portent leur propre horodatage et les unités figurent dans les noms de champs. Et la disponibilité des machines est explicite, grâce à un message will qui bascule l'état sur offline lorsque la passerelle disparaît.

Si votre edge parle déjà Sparkplug B, vous n'avez pas besoin de le réécrire. ConnectMQ décode les payloads Sparkplug B et peut les republier dans des topics ISA-95, par exemple spBv1.0/factory1/DDATA/line1/cnc1 vers connectmq/factory1/production/line1/cnc1/telemetry. Les edge nodes Sparkplug et les publicateurs JSON classiques peuvent ainsi partager un même namespace. Les compromis entre les deux approches sont détaillés dans MQTT, Sparkplug B et le Unified Namespace.

Étape 4 : ajouter vos premiers consommateurs

Un namespace prouve sa valeur lorsque des consommateurs apparaissent sans que personne ne touche à l'edge. Cet abonné construit en mémoire un modèle de toute l'usine à partir d'un seul abonnement avec wildcard :

import json
import paho.mqtt.client as mqtt

PREFIX = "connectmq/demo/k4p9"
plant = {}

def on_connect(client, userdata, flags, reason_code, properties):
    client.subscribe(f"{PREFIX}/#", qos=1)

def on_message(client, userdata, msg):
    levels = msg.topic[len(PREFIX) + 1:].split("/")
    if len(levels) != 5:
        return
    site, area, line, machine, kind = levels
    node = plant.setdefault(site, {}).setdefault(area, {}).setdefault(line, {}).setdefault(machine, {})
    text = msg.payload.decode()
    node[kind] = json.loads(text) if kind == "telemetry" else text
    print(f"{site}/{area}/{line}/{machine} {kind}: {node[kind]}" + (" (retained)" if msg.retain else ""))

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="uns-viewer-k4p9")
client.on_connect = on_connect
client.on_message = on_message
client.connect("broker.connectmq.com", 1883, keepalive=60)
client.loop_forever()

Lancez-le pendant que la passerelle tourne et remarquez que les premiers messages sont marqués comme retenus : le consommateur disposait de l'image complète de l'usine dès son abonnement. Restreignez le périmètre avec des wildcards après le préfixe, par exemple connectmq/demo/k4p9/+/packaging/# pour une zone sur tous les sites, ou connectmq/demo/k4p9/+/+/+/filler/telemetry pour toutes les remplisseuses, où qu'elles soient.

Les consommateurs suivants sont généralement un tableau de bord, un historian et un service d'alerte. Chacun n'est qu'un abonné de plus, tout comme un futur jumeau numérique de la ligne, qui lit le même état courant. Pour le stockage, notre guide sur l'historian MQTT montre des abonnés Telegraf et Python qui alimentent des bases de données de séries temporelles ; le namespace reste la source de vérité de l'état courant, tandis que le stockage conserve l'historique.

Étape 5 : gouverner le namespace

Sans règles, un UNS se dégrade en marécage de topics en quelques mois. Mettez celles-ci en place avant que la deuxième zone ne rejoigne le projet :

• Norme de nommage. Minuscules, tirets au lieu des espaces, aucun nom de personne ni numéro de ticket dans les topics.
• Propriété. Chaque branche de l'arborescence a un responsable qui approuve les nouveaux topics.
• Contrat de payload. Un schéma JSON documenté par type de topic, avec les règles d'unités et d'horodatage.
• Identifiants par publicateur. Une identité par passerelle ou application, pour savoir qui publie quoi et révoquer les accès proprement.
• Processus de changement. Les nouveaux topics sont ajoutés, les anciens sont dépréciés avec une date de fin, jamais renommés en silence.
• Observabilité. Quelqu'un surveille l'état des connexions, les débits de messages et les topics obsolètes.

Le portail ConnectMQ aide sur le volet observabilité : l'explorateur de topics en direct montre l'arborescence au fil de sa croissance, la vue des appareils ISA-95 indique à quels entreprise, site, zone et ligne appartient chaque appareil connecté, et les règles d'alerte à seuil vous préviennent lorsqu'une valeur franchit une limite.

Erreurs courantes lors de la construction d'un UNS

Pour le contexte industriel plus large, consultez notre guide MQTT pour l'IoT industriel.

Construisez votre Unified Namespace sur ConnectMQ

Un Unified Namespace a besoin d'un broker dont la disponibilité est fiable et d'une vue claire de l'arborescence de topics à mesure qu'elle grandit. ConnectMQ est un broker MQTT managé avec MQTT 3.1.1 et 5.0, TLS, retained messages, décodage Sparkplug B, republication ISA-95 et une vue des appareils ISA-95. Démarrez votre pilote avec l'offre Serverless (Free) sur app.connectmq.com, sans carte bancaire, puis passez à Serverless (Paid), Dedicated ou BYOC à mesure que d'autres lignes vous rejoignent.

Questions fréquentes

Faut-il Sparkplug B pour construire un Unified Namespace ?

Non. De nombreux namespaces utilisent du JSON simple sur MQTT. Sparkplug B ajoute la gestion d'état et des métriques typées, et les deux peuvent coexister si le broker republie les données Sparkplug dans des topics lisibles.

Le broker UNS doit-il tourner sur site ou dans le cloud ?

Les deux fonctionnent. Sur site, le trafic reste local ; un broker hébergé supprime le travail d'exploitation et facilite l'accès multisite. Beaucoup d'usines démarrent en hébergé pour le pilote et tranchent en fonction de ce qu'elles apprennent.

Quelle taille pour un premier pilote UNS ?

Une ligne ou une zone avec quelques machines et deux ou trois consommateurs suffit pour valider le modèle et affiner la norme de nommage.

Un Unified Namespace remplace-t-il un historian ?

Non. L'UNS conserve l'état courant et les événements ; un historian ou un data lake s'y abonne et conserve l'historique à long terme.