Alternatives à Azure Digital Twins : options managées, open source et basées sur MQTT

Si vous cherchez une alternative à Azure Digital Twins, c'est probablement que l'idée d'un graphe de jumeaux modélisé et interrogeable vous plaît, mais que vous souhaitez davantage de portabilité, une stack plus simple ou un déploiement qui ne dépende pas d'un seul cloud. Cet article compare les grandes familles d'alternatives : les autres services managés, les plateformes de jumeau open source et les stacks maison construites sur MQTT standard. Vous verrez aussi du code fonctionnel pour un graphe de jumeaux minimal alimenté par MQTT, afin de juger par vous-même la voie du fait maison.

Le concept est nouveau pour vous ? Le guide de la technologie du jumeau numérique en explique les fondamentaux.

Ce qu'Azure Digital Twins fournit réellement

Avant de comparer, il est utile de savoir précisément ce que vous remplaceriez. Azure Digital Twins est un service de plateforme destiné à modéliser des environnements. Ses principales briques sont :

• Les modèles DTDL : des définitions basées sur JSON-LD des types de jumeaux, de leurs propriétés, de leur télémétrie, de leurs composants et de leurs relations.
• Un graphe de jumeaux : des instances de ces modèles reliées par des relations, comme un étage qui contient des pièces qui contiennent des capteurs.
• Un langage de requête pour parcourir et filtrer le graphe.
• Des routes d'événements qui envoient les changements des jumeaux vers d'autres services Azure pour un traitement en aval.

Notamment, ce n'est pas là qu'arrivent les données des appareils. Les messages des appareils atterrissent généralement d'abord dans un service d'ingestion, et vous écrivez du code de liaison, souvent une fonction serverless, pour mettre à jour les propriétés des jumeaux. Vous apportez aussi votre propre stockage pour l'historique, votre propre visualisation et vos propres analyses. Autrement dit, c'est une couche d'une solution de jumeau, pas la solution entière.

Ce cadrage est important. La plupart des alternatives remplacent la couche de modélisation et de graphe, tandis que les couches d'ingestion, d'historique et de visualisation sont nécessaires dans toute architecture.

Pourquoi les équipes cherchent des alternatives

Les motivations que nous entendons le plus souvent sont pratiques plutôt qu'idéologiques :

1. La portabilité. Les sites tournent sur différents clouds ou sur site, et le jumeau doit fonctionner partout.
2. Les protocoles standard. Les équipes veulent que les appareils et les passerelles parlent MQTT tout simplement, plutôt qu'un SDK propre à un cloud.
3. La simplicité. De nombreux projets ont besoin d'un état en direct et d'une hiérarchie, pas d'un moteur complet de requêtes sur graphe. Plusieurs services managés assemblés peuvent être lourds pour cela.
4. Les standards industriels. Les industriels peuvent préférer l'Asset Administration Shell ou les structures ISA-95 au DTDL.
5. Les compétences et la prévisibilité des coûts. Les petites équipes préfèrent des composants qu'elles peuvent exploiter, inspecter et comprendre.

Comparaison des alternatives

La comparaison des outils open source de jumeau numérique approfondit Ditto, BaSyx et la partie visualisation, et le guide de l'Asset Administration Shell détaille la modélisation AAS.

L'approche native MQTT en pratique

L'alternative la plus légère fait de la hiérarchie de topics MQTT elle-même la colonne vertébrale du jumeau. Dans un Unified Namespace, chaque actif publie son état sur un topic qui encode sa position : site/area/line/cell/asset. La hiérarchie vous donne gratuitement les relations de contenance, les messages retenus vous donnent gratuitement l'état actuel, et les caractères génériques vous donnent des requêtes du type « tout ce qui se trouve sur la ligne 2 ».

Vous n'ajoutez ensuite que ce que la hiérarchie ne peut pas exprimer : des modèles typés, des liens transversaux comme « la pompe 104 alimente la cuve 3 » et l'historique.

Voici un service minimal de graphe de jumeaux en Python. Il s'abonne à un espace de noms, construit un arbre de jumeaux à partir des chemins de topics, stocke le dernier état de chacun et prend en charge une requête simple. Exécutez-le sur le serveur MQTT public gratuit avec votre propre préfixe aléatoire, uniquement avec des données de test.

import json
import threading

import paho.mqtt.client as mqtt

ROOT = "connectmq/demo/adt-5m1"
twins = {}  # chemin -> {"state": {...}, "children": set()}
lock = threading.Lock()


def upsert(path, state):
    parts = path.split("/")
    with lock:
        for i in range(1, len(parts) + 1):
            node = "/".join(parts[:i])
            twins.setdefault(node, {"state": {}, "children": set()})
            if i > 1:
                twins["/".join(parts[:i - 1])]["children"].add(node)
        twins[path]["state"].update(state)


def query(prefix, predicate):
    with lock:
        return {p: t["state"] for p, t in twins.items()
                if p.startswith(prefix) and t["state"] and predicate(t["state"])}


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


def on_message(client, userdata, msg):
    path = msg.topic[len(ROOT) + 1:-len("/state")]
    upsert(path, json.loads(msg.payload))


client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="adt-5m1-graph")
client.on_connect = on_connect
client.on_message = on_message
client.connect("broker.connectmq.com", 1883)
client.loop_start()

input("Publish some states, then press Enter to query...\n")
hot = query("site1/assembly", lambda s: s.get("temp_c", 0) > 70)
print(json.dumps(hot, indent=2))
print("Children of site1/assembly:", sorted(twins.get("site1/assembly", {}).get("children", [])))
client.loop_stop()

Alimentez-le avec quelques états :

