Une architecture de jumeau numérique claire fait toute la différence entre un jumeau qui passe à l'échelle sur des centaines d'actifs et une démo qui s'effondre après les cinq premiers. Ce guide présente une architecture de référence couche par couche, des capteurs et passerelles edge jusqu'aux stockages d'état, aux modèles et à la visualisation 3D en passant par une colonne vertébrale de messagerie, afin que vous puissiez concevoir une stack où chaque partie a un seul rôle et peut être remplacée indépendamment.
Pour les concepts sous-jacents, consultez notre guide de la technologie du jumeau numérique.
Les six couches d'une architecture de jumeau numérique
La plupart des jumeaux réussis, quels que soient l'éditeur ou le framework, finissent par adopter ces couches :
| Couche | Responsabilité | Technologie typique |
|---|---|---|
| 1. Appareils et edge | Lire capteurs et contrôleurs, normaliser, mettre en tampon | Automates, ESP32, Raspberry Pi, passerelles edge |
| 2. Messagerie | Acheminer données et commandes en temps réel, découpler producteurs et consommateurs | Broker MQTT |
| 3. État | Conserver la valeur actuelle de chaque propriété | Topics retained, base clé-valeur, service de jumeau |
| 4. Historique | Stocker les séries temporelles pour les tendances et l'analytique | Base de séries temporelles |
| 5. Modèle | Décrire actifs, relations, unités et comportement | Hiérarchie d'actifs, DTDL, AAS, modèles physiques ou de ML |
| 6. Visualisation et applications | Afficher le jumeau et agir dessus | Tableaux de bord, visualiseurs 3D web, applications mobiles |
La règle de conception essentielle : les couches communiquent entre elles via des contrats bien définis (topics et schémas de payload), jamais via des raccourcis privés. C'est ce qui vous permet de remplacer un tableau de bord par un visualiseur 3D ou d'ajouter un traitement analytique sans toucher au firmware des appareils.
Couche 1 : appareils et edge
Les actifs physiques parlent rarement une langue adaptée au jumeau. Un contrôleur CNC expose OPC UA ou un protocole constructeur ; une vieille pompe envoie un signal 4–20 mA à un automate ; un nouveau capteur peut tourner sur un ESP32. La couche edge comble cet écart.
Responsabilités à l'edge :
- Traduction de protocole de Modbus, OPC UA ou bus de terrain vers MQTT.
- Normalisation en unités et noms cohérents, pour que
spindle_rpmsignifie la même chose partout. - Bande morte et contrôle de fréquence : ne publier une valeur que lorsqu'elle change de façon significative ou à intervalle fixe.
- Mise en tampon lorsque la liaison montante tombe, puis réémission des données avec leur horodatage d'origine.
Horodatez à la source. Un jumeau qui ne connaît que l'heure de réception par le broker ne peut pas distinguer un réseau lent d'une machine lente.
Couche 2 : la colonne vertébrale de messagerie
La couche de messagerie est l'épine dorsale de l'architecture du jumeau numérique. Chaque producteur y publie et chaque consommateur s'y abonne, si bien que les appareils n'ont jamais besoin de savoir qui les observe. Un broker MQTT est le choix le plus courant, car il vous offre :
- Des topics hiérarchiques qui reflètent la hiérarchie des actifs.
- Des wildcards, pour qu'un visualiseur au niveau de la ligne s'abonne à
plant1/line2/#et reçoive toutes les machines. - Des retained messages qui transmettent immédiatement le dernier état aux nouveaux abonnés.
- Des niveaux de QoS pour arbitrer entre garanties de livraison et surcoût.
- Des messages Last Will, pour que le jumeau sache quand un appareil disparaît.
Une bonne conception de topics suit une hiérarchie de style ISA-95 et se termine par une classe de message :
<enterprise>/<site>/<area>/<line>/<asset>/telemetry
<enterprise>/<site>/<area>/<line>/<asset>/state
<enterprise>/<site>/<area>/<line>/<asset>/cmd
<enterprise>/<site>/<area>/<line>/<asset>/cmd/ack
Séparez telemetry (un flux, non retained), state (valeurs actuelles, retained) et cmd (commandes, jamais retained). Les mélanger est la source la plus fréquente de bugs de jumeau, comme une commande périmée rejouée vers un appareil après sa reconnexion. Notre guide du jumeau numérique avec MQTT approfondit ces patterns.
Exploiter le broker vous-même implique de gérer les certificats TLS, l'authentification, la montée en charge et la supervision. Un broker MQTT managé comme ConnectMQ supprime ce travail pour que l'équipe se concentre sur le jumeau lui-même.
Couche 3 : état
La couche d'état répond à une seule question : quelle est la valeur actuelle de l'actif, maintenant ? Il existe trois options courantes :
- Les topics MQTT retained. Chaque actif ou propriété a un retained message. Simple, sans infrastructure supplémentaire, et les visualiseurs reçoivent l'état complet à la connexion. Détaillé dans utiliser les retained messages MQTT comme état du jumeau numérique.
- Un service de jumeau. Un service dédié, comme Eclipse Ditto ou un microservice sur mesure, s'abonne à la télémétrie et maintient un document JSON par actif, exposé via une API.
- Un stockage en mémoire ou clé-valeur alimenté par un abonné, utile lorsque de nombreuses applications interrogent l'état via une API plutôt que via MQTT.
Pour beaucoup d'équipes, la bonne réponse consiste à commencer par les topics retained, puis à passer à un service de jumeau lorsque vous avez besoin de requêtes, d'un contrôle d'accès par actif ou d'une gestion de l'état désiré par rapport à l'état rapporté. Consultez la synchronisation d'état du jumeau numérique pour ces patterns.
Couche 4 : historique
L'état en temps réel ne suffit pas pour les tendances, l'analyse des causes racines ou le machine learning. Un abonné d'historique écoute les topics de télémétrie et écrit dans une base de séries temporelles. Des outils comme Telegraf, Node-RED ou un petit service Python jouent ce rôle en tant que clients MQTT ordinaires :
import json
import paho.mqtt.client as mqtt
def on_connect(client, userdata, flags, reason_code, properties):
client.subscribe("acme/plant1/+/+/+/telemetry", qos=1)
def on_message(client, userdata, msg):
point = json.loads(msg.payload)
asset_path = msg.topic.rsplit("/", 1)[0]
# Remplacer par une écriture dans votre base de séries temporelles
print(asset_path, point)
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="YOUR_CLIENT_ID")
client.username_pw_set("YOUR_USERNAME", "YOUR_PASSWORD")
client.tls_set()
client.on_connect = on_connect
client.on_message = on_message
client.connect("YOUR_BROKER_HOST", 8883)
client.loop_forever()
Gardez les écrivains d'historique indépendants du chemin temps réel. Si la base de données est lente, la vue 3D ne doit pas prendre de retard.
Couche 5 : le modèle
La couche modèle transforme des nombres en sens. Au minimum, c'est un registre d'actifs : quels actifs existent, comment ils sont liés (le site contient la ligne qui contient la machine), quelles propriétés possède chacun et dans quelles unités. Les jumeaux plus avancés ajoutent :
- Des schémas formels comme les interfaces DTDL ou les sous-modèles Asset Administration Shell.
- Des valeurs dérivées comme le TRS (OEE), le rendement ou la durée de vie résiduelle.
- Des modèles de simulation ou de ML qui prédisent le comportement et le comparent à la réalité.
Stockez le modèle séparément du flux de données, versionnez-le et référencez-le depuis les topics via des identifiants d'actifs stables. Lorsqu'une machine est remplacée, le modèle change mais le contrat de topics peut rester identique.
Couche 6 : visualisation et applications
La couche supérieure est ce que voient les utilisateurs : tableaux de bord, scènes 3D, applications mobiles et consoles d'alertes. Les visualiseurs 3D dans le navigateur se connectent directement au broker via WebSocket sécurisé, s'abonnent à la branche pertinente, chargent l'état retained à la connexion puis s'animent à mesure que les messages arrivent. Avec MQTT.js, cela tient en quelques lignes :
import mqtt from "mqtt";
const client = mqtt.connect("wss://broker.connectmq.com:8084/mqtt", {
clientId: "twin-viewer-" + Math.random().toString(16).slice(2, 10),
protocolVersion: 5,
});
client.on("connect", () => {
client.subscribe("connectmq/demo/a91c/plant1/#");
});
client.on("message", (topic, payload) => {
const assetPath = topic.split("/").slice(3, -1).join("/");
updateSceneObject(assetPath, JSON.parse(payload.toString()));
});
function updateSceneObject(path, values) {
console.log("update", path, values);
}
Cet exemple se connecte au serveur MQTT public gratuit broker.connectmq.com, réservé aux tests et aux prototypes, jamais aux données de production. En production, utilisez des identifiants limités à la lecture pour les visualiseurs et placez la publication de commandes derrière un backend qui valide les requêtes.
Checklist d'architecture de jumeau numérique
Avant de construire, validez chaque point :
- Hiérarchie de topics définie et documentée, avec des classes télémétrie, état et commande séparées.
- Schéma de payload par type d'actif, incluant unités et horodatage source.
- État retained pour chaque propriété dont un visualiseur a besoin au chargement.
- Messages Last Will pour que les actifs hors ligne apparaissent comme tels.
- Écrivain d'historique découplé du chemin temps réel.
- Modèle d'actifs versionné et indexé par des identifiants stables.
- TLS partout en dehors du réseau de l'usine, identifiants uniques par appareil ou passerelle.
- Chemin de commande avec acquittements et délais d'expiration.
La place de ConnectMQ dans l'architecture
ConnectMQ occupe la couche de messagerie : un broker MQTT cloud compatible MQTT 3.1.1 et 5.0, avec TLS sur le port 8883, WebSocket sécurisé sur le 8084 pour les visualiseurs dans le navigateur, retained messages et abonnements partagés pour faire monter en charge les consommateurs sur les offres payantes. Il détecte aussi les hiérarchies de topics ISA-95 et peut décoder Sparkplug B pour le republier dans des topics ISA-95, ce qui simplifie le contrat entre l'edge et le jumeau. Les stockages d'état, bases d'historique et services de modèle restent vos propres composants, connectés en tant que clients MQTT. La démo de jumeau numérique 3D de ConnectMQ montre la couche de visualisation de cette architecture fonctionnant en temps réel via WSS.
Démarrez votre architecture de jumeau numérique sur ConnectMQ
Inscrivez-vous sur app.connectmq.com, choisissez l'offre Serverless gratuite sans carte bancaire, créez un broker et utilisez les identifiants générés pour connecter votre passerelle edge et votre premier visualiseur. Le client intégré au navigateur et l'explorateur de topics en temps réel vous permettent de valider votre conception de topics avant d'écrire la moindre ligne de code de visualisation.
Questions fréquentes
Quelle est la couche la plus importante d'une architecture de jumeau numérique ?
La couche de messagerie et de contrat de données. Si les topics et les payloads sont bien conçus, toutes les autres couches peuvent être construites, remplacées ou mises à l'échelle indépendamment.
Faut-il une base de données séparée pour l'état du jumeau ?
Pas au début. Les retained messages MQTT peuvent conserver l'état actuel de nombreux jumeaux ; ajoutez un service ou un stockage de jumeau lorsque vous avez besoin de requêtes, d'un contrôle d'accès par actif ou de la gestion de l'état désiré.
Les visualiseurs 3D doivent-ils se connecter directement au broker MQTT ?
Pour des vues en temps réel en lecture seule, la connexion via WebSocket sécurisé est simple et rapide. Faites transiter les commandes par un backend qui les valide et les audite.
Comment une architecture de jumeau numérique gère-t-elle les appareils hors ligne ?
Utilisez les messages Last Will MQTT pour publier un statut hors ligne, mettez les données en tampon à l'edge pendant les coupures et incluez un horodatage source pour que les données tardives soient correctement placées.
