Digital Twins zwischen Erwartungen und Tragfähigkeit

• Was ist ein Digital Twin oder was kann er alles für mein Unternehmen sein?
• Für welche Unternehmen oder Produkte ist ein Digital Twin sinnvoll?
• Was unterscheidet das Digital-Twin-Konzept von anderen IT-Diensten?
• Dieser Crisp Analyst View gibt Orientierungshilfe beim wichtigsten Design-Element des Internet of Things und vieler Industrie 4.0 Projekte.

Wie die meisten Technologie-Terms geistert auch der “Digital Twin” schon seit einer Weile durch die Branche bevor er wirklich Aufmerksamkeit erlangt und Verbreitung findet. Einige IoT-Anbieter bezeichnen plötzlich alles was mit Software und Daten sowie physischen Geräten zu tun hat als “Digital Twin”.

Was ist nun der Digitale Zwilling genau? Der Begriff hat sich aus zwei Anwendungsbereichen parallel entwickelt. Einerseits kam er aus der Fertigung als Digital-Twin-Prototype (DTP). Der Prototype entsteht im Rahmen eines Product Lifecycle Managements (PLM) bei der Planung oder Bestellung eines physischen Produktes, lange bevor der physische Zwilling überhaupt geboren wird. Der DTP ist besonders für die Automatisierung der Fertigung in Industrie 4.0 Szenarien entscheidend. Mit seiner Hilfe können Unternehmen beispielsweise zu der individuellen Fertigung einer “Losgröße 1” übergehen. Der DTP erscheint bei jedem Fertigungsschritt an der jeweiligen Maschine gemeinsam mit dem physischen Teil und steuert die Verarbeitung. Am Ende der Fertigung ist der physische Twin geboren und hat alle Eigenschaften des DTP erhalten.

Ganz anders verhalten sich die Digital Twin Instanzen (DTI), die aus dem Abbild eines fertiggestellten Produktes entstehen und seine fortlaufende Konfiguration oder Betriebsdaten wiedergeben. In der Automobil-Industrie spiegelt der DTP die Fertigung und der DTI die Aftersale Prozesse, wie Software Updates oder auch die Betriebsdaten wie beispielsweise Telematikdaten, wieder. Tatsächlich gibt es neben DTP und DTI eine ganze Reihe von akademischen Definitionen eines Digitalen Twins:

Akademische Digital Twin Definitionen	Autoren
“Der Digitale Zwilling ist ein Satz von virtuellen Informations Konstrukten, die ein potentielles oder physisch existierendes Produkt vom mikroskopischen bis zum makroskopischen Level beschreiben. Optimalerweise können alle Informationen die aus dem physischen Produkt erhalten werden auch aus seinem Digitalen Zwilling kommen.”	Grieves & Vickers (2016)
“Ein digitaler Zwilling ist eine integrierte multiphysikalische, multiskalige, probabilistische Simulation eines Fahrzeugs oder Systems im Bauzustand, bei der die besten verfügbaren physischen Modelle, Sensor Aktualisierungen, die Flotten Historie usw. verwendet werden, um den Lifecycle des physischen Zwillings widerzuspiegeln.“	Glaessgen & Stargel, (2012)
„Gekoppeltes Modell der realen Maschine, die auf einer Cloud-Plattform arbeitet und den Zustand simuliert, mit integriertem Wissen sowohl aus datengesteuerten analytischen Algorithmen als auch aus anderen verfügbaren physikalischen Kenntnissen“	Lee, Lapira, Bagheri, an Kao, (2013)
„Der Digital Twin ist eine reale Abbildung aller Komponenten im Produktlebenszyklus unter Verwendung physischer Daten, virtueller Daten und Interaktionsdaten zwischen ihnen.“	Tao, Sui, Liu, Qi, Zhang, Song, Guo, Lu & Nee, (2018)
„Eine dynamische virtuelle Darstellung eines physischen Objekts oder Systems über seinen gesamten Lebenszyklus hinweg unter Verwendung von Echtzeitdaten, um Verständnis, Lernen und Denken zu ermöglichen.“	Bolton, McColl-Kennedy, Cheung, Gallen, Orsingher, Witell & Zaki, (2018)
„Digtial Twins verwenden eine digitalen Kopie des physischen Systems zur Durchführung einer Echtzeitoptimierung“	Söderberg, R., Wärmefjord, K., Carlson, J. S., & Lindkvist, L. (2017)
“Ein digitaler Zwilling ist eine digitale Echtzeit-Reproduktion eines physischen Geräts.”	Bacchiega (2017)
“Ein digitaler Zwilling ist eine digitale Nachbildung einer lebenden oder nicht lebenden physischen Entität. Durch die Verbindung von physischer und virtueller Welt werden Daten nahtlos übertragen, sodass die virtuelle Entität gleichzeitig mit der physischen Entität existieren kann.”	El Saddik, A. (2018)
Im Kontext von Digital Built Britain ist ein digitaler Zwilling „eine realistische digitale Darstellung von Assets, Prozessen oder Systemen in der hergestellten oder natürlichen Umgebung“.	The Gemini Principles (2018)

