Eine klare Architektur unterscheidet einen digitalen Zwilling, der auf Hunderte Assets skaliert, von einer Demo, die nach den ersten fünf zusammenbricht. Dieser Leitfaden geht Schicht für Schicht durch eine Referenzarchitektur, von Sensoren und Edge-Gateways über ein Messaging-Rückgrat bis zu Zustandsspeichern, Modellen und 3D-Visualisierung, damit Sie einen Stack entwerfen können, in dem jeder Teil genau eine Aufgabe hat und unabhängig austauschbar ist.
Die Konzepte hinter Zwillingen erklärt unser Leitfaden zur Digital-Twin-Technologie.
Die sechs Schichten einer Architektur für digitale Zwillinge
Die meisten erfolgreichen Zwillinge landen, unabhängig von Anbieter oder Framework, bei diesen Schichten:
| Schicht | Verantwortung | Typische Technologie |
|---|---|---|
| 1. Gerät und Edge | Sensoren und Steuerungen auslesen, normalisieren, puffern | SPS, ESP32, Raspberry Pi, Edge-Gateways |
| 2. Messaging | Daten und Befehle in Echtzeit transportieren, Produzenten und Konsumenten entkoppeln | MQTT-Broker als Unified Namespace (UNS) |
| 3. Zustand | Den aktuellen Wert jeder Eigenschaft vorhalten | Retained Topics, Key-Value-Store, Zwillingsdienst |
| 4. Historie | Zeitreihen für Trends und Analysen speichern | Zeitreihendatenbank |
| 5. Modell | Assets, Beziehungen, Einheiten und Verhalten beschreiben | Asset-Hierarchie, DTDL, AAS, physikalische oder ML-Modelle |
| 6. Visualisierung und Anwendungen | Den Zwilling anzeigen und darauf reagieren | Dashboards, 3D-Web-Viewer, mobile Apps |
Die zentrale Designregel: Schichten kommunizieren über klar definierte Verträge (Topics und Payload-Schemas), niemals über private Abkürzungen. Genau das ermöglicht es, ein Dashboard gegen einen 3D-Viewer zu tauschen oder einen Analysejob zu ergänzen, ohne die Geräte-Firmware anzufassen.
Schicht 1: Gerät und Edge
Physische Assets sprechen selten eine zwillingsfreundliche Sprache. Eine CNC-Steuerung stellt OPC UA oder ein Herstellerprotokoll bereit; eine alte Pumpe liefert ein 4–20-mA-Signal an eine SPS; ein neuer Sensor läuft vielleicht auf einem ESP32. Die Edge-Schicht überbrückt diese Lücke.
Aufgaben an der Edge:
- Protokollübersetzung von Modbus, OPC UA oder Feldbus nach MQTT.
- Normalisierung auf einheitliche Einheiten und Namen, damit
spindle_rpmüberall dasselbe bedeutet. - Totband- und Ratensteuerung, sodass ein Wert nur bei relevanter Änderung oder in festem Intervall publiziert wird.
- Pufferung bei Ausfall der Uplink-Verbindung und anschließendes Nachsenden mit den ursprünglichen Zeitstempeln.
Setzen Sie Zeitstempel an der Quelle. Ein Zwilling, der nur weiß, wann der Broker einen Wert empfangen hat, kann ein langsames Netzwerk nicht von einer langsamen Maschine unterscheiden.
Schicht 2: Das Messaging-Rückgrat
Die Messaging-Schicht ist das Rückgrat der Architektur eines digitalen Zwillings. Jeder Produzent publiziert dorthin und jeder Konsument abonniert von dort, sodass Geräte nie wissen müssen, wer zusieht. Ein MQTT-Broker ist die häufigste Wahl, weil er Folgendes bietet:
- Hierarchische Topics, die die Asset-Hierarchie widerspiegeln.
- Wildcards, sodass ein Viewer auf Linienebene
plant1/line2/#abonniert und jede Maschine erhält. - Retained Messages, die neuen Subscribern sofort den neuesten Zustand liefern.
- QoS-Stufen, um Zustellgarantien gegen Overhead abzuwägen.
- Last-Will-Nachrichten, damit der Zwilling erfährt, wenn ein Gerät verschwindet.
In industriellen Zwillingen ist diese Schicht der UNS: ein zentraler, ereignisgesteuerter Namensraum, in dem jedes Asset genau eine Adresse hat. Seine Struktur liefert ISA-95 (IEC 62264) mit der Anlagenhierarchie Enterprise → Site → Area → Line → Cell, etwa acme/werk-stuttgart/montage/linie-1/zelle-3/temperatur. SPS-Gateways, OPC-UA-Server, MES und ERP publizieren und abonnieren dort, statt Punkt-zu-Punkt-Schnittstellen zu pflegen, und der Zwilling liest einfach den passenden Ast. Wie Sparkplug B in dieses Bild passt, erklärt Sparkplug B und Unified Namespace.
Ein gutes Topic-Design folgt der Hierarchie im ISA-95-Stil und endet mit einer Nachrichtenklasse:
<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
Trennen Sie telemetry (ein Datenstrom, nicht retained), state (aktuelle Werte, retained) und cmd (Befehle, niemals retained). Diese zu vermischen ist die häufigste Fehlerquelle bei Zwillingen, etwa wenn ein veralteter Befehl nach einem Reconnect erneut an ein Gerät ausgeliefert wird. Unser Leitfaden zu digitalen Zwillingen mit MQTT vertieft diese Muster.
Einen Broker selbst zu betreiben bedeutet, sich um TLS-Zertifikate, Authentifizierung, Skalierung und Monitoring zu kümmern. Ein verwalteter MQTT-Broker wie ConnectMQ nimmt Ihnen diese Arbeit ab, damit sich das Team auf den Zwilling selbst konzentrieren kann.
Schicht 3: Zustand
Die Zustandsschicht beantwortet genau eine Frage: Was ist der aktuelle Wert des Assets in diesem Moment? Es gibt drei gängige Optionen:
- Retained MQTT-Topics. Jedes Asset oder jede Eigenschaft hat eine Retained Message. Einfach, keine zusätzliche Infrastruktur, und Viewer erhalten beim Verbinden den vollständigen Zustand. Ausführlich beschrieben in Retained MQTT-Nachrichten als Zustand digitaler Zwillinge.
- Ein Zwillingsdienst. Ein eigener Dienst, etwa Eclipse Ditto oder ein individueller Microservice, abonniert die Telemetrie, pflegt ein JSON-Dokument pro Asset und stellt es per API bereit.
- Ein In-Memory- oder Key-Value-Store, gespeist von einem Subscriber, sinnvoll, wenn viele Anwendungen den Zustand per API statt per MQTT abfragen.
Für viele Teams lautet die richtige Antwort: zuerst Retained Topics, dann ein Zwillingsdienst, sobald Sie Abfragen, Zugriffskontrolle pro Asset oder die Behandlung von Soll- und Ist-Zustand brauchen. Diese Muster beschreibt Zustandssynchronisation digitaler Zwillinge.
Schicht 4: Historie
Der Live-Zustand reicht für Trends, Ursachenanalysen oder Machine Learning nicht aus. Ein Historien-Subscriber hört auf Telemetrie-Topics und schreibt in eine Zeitreihendatenbank. Tools wie Telegraf, Node-RED oder ein kleiner Python-Dienst agieren dabei als normale MQTT-Clients:
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]
# Durch einen Schreibvorgang in Ihre Zeitreihendatenbank ersetzen
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()
Halten Sie Historien-Writer unabhängig vom Live-Pfad. Wenn die Datenbank langsam ist, darf die 3D-Ansicht nicht hinterherhinken.
Schicht 5: Das Modell
Die Modellschicht macht aus Zahlen Bedeutung. Mindestens ist sie ein Asset-Register: welche Assets existieren, wie sie zusammenhängen (Standort enthält Linie enthält Maschine), welche Eigenschaften jedes hat und in welchen Einheiten. Fortgeschrittenere Zwillinge ergänzen:
- Formale Schemas wie DTDL-Interfaces oder Teilmodelle der Verwaltungsschale (AAS), wie sie die Plattform Industrie 4.0 im Kontext von RAMI 4.0 beschreibt.
- Abgeleitete Werte wie OEE, Wirkungsgrad oder Restlebensdauer.
- Simulations- oder ML-Modelle, die Verhalten vorhersagen und mit der Realität vergleichen.
Speichern Sie das Modell getrennt vom Datenstrom, versionieren Sie es und referenzieren Sie es aus den Topics über stabile Asset-IDs. Die ISA-95-Hierarchie des UNS liefert dafür das gemeinsame Gerüst: Modell und Topic-Baum beschreiben dieselben Ebenen. Wird eine Maschine ersetzt, ändert sich das Modell, der Topic-Vertrag kann aber gleich bleiben.
Schicht 6: Visualisierung und Anwendungen
Die oberste Schicht ist das, was Menschen sehen: Dashboards, 3D-Szenen, mobile Apps und Alarmkonsolen. Browserbasierte 3D-Viewer verbinden sich direkt über Secure WebSocket mit dem Broker, abonnieren den relevanten Zweig, laden beim Verbinden den Retained State und animieren dann, sobald Live-Nachrichten eintreffen. Mit MQTT.js sind das nur wenige Zeilen:
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);
}
Verwenden Sie in der Produktion für reine Lese-Viewer entsprechend eingeschränkte Zugangsdaten und legen Sie das Publizieren von Befehlen hinter ein Backend, das Anfragen validiert.
Checkliste für die Architektur digitaler Zwillinge
Bestätigen Sie vor dem Bau jeden Punkt:
- Topic-Hierarchie als UNS nach ISA-95 definiert und dokumentiert, mit getrennten Klassen für Telemetrie, Zustand und Befehle.
- Payload-Schema pro Asset-Typ, einschließlich Einheiten und Quellzeitstempeln.
- Retained State für jede Eigenschaft, die ein Viewer beim Laden braucht.
- Last-Will-Nachrichten, damit Offline-Assets als offline angezeigt werden.
- Historien-Writer vom Live-Pfad entkoppelt.
- Asset-Modell versioniert und über stabile IDs referenziert.
- TLS überall außerhalb des Werksnetzes, eindeutige Zugangsdaten pro Gerät oder Gateway.
- Befehlspfad mit Bestätigungen und Timeouts.
Wo ConnectMQ in die Architektur passt
ConnectMQ übernimmt die Messaging-Schicht: ein Cloud-MQTT-Broker mit MQTT 3.1.1 und 5.0, TLS auf Port 8883, Secure WebSocket auf Port 8084 für Browser-Viewer, Retained Messages und Shared Subscriptions zur Skalierung von Konsumenten in den kostenpflichtigen Plänen. Außerdem erkennt ConnectMQ ISA-95-Topic-Hierarchien und kann Sparkplug B dekodieren und in ISA-95-Topics republizieren, was den Vertrag zwischen Edge und Zwilling vereinfacht. Zustandsspeicher, Historiendatenbanken und Modelldienste bleiben Ihre eigenen Komponenten, die sich als MQTT-Clients verbinden. Die 3D-Demo eines digitalen Zwillings von ConnectMQ zeigt die Visualisierungsschicht dieser Architektur live über WSS.
Starten Sie Ihre Zwillingsarchitektur auf ConnectMQ
Registrieren Sie sich unter app.connectmq.com, wählen Sie den kostenlosen Serverless-Plan ohne Kreditkarte, erstellen Sie einen Broker und verbinden Sie mit den generierten Zugangsdaten Ihr Edge-Gateway und Ihren ersten Viewer. Mit dem Client im Browser und dem Live-Topic-Explorer validieren Sie Ihr Topic-Design, bevor Sie eine einzige Zeile Visualisierungscode schreiben.
Häufig gestellte Fragen
Welche Schicht ist in der Architektur eines digitalen Zwillings am wichtigsten?
Die Schicht für Messaging und Datenverträge. Wenn Topics und Payloads gut entworfen sind, lässt sich jede andere Schicht unabhängig aufbauen, ersetzen oder skalieren.
Brauche ich eine separate Datenbank für den Zwillingszustand?
Anfangs nicht. Retained MQTT-Nachrichten können den aktuellen Zustand vieler Zwillinge vorhalten; ergänzen Sie einen Zwillingsdienst oder Speicher, wenn Sie Abfragen, Zugriffskontrolle pro Asset oder die Behandlung des Soll-Zustands brauchen.
Sollten sich 3D-Viewer direkt mit dem MQTT-Broker verbinden?
Für reine Live-Ansichten ist eine Verbindung über Secure WebSocket einfach und schnell. Leiten Sie Befehle über ein Backend, das sie validiert und auditiert.
Wie geht die Architektur eines digitalen Zwillings mit Offline-Geräten um?
Nutzen Sie MQTT-Last-Will-Nachrichten, um einen Offline-Status zu publizieren, puffern Sie Daten während Ausfällen an der Edge und fügen Sie Quellzeitstempel hinzu, damit verspätete Daten korrekt eingeordnet werden.
