Digitaler Zwilling vs. Simulation: Die Unterschiede

Die Frage „digitaler Zwilling vs. Simulation“ kommt in fast jedem Industrieprojekt früh auf, denn beide gehen von einem Modell eines physischen Objekts aus und sehen auf dem Bildschirm oft ähnlich aus. Dieser Artikel erklärt die Unterschiede, die wirklich zählen: woher die Daten kommen, wie lange das Modell lebt und ob Ergebnisse zum realen Asset zurückfließen. Am Ende wissen Sie, was Ihr Anwendungsfall braucht und wie Sie Live-Daten per MQTT anbinden, damit aus einem Modell ein Zwilling wird.

Den vollständigen Hintergrund zu Zwillingen liefert der Leitfaden zur Digital-Twin-Technologie.

Die kurze Antwort

Eine Simulation ist ein Modell, das Sie ausführen, um eine Frage dazu zu beantworten, was passieren könnte. Sie füttern es mit Annahmen, Szenarien oder historischen Eingaben, lassen es laufen, lesen die Ergebnisse und schließen es meist wieder.

Ein digitaler Zwilling ist ein Modell, das an ein bestimmtes physisches Asset gebunden ist und kontinuierlich anhand von Live-Daten dieses Assets verfolgt, was gerade passiert. Er lebt so lange wie das Asset und wird bei jeder Änderung des Assets aktualisiert.

Vereinfacht gesagt ist eine Simulation eine Tätigkeit, ein digitaler Zwilling dagegen eine dauerhafte, verbundene Repräsentation. Viele Zwillinge enthalten Simulationsmodelle – und genau dort beginnt die Verwirrung.

Digitaler Zwilling vs. Simulation im direkten Vergleich

Dimension	Simulation	Digitaler Zwilling
Datenquelle	Annahmen, Szenarien, historische Datensätze	Live-Telemetrie eines bestimmten Assets plus Historie
Gegenstand	Ein Entwurf oder eine Klasse von Systemen	Eine identifizierbare Instanz, etwa Pumpe P-104
Lebensdauer	Läuft für die Dauer einer Studie	Besteht über die gesamte Lebensdauer des Assets
Zeit	Kann schneller oder langsamer als Echtzeit laufen	Folgt der Echtzeit, kann in What-if-Läufe verzweigen
Rückkopplung zum Asset	Keine	Optional: Erkenntnisse oder Befehle fließen zurück
Typische Verantwortung	Engineering, F&E	Betrieb, Instandhaltung und Engineering gemeinsam
Zentrale Infrastruktur	Solver, Rechenleistung	Konnektivität, Messaging, Speicherung, Visualisierung
Leitfrage	„Was passiert, wenn ...?“	„Was passiert gerade, und was sollten wir tun?“

Die Zeilen zu Datenquelle und Gegenstand leisten die meiste Arbeit. Ist Ihr Modell nicht an eine bestimmte Seriennummer gebunden und erhält es keine Daten von ihr, handelt es sich um eine Simulation, so realistisch sie auch aussieht.

Was Live-Daten verändern

Ein Modell mit Live-Daten zu verbinden, hat Folgen, die über ein sich bewegendes Diagramm hinausgehen.

Das Modell muss identifizierbar sein. Ein Zwilling braucht eine Adresse: welche Linie, welche Maschine, welcher Sensor. Deshalb setzen Industrieteams auf einen Unified Namespace (UNS): eine zentrale Topic-Struktur auf dem MQTT-Broker, die den ISA-95-Ebenen folgt (Unternehmen, Standort, Bereich, Linie, Zelle). Ein Topic wie acme/werk-hamburg/verpackung/linie-2/fueller/telemetry benennt genau, zu welchem Füller die Daten gehören, und MES, SCADA, Zwilling und Simulation finden sie an derselben Stelle. Mehr dazu unter Sparkplug B und Unified Namespace.

Das Modell muss mit unvollkommenen Daten umgehen. Simulationen erhalten saubere Eingaben. Zwillinge erhalten verspätete Nachrichten, Sensorausfälle, sich neu verbindende Gateways und Uhrendrift. Gute Zwillinge verfolgen Datenqualität und Zeitstempel des letzten Kontakts und zeigen „veraltet“ an, statt so zu tun, als sei ein Wert aktuell.

Das Modell driftet und muss nachkalibriert werden. Weil laufend reale Messwerte eintreffen, können Sie Vorhersagen mit der Realität vergleichen. Wächst die Abweichung, hat sich entweder das Asset verändert (Verschleiß, Verschmutzung, ein neues Werkzeug) oder das Modell muss nachjustiert werden. Dieser Vergleich gehört zu den wertvollsten Leistungen eines Zwillings, und eine eigenständige Simulation kann ihn nicht leisten.