Verschiedene Digital Twin Definitionen, Quelle Wikipedia

Allein theoretische Definitionen helfen Unternehmen allerdings selten bei der Umsetzung der Digital Twin Strategie. CIOs, CDOs, CTOs, Digital Portfolio Manager, Product Owner sowie Entwickler sind auf dem besten Wege durch den “Corporate Digital Twin” eher frustriert zu werden als euphorisch das Konzept und die passende technologische Implementierung zu nutzen und im Unternehmen zu promoten. Was ist passiert?

• Digital Twins gehören zur Corporate Digital Strategie. Im Idealfall bedient der Digital Twin gleich mehrere Anwendungen, die mit einem physischen Produkt interagieren. Synergien werden aber erst dann erreicht, wenn auch verschiedene physikalischen Produkte gemeinsam eine Twin-Infrastruktur nutzen.

• Digital Twins beanspruchen eine Menge Fähigkeiten der Digital Architektur. Viele Funktionen könnte man auch in einzelnen Projekten zu einem bestimmten Digitalen Produkt entwickeln. Digital Twins können nur erhebliche Synergien heben, wenn man das eben nicht macht. Beispielsweise kann die physische Konnektivität im Twin abstrahiert werden, anstatt mit jeder einzelnen Anwendung bis ins Gerät zu konnektieren.

• Digital Twins können rasch überladen werden und werden dann nie fertig. Schnell packt man zu viel in ein Digital Twin Ansatz, der dann aber nie richtig fertig wird.

Diese Situation führt zur Digital-Twin-Frustration bei Product Ownern und Entwicklern einzelner Digital-Produkte. Besonders wenn sie die Vorreiter im Unternehmen sind, tun sie sich schwer auf einen “Corporate Digital Twin” zu warten. Auch wenn man kostbares Projekt-Budget dafür verwendet allgemeine Twin-Funktionalität zu entwickeln, sind sich erfahrene IoT-Architekten schnell bewusst, dass sich dies oft nicht zum Digital Twin im Corporate Standard entwickeln wird. Das Resultat sind unvollständige Digital Twin-Insellösungen für einzelne Anwendungen, die sich auf ein und demselben Edge-Device treffen. Im Gegensatz zu PCs, die sich auf mehrere Backend-Dienste verbinden, sitzen vor IoT Devices keine Menschen, die mögliche Probleme mit multiplen Backends überblicken.

Auch für CIOs, CTOs und CDOs steckt der Digital Zwilling hierzulande oftmals in der Patsche. Ähnlich wie früher bei firmenweiter Middleware ist das Funding schwierig und eine umfassende Digital Twin-Strategie droht genauso zu scheitern wie vor 10 bis 15 Jahren der Enterprise-Service-Bus, das Event-Network oder vor 5 Jahren der Corporate Data-Lake.

Um diesem Dilemma zu entgehen, sollten die Digital-Strategen und Umsetzer der IoT- und Industrie 4.0-Projekte die jeweils passende Definition des Twin für den Reifegrad der umliegenden Anwendung im Portfolio entwickeln. Zur Verortung des Digital Twins nutzen wir aber nicht die akademischen Definitionen, sondern die IT-Infrastruktur-Dienste, die man aus der Unternehmens-IT oder Cloud-Native-Architekturen kennt. Besonders aus der Erfahrung in der Technologieberatung empfehlen wir dazu keine verbale Beschreibung, sondern die folgende Darstellung des Wertbeitrags oder der Integration zu den traditionellen Infrastruktur-Diensten. Dabei wird insbesondere deutlich was der Twin macht und was er eben nicht macht!

Digital Twin Capabilities, Quelle Crisp Research 2019

Die Abbildung zeigt die Bandbreite des von Crisp Research empfohlenen Wertbeitrags eines Digital Twins zu anderen Infrastruktur-Diensten. Wählen sie die Rolle ihres Twins zwischen den empfohlenen Extremen.

• IoT Connectivity kann durch den Digital Twin gemanagt und konsolidiert werden. Auch wenn wir zu den Funktionen des Twins selbst keine klassische Connectivity-Infrastruktur, wie Mobile Internet Gateways, Firewalls oder gar Netze zählen, ist der Twin doch für alle anderen Prozesse und Applikationen die Schnittstelle in die Connectivity. Twins ohne Connectivity-Abstraktion machen wenig Sinn, außer bei reinen DTPs. Ist ein Device online? Wann war es das letzte mal online? Wie viel Datenvolumen hat das Device noch usw. – das sind alles Informationen, die sich für alle zugänglich im Twin sammeln sollten. Over-The-Air Transport Prozesse hängen sich an den Twin und transportieren die Änderungen zum und vom Device. (Capability Empfehlung 3..5)

• Der Digital Twin ist keine klassische Middleware. Auch wenn der Digital Twin schnell als Alleskönner dargestellt wird, gibt es noch einen riesen Unterschied zu einer klassischen Middleware wie einem Enterprise Service Bus oder einem Queueing System. Während Anwendungen gerne in den Twin gewünschte Änderungen/Daten für die Devices schreiben können, ist der Weg anders herum beschränkt. Das Device kann in seinen Zwilling zwar Daten spiegeln, aber nicht von ihm verlangen diese in ein ERP System zu transportieren. Der Twin sollte keine Bringschuld für Daten in Dritte Systeme eingehen wie eine klassische Middleware. Besser verkündet er in einer Event Queue die Existenz neuer Daten. ERP-Systeme oder eine klassische Middleware subscriben diese Events und transportieren die Daten dann aus dem Twin weiter an die Zielsysteme. So konzentriert sich der Twin auf die Synchronisation mit der physischen Welt und bleibt frei von Transactions-Logik in den Rest der IT-Landschaft. (Capability Empfehlung 2..4 )

• Der Twin sollte Devices vollständig verstehen. Genauso wie der DTP die Herstellung eines physischen Produktes beschreibt, sollten die DTI Instanzen von operativen Devices deren Konfiguration vollständig verstehen. Geht zum Beispiel ein Gateway Device oder eine “Sensorbox” irgendwo im Feld kaputt, sollte sich eine neue Hardware nur durch Anmelden an den Twin vollständig wiederherstellen können. Genauso wie ein neues Apple iPhone aus der iCloud beispielsweise das kaputte Vorgängergerät eines Nutzer rekonstruieren kann, sollte es auch in der Industrie mit Devices und ihren Zwillingen funktionieren. Ein zusätzliches IoT Device Management steuert dann über den Twin die Veränderungen der Devices. Dazu gehört die Verteilung von Software-Updates und die Parametrisierung. Das IoT Device Management hat dafür die Prozess-Logic. Der Twin selbst hat wieder keine Business Logik und ist nur ausführende Infrastruktur. (Capability Empfehlung 3..5)

• Der Twin ist genauso viel oder wenig ein Data Lake wie ein IoT Device. Auch ein Device merkt sich alleine aus Kapazitätsgründen nicht alle Daten. Gute Twin-Architekturen halten in der Cloud die gleichen Daten vor, die auch auf dem Device selbst liegen, nur eben mit höherer Geschwindigkeit und immer online. Oft werden auch die gesamten historischen Konfigurationen im Twin abgelegt. Ein komplettes Archiv der Bewegungsdaten würde jedoch einen Twin oftmals überladen. Im Beispiel eines autonomen Fahrzeugs ist die vollständige Abbildung der Software- und Konfigurationsdaten des Fahrzeugs sinnvoll. Dies sind gut strukturierte Daten, deren ganze Historie auch gut in den Twin passt. Auch die Telematikdaten der aktuellen Fahrsituation gehören in den Twin, da viele verschiedene Anwendungen darauf zugreifen wollen. Die gesamte Telematik-Historie gehört aber eher in einen dedizierten Data-Lake der ggf. anonymisiert ist und auf dem Machine Learning über alle Fahrzeuge lernen kann. Wie im Crisp Analyst View zu Gaia-X dargestellt, würden Europäer den Digital Twin dabei in einer hoch-privaten Edge Infrastruktur betreiben, während der Data-Lake besser auf einen Public Cloud Hyperscaler aufgehoben sein kann. (Capability Empfehlung 2..4)

• Digital Twins sollten Analytic abstrahieren und konsolidieren. Gute Twin Konzepte machen es dem Software-Entwickler sehr einfach. Möchte man zum Beispiel die Durchschnittsgeschwindigkeit eines Fahrzeugs über ein bestimmten Zeitraum wissen, ist das ein Query an den Twin. Ist der Zeitraum vielleicht 15 Minuten, liegen alle Daten im Twin und es kommt eine sehr schnelle Antwort. Ist der Zeitraum 2 Jahre, kann der Twin den Query eher an einen externen Data-Lake weiterleiten oder darauf zugreifen. Ist der gefragte Zeitraum aber 2 Sekunden, holt sich der Twin die Daten eher real-time aus dem aktuellen Telematik-Stream, der gerade erst vom Fahrzeug bei ihm ankommt. Der Programmieren oder Data Scientist erhält also eine große Abstraktion der Analytik. (Capability Empfehlung 3,5..4,5)
• Der Twin hilft bei Autonomen Abläufen. Wie der Name schon sagt, heißt autonom, dass ein Device bestimmte Dinge alleine tut, also ohne dauernd mit dem Digitalen Zwilling zu reden. Der Zwilling hilft dabei Software mit dem Device zu synchronisieren. Das können einzelne Funktionen (siehe AWS Lambda auf Greengras) oder ganze Container sein. Der Zwilling selbst ist aber nur Transport und Synchronisations Tool – Nicht runtime für externe Business Logik. (Capability Empfehlung 2..4)

• AI und Machine-Learning gehören nicht in den Twin, er transportiert nur Modelle. Genauso wie oben für autonome Abläufe allgemein beschrieben, sollte der Twin selbst auch keine Runtime-Umgebung für Machine Learning enthalten. Der Digital Twin transportiert jedoch sehr gut Lernmodelle aus der Cloud in das Device oder das Device schiebt über den Zwilling lokale Lernerfolge wieder in die Cloud. Das alles kann asynchron und offline stattfinden. (Capability Empfehlung 1..3)

• Process Engines gehören nicht in den Digitalen Zwilling. In Prozessen wird Geschäftslogik abgebildet. Und das gehört grundsätzlich nicht in den Zwilling als generische Infrastruktur. Nur in den Fällen, bei denen Prozesse in der Cloud und auf dem Device abgebildet sind, kann es Sinn machen Process Flows genauso wie Lernmodelle oder autonomen Code über den Twin zu transportieren. Crisp Research warnt aber davor eine Prozess Engine selbst als Teil des Twin-Dienstes zu betrachten. (Capability Empfehlung 1..2)

• Digital Twins sollten mit Event Networks reden, aber nicht selbst eins sein. Geht einem kleinen Device, beispielsweise einem Rauchmelder die Batterie aus, schreibt es diesen Event noch schnell in den Twin bevor es Offline geht. Natürlich macht es Sinn, dass der Twin diesen Event auch in eine Event Queue eines Event Network schreibt. Die Event Logik – also beispielsweise die Korrelation von Events – gehört in ein dafür gedachtes Event Network – nicht in den Twin selbst. Im Beispiel würde das Event Network feststellen, dass auch ein benachbarter Rauchmelder ausgefallen ist, wodurch keine sichere Alarmierung in einem Raum möglich wäre. (Capability Empfehlung 1,5..2,5)

• Product Lifecycle Daten (PLM) können in Digital Twin Prototypen (DTP) passen. PLM Daten wie CAD-Konstruktionen oder Stücklisten zum mechanischen Zusammenbau eines Produkts passen gut in einen DTP. Crisp Research warnt aber davor DTPs und den weiteren Lifecycle nach der physischen Fertigstellung (DTI) in einen Twin zu vermischen. Oft gehören die Daten im Betrieb nicht dem Hersteller der Hardware und es gibt eine natürlich Grenze zwischen DTP und DTI. Daten zur Software Pflege eines Devices gehören aber sehr wohl in den DPI wie oben beschrieben. Dazu sind aber nur minimale Hardware Daten notwendig. (Capability Empfehlung 1..5)

Eine wichtige Aufgabe des CDOs ist die Positionierung der Digital Twin Capabilities innerhalb dieser sinnvollen Wertschöpfung. Das hängt natürlich sehr stark von den gewünschten Digitalen Produkten bzw. den Digitalen Add-Ons zu physischen Produkten ab. Die PLM Capability in der obigen Abbildung hat die größte Bandbreite. Für einen DTP ist es maximal. Für einen DTI sind nur minimalen Hardware Daten notwendig, die den weiteren Software Lifecycle unterstützen. Über die Zeit kann sich der Wert der zehn Twin Capabilities weiter entwickeln.

So vermeidet der CDO das Digital Twin Dilemma:

Den Digital Twin richtig im Unternehmen zu positionieren und über die Zeit zu entwickeln ist einer der wichtigsten Maßnahmen um die eingangs beschriebene Frustration zu vermeiden. Läßt man die Unternehmenseinheiten und einzelne Digital-Projekte alleine damit, wird man kaum die Synergien erfahren, dass mehrere Anwendungen die gleiche Twin Infrastruktur nutzen und sich dadurch austauschen. Schreibt man anders herum den einzelnen Projekten eine Nutzung eine Twins vor, ist es eher wahrscheinlich, dass man die Erwartungen gar nicht so schnell erfüllen kann. Im einzelnen empfehlen wir folgende Schritte:

• Machen Sie den Digital Twin zur Chefsache! In größeren Unternehmen gibt es eine Vielzahl von digitalen Add-Ons oder digitalen Produkten mit unterschiedlicher Digitalen Intensität aus jedem Unternehmensbereich. Synchronisieren Sie das in einem Digital-Portfoliomanagement. Der Digitale Zwilling sollte aber vom CDO zusammen mit dem CIO selbst getrieben werden. Ohne diese Management Attention ist es riskant.

• Der Digitale Zwilling braucht eine eigene Roadmap. Nutzen Sie das Digital Portfolio um die Requirements der einzelnen Projekte zu verstehen. Ein strukturiertes Requirement Management moderiert die Erwartungen der Unternehmensteile. Fangen Sie mit einem einfachen Zwilling an, der zumindest Device-Identitäten abbildet. Kommunizieren Sie dann die Twin Roadmap über den schrittweisen Ausbau der zehn Twin Capabilities.

• Entwickeln Sie den Digital Twin zu einem großen Wertbeitrag. Digital Produkte ohne einen Digitalen Twin bedeutet Full-Stack-Development mit viel Aufwand. Bei einem gut ausgebauten Digital Twin jedoch kann ein Digital-Projekt nur durch die Bereitstellung einer Mobile App als Twin Front-End schon ein vollständiges Produkt darstellen. Denken Sie an eine Remote-Charging App für ein Elektroauto. Das ist plötzlich extrem einfach weil alle Daten schon im Twin aktuell sind. Selbst einen Ladestop schreibt die App-Einfach in den Twin der sich mit dem Fahrzeug synchronisiert und die physische Ladung beendet.

• Treffen Sie Plattform-Entscheidungen nach dem Requirement Engineering. Selbst die Out-Of-The-Box Digital Twins der drei Hyperscaler Amazon, Google und Microsoft sind vergleichsweise einfach. Beispielsweise läßt sich heute mit keinem der Out-Of-The-Box Twins ein konsistenter Verbund von Embedded Controllern hinter einem Device abbilden, wie man es braucht um eine Fahrzeug oder eine komplexe Industrieanlage zu steuern. Machen Sie deshalb keine voreiligen und unnötigen Plattform-Entscheidungen. Die wirklich differenzierenden Elemente eines Twins müssen Sie sowieso selbst entwickeln. Die dazu notwendigen Technologie sind in aller Regel auf allen drei Marktführern verfügbar.

• Entwickeln Sie eine Microservice-Architektur um den Digital Twin. Der Twin hat im Idealfall selbst keine Business-Logik. Er agiert wie eine Mischung aus Middleware, Connectivity Management, Analytics-Framework und anderen Diensten in einer Landschaft von Microservices. Das Service Design einer Digital Twin Architektur würde den Umfang diesen Analyst Views sprengen. Wir werden uns diesem Thema in einem eigenen Analyst View widmen.

Crisp Research hat in den vergangenen Jahren einige Unternehmen bei der Erstellung ihrer Digital-Twin-Strategie, Technologie und Architektur begleitet. Die Balance zwischen Corporate Governance und lokaler Agilität ist wie immer in der IT-Strategie ein wesentlicher Erfolgsfaktor. Beispielsweise ist es vollkommen in Ordnung wenn zu Anfang einzelne Anwendungen die Telematik/Sensor-Daten direkt aus Fahrzeugen oder Gebäuden holen, solange sie zumindest die Device-Identitäten aus dem Twin nehmen. Später, wenn es mehr als zwei Konsumenten der gleichen Bewegungsdaten gibt, sollte der Twin dies konsolidieren.

Nur wenn die CxOs aktiv die Stakeholder in den Unternehmensbereichen identifizieren und zu einem gemeinsamen Requirement Management und Funding motivieren können, gelingt es die Synergien zu heben. Der Digital Twin wird dann für ein Unternehmen keine “Mission Impossible” sondern ein für alle sichtbarer Querschnitts-Dienst im digitalen Produkt- und Investitions-Portfolio. Crisp Research ist davon überzeugt, dass man mit einem solchen strategischen Vorgehen das Digital Twin Dilemma in den meisten Unternehmen verhindern kann.