Wie Automotive.OS Software Defined Vehicles ermöglicht

Bei softwaredefinierten Produkten schätzen die Anwender unter anderem Benutzerfreundlichkeit, regelmäßige Updates mit Funktionserweiterungen und die Einbindung in ein vertrautes Ökosystem. Auch beim softwaredefinierten Fahrzeug (SDV) wird das Anwendererlebnis zunehmend von durch Software realisierten Funktionen definiert. Beispiele finden sich zur Genüge, von Assistenzsystemen und automatisierten Fahrfunktionen bis zum Infotainment, nahezu alle Funktionalitäten benötigen Software.

Historisch gesehen sind in der Automobilindustrie Software- und Hardwareentwicklung für solche Funktionen eng miteinander verbunden, da die Software-Funktion traditionell an ein (dezentrales) Steuergerät gekoppelt ist und im Verbund an einen Lieferanten zur Entwicklung vergeben wurde. Diese Praxis erweist sich jedoch zunehmend als Hindernis. Das dynamische Marktumfeld mit sich schnell ändernden Kundenanforderungen und hohem Wettbewerbsdruck erfordert eine kontinuierliche Weiterentwicklung der (Software-) Funktionen. Es braucht daher eine (zumindest teilweise) Entkopplung von Hardware- und Softwareentwicklung, was eine effizientere Entwicklung und Wartung ermöglicht, dazu beiträgt kundenrelevant zu bleiben und auch die Integration in Ökosysteme erlaubt.

Das Automotive Operating System als Wegbereiter des SDV

Dies erfordert einen neuen Ansatz einer automobilen Softwarearchitektur und -entwicklung. Hier kommt ein „Automotive Operating System“ (AOS) ins Spiel. Wenngleich es keine einheitliche Definition eines AOS in der Branche gibt, kann man es (stark vereinfacht) mit einem Smartphone Betriebssystem (z.B. iOS oder Android) vergleichen: Im Wesentlichen geht es um eine Softwareplattform, die als Abstraktionsschicht zwischen Hardwareplattform und Anwendungssoftware fungiert und gleichzeitig einen Entwicklungsrahmen für beide bereitstellt. Die Softwareplattform ermöglicht mit ihrem Entwicklungsrahmen einerseits die Entwicklung von kompatibler Hardware und andererseits die Entwicklung von kompatibler Anwendungssoftware. Die Softwareplattform reicht von Kerndiensten (z. B. Hypervisor) und Middleware (z. B. Kommunikationsschnittstellen) bis hin zu Plattformdiensten (z. B. Gerätestatus und Sicherheitsmanagement) und standardisierten APIs (Bild 1).

Somit spielt ein AOS eine entscheidende Rolle dabei, unabhängig voneinander entwickelte Hardware und Anwendungssoftware kompatibel zu machen und ein nahtloses Zusammenspiel zu ermöglichen. Diese Abstimmung vereinfacht nicht nur die Entwicklung, sondern ermöglicht den Benutzern auch ein verbessertes Kundenerlebnis, das durch kontinuierliche Verbesserungen und die bequeme Bereitstellung von Software-Updates über die installierte Hardware weiter optimiert werden kann.

Im Beispiel automatisierter Fahrfunktionen muss die Applikationssoftware (z. B. automatisiertes Einparken mit Integration im HMI) auf die Hardwareplattform (z. B. die Abstandssensoren, die Lenkaktuatorik) zugreifen können. Die Softwareplattform bzw. die Entwicklungsumgebung stellt hierfür die notwendigen Schnittstellen zur Verfügung, so dass sich sowohl Hardware (z.B. neue Fahrzeug-Generation mit weiterentwickelter Sensorik) als auch Applikationssoftware (z.B. neue Version mit weiteren Funktionen) unabhängig voneinander weiterentwickeln können (Bild 2).

Die Entkopplung der Entwicklung von Hardwareplattformen und Anwendungssoftware, die durch das Betriebssystem ermöglicht wird, bedeutet auch, dass die Anzahl der Varianten der Anwendungssoftware durch Wiederverwendung reduziert werden kann. Vereinfacht ausgedrückt: Wenn Hardware und Software unabhängig voneinander entwickelt werden können, muss es nicht eine Softwareversion pro Hardwareversion geben. Erst dann wird das Lebenszyklusmanagement von softwaredefinierten Produkten handhabbar. Das Betriebssystem fungiert jedoch nicht nur als Verbindung zwischen Hardwareplattform und einzelner Anwendungssoftware, sondern auch als zentrale Management- und (over the air) Updateplattform des gesamten Produkts.

Der steinige Weg zum eigenen AOS

Aufgrund der Bedeutung des AOS bemühen sich viele OEMs derzeit darum, ihre eigene Softwareplattform zu etablieren: Arene OS (Toyota), Xmart OS (Xpeng), MB.OS (Mercedes-Benz), Ford.OS (Ford), um nur einige Beispiele zu nennen. Die Motivation eine proprietäre Plattformlösung zu etablieren sind dabei vielfältig. Die Aussicht auf erhebliche Reduzierung der Komplexität bei der Softwareentwicklung, Integration und Wartung und damit kürzere Markteinführungszeiten für Software kann als einer der wesentlichen Gründe gesehen werden. Zudem wird eine deutliche Verringerung der Komplexität der Lieferkette und Erweiterung der Lieferantenbasis durch einen standardisierten Entwicklungsrahmen erwartet. Eine Verlängerung des Lebenszyklus der Hardware sorgt erwartungsgemäß für eine bessere Kostenposition bei Hardwareplattformen. Ebenfalls sollte ein effizienteres Management des Produktlebenszyklus und Vermeidung redundanter Investitionen in Software positiv auf die Kosten wirken. Schließlich kann auch die Kontrolle des SDV-Ökosystems und dessen Monetarisierung (z. B. durch Drittanbieter-Apps) als Motivation gelten.

Die Herausforderungen, vor denen OEMs diesbezüglich stehen, sind jedoch so vielfältig wie die potenziellen Vorteile, die sie erzielen könnten. Gemäß einer Expertenbefragung von Berylls aus dem Jahr 2023 glauben 86 Prozent der Befragten, dass die OEMs derzeit nicht über die erforderlichen Fähigkeiten und Ressourcen verfügen. Nicht zuletzt, weil viele fähige Entwickler im operativen Tagesgeschäft gebunden sind und eine eigentlich notwendige organisatorische Abkopplung gemieden wird.

Darüber hinaus müssen traditionelle OEMs aufgrund der Produktvielfalt mit einer großen Anzahl an schwer ersetzbaren Legacy-System umgehen, sowohl innerhalb als auch außerhalb des Fahrzeugs. Dies führt zu extremer Komplexität in der Softwareentwicklung und erschwert die Standardisierung.

Auch stehen für die etablierten Unternehmen typische traditionelle Entscheidungsprozesse und komplexe Organisationsstrukturen oft im krassen Gegensatz zu den agilen State-of-the-Art-DevOps-Prozessen. Die relativ langsamen Prozesse verlangsamen dabei auch die Software-Entwicklung. Neue OEMs wie Tesla, Rivian, Lucid oder BYD agieren hier anders und können damit ihren Produktentstehungsprozess in wenig über zwei Jahren durchführen.

Angesichts dieser Herausforderungen ist offensichtlich, dass die Entwicklung eines eigenen Automotive-Betriebssystems für OEMs ein komplexes Unterfangen ist, das nicht nur technische Herausforderungen, sondern auch organisatorische und ressourcenbezogene Hindernisse mit sich bringt. Daher sind Zusammenarbeit und Kooperation mit spezialisierten Partnern oft vielversprechende Ansätze, um die erforderlichen Fähigkeiten und Ressourcen zu bündeln und Innovationen im Bereich der Fahrzeugsoftware voranzutreiben.

Die Auswirkungen des AOS auf die Akteure in der Branche sind grundlegender als man zunächst vermuten würde. Denn das automobile Betriebssystem als Softwareplattform und die damit verbundene Entkopplung von Hard- und Software eröffnen neue Möglichkeiten für die Entwicklung. Anstelle einer SOP-Orientierung wird das Fahrzeug demnach über einen Lebenszyklus gesteuert, in dem Hard- und Software iterativ (teilweise unabhängig voneinander) entwickelt werden. Der Fokus wird daher erwartungsgemäß eher auf der Weiterentwicklung von Anwendungen liegen, die primär für den Kunden sichtbar sind (z.B. autonomes Fahren, Infotainment), um die knappen Entwicklerressourcen bestmöglich zu nutzen. Damit stellt sich zwangsläufig auch die Frage nach der Wertschöpfung der einzelnen OEMs bei der Entwicklung des AOS. Denn differenzierend ist vor allem ein AOS mit oben beschriebenen Vorteilen zu haben, nicht jedoch wie genau diese ausgestaltet ist.

Dementsprechend werden viele OEMs, die heute ihre eigenen „OS“-Lösungen entwickeln, irgendwann ihre Wertschöpfung überdenken und eher auf Marktlösungen zurückgreifen – d. h. Partnerschaften eingehen (z. B. mit BigTech oder spezialisierten Software-Unternehmen), OSS nutzen oder eine White-Label-Lösung übernehmen, sobald diese verfügbar ist. Eine Ausnahme werden wahrscheinlich einige sehr wenige OEMs bilden, die ungeachtet der hohen Kosten und Redundanzen nach wie vor die volle Kontrolle über die Plattform anstreben. Erstausrüster, die derzeit nicht an einem Betriebssystem arbeiten (z. B. Nischenmarken des oberen Luxussegments), werden sich wahrscheinlich nicht in die Entwicklung eines solchen stürzen, sondern diesen Schritt überspringen und direkt eine marktreife und verfügbare Lösung nutzen.

Daher ist ähnlich den Smartphone-Betriebssystemen, eine Konsolidierung auf drei bis fünf Plattformen zu erwarten, wenngleich diese aufgrund von Komplexität des Automobilmarktes und der vielfältigen Anforderungen der Kunden eher langsamer als im Smartphone-Sektor erfolgen wird. Dabei sind abgesehen von einer OEM-Lösung auch eine kollaborative Open-Source-Lösung (bspw. Eclipse SDV oder COVESA) sowie ein Angebot großer Technologieunternehmen zu erwarten, die ihr Software-Know-how und ihre Einstiegsdomänen von Cloud-Diensten und Infotainment-Anwendungen als Einfallstor nutzen, um vollständig ausgestattete Betriebssysteme und Hardwareabstraktionen des gesamten Fahrzeugs bereitzustellen.

Die Trennung von Hardware und Software ermöglicht es auch, etablierte Beschaffungsmuster zu durchbrechen und Hardware und Software getrennt zu beschaffen. Tier 1s laufen daher Gefahr, ihr HW/SW-Integrationsgeschäft zu verlieren und dabei zu reinen Hardware-Lieferanten degradiert zu werden. Der Schwerpunkt wird sich daher auf die Frage der Verantwortung für die Integration von Modulen und Systemen verlagern, die traditionell bei den Tier-1-Unternehmen liegt. Einige OEMs möchten ggf. verschiedene Softwaremodule selbst in ihre Hardware integrieren, um die Kontrolle zu behalten und auch um ihre Wertschöpfung zu erhöhen, aber andere werden die Integrationsaufgabe wahrscheinlich lieber auslagern. Sicher ist jedoch, dass nicht alle Zulieferer in der Lage sein werden, ihr angestrebtes Umsatz- und Rentabilitätsniveau zu halten, wenn man bedenkt, dass es mit zunehmender Wiederverwendung und Kostendruck auch bereits verschiedene preisgünstige Hardware-Hersteller gibt, die bereits nach dem Built-to-Print-Modell arbeiten.

Fazit

Zusammenfassend lässt sich sagen, dass das automobile Betriebssystem die Branche prinzipiell in die richtige Richtung bewegen wird, sehr zum Vorteil der Kunden, aber auch mit erheblichen Effizienzgewinnen in der Entwicklung. Es wird spannend sein zu sehen, wie der zu erwartende Konsolidierungsprozess verläuft und wie sich die einzelnen Akteure, von OEMs über Zulieferer bis hin zu BigTech, positionieren können und werden. (na)