Das Ökosystem für ein ganzes Fahrzeug-Zwillings-Leben

Das große Potential der Automobilindustrie ist ein digitales Ökosystem für die zukünftigen Consumer- und B2B-Fahrzeuge gleichermaßen. Experten der Fahrzeugbranche sind sich einig, dass dieses mit einer proprietären Punkt-zu-Punkt-Kommunikation zwischen Software-Anwendungen und Fahrzeugen nicht mehr abbildbar ist. In dem gerade erschienenen Artikel „Die Architektur für ein ganzes Fahrzeug-Zwillings-Leben“ konnte Cloudflight in Kooperation mit der Linde Material Handling als einem innovativen Vertreter der B2B Fahrzeughersteller einen technischen Lösungsansatz vorstellen. Ein digitaler „Post Production Twin“ abstrahiert die Kommunikation zum Fahrzeug und repräsentiert stets den aktuellen Stand eines Fahrzeugverbundes mit performanten Schnittstellen in der Cloud, anstatt direkt und einzeln mit dem Fahrzeug zu kommunizieren. Dieser zweite Artikel richtet sich nun gezielt an CXOs und Lobbyisten der Branche, um die strategischen Ansätze einer Community zur Umsetzung dieses Konzepts zu diskutieren und vorzuschlagen. Nun verfolgen wir konkret die Fragestellung, ob und wie Linde Material Handling und andere Unternehmen der Branche ein offenes Ökosystem erschaffen können.

Während in der Industrie 4.0 rund um die Automatisierung und Digitalisierung der Produktion viel passiert ist, fehlen für den Post Production Lifecycle weitgehend Standards. Obwohl gerade hier die Kollaboration zwischen Fahrzeugen in einem Fuhrpark und auch beliebigen Fahrzeugen im öffentlichen Verkehr (V2X) wichtig wären, gibt es praktisch nur proprietäre Lösungen im Markt. Viele Anwendungsfälle wie eine Digitalisierung der Service Prozesse, Verkauf von digitalen Add-Ons oder ein modernes Flottenmanagement setzen sich nicht durch, weil jede Anwendung einzeln zu jedem Fahrzeug jedes Herstellers spricht. Einige von Ihnen werden sich vielleicht noch an Unternehmenssoftware-Landschaften vor der Erfindung von moderner Middleware erinnern. Heute ist aus Unternehmenssoftware im Rechenzentrum und in der Cloud moderne Middleware wie ein Service Bus, Event Management, Adapter Framework oder API Management nicht mehr weg zu denken. Diese Software-Konzepte ermöglichen uns die Kombination aus ERP-, CRM-, eCommerce- oder HR-Systemen verschiedener Hersteller. Genau diese Aufgabe kann ein digitaler Zwilling für die Fahrzeugindustrie über den ganzen Lebenszyklus der Fahrzeuge erfüllen, wenn sich mehrere Hersteller auf ein Konzept einigen würden.

Einer der Vorreiter in der Fahrzeugindustrie in Bezug auf den digitalen Zwilling ist die Firma Linde Material Handling, die Teil der KION Group und vor allem durch ihre Gabelstapler bekannt ist. Bereits seit Anfang 2020 liefert Linde MH Gabelstapler mit einem Post Production Twin aus. Dieser Twin ist so generisch modelliert und implementiert, dass er nicht nur für andere Unternehmensteile und Fahrzeuge der KION Group leicht adaptierbar ist, sondern sogar als Blueprint für die Fahrzeugindustrie dienen könnte.

Types-of-digital-twins-in-automotive

