Doppelt hält besser: Was ist ein Digital Twin und wie ist er aufgebaut?

Wer in der Fertigung oder im Supply Chain Management arbeitet, hat die Begriffe „Digital Twin“ oder „digitaler Zwilling“ vermutlich schon mehr als einmal gehört. Erklärungen gibt es viele. Oft heißt es, ein digitaler Zwilling sei die digitale Abbildung eines Bauteils. Das stimmt – nur ist eine Teilenummer in einer Excel-Tabelle eben auch eine digitale Abbildung eines Bauteils. Wo liegt also der Unterschied? Was macht digitale Zwillinge besonders, und warum sind sie so aufgebaut, wie sie aufgebaut sind?

In diesem Artikel werden Sie nicht mit technischen Buzzwords zugeschüttet (ich habe nur eine Handvoll gezählt). Steigen wir stattdessen direkt in eine Situation aus der Praxis ein.

Schon wieder Manic Monday im Supply Chain Management

Es ist Montagmorgen und Andrea findet mehrere Nachrichten in ihrem Postfach – alle zum selben Bauteil: einem Gehäuse für einen Elektromotor. Andrea ist Head of Supply Chain Management bei der Wonder Metals GmbH, einem familiengeführten Aluminium-Druckgussunternehmen in Deutschland.

Die erste Kundenanfrage kommt von „Bavarian Automotive“. Der Kunde möchte wissen, wie viel CO2 bei der Produktion des Motorgehäuses entstanden ist. Eine einfache Frage. Andrea fragt ihren Kollegen und schickt die Daten anschließend als Excel-Datei an den Kunden. Berechnet worden waren sie zu Beginn des Jahres.

Abbildung 1: Die erste Anfrage manuell beantwortet – eine Datei, per E-Mail verschickt.

Andrea öffnet die zweite E-Mail. Sie kommt von „Swabian Luxury Automotive“ und fragt schlichte Produktionsdaten ab: Wo und wann wurde das Teil produziert, und mit welcher Seriennummer? Andrea sucht die Informationen in ihren Fertigungssystemen heraus und schickt dem Kunden eine Kopie.

Abbildung 2: Zwei Kunden, zwei Dateien – weiterhin manuell verschickt.

Andrea liest die E-Mails noch einmal durch und merkt: Beide Autohersteller wollen wöchentliche Updates. Ein Blick ins Postfach zeigt zwei weitere Anfragen – und sie sieht sich und ihre Kolleginnen und Kollegen schon die ganze Woche damit beschäftigt, Dateien zu aktualisieren und zu verschicken. Das muss auch anders gehen. Die Daten liegen doch längst in ihrem System – warum können die Kunden sie nicht einfach automatisch abrufen? Andrea erinnert sich, dass ein ehemaliger Praktikant bereits ein Tool gebaut hat, das die Daten wöchentlich exportiert. Also richtet sie zwei Server ein, die genau diese Dateien bereitstellen. Jeder Server gehört zu einem Kunden und einem Bauteil. Statt Dateien zu verschicken, teilt sie ihren Kunden künftig nur noch die Adresse mit, unter der sie die Daten selbst abholen können.

Abbildung 3: Ein Datenserver pro Kunde, jeder mit eigener Adresse.

Computer sagt nein – oder genauer: John aus der IT tut es

Andrea ist zufrieden mit sich, schließlich muss sie sich mit diesen Anfragen nicht mehr beschäftigen. Pling Eine weitere E-Mail. Sie ist von John aus der IT: „Andrea, wir haben 2.000 Kunden. Wir können nicht für jeden einzelnen einen Server aufsetzen – abgelehnt.“ Andrea denkt nach und erkennt ein Muster. Beide Kunden fragen Daten zum exakt selben Produkt ab, teilweise sogar exakt dieselben Daten. Sie nutzen sogar dieselbe interne Teilenummer. Vielleicht lassen sich die beiden Server zusammenlegen – zu einer einzigen Schnittstelle für beide Kunden.

Abbildung 4: Eine gemeinsame Schnittstelle für beide Kunden – beide ziehen jedoch dieselbe kombinierte Datei.

Andrea nippt an ihrem Kaffee, zufrieden mit dem Ergebnis – bis ihr ein Problem auffällt: Beide Kunden ziehen dieselbe Datei, CO2-Emissionen und Produktionsdaten zusammen, obwohl jeder von ihnen nur eines von beidem sehen darf. Die Schnittstelle sieht gut aus, die Zugriffskontrolle darunter nicht.