mosquitto_pub -h broker.connectmq.com -p 1883 -i adt-5m1-a -r -q 1 \
  -t "connectmq/demo/adt-5m1/site1/assembly/line2/robot3/state" -m '{"temp_c":74,"mode":"auto"}'
mosquitto_pub -h broker.connectmq.com -p 1883 -i adt-5m1-b -r -q 1 \
  -t "connectmq/demo/adt-5m1/site1/assembly/line2/press1/state" -m '{"temp_c":51,"mode":"auto"}'

Comme les deux messages sont retenus, le service de graphe reconstruit l'état actuel de chaque jumeau dès sa connexion, sans base de données séparée. C'est le cœur de ce que fait un service de graphe de jumeaux, en une quarantaine de lignes. En production, vous ajouteriez un registre de modèles (des fichiers DTDL ou JSON Schema décrivant chaque type d'actif), conserveriez l'historique dans une base de séries temporelles et exposeriez la requête via une API.

Si vous avez déjà des modèles DTDL issus d'un projet Azure, inutile de les jeter. DTDL est une spécification ouverte : vous pouvez conserver les fichiers d'interface comme documentation et schémas de validation, et associer la télémétrie et les propriétés de chaque modèle à des topics. Le guide DTDL montre comment.

Ce que vous perdez et ce que vous gagnez

Soyez lucide sur les compromis avant de changer.

Vous perdez un moteur de requêtes de graphe managé, la validation de modèles intégrée et l'intégration avec le reste de l'écosystème Azure. Si votre organisation fait tout tourner sur Azure et a besoin de requêtes de graphe complexes à plusieurs sauts sur de nombreuses entités, rester peut être la bonne réponse.

Vous gagnez un jumeau qui fonctionne partout où MQTT fonctionne, c'est-à-dire pratiquement partout : passerelles d'automates, cartes ESP32, Node-RED, Python, navigateurs via WebSocket. Chaque consommateur lit les mêmes données en direct. L'architecture est facile à expliquer, et chaque couche, du broker au stockage en passant par la 3D, peut être remplacée indépendamment.

Une voie médiane raisonnable est fréquente : conserver l'espace de noms MQTT comme système de référence pour l'état en direct, et le projeter dans l'outil de graphe ou d'AAS dont une application donnée a besoin.

Check-list de migration

1. Inventoriez vos modèles DTDL et vos instances de jumeaux, et notez quelles relations sont hiérarchiques et lesquelles sont des liens transversaux.
2. Concevez une hiérarchie de topics qui reflète les relations hiérarchiques, en suivant les niveaux ISA-95 lorsque c'est possible.
3. Faites pointer les passerelles vers un broker MQTT et publiez l'état sous forme de messages retenus, la télémétrie sous forme de messages non retenus.
4. Remplacez les routes d'événements par des abonnés MQTT : un écrivain pour l'historien, un service d'alertes, une visionneuse 3D.
5. Stockez les liens transversaux et les métadonnées des modèles dans un petit service de registre ou un dépôt de configuration.
6. Faites fonctionner l'ancien et le nouveau circuit en parallèle pendant quelques semaines et comparez les états avant de basculer les consommateurs.

Choisir le broker

Dans un jumeau natif MQTT, le broker est le seul composant dont tout dépend : ce ne doit donc pas être un serveur bricolé sous le bureau de quelqu'un. Un broker MQTT managé vous apporte des points d'accès TLS, l'authentification et la capacité sans avoir à exploiter l'infrastructure.

ConnectMQ prend en charge MQTT 3.1.1 et 5.0, TCP et TLS pour les passerelles, WebSocket et WebSocket sécurisé pour les jumeaux dans le navigateur, et détecte les topics ISA-95 et Unified Namespace dans son portail, en affichant les appareils par niveau de hiérarchie. Il ne cherche pas à être lui-même une plateforme de jumeau : vous connectez votre service de graphe, votre historien et vos visionneuses comme des clients MQTT ordinaires, ce qui garde l'architecture portable. Si vous avez besoin du broker dans votre propre compte cloud, le plan BYOC l'y fait tourner, géré par ConnectMQ.

Construisez un jumeau portable sur ConnectMQ

Commencez par l'espace de noms : publiez l'état retenu de quelques actifs et connectez une visionneuse et un service de graphe. Créez un broker ConnectMQ Serverless gratuit, sans carte bancaire, et vous disposerez en quelques minutes d'une base portable pour votre jumeau.

Questions fréquentes

Quelle est la meilleure alternative à Azure Digital Twins ?

Cela dépend de vos besoins. Eclipse Ditto convient aux jumeaux centrés sur les appareils avec API, Eclipse BaSyx aux projets Asset Administration Shell, et une stack native MQTT aux équipes qui veulent un état en direct portable avec un minimum d'infrastructure.

Peut-on réutiliser ses modèles DTDL ailleurs ?

Oui. DTDL est une spécification ouverte : les fichiers restent utiles comme schémas et comme documentation. Vous pouvez associer télémétrie et propriétés à des topics MQTT et valider les payloads par rapport à eux.

Faut-il une base de données orientée graphe pour un jumeau numérique ?

Pas toujours. Une hiérarchie de topics couvre les relations de contenance, et les messages retenus couvrent l'état actuel. N'ajoutez un stockage de graphe que si vous avez besoin de requêtes complexes sur de nombreuses entités liées entre elles.

MQTT suffit-il pour un jumeau en production ?

MQTT gère la distribution des données en direct. Un jumeau en production a aussi besoin d'un stockage de l'historique, d'un registre de modèles et d'une visualisation, qui se connectent au broker en tant que clients MQTT.