Alternativen zu Azure Digital Twins: verwaltet, Open Source und MQTT-basiert

Wenn Sie nach einer Azure Digital Twins Alternative suchen, gefällt Ihnen vermutlich die Idee eines modellierten, abfragbaren Zwillingsgraphen, Sie wünschen sich aber mehr Portabilität, einen einfacheren Stack oder ein Deployment, das nicht von einer einzigen Cloud abhängt. Dieser Artikel vergleicht die wichtigsten Gruppen von Alternativen: andere Managed Services, Open-Source-Zwillingsplattformen und Eigenbau-Stacks auf Basis von Standard-MQTT. Außerdem sehen Sie funktionierenden Code für einen minimalen, per MQTT gespeisten Zwillingsgraphen, damit Sie den Eigenbau-Weg selbst beurteilen können.

Neu im Thema? Der Leitfaden zur Digital-Twin-Technologie erklärt die Grundlagen.

Was Azure Digital Twins tatsächlich bietet

Vor dem Vergleich lohnt es sich, genau zu klären, was Sie ersetzen würden. Azure Digital Twins ist ein Plattformdienst zur Modellierung von Umgebungen. Seine wichtigsten Bausteine sind:

• DTDL-Modelle: JSON-LD-basierte Definitionen von Zwillingstypen, ihren Eigenschaften, Telemetrie, Komponenten und Beziehungen.
• Ein Zwillingsgraph: Instanzen dieser Modelle, verbunden durch Beziehungen, etwa ein Stockwerk, das Räume enthält, die wiederum Sensoren enthalten.
• Eine Abfragesprache zum Durchlaufen und Filtern des Graphen.
• Event Routes, die Zwillingsänderungen zur Weiterverarbeitung an andere Azure-Dienste senden.

Bemerkenswert ist, dass Gerätedaten dort nicht ankommen. Gerätenachrichten landen typischerweise zuerst in einem Ingestion-Dienst, und Sie schreiben Verbindungscode, oft eine Serverless-Funktion, um Zwillingseigenschaften zu aktualisieren. Speicherung für die Historie, Visualisierung und Analysen bringen Sie ebenfalls selbst mit. Mit anderen Worten: Es ist eine Schicht einer Zwillingslösung, nicht die ganze.

Diese Einordnung ist wichtig. Die meisten Alternativen ersetzen die Modellierungs- und Graphschicht, während Ingestion, Historie und Visualisierung in jeder Architektur benötigt werden.

Warum Teams nach Alternativen suchen

Die Beweggründe, die wir am häufigsten hören, sind eher praktischer als ideologischer Natur:

1. Portabilität. Standorte laufen in unterschiedlichen Clouds oder On-Premises, und der Zwilling muss überall funktionieren.
2. Standardprotokolle. Teams möchten, dass Geräte und Gateways einfaches MQTT sprechen statt eines cloudspezifischen SDKs.
3. Einfachheit. Viele Projekte brauchen Live-Zustand und eine Hierarchie, keine vollständige Graph-Abfrage-Engine. Mehrere zusammengeklebte Managed Services können dafür schwergewichtig sein.
4. Industriestandards. Hersteller bevorzugen womöglich die Asset Administration Shell oder ISA-95-Strukturen gegenüber DTDL.
5. Kompetenzen und planbare Kosten. Kleine Teams bevorzugen Komponenten, die sie selbst betreiben, untersuchen und nachvollziehen können.

Die Alternativen im Vergleich

Der Vergleich von Open-Source-Digital-Twin-Tools geht tiefer auf Ditto, BaSyx und die Visualisierungsseite ein, und der Leitfaden zur Asset Administration Shell behandelt die AAS-Modellierung im Detail.

Der MQTT-native Ansatz in der Praxis

Die schlankste Alternative behandelt die MQTT-Topic-Hierarchie selbst als Rückgrat des Zwillings. Im UNS veröffentlicht jedes Asset seinen Zustand auf einem Topic, das seine Position kodiert: site/area/line/cell/asset. Die ISA-95-Ebenen Enterprise → Site → Area → Line → Cell werden so direkt zur Topic-Struktur auf dem Broker, etwa acme/werk-stuttgart/montage/linie-2/roboter-3/state. Der Beitrag zu Sparkplug B und Unified Namespace vertieft den Aufbau. Die Hierarchie liefert Ihnen „enthält“-Beziehungen gratis, Retained Messages liefern den aktuellen Zustand gratis, und Wildcards ermöglichen Abfragen wie „alles in Linie 2“.

Ergänzen Sie dann nur, was die Hierarchie nicht ausdrücken kann: typisierte Modelle, Querverweise wie „Pumpe 104 speist Tank 3“ und Historie.

Hier ist ein minimaler Zwillingsgraph-Dienst in Python. Er abonniert einen Namespace, baut aus Topic-Pfaden einen Baum von Zwillingen auf, speichert den jeweils neuesten Zustand und unterstützt eine einfache Abfrage. Führen Sie ihn mit Ihrem eigenen zufälligen Präfix gegen den öffentlichen MQTT-Broker aus, der für Tests und nicht für Produktionsdaten gedacht ist.

import json
import threading

import paho.mqtt.client as mqtt

ROOT = "connectmq/demo/adt-5m1"
twins = {}  # Pfad -> {"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()

Speisen Sie einige Zustände ein:

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"}'

Da beide Nachrichten retained sind, baut der Graph-Dienst den aktuellen Zustand jedes Zwillings sofort nach dem Verbinden wieder auf, ganz ohne separate Datenbank. Das ist der Kern dessen, was ein Zwillingsgraph-Dienst leistet, in etwa vierzig Zeilen. Für die Produktion ergänzen Sie eine Modell-Registry (DTDL- oder JSON-Schema-Dateien, die jeden Asset-Typ beschreiben), speichern die Historie in einer Zeitreihendatenbank und stellen die Abfrage über eine API bereit.