Im ersten Expert View haben wir mit Linde MH genauer betrachtet was hier überhaupt entstanden ist, wie es gegenüber den Systemen in der Entwicklung und Fertigung abgegrenzt ist und mit Systemen im Service integriert ist. Vor allem wurde auch klar, wie komplementär die IoT-Plattformen der Public-Cloud-Anbieter ergänzt wurden, anstatt mit ihnen in Konkurrenz zu treten. Kurzum würde man den digitalen Zwilling der Linde MH als Domainspezifische IoT-Plattform bezeichnen, während die kommerziell erhältlichen IoT-Plattformen ja gerade branchen- und domänenunabhängig sind. Der Ansatz bietet eine relativ generische Datenmodellierung zur Abbildung von Fahrzeugen mit komplexen EE-Architekturen (EE = elektrisch-elektronisch), aber ist andererseits auch so flexibel, dass rasch komplett andere Fahrzeuge abbildbar sind. Motiviert war dieser Ansatz auch durch das Plattform-Konzept der KION Group, die mit der Firma Still eine zweite Gabelstapler-Brand am Markt hat und mit Dematic ein Marktführer für Intralogistik ist. Vergleichbar mit den Plattform-Baukästen der PKW-Hersteller strebt die KION Group gemeinsame Entwicklungen und Gleichteile in Fahrzeugen über die Brands hinaus an. Darunter fällt auch die EE-Architektur, die für viele neue Fahrzeuge gleich sein wird, obwohl es sich um sehr unterschiedliche Fahrzeuge handelt. Deshalb lag es nahe auch für den digitalen Zwilling einen Ansatz zu wählen der allgemein und gleichzeitig leicht spezialisierbar ist.

Cloudflight hat bereits einige Publikationen zum Thema IoT-Plattform-Strategie veröffentlicht. Strategisch gesehen haben Fahrzeughersteller, wie die KION Group, verschiedene Optionen mit digitalen Zwillingen und domainspezifischen IoT-Plattformen umzugehen:

  1. Twin/IoT-Plattform und die Anwendungen selbst entwickeln: Unternehmen differenzieren sich durch ihre Produkte und Software-Anwendungen am Markt. Die darunter liegenden Plattformen sind für Kunden oft nicht einmal transparent. Hersteller sollten deshalb auf jeden Fall die Software-Anwendungen, die für ihre Kunden und Servicepartner sichtbar sind, selbst schreiben. Wenn die nötigen Plattformen nicht von Software-Herstellern angeboten werden und sich keine Co-Innovations- oder Community-Modelle finden, muss man auch die domainspezifischen Teile der Plattform selbst entwickeln. Dieser heute eingeschlagene Weg bedeutet langfristige Investitionen in Basistechnologie und ist für kleinere Fahrzeughersteller kritisch.
  2. Warten auf die digitalen Zwillinge von Software-Herstellern wie Amazon, Bosch, IBM, PTC oder SAP, die EE-Architekturen für Post Production Twins generisch abbilden können. Sobald es hier Lösungen für die Fahrzeugbranche gibt, die wirklich auf dem heute bereits erreichten Niveau sind, könnte man die Plattform zu einem dieser Hersteller migrieren und sich auf deren Anpassung und die Entwicklung der für Kunden sichtbaren Anwendungen konzentrieren. Dies kann noch einige Jahre dauern und wird dann auch signifikante Lizenzkosten oder einen Anbieter-Lock-In erzeugen. Datenmodelle beziehen sich heute nicht genug auf die Fahrzeugbranche oder die Laufzeit-Performance für Millionen von Twin Assets ist kaum kostengünstig über Jahrzehnte darstellbar.
  3. Einen Spin-Off bilden, um die Twin-Daten-Architektur und ihre Implementierung oder auch ihren cloud-nativen Betrieb über die Unternehmensgruppe hinaus zu vermarkten. Damit bewegt man sich in ein reines Software Business in dem ein Fahrzeughersteller nicht zuhause ist. Partnerschaften oder Co-Investment mit einem Software-Anbieter können eine Lösung sein. Durch eine dauerhafte Beteiligung des eigenen Unternehmens und anderer Fahrzeughersteller am Spin-Off kann ein negativer Lock-In vermieden werden.
  4. Einen Community-Ansatz mit vergleichbaren Herstellern und Service-Unternehmen bilden, der sich auf die Weiterentwicklung des Twin-Kerns fokussiert. Hier liegt die Definition der Plattform mit Datenmodellen und APIs bei einer Non-Profit Community, während unabhängige IT-Dienstleister kommerzielle Implementierungen der entstehenden Standards anbieten.