Eine Teile-Nummer, sie alle zu binden – wie ein Identifier getrennte Teilmodelle verknüpft

Die Lösung: „die Datei“ nicht länger als eine Einheit behandeln. Andrea teilt sie in zwei getrennte Datensätze – einen mit CO2-Emissionen, einen mit Produktionsdaten – und teilt jeden nur mit dem Kunden, der ihn sehen darf. Beide Datensätze beschreiben aber weiterhin dasselbe physische Bauteil. Sie braucht also etwas, das beide verbindet, ohne sie wieder zu einer Datei zusammenzuführen.

Dieses „Etwas“ ist ein Eintrag mit der Teile-Nummer, der rein als Etikett funktioniert – wie ein Ordner im Regal mit der Aufschrift „Teil 123“. Schlägt man ihn auf, liegen darin zwei getrennte Dokumente, jedes mit einem anderen Unternehmen geteilt. Der Ordner selbst enthält keine Daten; er sagt nur, welche Dokumente zum selben Bauteil gehören. Beide Kunden fragen weiterhin dieselbe Teile-Nummer ab, bekommen aber jeweils nur ihr eigenes Dokument.

Abbildung 5: Die Teile-Nummer wird zum Etikett, das auf je einen Datensatz pro Kunde verweist.

Man soll schlafende IT-Kollegen nicht wecken

Alles läuft, und Andrea kann sich endlich wieder ihrer eigentlichen Arbeit widmen. Eine Woche später warten neue E-Mails auf sie. Ihr Ansprechpartner bei Bavarian Automotive braucht dringend Produktionsdaten und Daten zu den End-of-Line-Prüfungen – den finalen Qualitätstests, die jedes Teil durchläuft, bevor es das Werk verlässt. Andrea verbringt Stunden damit, die Daten bereitzustellen, und landet doch wieder bei einem Problem: Die Daten der End-of-Line-Prüfungen aktualisieren sich viel häufiger als alle anderen Datenattribute. Sie hört förmlich Johns Stimme, wie er sich beschwert, dass große Dateien aktualisiert werden, nur um Kleinigkeiten daran zu ändern. Also zerlegt Andrea den Datensatz in seine Bestandteile und macht jede Abteilung für ihre eigenen Daten verantwortlich.

Abbildung 6: Jeder Aspekt wird ein eigener Datensatz – verantwortet von der Abteilung, die ihn erzeugt.

Diese Architektur hat noch einen weiteren Vorteil: Wann immer Kunden neue Aspekte und neue Datenstrukturen brauchen, kann Andrea diese Daten einfach ergänzen, ohne sonst etwas zu verändern.

John ist zufrieden – dafür beschwert sich prompt die Nachhaltigkeitsabteilung, die für die CO2-Emissionsdaten zuständig ist. Offenbar wollen beide Kunden dieselben Daten in unterschiedlichen Formaten. Andrea seufzt… Angefangen hatte sie das Ganze, um redundante Daten zu vermeiden.

There's a Standard for That!

Andreas Leben wäre deutlich leichter, wenn beide Kunden dasselbe Datenformat akzeptieren würden. Dafür müsste sie eine Datenstruktur finden, die für beide Kunden funktioniert – und, mit Blick nach vorn, auch für andere Anwendungsfälle und Produkte. Eine Mammutaufgabe, denkt Andrea. Zum Glück gibt es bereits Expertenorganisationen, die branchenweit standardisierte Datenstrukturen entwickeln, zum Beispiel die International Digital Twin Association (IDTA), ein Industriegremium, das fertige Datenmodelle für die Fertigung veröffentlicht. Andrea nimmt sich einfach ein Datenmodell von der Stange und schafft es, auch ihre Kunden davon zu überzeugen – zum Vorteil aller Beteiligten.

Abbildung 7: Standardisierte Datenstrukturen plus Zugriffskontrolle regeln, wer welchen Datensatz lesen darf.