Der Zustand muss sofort verfügbar sein. Wenn ein Dashboard geöffnet wird, braucht es den aktuellen Zustand, nicht das nächste Update in fünf Minuten. MQTT Retained Messages lösen das elegant: Der Broker speichert die letzte Nachricht eines Topics und liefert sie jedem neuen Subscriber sofort aus.

Wie MQTT einen Zwilling synchron hält

MQTT ist die gängige Wahl zur Versorgung von Zwillingen, weil es nach dem Publish/Subscribe-Prinzip arbeitet, leichtgewichtig und ereignisgesteuert ist. Das Asset oder sein Gateway veröffentlicht einmal, und jeder Konsument – von der 3D-Ansicht über den Historian bis zur Simulations-Engine – abonniert, was er braucht. Wenn Ihnen das Muster neu ist, lesen Sie, was ein MQTT-Broker macht.

Die Mechanik sehen Sie in einer Minute mit dem kostenlosen öffentlichen MQTT-Broker unter broker.connectmq.com, der für Tests und Prototypen gedacht ist, nicht für Produktionsdaten. Verwenden Sie statt dts-91x ein eigenes zufälliges Präfix.

# Den aktuellen Zustand einer Pumpe als Retained Message veröffentlichen
mosquitto_pub -h broker.connectmq.com -p 1883 -i dts-91x-pump -r -q 1 \
  -t "connectmq/demo/dts-91x/site1/utilities/pump104/state" \
  -m '{"rpm":1480,"flow_m3h":42.1,"outlet_bar":3.2,"ts":"2026-10-16T09:00:00Z"}'

# Jede Zwillingskomponente, die später abonniert, erhält den aktuellen Zustand sofort
mosquitto_sub -h broker.connectmq.com -p 1883 -i dts-91x-twin \
  -t "connectmq/demo/dts-91x/site1/#" -v

Eine Simulation innerhalb eines Zwillings nutzen

Die wirkungsvollsten Lösungen kombinieren beides. Der Zwilling hält ein Live-Bild des Assets; ein darin eingebettetes Simulationsmodell nutzt diesen Live-Zustand als Ausgangspunkt, um vorausschauende Fragen zu beantworten. Das folgende Python-Beispiel abonniert den Zustand der Pumpe, führt ein sehr einfaches What-if-Modell aus (wie sich der Ausgangsdruck bei reduzierter Drehzahl ändern würde) und veröffentlicht die Vorhersage neben der Messung, damit ein Dashboard beides darstellen kann.

import json

import paho.mqtt.client as mqtt

BASE = "connectmq/demo/dts-91x/site1/utilities/pump104"


def predict_outlet_pressure(state, new_rpm):
    # Affinitätsgesetz: Der Druck skaliert mit dem Quadrat der Drehzahl
    ratio = new_rpm / state["rpm"]
    return round(state["outlet_bar"] * ratio ** 2, 2)


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


def on_message(client, userdata, msg):
    state = json.loads(msg.payload)
    scenario = {
        "scenario": "rpm_minus_10pct",
        "rpm": round(state["rpm"] * 0.9),
        "predicted_outlet_bar": predict_outlet_pressure(state, state["rpm"] * 0.9),
        "based_on_ts": state["ts"],
    }
    client.publish(f"{BASE}/sim/what-if", json.dumps(scenario), qos=1)
    print("Published", scenario)


client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="dts-91x-sim")
client.on_connect = on_connect
client.on_message = on_message
client.connect("broker.connectmq.com", 1883)
client.loop_forever()

Die Physik ist hier bewusst einfach gehalten, aber das Muster skaliert: Ersetzen Sie predict_outlet_pressure durch den Aufruf eines richtigen Solvers oder eines trainierten Modells, und der Zwilling bietet aus demselben Datenstrom sowohl „was ist“ als auch „was wäre, wenn“. Halten Sie simulierte Ausgaben in einem eigenen Subtopic (sim/...), damit niemand Vorhersagen mit Messwerten verwechselt.

Wann Simulation, wann Zwilling, wann beides

Wählen Sie eine Simulation, wenn:

das Asset noch nicht existiert und Sie Entwürfe oder Layouts bewerten.
Sie seltene oder gefährliche Szenarien testen müssen, die Sie an realen Anlagen niemals herbeiführen würden.
die Frage einmalig ist, etwa die Dimensionierung eines Puffers oder die Validierung einer Regelstrategie vor der Inbetriebnahme.

Wählen Sie einen digitalen Zwilling, wenn:

