Digitale Zwillinge in der Praxis: DTDL, JSON‑LD und DTMI erklärt – unser Recap zu „Digital Twins“ von Maximilian Mayr (Tributech)

Warum überhaupt ein „Zwilling“? Die Apollo‑13‑Brücke

Was bedeutet „Zwilling“ im Kontext der Technik? Maximilian Mayr eröffnet „Digital Twins“ mit einer anschaulichen Brücke: der Apollo‑13‑Mission. Auf dem Weg zum Mond trat ein Problem auf – die Crew konnte es nicht identifizieren. „Houston, we have had a problem“ war alles, was sie funken konnten. Aussteigen und nachsehen? Unmöglich. Die Lösung kam von der Erde – aus Simulatoren, die mit derselben Hardware wie das echte Raumschiff ausgestattet waren und an Computer gekoppelt wurden. Ingenieursteams passten diese Simulatoren an, reproduzierten den Fehler, testeten Workarounds und sendeten schließlich die korrigierten Schritte zurück ins All.

Diese Episode markiert das konzeptionelle Urbild: ein „Zwilling“, der parallel zum realen System existiert, es Verhalten nachbildet, Zustände spiegelt und es erlaubt, gefahrlos zu testen. Der digitale Zwilling überträgt diese Idee in Software – ein digitalisiertes Abbild, das Daten empfängt, Befehle sendet, sich strukturieren und in Gruppen organisieren lässt. Genau hier setzt die Praxis an: Wir modellieren Dinge, Prozesse und Beziehungen so, dass wir sie in einem digitalen Kontext zuverlässig verstehen, überwachen und steuern können.

Vom physischen Simulator zum digitalen Zwilling

Aus dem Apollo‑Beispiel bleibt die Essenz: Ein Zwilling braucht Verbindung, Daten, ein Modell und die Fähigkeit, Zustände und Aktionen konsistent abzubilden. Der digitale Anteil erweitert das:

• Datenströme spiegeln Telemetrie aus physischen Sensoren.
• Digitale Modelle beschreiben Eigenschaften (z. B. „Einschalten“), Kommandos („starte Messung alle 10 Minuten“) und Beziehungen (z. B. „Raum gehört zu Gebäude“).
• Instanzen dieser Modelle repräsentieren konkrete Geräte, Räume oder ganze Systeme.
• Gruppenbildung und Beziehungen erlauben, komplexe Domänen – etwa eine Smart City – strukturiert zu verwalten.

Kurz: Der digitale Zwilling ist die formale, maschinenlesbare Repräsentation eines realen Systems – ein Abbild, das sowohl den Zustand kommuniziert als auch Handlungen ermöglicht.

Anwendungsfelder: von Fertigung bis Smart City

Mayr bleibt bewusst breit und benennt Domänen, in denen Zwillinge konkrete Vorteile bringen:

• Fertigung: Maschinen mit Sensorik lassen sich als Zwillinge modellieren, Telemetrie wird strukturiert zugänglich.
• Gesundheitswesen: Ein Herz als digitaler Zwilling könnte z. B. eine standardisierte Schnittstelle zur Herzfrequenz bieten.
• Smart City: Jedes Gebäude ist ein Zwilling; es enthält Räume als Zwillinge; Räume besitzen Sensoren oder Aktoren wie Licht. Bezirke gruppieren Gebäude; Straßen haben Entitäten wie Autos oder Personen – ebenfalls wieder Zwillinge.
• Datenökonomien: Standardisierte, teilbare Datenströme – etwa einer Temperatursonde – werden über ein einheitliches Zwillingsmodell beschrieben. Dritte wissen, welcher Sensor vorliegt und wie der Datenstrom zugänglich ist.

Diese Beispiele zeigen: Mit digitalen Zwillingen lassen sich nahezu alle realen Entitäten und Beziehungen modellieren – entscheidend ist dabei die Standardisierung der Beschreibung.

Standardisierung statt Wildwuchs: DTDL im Fokus

