Die Frage Device Shadow vs. digitaler Zwilling taucht in fast jedem IoT-Projekt auf, weil beide eine Cloud-seitige Kopie des Gerätezustands vorhalten. Dieser Artikel erklärt genau, wie sie sich in Umfang, Daten und Zweck unterscheiden, zeigt, wann ein Shadow genügt und wann Sie einen vollständigen Zwilling brauchen, und führt durch ein portables Device-Shadow-Muster auf Basis von Retained MQTT-Topics.
Ausführlich zur Zwillingsseite: der Leitfaden zur Digital-Twin-Technologie.
Was ist ein Device Shadow?
Ein Device Shadow ist ein persistentes Zustandsdokument für ein einzelnes Gerät, das in der Cloud gehalten wird. Es besteht typischerweise aus drei Teilen:
- Reported: der zuletzt vom Gerät gemeldete Zustand.
- Desired: der Zustand, den eine App für das Gerät wünscht.
- Delta: die Differenz, auf die das Gerät reagieren soll.
Cloud-IoT-Plattformen haben Shadows (auf manchen Plattformen auch Device Twins genannt) eingeführt, um ein bestimmtes Problem zu lösen: Apps müssen den Gerätezustand lesen und ändern können, auch wenn das Gerät schläft oder offline ist. Der Shadow ist immer verfügbar; das Gerät synchronisiert sich mit ihm, sobald es sich verbindet.
Ein Shadow ist bewusst einfach gehalten. Er kennt ein Gerät, hält den aktuellen Zustand und eine Versionsnummer vor und macht sonst wenig.
Was ist ein digitaler Zwilling?
Ein digitaler Zwilling ist ein umfassenderes Konzept: eine virtuelle Live-Repräsentation eines physischen Assets, Prozesses oder Systems, die den aktuellen Zustand mit Kontext und Verhalten verbindet. Zusätzlich zum Zustand, den ein Shadow hält, ergänzt ein Zwilling typischerweise:
- Ein Modell: was das Asset ist, seine Eigenschaften, Einheiten und Semantik, oft in DTDL oder als Verwaltungsschale (Asset Administration Shell der Plattform Industrie 4.0) ausgedrückt.
- Beziehungen: Diese Pumpe gehört zu jener Station, die jenen Tank speist.
- Historie: Zeitreihen für Trends, Diagnose und Prognose.
- Analytik oder Simulation: abgeleitete Werte, Anomalieerkennung, Was-wäre-wenn-Szenarien.
- Visualisierung: Dashboards oder 3D-Szenen, die viele Assets gemeinsam zeigen.
Ein Zwilling kann Dinge darstellen, die überhaupt kein einzelnes Gerät sind: eine Produktionslinie, eine Gebäudeetage, ein ganzes Werk.
Device Shadow vs. digitaler Zwilling im direkten Vergleich
| Aspekt | Device Shadow | Digitaler Zwilling |
|---|---|---|
| Umfang | Ein Gerät | Asset, System oder Prozess, oft viele Geräte |
| Kerndaten | Aktueller Reported und Desired State | Zustand plus Historie, Modell und Kontext |
| Modell | Freies JSON | Explizites Schema, Semantik und Einheiten |
| Beziehungen | Keine | Hierarchien und Verknüpfungen zwischen Assets |
| Zeit | Nur der neueste Wert | Aktuell und historisch |
| Logik | Delta-Berechnung | Analytik, Simulation, Prognose |
| Typische Konsumenten | Mobile Apps, Geräteverwaltung | Ingenieure, Bediener, Planer |
| Visualisierung | Meist keine | Dashboards und 3D-Ansichten üblich |
| Aufwand für den Aufbau | Gering | Mittel bis hoch |
Die Beziehung ist kumulativ: Die meisten digitalen Zwillinge enthalten für jedes Gerät etwas Shadow-Ähnliches, während ein Shadow für sich allein noch kein vollständiger Zwilling ist. Unser Artikel zu digitalem Zwilling vs. digitalem Schatten behandelt eine verwandte, aber andere Unterscheidung aus der Forschungsliteratur, bei der ein digitaler Schatten einen einseitigen Datenfluss vom Asset zum Modell bezeichnet.
Wann ein Device Shadow genügt
Wählen Sie einen Shadow, wenn:
- Sie viele ähnliche Geräte verwalten, etwa smarte Steckdosen, Tracker oder Zähler.
- Der Hauptbedarf lautet: „Zeig mir den aktuellen Zustand und lass mich Einstellungen ändern."
- Geräte schlafen oder sich nur sporadisch verbinden und Konfigurationen nachholen müssen.
- Sie keine Beziehungen zwischen Geräten und keine Analytik darüber brauchen.
Consumer-IoT, Flottenkonfiguration und Ferneinstellungen sind klassisches Shadow-Terrain.
Wann Sie einen vollständigen digitalen Zwilling brauchen
Wählen Sie einen Zwilling, wenn:
- Der Nutzen daraus entsteht, Assets im Kontext zu sehen: eine Linie, ein Gebäude, ein Netz.
- Sie Zustand und Historie korrelieren müssen, um Probleme zu diagnostizieren.
- Mehrere Datenquellen ein Asset beschreiben (SPS, Vibrationssensor, MES).
- Nutzer räumliche oder 3D-Ansichten wünschen.
- Sie vorausschauende Wartung oder Simulation planen.
Industrieanlagen, Energiesysteme und Gebäude landen fast immer hier. In der Fertigung bildet dabei ein Unified Namespace (UNS) das Rückgrat: Die ISA-95-Anlagenhierarchie (Enterprise → Site → Area → Line → Cell) wird zur Topic-Struktur auf dem MQTT-Broker, etwa acme/werk-stuttgart/montage/linie-1/zelle-3/temperatur, und jeder Zwilling liest genau den Ast, der sein Asset beschreibt. Wie Sparkplug B dazu passt, zeigt Sparkplug B und Unified Namespace. Der Artikel zur Architektur digitaler Zwillinge zeigt die zusätzlichen Schichten, die Sie brauchen werden.
Einen portablen Device Shadow mit Retained MQTT-Topics bauen
Cloud-Shadow-Dienste sind an ihre Plattform gebunden. Dasselbe Verhalten erreichen Sie auf jedem standardkonformen MQTT-Broker mit Retained Messages, wodurch das Design portabel bleibt. Das Topic-Layout:
connectmq/demo/<id>/shadows/<device>/reported retained, device writes
connectmq/demo/<id>/shadows/<device>/desired retained, apps write
connectmq/demo/<id>/shadows/<device>/delta not retained, computed by a shadow service
connectmq/demo/<id>/shadows/<device>/status retained, last will
Retained Messages liefern Ihnen die wichtigste Shadow-Eigenschaft gratis: Wer auch immer abonniert, wann auch immer, erhält die neuesten Reported- und Desired-Dokumente. Ein kleiner Dienst berechnet die Deltas:
import json
import paho.mqtt.client as mqtt
BASE = "connectmq/demo/4d2a/shadows"
shadows = {}
def on_connect(client, userdata, flags, reason_code, properties):
client.subscribe(f"{BASE}/+/reported", qos=1)
client.subscribe(f"{BASE}/+/desired", qos=1)
def on_message(client, userdata, msg):
_, _, _, _, device, kind = msg.topic.split("/")
doc = json.loads(msg.payload) if msg.payload else {}
shadow = shadows.setdefault(device, {"reported": {}, "desired": {}})
shadow[kind] = doc
delta = {
key: value
for key, value in shadow["desired"].items()
if key not in ("version", "ts") and shadow["reported"].get(key) != value
}
if delta:
client.publish(f"{BASE}/{device}/delta", json.dumps(delta), qos=1)
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="shadow-service-4d2a")
client.on_connect = on_connect
client.on_message = on_message
client.connect("broker.connectmq.com", 1883)
client.loop_forever()
Probieren Sie es mit dem kostenlosen öffentlichen MQTT-Broker aus:
mosquitto_pub -h broker.connectmq.com -p 1883 -i lamp1-4d2a -q 1 -r \
-t "connectmq/demo/4d2a/shadows/lamp1/reported" -m '{"on": false, "brightness": 40}'
mosquitto_pub -h broker.connectmq.com -p 1883 -i app-4d2a -q 1 -r \
-t "connectmq/demo/4d2a/shadows/lamp1/desired" -m '{"version": 1, "on": true, "brightness": 80}'
mosquitto_sub -h broker.connectmq.com -p 1883 -i watch-4d2a \
-t "connectmq/demo/4d2a/shadows/lamp1/#" -v
Der Dienst publiziert {"on": true, "brightness": 80} auf das Delta-Topic. Ein Gerät kann den Dienst auch ganz weglassen: Es abonniert sein retained Desired-Topic und berechnet das Delta lokal, was für kleine Flotten oft einfacher ist. Die Regeln zu Reconnect und Versionierung aus Zustandssynchronisation digitaler Zwillinge gelten unverändert.
Grenzen des Shadows auf Basis von Retained Topics
Seien Sie ehrlich, was dieses Muster nicht leistet. Es gibt keine Abfrage-API („finde alle Lampen, die an sind"), keine Zugriffskontrolle pro Dokument über das hinaus, was Ihre Broker-Zugangsdaten erlauben, und Retained Messages liegen im Broker statt in einer Datenbank. Wenn Sie das brauchen, ergänzen Sie neben dem Broker einen Zwillingsdienst oder einen Datenbank-Subscriber. Für viele Flotten genügen Retained Topics jedoch und ersparen eine komplette Dienstschicht.
Häufige Fehler bei der Wahl zwischen beiden
Teams machen meist einen von zwei gegensätzlichen Fehlern. Der erste: einen Shadow als Zwilling bezeichnen und dann überrascht sein, wenn Stakeholder Historie, Kontext und Analytik erwarten, die ein einzelnes Zustandsdokument nicht liefern kann. Wenn der Werksleiter fragt: „Warum ist Linie 3 letzten Dienstag langsamer geworden?", hat ein Shadow keine Antwort.
Der zweite Fehler: mit einer schwergewichtigen Zwillingsplattform beginnen, wenn die eigentliche Anforderung lautet: „Die mobile App soll den Thermostat-Sollwert ändern können, während das Gerät schläft." Dieses Projekt braucht einen Shadow, und Modellierung, Graphdatenbanken und 3D-Szenen verzögern nur die Auslieferung.
Ein nützlicher Test: Schreiben Sie die drei Fragen auf, die Nutzer am dringendsten beantwortet haben wollen. Wenn sich alle drei auf den aktuellen Zustand oder die Konfiguration eines Geräts beziehen, bauen Sie einen Shadow. Wenn eine davon Zeit, Beziehungen zwischen Assets oder den Vergleich von erwartetem und tatsächlichem Verhalten betrifft, planen Sie einen Zwilling, beginnen aber trotzdem mit den oben beschriebenen Zustands-Topics im Shadow-Stil, denn der Zwilling wird auf ihnen aufbauen.
Vom Shadow zum Zwilling: ein praxisnaher Weg
- Mit einem retained Reported- und Desired-Topic pro Gerät beginnen.
- Ein Status-Topic mit Last Will für die Präsenz ergänzen.
- Einen Historien-Subscriber ergänzen, der in eine Zeitreihendatenbank schreibt.
- Ein Asset-Modell mit Hierarchie und Einheiten einführen, in Industrieanlagen entlang der ISA-95-Ebenen des UNS.
- Ein Dashboard oder eine 3D-Ansicht ergänzen, die ganze Zweige abonniert.
- Analytik auf Historie und Live-Zustand aufsetzen.
Jeder Schritt verwendet dieselben Topics, sodass Geräte nie geändert werden müssen.
Shadows und Zwillinge auf ConnectMQ bauen
ConnectMQ liefert Ihnen das Messaging-Fundament für beides: einen verwalteten MQTT-Broker mit Retained Messages, Last Will, MQTT 3.1.1 und 5.0, TLS auf Port 8883 und WSS auf Port 8084 für Browser-Dashboards. Ihre Shadow-Logik und Ihre Zwillingsdienste verbinden sich als gewöhnliche MQTT-Clients, sodass nichts an eine einzelne Cloud gebunden ist. Erstellen Sie unter app.connectmq.com einen kostenlosen Serverless-Broker, ganz ohne Kreditkarte, und verlagern Sie Ihren ersten Device Shadow dorthin.
Häufig gestellte Fragen
Ist ein Device Shadow ein digitaler Zwilling?
Ein Device Shadow ist eine einfache Form zwillingsähnlichen Zustands für ein Gerät. Ein digitaler Zwilling ergänzt ein Modell, Beziehungen, Historie und Analytik, oft über viele Geräte hinweg.
Kann ich einen Device Shadow ohne Cloud-IoT-Plattform bauen?
Ja. Retained MQTT-Topics für Reported und Desired State plus ein optionaler Delta-Dienst bilden das Shadow-Verhalten auf jedem standardkonformen MQTT-Broker nach.
Was ist der Unterschied zwischen einem Device Twin und einem Device Shadow?
Im Kern handelt es sich um dasselbe Konzept unter verschiedenen Plattformnamen: ein Cloud-seitiges Dokument mit Reported und Desired Properties für ein Gerät.
Brauche ich für einen Device Shadow eine Datenbank?
Nicht unbedingt. Retained Messages halten den neuesten Zustand vor. Ergänzen Sie eine Datenbank, wenn Sie geräteübergreifende Abfragen, Historie oder Audit-Trails brauchen.