Wenn Sie bereits DTDL-Modelle aus einem Azure-Projekt haben, müssen Sie diese nicht wegwerfen. DTDL ist eine offene Spezifikation; Sie können die Interface-Dateien als Dokumentation und Validierungsschemas behalten und die Telemetrie und Eigenschaften jedes Modells auf Topics abbilden. Wie das geht, zeigt der DTDL-Leitfaden.

Was Sie aufgeben und was Sie gewinnen

Seien Sie vor einem Wechsel ehrlich bei den Abwägungen.

Sie geben auf: eine verwaltete Graph-Abfrage-Engine, integrierte Modellvalidierung und die Integration in das übrige Azure-Ökosystem. Wenn Ihre Organisation alles andere auf Azure betreibt und komplexe Graph-Abfragen über viele Entitäten mit mehreren Sprüngen braucht, kann Bleiben die richtige Antwort sein.

Sie gewinnen: einen Zwilling, der überall funktioniert, wo MQTT funktioniert, also praktisch überall: SPS-Gateways, ESP32-Boards, Node-RED, Python, Browser über WebSocket. Jeder Konsument liest dieselben Live-Daten. Die Architektur ist leicht zu erklären, und jede Schicht, vom Broker über die Speicherung bis zu 3D, lässt sich unabhängig austauschen.

Ein sinnvoller Mittelweg ist verbreitet: Behalten Sie den Unified Namespace als führendes System für den Live-Zustand und projizieren Sie ihn in das Graph- oder AAS-Tool, das eine bestimmte Anwendung benötigt.

Checkliste für die Migration

1. Inventarisieren Sie Ihre DTDL-Modelle und Zwillingsinstanzen und notieren Sie, welche Beziehungen hierarchisch und welche Querverweise sind.
2. Entwerfen Sie eine Topic-Hierarchie, die die hierarchischen Beziehungen abbildet, nach Möglichkeit entlang der ISA-95-Ebenen.
3. Richten Sie Gateways auf einen MQTT-Broker aus und veröffentlichen Sie Zustand als Retained Messages, Telemetrie als nicht retained.
4. Ersetzen Sie Event Routes durch MQTT-Subscriber: einen Historian-Writer, einen Alarmdienst, einen 3D-Viewer.
5. Speichern Sie Querverweise und Modell-Metadaten in einem kleinen Registry-Dienst oder Konfigurations-Repository.
6. Betreiben Sie alten und neuen Pfad einige Wochen parallel und vergleichen Sie den Zustand, bevor Sie Konsumenten umstellen.

Den Broker auswählen

In einem MQTT-nativen Zwilling ist der Broker die eine Komponente, von der alles abhängt; er sollte also kein Hobby-Server unter jemandes Schreibtisch sein. Ein verwalteter MQTT-Broker bietet Ihnen TLS-Endpunkte, Authentifizierung und Kapazität, ohne dass Sie die Infrastruktur betreiben.

ConnectMQ unterstützt MQTT 3.1.1 und 5.0, TCP und TLS für Gateways, WebSocket und Secure WebSocket für Browser-Zwillinge und erkennt im Portal ISA-95- und Unified-Namespace-Topics, wobei Geräte nach Hierarchieebene angezeigt werden. Es versucht nicht, selbst eine Zwillingsplattform zu sein; Sie binden Ihren Graph-Dienst, Historian und Ihre Viewer als gewöhnliche MQTT-Clients an, was die Architektur portabel hält. Wenn Sie den Broker in Ihrem eigenen Cloud-Konto brauchen, betreibt ihn der BYOC-Plan dort, verwaltet von ConnectMQ.

Bauen Sie einen portablen Zwilling auf ConnectMQ

Beginnen Sie mit dem Namespace: Veröffentlichen Sie retained Zustände für eine Handvoll Assets und verbinden Sie einen Viewer und einen Graph-Dienst. Erstellen Sie einen kostenlosen ConnectMQ-Serverless-Broker, ohne Kreditkarte, und Sie haben in wenigen Minuten eine portable Grundlage für Ihren Zwilling.

Häufig gestellte Fragen

Was ist die beste Alternative zu Azure Digital Twins?

Das hängt von Ihren Anforderungen ab. Eclipse Ditto eignet sich für gerätezentrierte Zwillinge mit APIs, Eclipse BaSyx für Projekte mit der Asset Administration Shell und ein MQTT-nativer Stack für Teams, die portablen Live-Zustand mit minimaler Infrastruktur wollen.

Kann ich meine DTDL-Modelle anderswo wiederverwenden?

Ja. DTDL ist eine offene Spezifikation, daher bleiben die Dateien als Schemas und Dokumentation nützlich. Sie können Telemetrie und Eigenschaften auf MQTT-Topics abbilden und Payloads dagegen validieren.

Brauche ich eine Graphdatenbank für einen digitalen Zwilling?

Nicht immer. Eine an ISA-95 ausgerichtete Topic-Hierarchie im UNS deckt Enthaltensein-Beziehungen ab, und Retained Messages decken den aktuellen Zustand ab. Ergänzen Sie einen Graphspeicher nur, wenn Sie komplexe Abfragen über viele querverknüpfte Entitäten brauchen.

Reicht MQTT für einen produktiven Zwilling aus?

MQTT übernimmt die Verteilung der Live-Daten. Ein produktiver Zwilling braucht zusätzlich Historienspeicher, eine Modell-Registry und Visualisierung, die sich als MQTT-Clients mit dem Broker verbinden.