Der richtige Weg hängt letztlich vom Entwicklungsstand der Branche ab. Vor zwei Jahren gab es keinen einzigen Fahrzeughersteller, der den gesamten elektrisch-elektronischen Fahrzeugverbund über das ganze Fahrzeugalter abgebildet hat. Selbst in der Aerospace-Branche wurden nur einzelne Teile – wie die Turbinen – durch vollständige Twins abgebildet. Vorreiter, wie Linde MH, mussten also Anwendungen und den digitalen Zwillingskern selbst entwickeln. Der Vorsprung gegenüber Herstellern, die branchenübergreifenden Software adaptieren könnten, ist immer noch immens, was die Option 2 kombiniert mit signifikanten Lizenzkosten auch heute noch nicht attraktiv erscheinen lässt. Schauen wir uns die Möglichkeiten eines Spin-Offs oder einer Community genauer an:

Eine ähnliche Herausforderung hatte die Fahrzeugindustrie vor 25 Jahren, als die Komplexität der EE-Architektur selbst mit vielen Steuergeräten von unterschiedlichen Herstellern nicht mehr beherrschbar war. Steuergeräte von Bosch, Brose und Continental in einem Fahrzeug zu mischen war funktional und unter Kostenaspekten hoch attraktiv aber technisch praktisch unmöglich. Dies führte im Jahre 2003 zur gemeinsamen Definition der AUTOSAR Architektur durch Automobilhersteller und die Zulieferindustrie. Sie bildet bis heute die Grundlage für die Interoperabilität von Steuergeräten verschiedener Hersteller INNERHALB eines Fahrzeugs. Es ist nun an der Zeit, dass die Automobilbranche – und damit sind nicht nur die Hersteller, sondern auch die Service und Maintenance-Anbieter gemeint – eine Datenarchitektur für Fahrzeug-Zwillinge ins Leben rufen, die Fahrzeuge herstellerübergreifend NACH AUSSEN mit der Cloud verbinden.

Cloudflight hatte ja bereits in einem eigenen Expert View den digitalen Zwilling von Tesla untersucht. Hier kann man zwar einiges zu der Verteilung von Daten zwischen einem Technical Twin und einem Remote Twin lernen, der Ansatz ist aber keineswegs offen oder für einen Community-Ansatz geeignet. Es liegt nahe den Ansatz von Linde MH als Blueprint für einen Community-Ansatz zu diskutieren. Warum glaubt Cloudflight, dass so eine Community funktionieren könnte?