das Asset in Betrieb ist und Entscheidungen von seinem aktuellen Zustand abhängen.
Sie Fernsicht für Personen brauchen, die nicht neben der Maschine stehen können.
Sie Drift, Verschleiß oder Anomalien erkennen möchten, indem Sie erwartetes und tatsächliches Verhalten vergleichen.

Wählen Sie beides, wenn betriebliche Entscheidungen durch vorausschauende Analysen gestützt werden sollen, etwa bei der Frage, ob eine Linie verlangsamt werden soll, um die Lebensdauer eines verschlissenen Bauteils bis zum nächsten geplanten Stillstand zu strecken.

Eine verwandte Unterscheidung – zwischen Modell, Schatten und vollständigem Zwilling – hängt davon ab, in welche Richtung die Daten fließen. Der Artikel digitaler Zwilling vs. digitaler Schatten behandelt sie im Detail, und Arten digitaler Zwillinge erklärt, wie sich der Umfang von einer einzelnen Komponente bis zu einem ganzen Prozess verändert.

Häufige Fehler

Eine 3D-Animation als Zwilling bezeichnen. Spielt das Modell eine geskriptete Animation ab, ist es eine Visualisierung. Zum Zwilling wird es, wenn sein Zustand vom Asset kommt.
Vorhergesagte und gemessene Daten auf einem Topic mischen. Nachgelagerte Tools können sie nicht unterscheiden. Trennen Sie sie nach Topic und kennzeichnen Sie Einheiten und Quellen.
Veraltete Daten ignorieren. Ein Zwilling, der einen zwei Stunden alten Wert als aktuell anzeigt, ist schlechter als gar kein Zwilling. Verfolgen Sie Zeitstempel und Verbindungsstatus.
Mit dem Solver anfangen. Der schwierige Teil der meisten Zwillingsprojekte ist eine zuverlässige Datenanbindung, nicht die Mathematik. Bringen Sie zuerst die Telemetrie zum Fließen.

Infrastruktur für die Live-Seite

Simulationen brauchen Rechenleistung. Zwillinge brauchen zuverlässige Konnektivität, und das bedeutet einen MQTT-Broker, der immer verfügbar ist, mit TLS und Authentifizierung gesichert ist und gleichzeitig Verbindungen von Gateways, Viewern und Analysediensten annehmen kann. Das selbst zu betreiben ist möglich, doch ein verwalteter MQTT-Broker nimmt Ihnen Patches, Zertifikate und Kapazitätsplanung ab.

ConnectMQ unterstützt MQTT 3.1.1 und 5.0 über TCP, TLS, WebSocket und Secure WebSocket, sodass derselbe Broker Python-Simulations-Worker und browserbasierte 3D-Ansichten bedient. Das Portal erkennt außerdem UNS-Topics im ISA-95-Stil und zeigt Geräte nach Hierarchieebene an, was hilft, wenn Sie Zwillinge realen Anlagen zuordnen.

Halten Sie Ihre Zwillinge mit ConnectMQ synchron

Ob Sie mit einer Simulation beginnen und später Live-Daten ergänzen oder vom ersten Tag an einen Zwilling bauen – die Konnektivitätsschicht ist dieselbe. Erstellen Sie einen Broker im ConnectMQ-Portal im kostenlosen Serverless-Plan, ohne Kreditkarte, und richten Sie Ihre Publisher und Modelle darauf aus.

Häufig gestellte Fragen

Ist ein digitaler Zwilling nur eine Simulation mit Live-Daten?

Teilweise. Live-Daten eines bestimmten Assets sind das definierende Merkmal, aber ein Zwilling besteht zudem über die gesamte Lebensdauer des Assets, verfolgt die Datenqualität und kann Erkenntnisse oder Befehle zurückspielen. Eine Simulation kann eine Komponente darin sein.

Kann ein digitaler Zwilling vor dem physischen Asset existieren?

Ein Modell eines geplanten Assets wird oft als digitaler Prototyp oder Design-Zwilling bezeichnet. Zum operativen Zwilling wird es, sobald es mit den Daten des realen Assets verbunden ist.

Welches Protokoll eignet sich am besten zur Versorgung eines digitalen Zwillings?

MQTT ist weit verbreitet, weil es leichtgewichtig und ereignisgesteuert ist und viele Konsumenten sich einen Datenstrom teilen können. OPC UA ist auf Maschinenebene üblich, und Gateways überführen OPC-UA-Daten häufig in MQTT-Topics.

Brauche ich Echtzeitdaten für einen Zwilling?

Sie brauchen Daten, die für die Entscheidungen, die der Zwilling unterstützt, aktuell genug sind. Für das Monitoring können das Sekunden sein; für die Instandhaltungsplanung reichen oft Minuten.

Digitaler Zwilling vs. Simulation: Die wichtigsten Unterschiede und wann Sie was einsetzen