Associer un jumeau numérique à MQTT est le moyen le plus direct de garder un modèle virtuel en phase avec des équipements réels. Dans ce guide, vous verrez pourquoi le modèle publish/subscribe de MQTT convient si bien aux jumeaux, comment concevoir les topics, l'état retained, la présence et les commandes, et comment diffuser l'état en temps réel vers un jumeau dans le navigateur avec du Python et du JavaScript exécutables.
Si le concept de jumeau est nouveau pour vous, commencez par le guide de la technologie du jumeau numérique.
Pourquoi MQTT convient aux jumeaux numériques
Un jumeau attend trois choses de son transport : des mises à jour à faible latence, un moyen pour les retardataires d'obtenir l'état actuel, et un couplage faible pour ajouter de nouveaux consommateurs sans toucher aux appareils. MQTT fournit les trois au sein même du protocole.
| Besoin du jumeau | Fonctionnalité MQTT | Pourquoi c'est utile |
|---|---|---|
| Mises à jour en temps réel | Connexions persistantes, livraison en push | Les valeurs arrivent en quelques millisecondes, sans polling |
| État actuel au chargement | Retained messages | Un nouveau visualiseur reçoit instantanément la dernière valeur de chaque topic |
| Hiérarchie d'actifs | Topics hiérarchiques et wildcards | plant1/line2/# donne toute une ligne en un seul abonnement |
| Statut en ligne/hors ligne | Last Will and Testament | Le broker annonce quand un appareil décroche |
| Contrôle de la fiabilité | QoS 0, 1, 2 | Télémétrie rapide en QoS 0, événements importants en QoS 1 |
| Nombreux consommateurs | Découplage publish/subscribe | Tableaux de bord, vues 3D et analytique partagent un même flux |
| Visualiseurs dans le navigateur | MQTT over WebSocket | Les scènes 3D se connectent directement, sans passerelle supplémentaire |
Le polling HTTP, à l'inverse, oblige chaque visualiseur à bombarder une API et laisse malgré tout des trous entre deux requêtes. Les files de messages conçues pour le traitement backend n'offrent souvent ni état retained ni connectivité navigateur. C'est pourquoi tant de plateformes de jumeau placent un broker MQTT en leur centre.
Concevoir les topics d'un jumeau numérique avec MQTT
L'arborescence de topics est le schéma d'adressage de votre jumeau. Reflétez la hiérarchie physique, puis terminez par une classe de message :
connectmq/demo/<id>/factory1/line1/cnc1/telemetry stream, not retained
connectmq/demo/<id>/factory1/line1/cnc1/state current state, retained
connectmq/demo/<id>/factory1/line1/cnc1/status online/offline, retained + last will
connectmq/demo/<id>/factory1/line1/cnc1/cmd commands, never retained
connectmq/demo/<id>/factory1/line1/cnc1/cmd/ack command results
Des règles qui vous éviteront des ennuis plus tard :
- Utilisez des identifiants stables comme niveaux de topic, pas des noms d'affichage. Les noms changent, les identifiants non.
- Placez unités et horodatages dans le payload, pas dans le topic.
- Gardez chaque payload petit et centré sur un seul actif.
- Ne mettez jamais de commandes en retained. Un
cmdretained serait réexécuté à chaque reconnexion d'un appareil.
Pour une analyse plus poussée de la correspondance entre topics et modèle d'actifs, consultez l'architecture du jumeau numérique.
Les retained messages comme mémoire du jumeau
Lorsqu'un visualiseur ouvre le jumeau, il ne doit pas attendre le prochain cycle de télémétrie pour afficher chaque machine. Publier l'état avec le flag retain signifie que le broker conserve le dernier message de chaque topic et le livre immédiatement à l'abonnement. Le tutoriel sur l'état MQTT retained construit un jumeau complet de cette façon ; voici l'idée principale en Python avec paho-mqtt 2.x :
import json
import random
import time
import paho.mqtt.client as mqtt
PREFIX = "connectmq/demo/b72e/factory1/line1/cnc1"
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="cnc1-sim-b72e")
client.will_set(f"{PREFIX}/status", payload="offline", qos=1, retain=True)
client.connect("broker.connectmq.com", 1883)
client.loop_start()
client.publish(f"{PREFIX}/status", "online", qos=1, retain=True)
try:
while True:
state = {
"ts": int(time.time() * 1000),
"spindle_rpm": random.randint(7800, 8200),
"feed_mm_min": random.randint(900, 1100),
"tool": 4,
"mode": "AUTO",
}
client.publish(f"{PREFIX}/state", json.dumps(state), qos=0, retain=True)
time.sleep(1)
except KeyboardInterrupt:
client.publish(f"{PREFIX}/status", "offline", qos=1, retain=True)
client.loop_stop()
client.disconnect()
Le Last Will sur le topic status est important. Si le simulateur plante ou si le réseau tombe, le broker publie offline à votre place et, comme le message est retained, tout visualiseur ouvert plus tard voit lui aussi la machine hors ligne.
Diffuser le jumeau dans un navigateur
Un jumeau 3D ou 2D dans le navigateur se connecte via WebSocket sécurisé sur le port 8084 avec le chemin /mqtt. Cet exemple MQTT.js s'abonne à toute la ligne et met à jour un modèle de jumeau en mémoire que votre code de rendu peut lire à chaque image :
import mqtt from "mqtt";
const prefix = "connectmq/demo/b72e/factory1/line1";
const twin = new Map();
const client = mqtt.connect("wss://broker.connectmq.com:8084/mqtt", {
clientId: "twin-viewer-" + Math.random().toString(16).slice(2, 10),
protocolVersion: 5,
clean: true,
});
client.on("connect", () => {
client.subscribe(`${prefix}/+/state`);
client.subscribe(`${prefix}/+/status`);
});
client.on("message", (topic, payload) => {
const parts = topic.split("/");
const asset = parts[parts.length - 2];
const kind = parts[parts.length - 1];
const current = twin.get(asset) || {};
if (kind === "status") {
current.online = payload.toString() === "online";
} else {
Object.assign(current, JSON.parse(payload.toString()));
}
twin.set(asset, current);
console.log(asset, current);
});
Découplez le traitement des messages du rendu. Les messages mettent à jour le modèle ; la boucle de rendu lit le modèle. Le nombre d'images par seconde reste ainsi fluide même lorsque les messages arrivent en rafales.
Concevoir les payloads des messages du jumeau
Les topics indiquent aux consommateurs à quoi appartient une valeur ; les payloads leur disent ce qu'elle signifie. Quelques conventions gardent un jumeau en croissance maîtrisable :
- Incluez un horodatage source (
tsen millisecondes) dans chaque message d'état et de télémétrie. Les visualiseurs peuvent alors afficher l'âge de chaque valeur et ignorer les mises à jour arrivées dans le désordre. - Utilisez des noms de champs et des unités cohérents entre actifs du même type, idéalement documentés dans un schéma ou un langage de modélisation comme DTDL.
- Envoyez l'état complet sur le topic d'état, pas des correctifs partiels. Un correctif partiel retained laisserait un nouveau visualiseur avec une image incomplète.
- Gardez des payloads compacts. JSON est facile à déboguer et convient à la plupart des jumeaux ; ne passez à un encodage binaire que si la bande passante est réellement contrainte.
- Ajoutez un champ de version de schéma lorsque les payloads sont susceptibles d'évoluer, pour que les anciens et les nouveaux appareils coexistent pendant les déploiements.
Ces règles ne coûtent rien au départ et évitent un travail de reprise considérable lorsque des dizaines de types d'actifs et plusieurs applications consommatrices dépendent du même flux.
Les commandes : fermer la boucle
Un jumeau qui observe devient un jumeau qui opère dès qu'il peut envoyer des commandes. Le pattern sûr :
- L'application publie une commande avec un identifiant de corrélation sur
.../cmden QoS 1, non retained. - L'appareil la valide et l'exécute, puis publie le résultat sur
.../cmd/ackavec le même identifiant. - L'appareil met à jour son
stateretained, que voit chaque visualiseur. - L'application déclenche un timeout si aucun acquittement n'arrive.
MQTT 5 rend cela plus propre avec les propriétés response topic et correlation data, ainsi qu'avec l'expiration des messages, qui fait qu'une commande restée trop longtemps en attente est écartée plutôt qu'exécutée en retard. Lisez les fonctionnalités de MQTT 5 pour les détails. Pour la gestion de l'état désiré par rapport à l'état rapporté, consultez la synchronisation d'état du jumeau numérique.
Choisir la QoS des données du jumeau
- Télémétrie rapide pour l'animation : QoS 0. Une image manquée est remplacée par la suivante.
- Changements d'état et alarmes : QoS 1, pour qu'ils ne soient pas perdus lors de brèves déconnexions.
- Commandes : QoS 1 avec traitement idempotent et identifiants de corrélation. La QoS 2 est rarement nécessaire si les commandes sont idempotentes.
L'article les niveaux de QoS MQTT expliqués détaille ces compromis.
Comment ConnectMQ fait tourner un jumeau numérique 3D en temps réel
ConnectMQ propose une démo web de jumeau numérique 3D d'une petite usine avec une machine CNC, un bras robotisé, un four, une cuve, un convoyeur et une pompe. Les actifs simulés publient leur état sur le broker, et la scène 3D s'abonne via WebSocket sécurisé, en utilisant exactement les patterns ci-dessus : topics hiérarchiques, état retained pour un chargement instantané et mises à jour en temps réel qui pilotent l'animation.
Pour votre propre jumeau, ConnectMQ fournit un broker MQTT managé compatible MQTT 3.1.1 et 5.0, avec TLS sur le port 8883 et WSS sur le 8084 avec un certificat Let's Encrypt, pour que les visualiseurs dans le navigateur se connectent sans avertissement de certificat. L'explorateur de topics en temps réel du portail et la vue des appareils par niveaux ISA-95 vous aident à vérifier que chaque actif publie là où il le doit. Commencez à expérimenter sur le serveur MQTT public gratuit avec des données de démonstration uniquement (il sert aux tests et prototypes, pas aux données de production), puis passez à vos propres identifiants pour les actifs réels.
Dépannage des configurations jumeau numérique MQTT
- Le visualiseur n'affiche rien avant la première mise à jour. L'état n'est pas publié avec le flag retain.
- Un appareil continue d'exécuter une ancienne commande après redémarrage. Une commande a été retained. Effacez-la en publiant un payload retained vide sur ce topic, et cessez de mettre les commandes en retained.
- Les actifs restent « en ligne » après une coupure de courant. Aucun Last Will configuré, ou keepalive trop long.
- Le navigateur ne parvient pas à se connecter. Vérifiez l'URL
wss://, le port 8084 et le chemin/mqtt. - Animation saccadée. Le rendu est couplé au traitement des messages, ou la fréquence de télémétrie est trop faible pour un mouvement fluide ; interpolez entre les échantillons.
Connectez votre jumeau numérique à ConnectMQ
Créez un broker avec l'offre Serverless gratuite sur app.connectmq.com, sans carte bancaire, copiez le nom d'utilisateur, le mot de passe et le client ID générés, puis pointez-y votre simulateur et votre visualiseur. En quelques minutes, vous aurez un jumeau en temps réel diffusé via MQTT.
Questions fréquentes
Pourquoi utiliser MQTT plutôt que REST pour un jumeau numérique ?
MQTT pousse les mises à jour dès qu'elles se produisent via une connexion persistante et conserve le dernier état dans des retained messages, tandis que REST nécessite du polling, ce qui ajoute latence et charge.
Un navigateur peut-il se connecter directement à MQTT pour un jumeau 3D ?
Oui. Les navigateurs se connectent via MQTT over WebSocket, par exemple wss://broker.connectmq.com:8084/mqtt, à l'aide d'une bibliothèque comme MQTT.js.
Faut-il mettre en retained la télémétrie ou seulement l'état ?
Mettez en retained le topic d'état actuel pour que les visualiseurs se chargent instantanément ; laissez les flux de télémétrie à haute fréquence non retained pour éviter toute confusion entre le flux et l'instantané.
Comment montrer dans le jumeau qu'un appareil est hors ligne ?
Configurez un message Last Will sur un topic de statut retained. Le broker le publie automatiquement lorsque l'appareil se déconnecte de façon inattendue.