Wenn sie schon dabei ist, führt sie gleich einen Mechanismus ein, der steuert, welcher Kunde auf welchen Datensatz zugreifen darf. Wie das genau funktioniert, versteht sie nicht wirklich – solange es einfach einzurichten ist, reicht ihr das. Sie hat genug anderes zu tun und überlässt die Details ihrem vertrauten Lösungsanbieter (sovity GmbH) für Catena-X, dem Datenaustausch-Ökosystem der Automobilindustrie.

Andrea lehnt sich in ihrem Stuhl zurück und ist zufrieden mit dem Ergebnis. Ihre Kunden können die Daten automatisch abrufen, das System ist so schlank wie möglich – und sogar John freut sich, wenn er auf seine Cloud-Speicher-Rechnung schaut.

Während Andrea in ihrem bequemen Bürostuhl wegdämmert, reißt sie der vertraute Teams-Klingelton aus ihren Tagträumen. Es ist die Nachhaltigkeitsabteilung. Die Stimmen klingen nervös. Offenbar kennt niemand den genauen CO2-Wert des Motorgehäuses, weil der größte Teil der Emissionen bei Toto Aluminum entsteht, ihrem Lieferanten für Rohmaterial. Nur noch eine Stunde trennt Andrea vom Wochenende, während sich Schweißperlen auf ihrer Stirn bilden. Sie wird zu genau dem, was sie eigentlich abschaffen wollte, und ruft ihren Lieferanten an, um CO2-Emissionsdaten anzufragen. „Klar, kennen Sie digitale Zwillinge?“, antwortet die freundliche Stimme am Telefon – und bei Andrea macht es endlich klick. Toto Aluminum hat die Daten längst aufbereitet. Und noch besser: Sie nutzen dieselben Datenstrukturen und Austauschprotokolle, sodass die Nachhaltigkeitsabteilung die Daten so einfach wie möglich selbst abrufen kann.

Abbildung 8: Dieselbe Struktur wiederholt sich entlang der Lieferkette – vom OEM über Tier 1 bis Tier 2.

Double Trouble – was ist ein digitaler Zwilling denn nun?

Kurz gesagt: Ein digitaler Zwilling ist die digitale Abbildung eines Bauteils – und er besteht aus zwei Bausteinen. Der erste Baustein ist die „Shell“: eine Hülle, die nichts weiter enthält als den Identifier des Bauteils und eine Liste von Verweisen – der Ordner in unserer Geschichte. Der zweite ist das „Sub-Model“: ein in sich geschlossener Datensatz zu genau einem Thema, etwa CO2-Emissionen oder Produktionsdaten – die einzelnen Dokumente in unserer Geschichte. Die Shell verweist auf die Sub-Models, und jedes Sub-Model kann mit einem anderen Partner geteilt werden. Abgesehen von einigen Basisinformationen gibt es keine Mindestanforderung daran, welche Aspekte und Informationen ein digitaler Zwilling enthalten muss. Es kann bei einer Seriennummer bleiben – oder alles umfassen, was über das Bauteil bekannt ist.

Übersetzt man das, was wir in diesem Artikel gelernt haben, in die Sprache von Catena-X, ergibt sich dieses Bild:

Abbildung 9: Dasselbe Bild in Catena-X-Begriffen – Digital Twin Registry und Sub-Model Repository.

Der digitale Zwilling allein stiftet noch keinen Nutzen. Erst wenn Unternehmen ihn klug nutzen und untereinander austauschen, ermöglicht er datenbasierte Entscheidungen – und hilft Partnern entlang der Lieferkette, in einem zunehmend umkämpften Markt gemeinsam erfolgreich zu sein.

Nach einer wahren Begebenheit – mehr oder weniger: digitale Zwillinge in einer echten Lieferkette

Danke, dass Sie diesen Artikel über die Entstehung digitaler Zwillinge gelesen haben. Unsere Beispielgeschichte ist offensichtlich fiktiv und vereinfacht. Sie erklärt aber, warum digitale Zwillinge so aufgebaut sind, wie sie es sind. Und sie zeigt, worauf es in Datenräumen ankommt: standardisierter Datenaustausch und sauberes Zugriffsmanagement.

Diese Struktur hat noch viele weitere Vorteile (zum Beispiel, dass sie maschinenlesbar ist), und einige Details haben wir übersprungen. Sie wollen wissen, wie Sie Ihre digitalen Zwillinge erstellen, speichern und mit Geschäftspartnern teilen? Oder wie ein skalierbares Setup aussieht? Sprechen Sie uns an: