Der Sinn eines Automotive OS

Auf dem Weg zum Software-definierten Fahrzeug

30. Januar 2023, 13:30 Uhr | Autoren: Rudolf Grave und Christoph Herzog, Redaktion: Irina Hübner

In der Automobilindustrie wird vielerorts an einem sogenannten Automotive OS, Car.OS, Vehicle.OS oder OEM.OS gearbeitet. Doch worin liegt für OEMs und Tier-Ones der Mehrwert eines eigenen Automotive OS? Aus welchen Analogien kann die Automobilindustrie lernen? Welchen Weg sollte die Industrie gehen?

Im klassischen Sinn versteht man unter einem Betriebssystem (OS, Operating System) einen Scheduler, Interrupt-Handler, OSEK OS oder Linux. Doch der Begriff Automotive OS meint im Allgemeinen etwas anderes, nämlich eine komplette Umgebung zur Entwicklung von Software für Fahrzeuge, einschließlich Zielsoftware, Cloud-Ökosystemen, Datenmanagement, Entwicklungstools, Continuous-Delivery-Systemen und vieles mehr.

Diese Umgebung muss Echtzeit- und Sicherheitsanforderungen sowie ansprechende kundenorientierte Funktionen für das Entertainment und die Unterstützung des Fahrers umfassen. Aber nicht nur das: Auch regulatorische Anforderungen im Automobilbereich wie UNECE 155/156, Sicherheitsstandards und die kommenden Vorschriften für autonomes Fahren müssen erfüllt werden.

Welche Anwendungsfälle sind denkbar? Ein Beispiel ist ein Fahrzeugservice, der einen lang anhaltenden Stau erkennt und das Mobiltelefon des Fahrers darüber informiert. So kann dieser früher aufstehen, um pünktlich zu seinem Geschäftstermin zu erscheinen.

Oder die Nutzer können gegen Gebühr Langstreckenbatteriekapazität oder den »Aggressive Highway Assist« auf Abruf erwerben. Auch Updates und Modifikationen von sicherheitskritischen Fahrfunktionen sowie die Datenerfassung zur Optimierung des Fahrzeugs und des Geschäfts der OEMs müssen berücksichtigt werden (Bild 1).

Was ist der Mehrwert eines Automotive OS?

Alles dreht sich um die Zeit bis zur Markteinführung (Time to Market, T2M). Softwarefunktionen müssen mit kurzer T2M und konstant über den Lebenszyklus des Fahrzeugs – unabhängig von Produktionsstart oder -stopp – geliefert werden. Die derzeitige, auf Zulieferern basierende Wertschöpfungskette funktioniert nicht mehr, da die ständige Bearbeitung von Änderungsanforderungen, die Integration von Softwarelieferungen und die kommerziellen Change-Requests zwischen den Firmen sie zu langsam macht.

Infolgedessen muss der OEM die Software-Architektur sowie die Art und Weise der Integration definieren, indem er die CI/CD-Umgebung (Continuous Integration, Continuous Delivery) kontrolliert. Das bedeutet nicht, dass alles von den OEMs selbst entwickelt werden muss, sondern dass Tier-Ones, Softwarelieferanten und Ingenieurdienstleister dem Automotive OS untergeordnet werden. Das erfordert ein Umdenken, zumal die entwickelte IP nicht mehr dem Zulieferer selbst gehört, sondern oft OEM-IP oder gemeinsam genutzte IP ist, was das Geschäft selbst verändert.

Die Anwendungen werden gegen eine Fahrzeug-API entwickelt. Diese Fahrzeug-API ist fest definiert und gehört dem Eigentümer des Automotive OS, aber wie sieht es mit den nicht differenzierenden Softwareelementen unterhalb der Fahrzeug-API aus, wie dem Netzwerk-Stack, den Diagnosefunktionen, dem OTA-Modul und dem Betriebssystem selbst?

Die Antwort ist nicht einfach, da es nicht nur um die Eigentumsverhältnisse geht, sondern auch um die Kosten und den Einfluss auf potenzielle Lieferanten. Die konventionelle Beschaffung von Softwareprodukten oder -lizenzen wird in den nächsten Jahren auf ein Minimum reduziert werden, da dieser Ansatz keine Kontrolle über die gelieferte Software zulässt. Da der Anbieter des Automotive OS allerdings nicht in der Lage sein wird, die gesamte benötigte Software selbst zu erstellen – ein Grund dafür ist der Mangel an Softwareentwicklern –, wird es mehr und mehr zu Kooperationen zwischen Unternehmen kommen.

