Ein Reifegradmodell für digitale Zwillinge liefert eine gemeinsame Sprache dafür, wo eine Zwillingsinitiative steht und was nötig ist, um voranzukommen. Dieser Leitfaden definiert sechs praxisnahe Stufen, vom statischen Modell bis zur autonomen Regelung im geschlossenen Kreis, und nennt für jede die Fähigkeiten, die Dateninfrastruktur und die MQTT-Muster, die sie erfordert. Mit der Selbsteinschätzung am Ende ordnen Sie Ihr Projekt ein und planen den nächsten Schritt.
Die Grundlagen finden Sie im Leitfaden zur Digital-Twin-Technologie.
Warum ein Reifegradmodell?
Zwillingsprojekte geraten oft ins Stocken, weil die Beteiligten unterschiedliche Zielbilder vor Augen haben. Der Betrieb erwartet ein Live-Dashboard, das Management vorausschauende Wartung, die Konstruktion automatisierte Optimierung. Ein Reifegradmodell macht diese Unterschiede explizit und bringt sie in eine Reihenfolge. Außerdem verhindert es den teuersten Fehler: Analysen der Stufe 4 auf Daten der Stufe 1 aufbauen zu wollen.
Es gibt mehrere veröffentlichte Frameworks mit unterschiedlicher Anzahl und Benennung der Stufen. Die folgende Version ist bewusst praxisorientiert: Jede Stufe wird dadurch definiert, was der Zwilling kann und welche Infrastruktur er braucht, sodass Sie sie mit Ihrem eigenen System abgleichen können.
Die sechs Stufen
| Stufe | Name | Was der Zwilling tut | Beantwortete Kernfrage |
|---|---|---|---|
| 0 | Digitales Modell | Statische Abbildung (CAD, Dokumentation, Nenndaten) | Was wurde konstruiert? |
| 1 | Deskriptiv | Zeigt den Live-Zustand der Assets | Was passiert gerade? |
| 2 | Diagnostisch | Ergänzt Historie, Alarme und Kontext | Warum ist es passiert? |
| 3 | Prädiktiv | Prognostiziert Verhalten aus Daten und Modellen | Was wird passieren? |
| 4 | Präskriptiv | Empfiehlt Maßnahmen mit erwarteten Ergebnissen | Was sollten wir tun? |
| 5 | Autonom | Wirkt innerhalb definierter Leitplanken auf das Asset ein | Kann das System es selbst erledigen? |
Stufe 0: Digitales Modell
Sie haben Geometrie, Zeichnungen, Datenblätter und vielleicht Simulationsmodelle, aber nichts davon ist mit dem laufenden Asset verbunden. Das ist das Fundament, kein Versagen: Das Modell liefert die Struktur (Asset-Namen, Hierarchie, Nennwerte), an die spätere Stufen Daten anhängen.
Infrastruktur: Dokumentenmanagement und CAD. Nächster Schritt: Einigen Sie sich auf eine Asset-Hierarchie, idealerweise nach den ISA-95-Ebenen (IEC 62264), denn sie wird zu Ihrer Topic-Struktur. Genau das ist der Kern eines Unified Namespace (UNS): Enterprise → Site → Area → Line → Cell wird auf dem MQTT-Broker zum Topic-Pfad, etwa acme/werk-stuttgart/montage/linie-1/zelle-3/temperatur, und alle späteren Stufen hängen ihre Daten an diese eine Struktur. Hintergründe liefert Sparkplug B und Unified Namespace.
Stufe 1: Deskriptiver Zwilling
Live-Daten fließen automatisch von den Assets in den Zwilling, der den aktuellen Zustand zeigt: läuft oder steht, wichtige Werte, Alarme. Häufig ist das eine 3D-Ansicht oder ein Dashboard, das tatsächlich genutzt wird.
Infrastruktur: Edge-Gateways, die SPS oder Sensoren auslesen, ein MQTT-Broker und ein Viewer. Die zentralen MQTT-Muster sind:
- Eine konsistente, an ISA-95 ausgerichtete UNS-Topic-Hierarchie, zum Beispiel
site/area/line/cell/asset/state. - Retained Messages für den Zustand, damit Viewer aktuelle Werte sofort beim Verbinden anzeigen.
- Last-Will-Nachrichten, damit der Zwilling erfährt, wenn ein Gateway offline geht.
# Gateway registriert einen retained Last Will, damit der Zwilling erfährt, wenn es offline geht
mosquitto_sub -h broker.connectmq.com -p 1883 -i dtm-6r2-gw \
--will-topic "connectmq/demo/dtm-6r2/site1/line1/status" --will-payload offline \
--will-retain --will-qos 1 -t "connectmq/demo/dtm-6r2/site1/line1/cmd/#"
Prototypen dieser Stufe können Sie auf dem kostenlosen öffentlichen MQTT-Broker mit Demodaten bauen; er ist für Tests und Prototypen gedacht, nicht für Produktionsdaten. Der digitale Zwilling eines Roboterarms ist ein vollständiges Beispiel für Stufe 1 mit 3D-Ansicht.
Stufe 2: Diagnostischer Zwilling
Der Zwilling hat jetzt ein Gedächtnis. Dank Zeitreihenhistorie können Ingenieure zum Zeitpunkt eines Fehlers zurückblättern, Signale korrelieren und Schichten vergleichen. Grenzwertalarme benachrichtigen Personen, wenn Werte ihren Normalbereich verlassen, und Kontext wie Auftrag, Rezept oder Bediener wird an die Daten angehängt.
Infrastruktur: ein Historian oder eine Zeitreihendatenbank, gespeist von einem MQTT-Subscriber, Alarmregeln sowie Kontext aus MES oder ERP, der in denselben Unified Namespace publiziert wird. Datenqualität wird nun wichtig: Zeitstempel an der Quelle, Einheiten in den Payloads und Erkennung veralteter Daten.
Hier ein kleiner Subscriber, der jede Zustandsnachricht zur Diagnose in eine lokale SQLite-Datei schreibt. In der Produktion würden Sie eine richtige Zeitreihendatenbank verwenden, doch das Muster ist identisch.
import json
import sqlite3
import time
import paho.mqtt.client as mqtt
ROOT = "connectmq/demo/dtm-6r2"
db = sqlite3.connect("history.db", check_same_thread=False)
db.execute("CREATE TABLE IF NOT EXISTS samples (ts REAL, topic TEXT, payload TEXT)")
def on_connect(client, userdata, flags, reason_code, properties):
client.subscribe(f"{ROOT}/#", qos=1)
def on_message(client, userdata, msg):
try:
json.loads(msg.payload)
except ValueError:
return # Nicht-JSON-Nachrichten wie Status-Strings überspringen
db.execute("INSERT INTO samples VALUES (?, ?, ?)",
(time.time(), msg.topic, msg.payload.decode()))
db.commit()
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="dtm-6r2-historian")
client.on_connect = on_connect
client.on_message = on_message
client.connect("broker.connectmq.com", 1883)
client.loop_forever()
Für Alarme auf dieser Stufe brauchen Sie unter Umständen gar keinen Code: Das ConnectMQ-Portal enthält Grenzwert-Alarmregeln und ein Alarmprotokoll, was die übliche Anforderung „Sag mir Bescheid, wenn die Temperatur X überschreitet" in der frühen Einführungsphase abdeckt.
Stufe 3: Prädiktiver Zwilling
Mit genügend sauberer Historie erstellt der Zwilling Prognosen: Restlebensdauer einer Komponente, wahrscheinliche Qualitätsabweichungen, Energiebedarf der nächsten Schicht. Die Modelle können physikbasiert, datengetrieben oder hybrid sein.
Infrastruktur: Merkmalsextraktion an der Edge für hochfrequente Signale, eine Datenplattform zum Trainieren der Modelle und ein Inferenzdienst, der Live-Daten abonniert und Prognosen auf eigenen Topics in den Namespace zurückpubliziert, zum Beispiel .../pump104/predictions/rul. Prognosen auf separaten Topics zu halten verhindert, dass jemand sie mit Messwerten verwechselt. Der Leitfaden zur vorausschauenden Wartung mit digitalen Zwillingen geht auf die Modellwahl ein.
Auf dieser Stufe schmerzen Datenlücken am meisten. Modelle, die auf einer Historie mit fehlenden Intervallen oder inkonsistenten Einheiten trainiert wurden, liefern schlechte Ergebnisse, weshalb sich die Disziplin aus Stufe 2 auszahlt.
Stufe 4: Präskriptiver Zwilling
Der Zwilling empfiehlt Maßnahmen und schätzt deren Wirkung ab: die Linie um einen bestimmten Betrag verlangsamen, um ein verschlissenes Lager bis zum geplanten Stillstand zu schonen, einen Sollwert ändern, um Ausschuss zu reduzieren, einen Auftrag umplanen. Menschen geben weiterhin frei und führen aus.
Infrastruktur: Was-wäre-wenn-Simulation auf Basis des Live-Zustands, Optimierungslogik und ein Workflow für Empfehlungen und Freigaben. In MQTT-Begriffen werden Empfehlungen auf Topics publiziert, die eine Bedienoberfläche abonniert, und Freigaben erzeugen Befehle, was ganz natürlich zu Stufe 5 führt.
Stufe 5: Autonomer Zwilling
Der Zwilling wirkt innerhalb definierter Leitplanken direkt auf das Asset ein und schließt so den Regelkreis. Der typische Umfang ist eng und gut verstanden: einen Sollwert innerhalb eines Bandes nachführen, Pumpen energieeffizient zu- und abschalten, Arbeit zwischen parallelen Maschinen umverteilen.
Infrastruktur: Befehls-Topics, die von Gateways konsumiert werden, die jede Anfrage gegen Grenzwerte und Verriegelungen prüfen, Bestätigungen, die melden, was tatsächlich umgesetzt wurde, Message Expiry, damit verspätete Befehle verworfen werden, und eine lückenlose Audit-Protokollierung. Sicherheitsfunktionen bleiben immer in der SPS und im Sicherheitssystem, niemals im Zwilling.
{
"id": "cmd-2026-10-16-0042",
"issued_by": "energy-optimizer",
"target": "site1/utilities/cooling/pump104",
"setpoint": { "rpm": 1350 },
"valid_for_s": 30,
"reason": "chiller load low, reduce pump speed within approved band"
}
MQTT 5 hilft hier mit Message Expiry, Response Topics und Correlation Data für Request/Response; der Leitfaden zu den MQTT-5-Funktionen erklärt sie.
Infrastruktur je Stufe
| Fähigkeit | S1 | S2 | S3 | S4 | S5 |
|---|---|---|---|---|---|
| Topic-Hierarchie und Retained State | Erforderlich | Erforderlich | Erforderlich | Erforderlich | Erforderlich |
| TLS und Zugangsdaten pro Client | Empfohlen | Erforderlich | Erforderlich | Erforderlich | Erforderlich |
| Zeitreihenhistorie | Optional | Erforderlich | Erforderlich | Erforderlich | Erforderlich |
| Alarme und Kontextdaten | Optional | Erforderlich | Erforderlich | Erforderlich | Erforderlich |
| Merkmalsextraktion an der Edge | Optional | Optional | Oft erforderlich | Oft erforderlich | Oft erforderlich |
| Prognose- und Simulationsdienste | Nein | Nein | Erforderlich | Erforderlich | Erforderlich |
| Befehls-Topics mit Bestätigungen | Nein | Nein | Nein | Für freigegebene Maßnahmen | Erforderlich |
| Audit-Protokollierung von Befehlen | Nein | Nein | Nein | Erforderlich | Erforderlich |
Checkliste zur Selbsteinschätzung
Vergeben Sie einen Punkt für jede Aussage, die heute zutrifft:
- Jedes Asset im Scope hat eine eindeutige, hierarchische Kennung, die in Topics verwendet wird.
- Der Live-Zustand erreicht den Zwilling automatisch und wird für neue Viewer vorgehalten (retained).
- Der Zwilling zeigt an, wenn Daten veraltet sind oder ein Gateway offline ist.
- Mindestens drei Monate saubere Historie sind mit Quellzeitstempeln und Einheiten gespeichert.
- Alarme erreichen die richtigen Personen und werden protokolliert.
- Prognosen werden getrennt von Messwerten publiziert und mit der Realität abgeglichen.
- Empfehlungen enthalten ihre erwartete Wirkung und einen Freigabenachweis.
- Befehle werden validiert, bestätigt, verfallen bei Verspätung und werden vollständig auditiert.
Null bis zwei Punkte deuten auf Stufe 1 hin; drei bis fünf auf Stufe 2; sechs auf Stufe 3; sieben auf Stufe 4; alle acht bedeuten, dass Sie für ausgewählte Anwendungsfälle der Stufe 5 bereit sind. Steigen Sie jeweils nur eine Stufe auf und nur für Anwendungsfälle mit klarem Nutzen. Der Leitfaden zum ROI digitaler Zwillinge hilft bei der Auswahl.
Das Rückgrat auf jeder Stufe
Jede Stufe ab 1 läuft auf demselben Messaging-Rückgrat, und dessen Anforderungen wachsen mit jedem Schritt: mehr Clients, strengere Sicherheit, Befehle, die nicht verloren gehen dürfen. Starten Sie mit einem verwalteten MQTT-Broker, damit das Rückgrat schon für die Disziplin der Stufe 5 gerüstet ist, während Sie sich noch auf Stufe 1 befinden. ConnectMQ unterstützt MQTT-5-Funktionen wie Message Expiry und Response Topics, TLS- und Secure-WebSocket-Endpunkte, an Client IDs gebundene Zugangsdaten sowie eine ISA-95-Geräteansicht, die die Hierarchie aus Stufe 0 im Portal sichtbar macht.
Erklimmen Sie die Reifegradstufen mit ConnectMQ
Bringen Sie Stufe 1 auf einem soliden Broker zum Laufen, und jede weitere Stufe wird zur Ergänzung statt zum Neubau. Starten Sie kostenlos mit ConnectMQ im Serverless-Plan, ganz ohne Kreditkarte.
Häufig gestellte Fragen
Was ist ein Reifegradmodell für digitale Zwillinge?
Es ist ein Framework, das die Entwicklungsstufen eines Zwillings beschreibt, von statischen Modellen über Live-Monitoring und Prognose bis zur autonomen Regelung, zusammen mit den Anforderungen jeder Stufe.
Welche Reifegradstufe sollten wir anstreben?
Streben Sie die niedrigste Stufe an, die den benötigten Nutzen liefert. Viele Organisationen erzielen den Großteil ihres Nutzens mit den Stufen 1 und 2 und ergänzen dann Prognosen für bestimmte kritische Assets.
Können wir Stufen überspringen?
Selten. Prädiktive und präskriptive Zwillinge hängen von den sauberen Live-Daten und der Historie ab, die auf den Stufen 1 und 2 aufgebaut werden; wer überspringt, muss in der Regel später neu bauen.
Ist autonome Regelung sicher?
Sie kann es sein, wenn der Umfang eng ist, Maßnahmen durch validierte Grenzwerte begrenzt sind, Befehle bestätigt und auditiert werden und Sicherheitsfunktionen in der Steuerung und im Sicherheitssystem verbleiben.