Wie beschreibt man Zwillinge so, dass Teams, Systeme und Tools sie konsistent verstehen? Hier setzt die Digital Twins Definition Language (DTDL) an – ein von Microsoft mit Branchenpartnern entwickeltes, quelloffenes Beschreibungsformat, das auf JSON‑LD (JSON‑Linked Data) basiert. Viele Webentwickler kennen JSON‑LD von strukturierten Metadaten auf Websites; DTDL nutzt denselben Ansatz, um IoT‑Geräte und digitale Zwillinge zu modellieren.

Wesentlich an DTDL ist die Balance zwischen Ausdruckskraft und Restriktion. Mayr bringt es auf den Punkt: Beim Modellieren sind „einige Einschränkungen oft besser als keine“. DTDL gibt genau die Bausteine vor, die für die meisten IoT‑Anwendungen gebraucht werden – nicht mehr und nicht weniger. Das sorgt für Verständlichkeit, Wiederverwendbarkeit und tooling‑freundliche Modelle.

Die Bausteine von DTDL

DTDL stellt sechs Bausteine plus eine übergeordnete Struktur bereit, um Modelle präzise zu beschreiben. In der Praxis arbeiten wir mit folgenden Elementen:

• Interface (Schnittstelle): Der Container für die übrigen Bausteine; hier definieren wir die „Form“ eines Zwillings. Interfaces können andere Interfaces erweitern (Vererbung) und dienen als zentrale Aggregation von Telemetrie, Eigenschaften, Kommandos und Beziehungen.
• Telemetrie: Daten, die ein Gerät streamt oder in definierten Abständen liefert – z. B. die aktuelle Temperatur.
• Eigenschaften (Properties): Zustände oder Konfigurationen, z. B. „Messung fortsetzen“, „Gerät ein/aus“. Eigenschaften können praktisch alle gängigen Typen annehmen: Zeichenketten, Ganzzahlen, Dauer, Maps, Objekte und sogar andere Schemas oder Interfaces.
• Kommandos (Commands): Aufrufe, die wir an das Gerät schicken – z. B. „gib mir den aktuellen Temperaturwert als Antwort (kein Stream)“, „schalte ein/aus“, „miss alle 10 Minuten“. Semantisch entsprechen sie Funktionen/Methoden mit definierten Eingaben und Ausgaben.
• Beziehungen (Relationships): Strukturieren Modelle in der Breite – der Bezirk hat Gebäude, das Gebäude hat Räume; ein Raum gehört zu einem Haus. Beziehungen machen Hierarchien und Zugehörigkeiten explizit.
• Komponente (Component): Das kleinstmögliche, in sich geschlossene Modul innerhalb eines Interfaces. Wenn ein Gerät nicht aus vielen Interfaces bestehen soll, sondern als kompakte Einheit beschrieben wird, nutzen wir Komponenten.

Diese Bausteine bilden das Vokabular für das, was Entwicklerinnen und Entwickler tatsächlich brauchen: Messwerte, Zustand, Befehle, Struktur und Wiederverwendung.

Eindeutige Identität für Modelle: DTMI

Sobald ein Modell erstellt ist, braucht es eine robuste, menschenlesbare Kennung. Dafür definiert DTDL die Digital Twin Model Identifier (DTMI). Eine DTMI besteht im Kern aus drei Teilen:

1. Schema: immer „dtmi“.
2. Namensraum/Pfad: bewährt ist die Umkehrung des eigenen vollqualifizierten Domainnamens, z. B. „io:tribotech“ aus „io.tribotech.io“, gefolgt von frei definierbaren Segmenten. Der Grund: So sinkt die Kollisionswahrscheinlichkeit erheblich, und etwaige Kollisionen sind meist geografisch oder organisatorisch begrenzt (z. B. innerhalb eines Landes).
3. Versionsnummer: Modelle entwickeln sich weiter – Versionen machen Änderungen nachvollziehbar und Kompatibilität handhabbar.

Das Ergebnis ist eine gut lesbare, global eindeutige Kennung für jedes Modell. Das erleichtert Referenzierung, Versionierung und die spätere Instanziierung.