Nun, die gleiche Autmobilindustrie, die sich hier zusammenfinden müsste, hat bereits für die Industrie-4.0-Fertigung ähnliche Industrie-Communities um kommerzielle Hersteller gebildet. Ein schönes Beispiel ist die Adamos Allianz um den IoT-Software-Hersteller Software AG oder das Mindsphere-Ökosystem um Siemens. IoT vor und nach der Produktion ist ähnlich und doch so unterschiedlich. Die Industrie-4.0-Welle hat einerseits eine klasse Vorarbeit geleistet, was die Technologie und die Organisation der Branche angeht, aber leider das Produkt im Post Production Lifecycle meist komplett vernachlässigt. Es wäre also ein guter Zeitpunkt, eine Community um Post Production Twins für die gesamte Fahrzeugindustrie zu bilden. Strategische Schritte dazu könnten im Einzelnen folgende sein:

  1. Von der Industrie 4.0 und AUTOSAR lernen: Die Automatisierung in der Fertigung hat eine lange Tradition. Daten-Architekturen entwickeln eine Interoperabilität zwischen verschieden Systemen entlang der Fertigungslinie. Hier gibt es auch die „Asset Administration Shell“, die theoretisch auch einen digitalen Zwilling fertiger Produkte abbilden kann. In der Realität werden hier aber mehr die Fertigungsmittel als die Produkte abgebildet. Es besteht deshalb auch ein Mapping zu der Automatisierungsarchitektur OPC Unified Architecture (OPC-UA), die von der OPC Foundation moderiert wird. Auch AutomationML kann auf dieser Industrie 4.0 Verwaltungsschale abgebildet werden. Größere Dienstleister oder Allianzen aus Industrie und Software-Herstellern wie Adamos bieten für einzelner Branchen Frameworks und vordefinierte Datenstrukturen an. Die Industrie-4.0-Ansätze sind zwar über mehrere Teilnehmer einer Supply-Chain kollaborativ, aber leider nur für die Automatisierung selbst, nicht für einen fahrenden Fahrzeugverbund mit Telematikdaten ausgearbeitet. Der AUTOSAR Standard hingegen deckt, gerade andersherum, die Detailkommunikation zwischen Controllern in einem Fahrzeug ab, war aber nie für die Kommunikation aus dem Fahrzeug heraus oder gar als kollaborative Kommunikation in der Cloud gedacht.
  2. Eine Non-Profit Foundation und ein kommerzielles Konsortium kombinieren:
    Datenstandards setzen sich dann besonders gut durch, wenn sie ohne kommerzielle Konflikte in einem Non-Profit Konsortium gebildet werden. So machte es die Europäische Datenstrategie mit der Industrial Data Spaces Association, die um die Fraunhofer Gesellschaft entstanden ist und heute von kommerziellen Software und Infrastrukturanbietern auch mit dem Gaia-X Ansatz begleitet wird. Unternehmen können selbst eine mit den Industrial Data Spaces konforme Kommunikation aufbauen oder zwischen den kommerziellen Anbietern wechseln. In den USA hat sich bereits das Digital Twin Consortium gebildet, dass von der OMG geführt wird, die auch das Industrial Internet Consortium verantwortet. In Deutschland gibt es parallel dazu die Industrial Digital Twin Association, die vom VDMA und ZVEI gemeinsam mit dem Bitkom gegründet wurde. Leider verfolgen bei Associations hauptsächlich den industriellen Production Twin im Industrie-4.0-Kontext, wie die Industrial Digital Twin Association auf Anfrage von Cloudflight bestätigte. Grundsätzlich könne man sich hier aber auch die Definition eines Post Production Twins vorstellen oder mit einer darauf fokussierten Association kooperieren.
  3. Kommerzielles Ökosystem aufbauen: Besonders kleinere Fahrzeughersteller oder eigenständige Service-Unternehmen von B2B Fahrzeugen sind meist zu klein, um selbst in IoT-Plattformen zu investieren. Es wäre ideal, wenn es aus inhaltlich führenden Unternehmen, wie der KION Group, einen kommerziellen Spin-Off gäbe, der aber keine Exklusivität hat. Während es genau ein Standard-Konsortium geben sollte, ist es bei den kommerziellen Providern genau andersherum. Ein gesunder Wettbewerb von kommerziellen Anbietern, die Fahrzeug-Zwillinge als SaaS-Lösung oder kundenspezifische Modellierung und Software Implementierungen anbieten, ist innovativ und bringt den API-Datenstandard in den Markt.
  4. Co-Innovation mit Telcos und Hyperscalern initiieren: Die Fahrzeug-zu-Twin- Kommunikation hat gewisse strategische Parallelen zur Fahrzeug-zu-Fahrzeug- Kommunikation und 5G-Herausforderung der Automobilindustrie. Auch für den digitalen Zwilling von Fahrzeugen im Feld ist eine professionelle Mobilfunkverbindung essenziell und es kann sinnvoll sein Teile der Twin-Infrastruktur in die 5G-Multi-Access-Edge zu legen. In diesem Bereich kooperieren die Hyperscaler mit den Telcos gerade intensiv.

Zusammenfassend könnte also ein Spin-Off aus Linde MH das dort geschaffene Konzept eines digitalen Zwillings der gesamten Fahrzeugbranche zugänglich machen. Es wird aber nur wirkliches Markt-Moment aufnehmen, wenn sich parallel eine non-profit Community bildet, die die vorliegende Daten- und API-Architektur zu einem anerkannten Standard weiterentwickeln.

Welchen Weg die Linde Material Handling und die KION Group letztlich einschlagen werden, ist heute nicht öffentlich bekannt. Es könnte aber auch von der Resonanz in der Branche auf diese beiden Artikel abhängen.

Auf dem Weg zur einem standardisierten Fahrzeug-Zwilling sollten die Strategen und Lobbyisten nie vergessen: Die Vision hat viele Beispiele! Der digitale Zwilling könnte für die Fahrzeugindustrie so revolutionär wie vor 25 Jahren die Standardisierung des USB-Steckers mit einem einheitlichen Protokoll für alle möglichen Geräte in der Computerindustrie sein. Es ist jetzt an den Herstellern und den Service-Unternehmen so einen Standard zur digitalen Multi-Access-Interaktion mit Fahrzeugen zum Leben zu erwecken.

#Cloudflight

Haben Sie Themen, die Sie mit unseren Experten diskutieren möchten?

Schreiben Sie uns

Schreiben Sie uns

Menü