Die physische Welt aller möglichen Fahrzeuge von PKW und LKW, über Baumaschinen bis zu Flugzeugen ist heute leider oft mangelhaft in der digitalen Welt repräsentiert oder mit ihr verbunden. Schnell entstehen durch unsynchronisierte Digitalisierungsinitiativen einzelner Stakeholder wie CDOs, CIOs oder COOs, die oft den After-Sales Service-Lifecycle verantworten, einzelne Inseln oder ein digitales Paralleluniversum, dass mit der Realität wenig zu tun hat. Digitale Zwillinge sind die modernen Hoffnungsträger, die physische Welt zu digitalisieren und zwischen den Inseln der Stakeholder zu integrieren. Inzwischen gibt es drei Hauptvarianten von digitalen Zwillingen mit sehr unterschiedlichem Fokus. Dies hat letztlich die begriffliche Verwirrung zwischen Stakeholdern in der industriellen Fertigung, im Produktlebenszyklus und bei der Weiterentwicklung von Produkten noch verstärkt. Deshalb haben wir einem ersten Artikel zu dem Thema versucht die Begrifflichkeiten zu klären und als Beispiel aus der Fahrzeugbranche den digitalen Zwilling von Tesla genauer unter die Lupe genommen. Während viele Unternehmen in Deutschland und Österreich die vierte Industrialisierungswelle schon begonnen oder teilweise erfolgreich umgesetzt haben, ist die Digitalisierung des Post Production Lifecycle bei den meisten Produkten so vernachlässigt, dass die Serviceorganisationen und letztlich die Anwender noch gar keine digitale Erfahrung ihrer „modernen“ Produkte erleben. Um dies zu ändern braucht jede Industriesparte endlich ihr gemeinsames Verständnis vom digitalen Zwilling nach der Industrie 4.0-Fertigung. Dieser zweiteilige Cloudflight Expert View richtet sich deshalb gezielt an CDOs und Software-Architekten in der Fahrzeugbranche mit einem Vorschlag einer branchenweiten Co-Innovation, um den Post Production oder Digital Instance Twin, der das Produkt über sein Leben bei Kunden hinweg begleitet. Im ersten Teil empfehlen wir eine Architektur, während der zweite Teil einen konkreten Vorschlag für ein Ökosystem enthält. Das Konzept ist in Kooperation mit Linde Material Handling, einer der Gabelstapler-Brands der KION Group entstanden, die in den letzten beiden Jahren einen branchenführenden Ansatz entwickelt hat.
Ganz allgemein kann man den Lebenszyklus von Fahrzeugen und ihren Daten in die Zeit vor und nach der Fertigstellung bzw. Auslieferung durch den Hersteller unterscheiden. Man spricht entsprechend vom Production oder Post Production Lifecycle. Im Industrie-4.0-Kontext nennt man die entsprechenden digitalen Zwillinge auch Digital Twin Prototype für den Production Lifecycle und Digital Twin Instance für den Post Production Lifecycle, wie in vorherigen Publikationen beschrieben wurde. Wenn man die Simulation von imaginären Produkten auch durch einen digitalen Zwilling abbildet, kommt der Simulation Twin hinzu. Im Überblick könnte man folgende Charakterisierungen geben:
- Production / Prototype Twin von der Bestellung bis zur Auslieferung: Dieser Twin entsteht bereits bei der Bestellung und kann als digitaler Prototyp Informationen darüber liefern, ob eine bestimmte Konfiguration überhaupt herstellbar ist. In einer Industrie-4.0-Fertigung hat jeder automatisierte Fertigungsschritt Zugriff auf den Twin und holt sich mögliche Abweichungen von Standard-Produktionsschritten vom Production Twin. Auch Prozessdaten wie Material-Chargen-Nummern von verbauten Teilen können hier gespeichert werden. Bei der Auslieferung eine Fahrzeugs beendet dieser Twin sein aktives Leben, wird archiviert und gibt ggf. initiale Daten „as built“ an den Post Production Twin weiter.
- Post Production / Instance Twin von der Auslieferung bis zur Verschrottung: Dieser Twin begleitet das Fahrzeug über den ganzen Lebenszyklus bis zu seiner Verschrottung. Die Konfiguration wird aus dem Production Twin übernommen – Fertigungsdetails aber nicht. Hinzu kommen viele weitere Daten, auf die wir unten im Detail eingehen. Er wird damit zu Interaktionsdrehscheibe zwischen Fahrzeug und zahlreichen Nutzer- & Serviceanwendungen.
- Tracing Twins für „einfache“ Assets – praktisch jedes Ding kann einen Twin haben: In vielen Branchen geht man dazu über nicht mehr in transaktionalen Systemen zu denken, die traditionell Business-Logik und Speicherung an einer Stelle vereinen, sondern nutzt dafür einen für alle Beteiligten zugänglichen Twin, der sich auf die Statusinformationen konzentriert und Anwendungen deren Business-Logik nicht (nur) mit einer lokalen Persistenz, sondern mit dem Twin interagiert. Wie in diesem Expert View mit Beispielen aus der Logistik gezeigt kann jedes physische Objekt wie ein Paket, eine Palette oder ein Container auch einen Twin bekommen. Damit lassen sich beispielsweise interne Transportsysteme mehrerer am Transport beteiligter Unternehmen und Scanpoints mit einer Sendungsverfolgung für Kunden verbinden. Im Fahrzeug-Kontext entstehen aus serialisierten Teilen oft Sub-Twins, die eine Relation zu einem Post Production Twin haben können.
Simulation Twin für optimierte oder imaginäre Produkte und Prozesse: Über den Post Production Twin kann man viele Daten bekommen und ein gutes Verständnis der realen Nutzung erhalten. Das ist beispielsweise beim autonomen Fahren unverzichtbar. Aus den neuen Lerndaten werden immer wieder aktuellere Software-Stände ins Fahrzeug gespielt. Genauso kann man aus dem Production Twin eine Korrelation zwischen Fertigungsabläufen und beispielsweise der resultierenden Produktqualität bekommen. Der Simulation Twin kann aber viel weiter gehen und imaginäre Fahrzeuge oder Produktionsanlagen simulieren. Man könnte also simulieren, was passieren würde wenn man einen weiteren Radarsensor im autonomen Fahrzeug hätte, oder einen weiteren Roboter im Fertigungsablauf. Damit entsteht Feedback zu den nächsten Generationen der physischen Produkte. AWS setzte mit der Firma Boom Supersonic ein schönes Beispiel für solche Simulation Twins. Der neue Hersteller von Überschallflugzeugen konnte eine große Zahl von möglichen Flugzeug-Designs in der Simulation testen, bevor dann nur die Besten davon im Windkanal als Modell getestet und letztlich als realer Flugzeug-Prototyp umgesetzt wurden. Auch die Simulation von verfahrenstechnischen Schritten wie in einer Müllerverbrennungsanlage kann mit dem Software-Konstrukt eines digitalen Twins einfacher sein. Damit lassen sich Verbrennungs- und Abgasbehandlungsverfahren durchspielen, die mit der heutigen Anlage vielleicht noch gar nicht möglich sind.Für diesen Expert View konzentrieren wir uns auf den Post Production Twin in der Automobilindustrie. Bereits hier gehen die Erwartungen schon recht weit auseinander. Während sich Hersteller und Kunden im Consumer-PKW-Sektor noch nicht so einig sind, ob Fahrzeuge wirklich „Over-The-Air“ mit einem digitalen Zwilling beim Hersteller verbunden sein sollten, herrscht im B2B Sektor bereits eine große Akzeptanz für solche Fahrzeuge. Bei LKWs, Spezialfahrzeugen, Gabelstaplern, Anhängern, Fahrzeugen für Rettungskräfte oder einfach jedem kommerziellen Fuhrpark, kennt die Fahrzeugindustrie schon lange viele Use Cases:
- Software-Wartung und Fehlerkorrektur ohne Betriebsausfall oder Werkstatttermin
- Kundenspezifische Konfiguration beispielsweise von An- und Umbauten
- Predictive Maintenance der mechanischen Verschleißteile
- Steigerung der Effizienz im Service durch vorherige Kenntnis von Fehlern
- Restaurierung von Kundenspezifischen Software- und Parameter-Ständen beim Austausch von EE-Controllern
- Verkauf von Softwaredefinierten Features bis hin zu mehr Motorleistung
- Zusätzlichen Anzeige- oder Regelfunktionen mit bereits verbauter Sensorik
- Flottenmanagement inklusive Fahrer-Zugangsmanagement
- Konfiguration und Autorisierung von Leihfahrzeugen oder Equipment-as-a-Service
- Dokumentation von Telematikdaten
- Asset Tracking von Anhängern, Ladestationen, Baumaschinen
- Nutzungsbasierte Versicherung
- …
All diese Anwendungen bringen entweder für den Fahrzeughersteller, das Servicenetz oder den Betreiber ein neues digitales Geschäftsmodell mit sich. In den meisten Fällen mit direkten Vorteilen für mehrere Teilnehmer des Fahrzeug-Ökosystems. Den Herstellern ermöglicht die Nachverfolgung vernetzter Assets vor allem eine Wertschöpfung entlang des „Post Production Lifecycles“ zu generieren. Heute ist dies – wenn überhaupt – auf Full-Service-Verträge von Neufahrzeugen beschränkt, also das „erste Leben“ des Assets. Viele Automotive-OEMs bekommen immer noch zu wenig vom After-Sales-Leben ihrer Fahrzeuge mit. Ganz sicher erzeugen diese Anwendungen jedoch eine viel engere Kundenbindung zwischen Betreibern und Herstellern oder Service-Partnern, solange das Fahrzeug überhaupt in Nutzung ist.
Was hindert Hersteller daran ihre Strategien zum Leben zu erwecken?
Bereits im „ersten Leben“ des Fahrzeugs ist die durchgängige Nachverfolgung von technischen Daten, Nutzungsdaten und kommerziellen Daten – beginnend bei der Bestellung bis hin zu dessen Verschrottung – schwierig. Die relevanten Daten liegen in unterschiedlichen Teilsystemen wie ERP-Systemen, Service-Applikationen, IoT-Applikationen, CRM-Systemen oder Fuhrparkmanagement Systemen. In den seltensten Fällen passen die Datenstrukturen zusammen. CIOs und CDO sollten also nicht die Verantwortlichkeit von einzelnen Systemen (Systemarchitektur), sondern zunächst die Struktur und Semantik der Daten homogenisieren.
Noch komplexer wird es nach Vertragsende der ersten Neufahrzeugwartung oder als Gebrauchtfahrzeug. In diesem „zweiten oder dritten Leben“ des Assets führen oft nicht mehr die Servicetechniker oder Vertragspartner des OEMs den Service durch. Dabei muss man sich nur ein Fahrzeug eines Stadtwerks vorstellen, dass plötzlich anstelle einer Schneeschaufel, eine Kehrmaschine montiert bekommt. Der Anwender erwartet natürlich das sich Parameter von Steuergeräten und die Display-Beschriftung der Hydrauliksteuerung entsprechend anpassen. Neben diesen Bequemlichkeiten können aber auch sicherheits- und zulassungsrelevante Dingen wie die Höchstgeschwindigkeit angepasst werden müssen. Dieses Level sollte ein Fahrzeug-Twin abbilden, um eine langfristige Wertschöpfung und Kundenbindung zu erzeugen.
Es gibt heute schon viele Prototypen und Piloten zu den oben genannten Anwendungen, aber fast alle etablieren eine individuelle Verbindung zum Fahrzeug, sind nicht interoperabel oder kombinierbar und meist sehr proprietär. Damit liegen sie fern der Realität einer echten Unternehmensflotte. Hier sollten Fahrzeuge verschiedener Hersteller, Neufahrzeuge und Gebrauchte mit mehreren Use Cases gleichzeitig bedient werden. Auch der Service wird oft dadurch effizient, dass ein Service-Dienstleister Fahrzeuge verschiedener Hersteller wartet. Nach einer mechanischen Reparatur oder Anpassung könnte die nötige Parametrisierungen, wie im Beispiel der Kehrmaschine, „Over-The-Air“ von einem Experten kostengünstig durchgeführt werden können. Der Servicetechniker vor Ort muss also nicht die „digitale Komplexität“ des Fahrzeugs beherrschen. Die Realität der meisten kommerziellen Fahrzeuge ist heute jedoch vollkommen analog! Dabei sehen wir digitale Zwillinge als ein primäres Wachstumsfeld der Automobilbranche.
Die Vision eines digitalen Zwillings ist allgemein anerkannt. Software- und Parameteränderungen oder die Freischaltungen von Features werden nicht mehr manuell am physischen Asset vorgenommen, sondern am digitalen Zwilling, dem „Post Production Twin“ in der Cloud. So können mehrere Anwendungen mit dem Zwilling in der Cloud kommunizieren, während gleichzeitig der Hersteller eine einzige sichere Synchronisation zwischen dem digitalen Zwilling und dem physischen Zwilling – also dem Fahrzeug – sicherstellt.
Genau das hat der „Digital Lifetime Twin“ der Linde Material Handling erreicht. Bemerkenswert ist, dass Linde’s Twin keine spezielle Lösung, sondern ein offener Ansatz ist. Auf seinen Kern könnten andere Fahrzeughersteller eigene Varianten ihres Datenmodells deployen und implementieren. Er besteht im Wesentlichen aus folgender Datenarchitektur, die in einer cloud-nativen Architektur implementiert wurde.
- Technical Twin: Hier ist tatsächlich die vollständige elektrisch-elektronische Architektur (E/E Architecture) des Fahrzeugs mit all seinen Steuergeräten, ihrer Firmware und individuellen Parameterständen abgebildet. Geht ein Steuergerät kaputt, kann ein neues eingesetzt werden und der Twin restauriert die kunden- und fahrzeugspezifische Konfiguration des einzelnen Fahrzeugs. Der Technical Twin kennt die Historie aller Komponenten die aktuell oder zuvor in dem Fahrzeugverbund betrieben wurden. Eine der wichtigsten Software-Anwendungen im Fahrzeugleben ist ein zentrales Firmware-Management. Es kann bei der Planung von Roll-Out-Kampagnen vorhersehen, ob ein neuer Softwarestand zu der tatsächlich vorhandenen Hardware eines jedes einzelnen Fahrzeugs passt. In Abstimmung mit dem Kunden wird neue Software dann als „desired state“ auf den Twin in der Cloud geschrieben – noch nicht in das Fahrzeug selbst. Sobald das Fahrzeug online ist, holt es sich die Änderungsaufträge und aktualisiert sich automatisch oder mit Nutzerinteraktion. Sogar Fahrzeuge, die aus bestimmten Gründen nie online sein können (im Einsatz unter Tage, auf Schiffen oder beim Militär), können durch einen Servicetechniker mit einem Laptop verbunden werden. Dabei stellt der Laptop nichts anderes dar als eine Offline Kopie des Twins aus der Cloud und synchronisiert den lokalen Stand dann auch wieder mit der Cloud. Durch diese Entkopplung von Datentransfer und Zugriff der Anwendungen, muss eine Anwendung nicht wissen auf welchem Wege ein Fahrzeug sich synchronisiert. Firmware-Management, Parameter-Management, Flottenverwaltung mit Fahrer-Pins, Service-Anwendungen und Third-Party-Anwendungen interagieren lediglich mit dem Twin in der KION-Cloud. Dieser stellt eine sichere LTE-Verbindung mit dem Fahrzeug selbst oder über Service-Laptops her. Damit entsteht eine konsistente Handhabung selbst von Fahrzeugen ohne Mobilfunk-Gateway.
- Usage & Analytic Twin: Hier geht es um Telematikdaten. In der Praxis hat sich herausgestellt, dass für die wichtigsten Daten die aktuellen oder zuletzt bekannten Werte extrem einfach direkt im Twin verfügbar sein müssen. Dazu gehören beispielsweise die GPS-Position (soweit vom Kunden freigegeben) oder der Zustand der Batterie. Jedoch bildet der Twin nicht selbst einen Data Lake ab, der große Mengen von Telematikdaten speichert. Dafür stellt der Analytic Twin lediglich die Konfiguration und eine Proxy API dar. Im Beispiel von Linde HM landen große Datenmengen gleich in dem Data Lake der KION Analytic Plattform und die Twin API verweist auf die entsprechende Zugriffsmethode. Kunden legen beispielsweise über ihre bekannten Fuhrparkmanagement-Anwendungen individuell fest, welche Daten in die KION-Cloud wandern und welche Anwendungen darauf zugreifen können. Sind diese Regeln fahrzeugspezifisch, liegen sie auch wieder im Analytic Twin, egal auf welchem Wege Kunden diese Regeln erstellt haben.
- Status & Financial Twin: Umfangreich diskutiert wurde neben dem technischen Status des Fahrzeugs und seiner Manipulation, der betriebswirtschaftliche Zustand eines Fahrzeugs. Linde Material Handling hat in das Konzept eines Status & Financial Twins Informationen aufgenommen, die es nicht nur Linde Mitarbeitern, sondern auch sorgfältig autorisierten Dritten erlauben, zu verstehen, wem beispielsweise ein Fahrzeug gehört oder wer es möglicherweise gerade gemietet hat. Gibt es einen Service-Vertrag mit einem Service-Partner oder Zuordnungen zu Flottenmanagementsystemen eines Kunden? All diese Daten liegen ursprünglich in anderen Enterprise-Systemen, wie schon in einem früheren Expert View untersucht wurde. In der Praxis könnte beispielsweise ein Service-Vertrag zu einem Fahrzeug im ERP-System von Linde MH oder in einem der über hundert ERP-Systemen von Linde-Partnern liegen. So wird der Twin auch zum einfachen Integrationspunkt mit externen Fahrzeugvermietungen. Der Status & Financial Twin trennt hier wieder deutlich die Business-Logik der Vertragsverwaltung, die natürlich weiterhin in den jeweiligen ERP-Systemen liegt, von den Statusinformationen, die für andere Anwendungen zur Verfügung stehen. In der Praxis kann ein Servicetechniker auch bei einem größeren Fuhrpark sofort erkennen, ob er ein bestimmtes Fahrzeug reparieren darf, oder ob es möglicherweise temporär gemietet ist und von einer anderen Service-Gesellschaft gewartet wird.
- Documentation Twin: Die Wartung von hoch-konfigurierbaren B2B-Fahrzeugen ist weit komplexer als von PKWs. Durch kundenspezifische Konfigurationen und Third-Party An- und Umbauten entstehen individuelle Einzelstücke. Nicht nur bei der Wartung und Reparatur sondern auch beim Export ist der Zugriff auf ein individuelles Set von Dokumenten und Zertifikaten notwendig. Im Documentation Twin stehen dazu alle Verweise. Hier sind auch die URLs der Firmware Binaries hinterlegt die zu der individuellen Konfiguration und der Freigabe durch den Hersteller passen und vom Technical Twin referenziert werden. Der Zugriff auf den Documentation Twin ist damit die Basis für die Compliance mit den Sicherheits- und Herstellervorgaben bei allen Änderungen durch Dritte.
- Remote Access Twin: Auch wenn das Konzept einer bidirektionalen Datenspiegelung zwischen dem digitalen und physischen Zwilling für viele Dinge eine geniale Lösung ist, entsteht nicht für alle Abläufe ein Mehrwert durch einen digitalen Zwilling. Insbesondere für interaktive Kommunikation wie eine Remote-Diagnose-Sitzung macht es keinen Sinn einen Umweg über den digitalen Zwilling zu nehmen. Trotzdem hilft der Remote Twin überhaupt den Weg zum remote Zugang des physischen Fahrzeugs zu finden. Auch die Richtlinien zur Autorisierung und Authentifikation können hier liegen. Damit kann ein Fuhrparkleiter beispielsweise die Gruppe von Service-Technikern festlegen, die überhaupt einen Remote-Dialog zu einem Fahrzeug eröffnen dürfen. Auch die Protokollierung von Remote-Zugriffen könnte im Remote Access Twin auditierbar gespeichert sein.
Zusammenfassend kann sich ein Programmierer die Interaktion mit dem Digitalen Post Production Twin wie die direkte Programmierung gegen die Programmierschnittstelle (API) des Fahrzeugs vorstellen. Nur dass der Twin eben immer verfügbar ist, auch wenn das Fahrzeug vielleicht gerade nicht online ist. Als Cloud-API kann man sehr professionell mit der Sicherheit und Privatsphäre umgehen und die üblichen Hackerangriffe, DDOS-Attacken, Man-In-The-Middle oder physische Beschädigungen durch vorsätzlich falsche Parametrisierung abwenden. Die Kommunikation zwischen digitalem Zwilling und Fahrzeug findet nur in einem sicheren Tunnel zu einem dedizierten LTE/5G APN statt. Zusätzlich gibt es natürlich eine Verschlüsselung des Datentransports und Signaturen von Binärdateien. Damit ist nur die Kommunikation von Anwendungen zum digitalen Zwilling, nicht aber der Traffic von dort zum Fahrzeug im öffentlichen Internet sichtbar. Außerdem lässt der digitale Zwilling den Zugriff von mehreren verschiedenen Anwendungen und verschiedenen Nutzergruppen gleichzeitig zu. Im digitalen Zwilling ist dabei selbst gar keine Business-Logik hinterlegt; sie liegt weiterhin in den Anwendungen. Das Einzige, was der Twin bei Linde Material Handling selbst regelt, ist ein smarter Umgang mit möglichen Konflikten, die durch den gleichzeitigen Zugriff oder zeitverzögerte Synchronisierung entstehen könnten.
Nicht nur theoretisch, sondern auch in der Praxis geht damit beispielsweise der Austausch eines EE-Steuergeräts wirklich so einfach, wie ein defektes iPhone aus der Apple-Cloud auf ein neues Smartphone zu restaurieren.
Kann man einen Fahrzeug-Twin nicht einfach fertig kaufen?
Linde MH und Cloudflight haben bereits vor zwei Jahren die führenden IoT-Plattform und dem PLM-Anbieter am Markt betrachtet. Dabei muss man zwischen den verschiedenen Twin-Ansätzen entlang des Lebenszyklus eines Produktes unterscheiden. Wir fokussieren uns auf den Post Production Twin, wie eingangs geschildert. Trotz des Fokus darf der Twin aber keine neue Insel sein und sollte eine Interoperabilität zum Production Twin haben. Ein Simulation Twin setzt Linde MH heute noch nicht ein. Dieser wäre jedoch für Fahrzeuge mit autonomen Assistenzsystemen wichtig, wie sie schon in anderen Unternehmensteilen der KION Group existieren.
Sowohl das Leistungsangebot von PTC als auch von SAP ist im Hause bekannt. Beide Hersteller bieten aus ihrer jeweiligen Domäne und mit einigen Überlappungen einen umfangreichen Ansatz für die PLM-Welt während der Entwicklung bzw. während der Fertigung. Hier liegt der Fokus auf den Bereichen Engineering und Production des Lebenszyklus. Dazu bieten diese und vergleichbare Hersteller auch entsprechende Datenmodelle an und das Unternehmen hat eine Anpassung auf die spezielle Ausprägung der Linde Fahrzeuge gewählt. Mit der PLM-Welt kommuniziert die Fahrzeugentwicklung die möglichen Kombinationen aus Hardware, Elektronik, Software-Versionen und passender Parametrisierung in einer „As Allowed“ Datenschnittstelle. Die SAP-Welt bildet dann darauf aufbauend Fertigungsaufträge ab, die man als Digital Prototype Twin bezeichnen könnte. Mit der Auslieferung eine Fahrzeugs werden relevante Informationen in den Post Production Twin übernommen. Dieser begleitet das Fahrzeug nun über seinen ganzen Lebenszyklus vom ersten Einsatz, weiteren Konfigurationen durch Servicepartner bis zur Verschrottung. Die Vielfalt der möglichen Konfigurationen mit fortlaufenden Aktualisierungen aus der Entwicklung steht dann auch weiterhin dem Post Production Twin bzw. den Serviceanwendungen, die damit interagieren, zur Verfügung. Dies stellt sicher, dass keine Software-Kombinationen oder Parametrisierungen nach der Auslieferung erzeugt werden, die unzulässig oder außerhalb der Sicherheit und Zulassung der Fahrzeuge liegen.
Für den Post Production Twin sieht das Herstellerangebot allerdings ganz anders aus. Gängige Asset Lifecycle Management Systeme (z. B. von SAP) können zwar komplexe Eigenschaften von Assets abbilden, aber keine Wertschöpfung bis auf die Ebene der einzelnen Controller im Fahrzeugverbund anbieten. Da jedes Fahrzeug zwischen 30 und im PKW-Bau oft über hundert Controller im EE-Verbund haben kann, muss ein Post Production Twin schnell mit einigen Millionen Twin Assets umgehen, die binnen weniger Sekunden mit dem Fahrzeug interagieren. Denken Sie an die Freischaltung eines Fahrzeug-Zugangscodes vom Fuhrpark-Management über den Twin, über die Over-The-Air-Schnittstelle ins Fahrzeug. Diese gesamte Übertragung sollte nicht mehr als eine Minute dauern, um praxistauglich zu sein.
In diesem High-Performance-IoT-Bereich positionieren sich hauptsächlich die drei Hyperscaler (AWS, Microsoft, Google), während die klassischen PLM Anbieter kaum Marktanteil haben und vorgefertigte Funktionalität bieten. Wie im folgenden Bild deutlich wird, konzentrieren sich die Hyperscaler mit ihren hochskalierbaren Plattformen auf horizontale – also branchenunabhängige – Angebote:
Vom Fahrzeug OEM, Linde MH, selbst kommt natürlich die elektrisch-elektronische (EE) Architektur des Fahrzeugs. Hier gibt es auch wieder einige Tooling-Anbieter wie BOSCH, die zum Flashen und Parametrisieren der EE-Komponenten eingesetzt werden. Insidern in der Branche ist auch bekannt, dass BOSCH umfangreiche digitale Zwillinge für einzelne Automotive OEMs individuell geliefert hat. Trotzdem kommt aus Feuerbach bis heute leider kein Produktangebot eines generischen digitalen Zwillings für die EE-Architektur. Daher wurden, grob zusammengefasst, die Komponenten auf der linken Seite der Abbildung aus Cloud-Diensten orchestriert und die automotive-spezifischen Anforderungen auf der rechten Seite von Linde MH und seinen Partnern selbst entwickelt.
In der Abbildung der EE-Architektur ist hier nicht nur eine Hierarchie sondern auch ein Konzept von Sub Twins enthalten, wie tauschbare Batterien oder Anbauteile, die vorübergehend zum Fahrzeugverbund gehören. Sie haben langfristig ihren eigenen Lebenszyklus und möchten in ihrem Sub Twin beispielsweise eine Ladehistorie ablegen, obwohl sie sich eigenständig gar nicht mit dem digitalen Zwilling verbinden können. Trotzdem müssen sie vom Technical Twin als Teil des EE-Verbundes gesehen werden und kompatibel mit ihm sein.
In der Cloud stellt der Fahrzeughersteller dann unter Zuhilfenahme der allgemeinen Plattformdienste, das Spiegelbild des Fahrzeugs als digitalen Zwilling in den oben beschrieben Daten-Domänen dar. Dabei kann die Digital Twin Definition Language (DTDL) helfen, die auf JSON-LD basiert und für die meisten Programmierer sehr intuitiv ist. Die Twin-Daten sind damit dann auch meistens JSON-Dokumente. Dies ist besonders praktisch da man damit einerseits streng definierte Datenschemata durchsetzen kann, aber andere Datenbereiche, die möglicherweise von 3rd-Party-Komponenten erzeugt wurden, recht flexibel lassen kann. Entsprechend sind generische Document-Datenbanken wie Microsofts CosmosDB oder die MongoDB, die als der Atlas-Service auf allen Hyperscalern verfügbar ist, eine gute Option. Letztere unterstützt sogar verteilte Multi-Cloud Szenarien bei denen verschiedene Hyperscaler gleichzeitig eingesetzt werden. DTDL wird auch von Microsoft präferiert und im Tooling unterstützt. Wir hatten das Format gerade für einen Logistic Twin betrachtet, bei dem Tracing Twins für Pakete, Paletten und Container damit definiert wurden. Dies ist vergleichbar mit serialisierten Teilen, die einem Sub Twin in einem Linde Fahrzeugverbund erhalten.
Linde Material Handling legt der Fahrzeugbranche den Blueprint eines Twins vor
Letztlich war die oben beschriebene Erstellung eine Post Production Twins für Fahrzeuge eine Menge Arbeit für einen Fahrzeug-OEM, die er heute von keinem Softwarehersteller abgenommen bekommt – egal welche Plattformhersteller man sich zur Hilfe holt. Die Hyperscaler AWS und Microsoft bieten gutes Tooling, aber keine branchenspezifischen Datenmodelle. Die klassischen Engineering- und PLM-Software-Hersteller wie PTC und SAP mit seinem Asset Lifecycle Management müssten extrem erweitert werden und bieten keine skalierbare Laufzeitumgebung, um Millionen von Fahrzeugen mit einigen 10 Millionen embedded Controller über Jahrzehnte ihres gesamten Post Production Lifecycle kostengünstig abzubilden.
Genau bei diesem Dilemma setzt das offene Fahrzeug-Twin-Konzept der Linde Material Handling an. Die Datenmodelle der Fahrzeuglogik so allgemein modelliert und implementiert, dass man damit nicht nur schnell ganz andere Fahrzeuge der KION-Group abbilden konnte. Darüber hinaus wird es mittelfristig den Service-Gesellschaften, die teilweise zur KION-Group gehören, aber auch teilweise selbstständige Unternehmen sind, möglich, komplett andere Fahrzeuge abzubilden, die sie möglicherweise auch in ihren Serviceverträgen haben. Entsprechend können auch andere Fahrzeughersteller von PKWs, LKWs, Sonderfahrzeugen bis hin zu Baumaschinen ihre individuelle Modellierung der Fahrzeugarchitektur auf dem vorhanden generischen Fahrzeugmodell aufsetzen. Damit wären sie technologisch deutlich schneller am Ziel. Linde MH und die KION Group sind gesprächsbereit einen Community-Ansatz mit der Fahrzeugindustrie in Europa zu führen. Wie dies gelingen kann, was die Erwartungen aller Beteiligten sind und wie so ein Post-Production-Twin-Ökosystem aussehen könnte, lesen Sie im zweiten Teil, der sich gezielt an CXOs und Strategen der Fahrzeugindustrie richtet.