Vom Modell zur Instanz: Aufbau, Vererbung, Metadaten

Mayr zeigt exemplarisch die Trennung zwischen Modell und Instanz. Links steht das Modell mit seinen Bestandteilen; rechts eine konkrete Instanz, die auf dieses Modell verweist. Wichtige Aspekte:

• Vererbung (extends): Ein Interface kann ein anderes erweitern – so lassen sich gemeinsame Teile wiederverwenden und Spezialisierungen sauber abbilden.
• contents: Hier liegen die eigentlichen Bausteine (Telemetrie, Eigenschaften, Kommandos, Beziehungen, Komponenten).
• Metadaten auf Baustein‑Ebene: Beschreibungstexte, Kommentare, Anzeigenamen, Schreibbarkeit (writable) sowie das zugrundeliegende Schema (Datentyp) werden explizit gepflegt.
• Referenzierung per Metadaten: Die Instanz enthält einen klaren Verweis auf das zugrunde liegende Modell, inklusive DTMI – damit ist für jede laufende Instanz eindeutig, welchem Modell sie entspricht.

Diese Trennung schafft Klarheit: Das Modell ist die Spezifikation („So sieht ein Temperatur‑Sensor aus“), die Instanz ist die konkrete Realisierung („Sensor #17 in Raum A misst gerade 21,4 °C“).

Vorteile für Entwickler: vom Mocking bis zur UI‑Generierung

Warum sollten Teams DTDL‑basierte Zwillinge einsetzen? Mayr fasst die Vorteile prägnant:

• Abstraktion statt Gerätespezifika: Jedes IoT‑Gerät lässt sich abstrakt über Bausteine und Kombinationen darstellen. Man muss nicht jedes einzelne Gerät neu verstehen – das Modell liefert die Semantik.
• Testbarkeit und Mocking: Da zulässige Kommunikation und Datentypen definiert sind, lassen sich Daten- und Serverantworten zuverlässig mocken.
• Generische Benutzeroberflächen: „Man muss nur jeden Baustein repräsentieren und kann sie zusammensetzen“ – aus Modellen heraus lassen sich generische UIs generieren, ohne pro Gerät händisch zu entwerfen.
• Konsistente Repräsentation über alle Schichten: Das Modell dient als Single Source of Truth vom Gerät über das Backend bis zum Frontend. Datenstrukturen bleiben konsistent, Zustände bleiben nachvollziehbar.
• Domänenspezifische Modellierung: Die Bausteine sind allgemeingültig, aber flexibel. Teams können domänenspezifische Modelle erstellen, ohne aus der Standard‑Schiene zu fallen.
• Nachvollziehbarkeit und Fehlerbeobachtung: Sobald etwas geändert wird, meldet die Telemetrie Abweichungen. Änderungen werden dadurch schneller sichtbar und besser rückverfolgbar.

Eine Aussage bleibt hängen: DTDL ist „im Grunde wie ein Open‑API‑Standard – nur für IoT‑Geräte“. Diese Analogie spürt man in der täglichen Arbeit: Verträge werden explizit, Schnittstellen beschreibbar, Generierung und Validierung automatisierbar.

Plattformpfade: Eclipse D2 und die „Asia“-Plattform von Microsoft

Zum operativen Arbeiten mit Zwillingen nennt Mayr zwei Wege:

• Eclipse D2 Project: vollständig Open Source; Twins lassen sich erstellen, verwalten und „ansprechen“.
• „Asia“-Plattform von Microsoft: ein Digital‑Twin‑Service, der die Verwaltung von Zwillingen erlaubt.

Beide Wege zeigen, dass DTDL‑konforme Modelle nicht im luftleeren Raum leben, sondern in Plattformen münden, auf denen Instanzen laufen, Daten fließen und Befehle ausgeführt werden.

Schritt‑für‑Schritt: ein einfacher Sensor als DTDL‑Zwilling

Um den Übergang in die Praxis greifbar zu machen, haben wir die Kerngedanken aus der Session in einen generischen Umsetzungsablauf gegossen. Er bleibt eng am Gesagten und verwendet ausschließlich die Bausteine, die Mayr vorstellt:

1. Kontext festlegen: Was ist die reale Entität? Beispiel: eine Temperatursonde.
2. Interface schaffen: Ein DTDL‑Interface bildet den Container.
3. Telemetrie definieren: „currentTemperature“ als Stream von Messwerten (Schema: Zahl mit Einheit; die Einheit selbst wird im Schema beschrieben). Ziel: kontinuierlicher Zugriff auf aktuelle Messwerte.
4. Eigenschaften modellieren: z. B. „poweredOn“ (boolesch), „measurementInterval“ (Dauer). Schreibbarkeit je nach Gerät festlegen.
5. Kommandos festlegen: z. B. „readOnce“ (liefert einen Einzelwert, kein Stream), „setInterval(10min)“, „switchOn/Off“.
6. Beziehungen skizzieren: Sensor gehört zu Raum; Raum gehört zu Gebäude; Gebäude zu Bezirk. Beziehungen dienen dem Einordnen in Smart‑City‑ähnliche Strukturen.
7. Komponenten nutzen: Falls der Sensor intern Module hat (z. B. Kommunikations‑Modul), können diese als Komponente zusammengefasst werden – oder der Sensor bleibt die kleinste Einheit.
8. DTMI vergeben: Schema „dtmi“, umgekehrte Domain, sprechender Pfad (z. B. „sensor.temperature“), Version „;1“. Damit sind Identität und Versionierung geklärt.
9. Metadaten pflegen: Beschreibungen, Anzeigenamen, Kommentare, Schreibbarkeit, Schemas.
10. Instanz erstellen: Ein konkreter Sensor am Standort X verweist über Metadaten auf das Modell (per DTMI) und setzt initiale Eigenschaften.
11. Telemetrie anbinden: Datenstrom vom physischen Sensor wird der Telemetrie des Zwillings zugeführt; Befehle werden von der Instanz auf das Gerät gemappt.
12. UI generieren: Eine generische Oberfläche für Telemetrie, Eigenschaften und Kommandos entsteht durch die Darstellung der Bausteine – ohne Gerätespeziallogik.
13. Testen und Mocken: Datenflüsse simulieren, Kommandos durchspielen, Fehlerfälle prüfen. Weil das zulässige Protokoll im Modell steckt, gelingen reproduzierbare Tests.

Dieser Ablauf spiegelt exakt das Prinzip der Session: mit wenigen, präzisen Bausteinen vom Domänenmodell zur laufenden Instanz.

Muster für komplexere Domänen: Smart City und Healthcare

Zwei Domänen heben die Modellierungskraft hervor:

• Smart City: Gebäude als Zwillinge enthalten Räume als Zwillinge; Räume besitzen Sensoren (z. B. Temperatur) und Aktoren (z. B. Licht). Distrikte gruppieren Gebäude; Straßen binden Entitäten wie Autos oder Personen ein – wiederum Zwillinge. Beziehungen sind hier der entscheidende Baustein, um Struktur abzubilden.
• Gesundheitswesen: Ein Herz als Zwilling, dessen Telemetrie die Herzfrequenz liefert. Die Eigenschaft der Standardisierung ist zentral: Andere Systeme wissen, wie sie die Daten ansprechen können.

In beiden Fällen ist das Ziel, Zugänglichkeit, Struktur und Wiederverwendung sicherzustellen – statt Einzellösungen zu basteln.

Modellqualität: Einschränkungen als Enabler

Eine Kernbotschaft der Session: Durch wohldefinierte Bausteine wird Modellierung einfacher, nicht schwerer. DTDL verhindert Wildwuchs, ohne Flexibilität zu opfern. Für Engineering‑Teams heißt das:

• geringere Einarbeitungszeit (Bausteine statt Freiform‑Schema),
• bessere Tool‑Unterstützung (Validierung, Generierung),
• konsistente Integrationen (Frontend/Backend/Device sprechen dieselbe Sprache),
• weniger Überraschungen beim Betrieb (verifizierbare Schnittstellen, klarer Änderungsfluss über Versionen).

Diese Eigenschaften zahlen direkt auf die Stabilität von IoT‑Plattformen ein – insbesondere, wenn viele Geräte und Domänen zusammenkommen.

Fehlerdiagnose und Nachvollziehbarkeit: Telemetrie als Wachtposten

Mayr betont, dass Telemetrie im laufenden Betrieb sofort sichtbar macht, wenn etwas schiefgeht. Wird etwas geändert, schlägt Telemetrie aus – das System zeigt Unstimmigkeiten, Abweichungen oder Fehlzustände. Für Betreiber bedeutet das:

• schnellere Ursachenfindung,
• weniger blinde Flecken,
• bessere Post‑Mortems dank klarer Modell‑ und Instanzreferenzen (DTMI) und dokumentierter Änderungsstände (Versionen).

Das Apollo‑13‑Motiv schwingt mit: Ein gutes Modell (damals als Simulator) und gute Messdaten sind die Grundlage, um Probleme einzukreisen und Lösungen zu validieren.

Praktische Takeaways für Engineering‑Teams

Basierend auf dem Talk von Maximilian Mayr haben wir die wichtigsten Lehren für den Alltag zusammengefasst:

• Nutzt DTDL als klare Vertragssprache zwischen Gerät, Backend und Frontend.
• Vergebt DTMI‑Kennungen konsequent – sprechend, versioniert, mit umgekehrter Domain.
• Trennt Modell und Instanz strikt. Haltet Instanz‑Metadaten aktuell, inkl. Verweis auf das Modell.
• Denkt in Bausteinen, nicht in Geräten: Telemetrie, Eigenschaften, Kommandos, Beziehungen, Komponenten.
• Baut Beziehungen bewusst auf: Hierarchien (Bezirk → Gebäude → Raum → Sensor) machen Administration, Suche und UI einfacher.
• Nutzt die Vorteile fürs Mocking: definiert erlaubte Kommunikation und testet End‑to‑End ohne echte Hardware.
• Erzeugt generische UIs aus dem Modell – das reduziert Speziallogik pro Gerät.
• Beobachtet Telemetrie aktiv nach Änderungen – sie ist euer Frühwarnsystem.
• Plant Versionierung als Teil des Entwicklungsprozesses ein; Änderungen am Modell sind normal, nicht die Ausnahme.

Fazit: Einfache Bausteine, große Wirkung

„Digital Twins“ von Maximilian Mayr (Tributech) zeigt, wie man mit wenigen, scharf geschnittenen Bausteinen robuste, verständliche digitale Zwillinge baut. DTDL liefert die Sprache, JSON‑LD die Grundlage, DTMI die Identität. Aus dem physischen Simulator von Apollo‑13 wird ein generisches, digitales Muster: Daten empfangen, Befehle senden, Beziehungen modellieren, Instanzen sauber versionieren – und all das so, dass Teams über Domänen hinweg zusammenarbeiten können.

Ob Fertigung, Gesundheitswesen, Smart City oder Datenökonomien: Die Prinzipien bleiben gleich. Für uns war die prägnanteste Erkenntnis die Kombination aus Standardisierung und Pragmatismus. Oder, in Mayrs Worten: DTDL ist „im Grunde wie ein Open‑API‑Standard – nur für IoT‑Geräte“. Genau das macht den Ansatz für Engineering‑Teams so attraktiv.

Wer starten will, findet zwei naheliegende Wege: das Open‑Source‑„Eclipse D2 Project“ und die „Asia“-Plattform von Microsoft mit Digital‑Twin‑Service. Wichtig ist weniger die Tool‑Wahl als der erste Schritt: ein klares Modell, eine saubere DTMI und die Disziplin, Telemetrie, Eigenschaften, Kommandos, Beziehungen und Komponenten konsequent zu nutzen. Der Rest ergibt sich – modellgetrieben, nachvollziehbar und skalierbar.