Ein Digital Twin sollte erkennen, aus welchem Kontext ein User stammt und seine „Sprache“ in unterschiedliche Systeme „übersetzen“. (Bild: Siemens)
Welche Daten für den digitalen Zwilling (DT) gebraucht werden, gehört zu den wichtigsten Fragestellungen bei der Umsetzung entsprechender Konzepte. Damit verbunden ist die Überlegung, welche Fähigkeiten der DT benötigt und wie autonom er sein soll. „Im Automotive-Umfeld gibt es eine hohe Arbeitsteilung und viele einzelne Silos. Die Datenmodelle in den einzelnen Disziplinen sind sehr verschieden, es wird eine unterschiedliche Sprache gesprochen und Informationen werden nicht immer geteilt: So werden Änderungen in der Produktion beispielsweise oft nicht in der Entwicklung nachgehalten“, sagt Jörg Greitemeyer, Senior-Geschäftsfeldleiter Automotive beim Beratungshaus Unity. Ein Digital Twin sollte deshalb erkennen, aus welchem Kontext ein User stammt und seine „Sprache“ in unterschiedliche Systeme „übersetzen“ können.
Der Zwilling muss demnach Sichten verbinden und Informationen aus den verschiedensten Bereichen generieren, sei es aus dem ERP-System oder sozialen Medien. Hinzu kommen PLM- und Simulationssysteme, Kundenmanagement-, Aftersales- und Servicesysteme sowie Sensoren im Produkt selbst. „Bei der Verbindung dieser unterschiedlichen Ebenen können KI-Algorithmen helfen“, meint Unity-Manager Martin Kopp. Vor allem aber sei es wichtig, die Daten nicht am Anfang schon zu stark zu strukturieren. „Es gilt, auch die Bedürfnisse von künftigen Nutzern im Hinterkopf zu haben“, so Kopp. Aus Sicht der Berater kommt es jetzt darauf an, Use Cases zu entwickeln. „Dazu gehört es, die Frage zu stellen, welche Informationen zum Beispiel ein Bordnetz- oder ein Komponentenentwickler braucht oder welche Daten Produktion, Marketing und Sales benötigen, und dann die einzelnen Instanzen eines digitalen Zwillings verfügbar zu machen“, so Greitemeyer.
Digital Twins erfordern Abschied vom Silodenken
„In der Entwicklung ist eine fundamentale Veränderung notwendig: Von der heutigen Denkweise, bei der jemand beispielsweise für ein Bauteil und nur ‚seine‘ Daten verantwortlich ist, hin zum Ansatz ‚Proud to share‘. Hier werden Ideen nach der Aufgabenstellung geteilt und es wird offener konzipiert, zum Beispiel mit Blick auf Montagemöglichkeiten“, glaubt Martin Kopp. Diese Offenheit müsse allerdings auch in einer Datenarchitektur abgebildet werden, die unterschiedlichste, auch externe Datenquellen berücksichtigt. Dafür gilt es, Quellsysteme über APIs anzudocken. Zugleich sollte aber auch die Datenbeschreibung so gestaltet sein, dass zum Beispiel Entwickler die Daten aus der Produktion verstehen und umgekehrt. Eine Datenkomprimierung mittels Hashcode könnte dazu beitragen, dass digitale Zwillinge nicht mit großen Datenvolumen überfrachtet werden. Zugleich gehe es darum, wie Daten erneut in den Kreislauf einfließen können – wieder ein Abschied vom Silodenken.
Doch wie weit ist man heute noch vom Generative Design entfernt, bei dem Verbesserungen aus den Betriebsdaten des Produkts heraus erfolgen – und wie kann der digitale Zwilling dabei helfen? „Man hat die Konzepte schon angedacht, aber die wichtigen Daten müssen jetzt noch integriert werden. Dann können aus Felddaten Fehler und Verhaltensdaten der realen Produkte einbezogen werden“, konstatiert Jörg Greitemeyer. Ganz entscheidend ist zudem die Frage, wer die Modelle erstellt und pflegt: Das bisher oft unzureichende Datenmanagement in der Branche wird für den Digital Twin auf eine neue Ebene gehoben werden müssen.
