„Digitaler Zwilling vs. digitaler Schatten“ ist keine Frage des Brandings, sondern eine präzise Unterscheidung danach, in welche Richtung Daten zwischen einem physischen Asset und seinem digitalen Gegenstück fließen. In diesem Artikel lernen Sie die drei Integrationsstufen kennen (digitales Modell, digitaler Schatten, digitaler Zwilling), sehen jede als konkrete MQTT-Topics und erhalten eine Checkliste, um Ihr eigenes Projekt ehrlich einzuordnen.
Der Leitfaden zur Digital-Twin-Technologie behandelt das übergreifende Konzept; hier konzentrieren wir uns auf den Datenfluss.
Die drei Stufen im Überblick
Die in der Fertigungsforschung weit verbreitete Einteilung unterscheidet drei Stufen danach, wie sich Daten zwischen physischem und digitalem Objekt bewegen:
| Stufe | Physisch zu digital | Digital zu physisch | Beispiel |
|---|---|---|---|
| Digitales Modell | Manuell | Manuell | CAD-Modell einer Presse, das ein Ingenieur nach einem Retrofit aktualisiert |
| Digitaler Schatten | Automatisch | Manuell | Dashboard mit Live-Presskraft; ein Bediener entscheidet, was zu tun ist |
| Digitaler Zwilling | Automatisch | Automatisch | Zwilling erkennt Werkzeugverschleiß und passt den Pressensollwert über die Steuerung an |
„Manuell“ bedeutet hier, dass ein Mensch die Information überträgt, indem er Werte eintippt, Dateien exportiert oder zu einem Bedienpanel geht. „Automatisch“ bedeutet, dass Daten ohne menschliches Eingreifen durch ein System fließen. Die Stufe bestimmt das schwächste Glied: Ist eine Richtung manuell, ist es kein vollständiger Zwilling.
Stufe 1: Das digitale Modell
Ein digitales Modell ist eine statische oder offline Repräsentation. Eine CAD-Baugruppe, eine Tabelle mit Nennparametern oder eine aus Datenblättern aufgesetzte Simulation sind allesamt digitale Modelle. Nichts verbindet sie mit dem laufenden Asset, daher beschreiben sie den Entwurf, nicht den aktuellen Zustand.
Digitale Modelle sind dennoch wertvoll. Sie sind das Fundament, auf dem die anderen Stufen aufbauen: Geometrie für 3D-Ansichten, Nennwerte für Vergleiche und die Struktur, aus der später eine Topic-Hierarchie wird. Sie veralten aber in dem Moment, in dem sich das physische Asset ändert und niemand die Datei aktualisiert.
In MQTT-Begriffen: Es gibt keine Topics. Wenn Sie einen Wert einmal exportiert und von Hand veröffentlicht haben, befinden Sie sich immer noch auf dieser Stufe.
Stufe 2: Der digitale Schatten
Ein digitaler Schatten erhält einen automatischen, kontinuierlichen Datenfluss vom Asset. Das digitale Objekt spiegelt stets den aktuellen Zustand wider, aber jede Reaktion darauf läuft weiterhin über einen Menschen.
Hier stehen die meisten „Digital-Twin“-Projekte tatsächlich, und das ist in Ordnung. Eine Live-Ansicht jeder Maschine, Alarme bei Überschreiten eines Schwellwerts und eine Historie für die Ursachenanalyse liefern viel Nutzen ohne jede automatisierte Steuerung.
In MQTT-Begriffen: Das Asset oder sein Gateway veröffentlicht Telemetrie und Zustand, und Konsumenten abonnieren. Die Daten fließen in eine Richtung.
connectmq/demo/shd-4q2/press/line3/press07/telemetry (asset -> shadow)
connectmq/demo/shd-4q2/press/line3/press07/state (asset -> shadow, retained)
connectmq/demo/shd-4q2/press/line3/press07/status (Last Will: online/offline)
Im Werk liegen diese Topics idealerweise in einem Unified Namespace (UNS): Die ISA-95-Hierarchie (Enterprise → Site → Area → Line → Cell) wird zur Topic-Struktur auf dem MQTT-Broker, etwa acme/werk-stuttgart/presswerk/linie-3/presse-07/telemetry. So abonnieren Schatten, MES und SCADA dieselben Daten an derselben Stelle; Details liefert Sparkplug B und Unified Namespace.
Probieren Sie es auf dem öffentlichen MQTT-Broker aus, der für Tests und Prototypen gedacht ist, und ersetzen Sie shd-4q2 durch Ihre eigene zufällige ID:
mosquitto_sub -h broker.connectmq.com -p 1883 -i shd-4q2-shadow \
-t "connectmq/demo/shd-4q2/#" -v
mosquitto_pub -h broker.connectmq.com -p 1883 -i shd-4q2-press07 -q 1 \
-t "connectmq/demo/shd-4q2/press/line3/press07/telemetry" \
-m '{"force_kn":812,"stroke_rate_spm":28,"die_temp_c":61.5}'
Der Subscriber ist ein digitaler Schatten: Er weiß, was Presse 07 tut, kann sie aber nicht beeinflussen.
Stufe 3: Der digitale Zwilling
Ein digitaler Zwilling ergänzt den automatischen Rückweg. Das digitale Objekt kann das Verhalten des physischen Assets ändern – durch Anpassen eines Sollwerts, Einplanen eines Stopps oder Ändern einer Rezeptur –, ohne dass jemand die Entscheidung erneut eintippt.
In MQTT-Begriffen: Sie ergänzen Befehls-Topics, die das Gateway abonniert, und Bestätigungs-Topics, die bestätigen, was tatsächlich angewendet wurde.
connectmq/demo/shd-4q2/press/line3/press07/cmd/setpoint (twin -> asset)
connectmq/demo/shd-4q2/press/line3/press07/cmd/ack (asset -> twin)
Hier ist ein minimales Gateway, das den Kreis schließt. Es akzeptiert einen Hubzahl-Sollwert innerhalb von Grenzen, wendet ihn an und meldet zurück. Die eigentliche Zwillingslogik, also der Teil, der den neuen Sollwert festlegt, könnte ein Regelskript, ein Optimierungsmodell oder eine vom Bediener freigegebene Empfehlung sein.
import json
import paho.mqtt.client as mqtt
BASE = "connectmq/demo/shd-4q2/press/line3/press07"
current = {"stroke_rate_spm": 28}
def on_connect(client, userdata, flags, reason_code, properties):
client.subscribe(f"{BASE}/cmd/setpoint", qos=1)
def on_message(client, userdata, msg):
cmd = json.loads(msg.payload)
rate = cmd.get("stroke_rate_spm")
if isinstance(rate, (int, float)) and 10 <= rate <= 35:
current["stroke_rate_spm"] = rate # an einer realen Linie: hier in die SPS schreiben
result = "applied"
else:
result = "rejected"
client.publish(f"{BASE}/cmd/ack",
json.dumps({"id": cmd.get("id"), "result": result, **current}), qos=1)
client.publish(f"{BASE}/state", json.dumps(current), qos=1, retain=True)
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="shd-4q2-press07-gw")
client.on_connect = on_connect
client.on_message = on_message
client.connect("broker.connectmq.com", 1883)
client.loop_forever()
Senden Sie einen Befehl und beobachten Sie, wie die Bestätigung und der neue retained Zustand in Ihrem Subscriber ankommen:
mosquitto_pub -h broker.connectmq.com -p 1883 -i shd-4q2-twin -q 1 \
-t "connectmq/demo/shd-4q2/press/line3/press07/cmd/setpoint" \
-m '{"id":"sp-17","stroke_rate_spm":24}'
Beachten Sie, dass der Zwilling nicht davon ausgeht, dass sein Befehl funktioniert hat. Er wartet, bis das Asset den angewendeten Wert meldet, und die Schattenseite des Systems zeigt den gemessenen Zustand an. Diese Disziplin hält den Zwilling wahrheitsgetreu, auch wenn Befehle abgelehnt oder verzögert werden.
Warum die Unterscheidung in der Praxis zählt
Der Sicherheitsumfang ändert sich. Ein Schatten braucht nur Lesezugriff für Konsumenten und Schreibzugriff für das Gateway auf Telemetrie-Topics. Ein Zwilling führt Clients ein, die physisches Verhalten ändern können. Das erhöht die Anforderungen an Authentifizierung, Trennung von Zugangsdaten und Audit-Logging. Der Leitfaden zu MQTT-Sicherheit: Best Practices behandelt TLS, Zugangsdaten und das Prinzip der minimalen Rechte.
Die Zuverlässigkeitsanforderungen ändern sich. Geht in einem Schatten ein Telemetriewert verloren, entsteht eine Lücke im Diagramm. Geht in einem Zwilling ein Befehl verloren oder wird er doppelt ausgeführt, kann das einen falschen Sollwert bedeuten. Verwenden Sie QoS 1 für Befehle, fügen Sie IDs zur Deduplizierung hinzu und ergänzen Sie einen Ablauf, damit verspätete Befehle ignoriert werden. Die Message Expiry Intervals von MQTT 5 sind genau dafür gemacht.
Die Verantwortung ändert sich. Schatten gehören meist der IT oder einem Datenteam. Zwillinge, die zurückschreiben, brauchen die Freigabe von Steuerungstechnik und Arbeitssicherheit, denn der automatisierte Pfad muss die Verriegelungen in SPS und Sicherheitssystem respektieren.
Die Erwartungen ändern sich. Einen Schatten als Zwilling zu bezeichnen, programmiert Enttäuschung bei den Stakeholdern vor. Die Stufe ehrlich zu benennen, ermöglicht es, den nächsten Schritt bewusst zu planen.
Ordnen Sie Ihr Projekt ein: eine Checkliste
Gehen Sie diese Fragen für jedes Asset im Projektumfang durch:
- Ist die digitale Repräsentation an ein bestimmtes, identifizierbares Asset gebunden? Wenn nicht, ist es ein generisches Modell oder eine Simulation.
- Kommen die Daten vom Asset an, ohne dass jemand sie eintippt oder exportiert? Wenn nicht, haben Sie ein digitales Modell.
- Sind die Daten aktuell genug für die Entscheidungen, die Sie damit treffen, und zeigen Sie an, wenn sie veraltet sind?
- Kann die digitale Seite das Verhalten des Assets über einen Systempfad ändern, etwa über ein Befehls-Topic, das ein Gateway verarbeitet?
- Erhält jeder Befehl eine Bestätigung, die widerspiegelt, was das Asset tatsächlich angewendet hat?
- Sind Befehlspfade getrennt von reinen Lese-Konsumenten authentifiziert und werden sie protokolliert?
Positive Antworten auf 1 bis 3 ergeben einen soliden digitalen Schatten. Sind auch 4 bis 6 positiv, haben Sie einen digitalen Zwilling. Liegen Sie dazwischen, ist es üblich und sinnvoll, zunächst als Schatten zu arbeiten, die Datenqualität nachzuweisen und den Rückweg dann Anwendungsfall für Anwendungsfall freizuschalten.
Lesenswerte verwandte Vergleiche sind Device Shadow vs. digitaler Zwilling, der das „Device Shadow“-Muster von Cloud-IoT-Plattformen betrachtet, und digitaler Zwilling vs. Simulation, der Live-Zwillinge von Offline-Modellen abgrenzt.
Der Broker auf jeder Stufe
Ab der Schattenstufe beruht alles auf zuverlässigem Messaging. Der Cloud-MQTT-Broker wird zur Drehscheibe, über die Telemetrie herein- und Befehle hinausfließen; seine Verfügbarkeit und Sicherheit bestimmen daher die Obergrenze für den gesamten Zwilling. Für alles, was über eine Demo hinausgeht, verwenden Sie private Zugangsdaten und TLS auf einem verwalteten MQTT-Broker statt des öffentlichen MQTT-Brokers.
Mit ConnectMQ erhält jedes Gateway und jeder Zwillingsdienst eigene Zugangsdaten und eine eigene Client ID aus dem Portal, und der Live-Topic-Explorer zeigt Telemetrie, Befehle und Bestätigungen während der Inbetriebnahme in einer Ansicht. Die Schwellwert-Alarmregeln im Portal decken zudem einen typischen Bedarf auf Schattenebene ab: benachrichtigt zu werden, wenn ein Wert den zulässigen Bereich verlässt.
Vom Schatten zum Zwilling mit ConnectMQ
Beginnen Sie mit der Einweg-Telemetrie eines digitalen Schattens und ergänzen Sie Befehls- und Bestätigungs-Topics, sobald Sie bereit sind, den Kreis zu schließen. Beides läuft auf demselben Broker. Erstellen Sie einen kostenlosen ConnectMQ-Serverless-Broker, ohne Kreditkarte, und verbinden Sie noch heute Ihr erstes Gateway.
Häufig gestellte Fragen
Was ist ein digitaler Schatten?
Ein digitaler Schatten ist eine digitale Repräsentation, die automatisch Daten von einem physischen Asset erhält, während jede Rückwirkung auf das Asset manuell durch einen Menschen erfolgt. Er spiegelt die Realität, ohne sie zu beeinflussen.
Ist ein digitaler Schatten schlechter als ein digitaler Zwilling?
Nicht unbedingt. Viele Anwendungsfälle in Monitoring, Analyse und Instandhaltung brauchen nur einen Schatten, und er birgt ein geringeres Risiko. Wechseln Sie zu einem Zwilling, wenn automatisierte Rückkopplung klaren Mehrwert schafft.
Wie spiegeln MQTT-Topics den Unterschied wider?
Ein Schatten nutzt Telemetrie- und Zustands-Topics, die vom Asset ausgehen. Ein Zwilling ergänzt Befehls-Topics zum Asset hin und Bestätigungs-Topics, die bestätigen, was angewendet wurde.
Muss ein digitaler Zwilling das Asset direkt steuern?
Der Rückweg muss automatisch sein, kann aber dennoch Freigabeschritte oder Sicherheitsprüfungen in Gateway und Steuerung erfordern. Entscheidend ist, dass niemand die Entscheidung von Hand erneut eingibt.