Das wird mit einer bestimmten Anzahl von Funktionen beginnen, die vom Anbieter des Automotive OS pro Produkt-Iteration definiert wird, und mit einer gemeinsamen Entwicklung in einer geschlossenen Source-Entwicklung fortgesetzt werden, bis hin zu einer vollständigen Open-Source- oder Inner-Source Entwicklung der nichtdifferenzierenden Softwareelemente.

Mehr und mehr nichtdifferenzierende Funktionen werden von Unternehmen außerhalb des Automobilmarktes eingeführt werden, zum Beispiel Linux-Distributionen oder Cloud- und Datendienste, wie sie bereits heute in IoT-Anwendungen verwendet werden. All das wird enorme Auswirkungen auf das Geschäftsmodell der derzeitigen Tier-Ones und Softwareanbieter haben, wenn diese im Geschäft bleiben wollen.

Wer wird das Rennen um das Automotive OS gewinnen?

Der Übergang von der heutigen Automobilsoftware zu einem softwaregesteuerten Automobil-Ökosystem kann mit dem Übergang von einem GSM-Telefon aus dem Jahr 1998 (mit vielen, vielen Zeilen proprietärem Softwarecode) zu einem internetfähigen Smartphone (mit vielen, vielen Apps auf der Grundlage offener Schnittstellen) verglichen werden. Dieser Übergang führte dazu, dass es heute nur noch zwei vorherrschende Ökosysteme gibt: Google und Apple.

Unter den derzeit gestarteten Automotive-OS-Projekten hat das VW.OS gute Chancen auf Erfolg, da das Unternehmen über eine große Fahrzeugflotte verfügt und frühzeitig mit der Entwicklung begonnen hat. Ein Schlüsselfaktor für den Erfolg ist, ob und wann das VW.OS für andere OEMs geöffnet wird.

Eine weitere Alternative ist SOAFEE, das von Arm vorangetrieben wird . Die Idee, Hardware-IP mit darauf laufender Open-Source-Software (OSS) zu kombinieren und mit AWS zu verbinden, bringt eine unglaubliche Beschleunigung mit sich – vor allem, wenn die Softwareanbieter Serienreife- oder Sicherheits-Zertifizierungen für die Verwendung von OSS bereitstellen.

Eclipse Software-Defined Vehicle (SDV) befindet sich derzeit in der Aufbauphase und lädt viele Partner zum Mitmachen ein. Einer der Haupttreiber ist Microsoft. Das Unternehmen sieht die Chance, auf diese Weise eine starke Nutzung seiner Produkte auf dem Markt zu etablieren – dabei geht es nicht um MS Windows.

Neben den klassischen Automotive-Playern und den Tech-Giganten muss im Auge behalten werden, worauf sich der starke Software- und Automobilmarkt in Asien konzentriert.

In Japan arbeitet , ein Konsortium der führenden japanischen OEMs, an der Definition der Architektur der nächsten Generationen. Diese Aktivität ist ziemlich abgeschlossen und sehr lokal, was es den führenden Cloud- und IoT-Unternehmen schwer macht, einen Beitrag zu leisten. Außerdem wird der Markt und damit der Erfolg begrenzt, da er lokal bleibt.

Eine weitere Aktivität namens Woven Planet konzentriert sich auf Toyotas Fahrzeug-Entwicklungsplattform Arene. Deren Ziel ist es, fahrzeugunabhängige APIs zu definieren, die die Entwicklung und den Austausch von Funktionen (Diensten) ermöglichen. Erfolgversprechend könnte es für Toyota sein, die Plattform für den japanischen oder sogar den weltweiten Markt zu öffnen, um ein Ökosystem von Anwendungen zu schaffen, was auch die Investitionen reduzieren würde.

In China gibt es eine Initiative namens SDV (Software Defined Vehicle). Die Arbeitsgruppe hat eine ähnliche Vision wie andere Initiativen, nämlich eine bereichsübergreifende API einschließlich eines SDK zu definieren und zu entwickeln und diese schnell in die Industrie zu bringen. Des Weiteren laufen in der chinesischen Industrie zwei weitere Initiativen, zum einen die Harmony-OS-Initiative von Huawei und zum anderen die von Foxconn vorangetriebene MIH-EvKit-Initiative, die dieselbe Vision wie die anderen Aktivitäten verfolgt, aber mit einem stärkeren Fokus auf Identitätsmanagement und der Einführung eines offenen Marktplatzes.