Dr. Sara Gallian, Dr. Diana Kupfer & Ansgar Lindwedel 24. September 2024

Open Source in der Automobilbranche

Kooperation als Game Changer für aktuelle und zukünftige Herausforderungen

Immer mehr Big Player der Automobilbranche setzen auf Open-Source-Software (OSS). © Adobe: MP Studio / stock.adobe.com / 721481547 / Generiert mit KI — © Adobe: MP Studio / Generiert mit KI

In der Automobilbranche vollzieht sich ein Paradigmenwechsel: weg vom traditionellen Hardware-zentrierten Ansatz hin zu einer Software-orientierten Ausrichtung, Stichwort: "Software-Defined Vehicle". Doch nicht nur das: Die großen Player der Branche entdecken zunehmend die Vorteile einer herstellerübergreifenden Zusammenarbeit rund um Grundbausteine ihres Tech-Stacks für sich. Immer mehr von ihnen setzen auf Open-Source-Software (OSS). Wir geben einen Überblick über diese Entwicklungen und zeigen, wo der Einsatz von OSS in der Automobilbranche bereits heute möglich ist.

Software hält Einzug ins Fahrzeug

2011 veröffentlichte Marc Andreessen von der Venture-Capital-Firma Andreessen-Horowitz seinen wegweisenden Essay "Why Software is eating the World" ("Warum sich Software die Welt einverleibt"). Darin konstatierte er, was vielen in der Software-Branche bereits bewusst war: "My own theory is that we are in the middle of a dramatic and broad technological and economic shift in which software companies are poised to take over large swathes of the economy." ("Meine Theorie ist, dass wir uns mitten in einem dramatischen und umfassenden technologischen und wirtschaftlichen Wandel befinden, bei dem Software-Unternehmen große Teile der Wirtschaft übernehmen werden.") [1]

Heute, fast genau 13 Jahre später, ist diese Prophezeiung längst Realität geworden – und Software als Grundpfeiler erfolgreicher Geschäftsmodelle eine Selbstverständlichkeit. Selbst traditionelle Hardware-zentrische Wirtschaftssektoren wie die Automobilindustrie hat die Software-Revolution mächtig aufgemischt. Die "Softwareisierung" der Automobilindustrie ist, wie in anderen Bereichen auch, kein Selbstzweck, sondern wird im Wesentlichen von fünf disruptiven Trends angetrieben:

Elektromobilität
autonomes Fahren
Vernetzung (Vehicle-to-Everything oder V2X)
stärkere Zentralisierung der Hardware-Architektur und damit einhergehende, steigende Rechenleistung
zunehmende Fokussierung auf kundengerechte, personalisierte Services und Applikationen, die intuitive Benutzeroberflächen und innovative Bedienkonzepte (z. B. Sprachsteuerung) umfassen und damit einhergehend die Möglichkeit für die Hersteller, neue Monetarisierungspunkte rund um das Automobil zu entwickeln.

Die Zukunft der Automobilunternehmen und ihres Zulieferer- und Dienstleister-Ökosystems wird wesentlich davon abhängen, wie schnell diese auf die Herausforderungen reagieren und die Chancen ergreifen können, die sich aus dieser Transformation ergeben. Zunächst stellt sich die zunehmende Ausrichtung auf Software für traditionelle Automobilunternehmen als enorme Herausforderung dar, wie es der Ford-CEO Jim Farley in einem Interview zusammenfasste: "Autounternehmen haben noch nie Software entwickelt. Wir schreiben die Software, mit der Autos betrieben werden, zum allerersten Mal selber." [2]

Bei mehreren hundert Millionen Zeilen Code, die in jedem modernen Auto zur Norm werden, wird es für die Hersteller zudem zunehmend schwierig, die Software-Komplexität zu bewältigen und gleichzeitig mit modernen Entwicklungsmethoden und Technologien – agile Entwicklung, schnelle Release-Zyklen, modernste Software-Tests, Nutzung von Künstlicher Intelligenz oder neue Programmiersprachen – Schritt zu halten. Und die Konkurrenz schläft nicht: In Ostasien erleichtern staatliche Subventionen den schnellen Markteintritt neuer Autohersteller. Große Halbleiterunternehmen außerhalb der EU bieten zudem integrierte Hardware-Software-Plattformen an und haben zahlreiche Partnerschaften im Automobilbereich angekündigt, die zu Anbieterabhängigkeiten führen.

Abb. 1: Traditionelles vs. agiles Entwicklungsmodell im SDV-Umfeld. © Eclipse Foundation

Mit einer Umstellung bewährter, wertschöpfender Prozesse auf ein neues Entwicklungsmodell (s. Abb. 1) und dem gezielten Zukauf von Expertise tut sich ein etabliertes Unternehmen mit langer Geschichte häufig schwerer als ein auf einem "Greenfield" gegründetes Startup, das Software-Entwicklung von Grund auf in seinem Businessmodell mitdenkt und sich dadurch anschickt, manch einen großen Akteur – zumindest in Sachen Agilität und Innovationskraft – mit einem "Leapfrog" hinter sich zu lassen, gerade im noch relativ jungen Feld der Elektromobilität [3]. Dies gilt insbesondere für die oben erwähnten innovativen Marktteilnehmer aus Ostasien.

Zusammenfassend kann man also sagen, dass Software natürlich schon seit Jahrzehnten im Automobil einen festen Bestandteil hat, aber bisher immer als "notwendiges Übel" gesehen wurde, damit die Hardware funktioniert. Heute braucht es nachhaltige Software-Architekturen, die auch über viele Modellreihen Bestand haben und entsprechende Konzepte, die in der IT-Welt nicht neu sind, aber im Auto bisher wenig Anwendung finden:

Containerisierung, um Software-Funktionen flexibler integrier- und einsetzbar zu machen
Hardware-Software-Abstraktion (Was nützen mir X Cent Einsparung in Hardware-Ressourcen, wenn der Software-Entwicklungs- und Pflegeaufwand um ein Vielfaches explodiert?)
Standardisierte APIs, um Applikations-Software (also die Software-Funktionen, die für den Fahrer des Autos erlebbar sind) einfach in verschiedene Fahrzeuge integrieren zu können
Harmonisierung von Tool- und Entwicklungslandschaften, um die Komplexität der Software-Entwicklung zu reduzieren und damit die Entwicklung selbst drastisch zu beschleunigen (vgl. die beschriebenen Herausforderungen bei der Erstellung einer CI/CD-Pipeline im Automotive-Umfeld [4]).

In Summe braucht es für das SDV also eine Vielzahl an sogenannter "Enabling Software", also Technologie, die Grundlage dafür ist, dass die darauf aufbauende Software gut funktioniert und einfach entwickelt werden kann, die aber nicht für Endkunden erlebbar ist und somit das Fahrzeug auch nicht wirklich wettbewerblich differenziert. Die Hersteller benötigen diese Enabling Software, um dann die wettbewerbsdifferenzierende Applikations-Software effizient entwickeln und pflegen zu können.

Mehr Software = mehr Open Source?

Eine logische Überlegung ist es, aus der zunehmenden Softwareisierung einen höheren Bedarf an Open-Source-Software-Entwicklung zu folgern. Schließlich hat sich OSS als wegweisendes Modell für kollaborative Innovation etabliert, um beim oben zitierten Bonmot von Marc Andreessen zu bleiben, das Joseph Jacks 2022 folgendermaßen aktualisierte: "Open Source Is Eating Software FASTER Than Software Is Eating The World"[5].

Einschlägige Zahlen belegen diesen Trend: Laut einem Bericht von Synopsis aus dem aktuellen Jahr enthalten 96 Prozent der untersuchten Codebasen Open-Source-Software [6]. Laut einer Todo-Group-Umfrage konsumierten im Jahr 2020 81 Prozent der Unternehmen OSS in Produkten oder Services [7]. Würden sie darauf verzichten und alle Software in-house entwickeln, müssten sie einer weiteren Studie zufolge mit sage und schreibe 8,8 Billionen US-Dollar Mehrausgaben rechnen [8].

Und in der Automobilindustrie? Bereits 2018 wurde der Anteil von OSS in den Tech-Stacks dort auf 40 bis 70 Prozent geschätzt [9]. Ist OSS also die Antwort auf alle aktuellen Herausforderungen in der Automobilbranche? Wird sie es Autoherstellern und Zulieferern ermöglichen, innerhalb kürzerer Zeit mit weniger Investitionen mehr Innovationen auf den Markt zu bringen als bisher?

Um diese Frage zu beantworten, ist ein differenzierterer Blick auf die Software notwendig, die in den Tech-Stacks der Automobilhersteller zum Einsatz kommt. Denn Software ist nicht gleich Software: In den unterschiedlichen Automotive-Domänen trifft man auf sehr heterogene Entwicklungsmodelle und -zyklen, Tools, Standards und Prozesse.

Zudem bestehen im sicherheitskritischen Kontext der Automobilindustrie strenge Anforderungen an die Software und deren zugrunde liegende Entwicklungsprozesse. Diesen wird OSS meist noch nicht gerecht, weshalb sich Unternehmen, die auf Open Source setzen wollen, überlegen müssen, wie sie OSS und funktionale Sicherheitszertifizierungen wertschöpfend in Einklang bringen. Ebenso wichtig ist Transparenz in Bezug auf OSS-Bausteine in der Lieferkette. Beide Aspekte erfordern ein proaktives und methodisches Vorgehen. Nur so kann über den langen Lebenszyklus eines Fahrzeuges hinweg garantiert werden, dass den Sicherheitsanforderungen entsprochen werden kann.

Der Einsatz von OSS-basierten Technologien stößt in sicherheitskritischen Bereichen wie ADAS und tief eingebetteten Systemen also bisher noch an seine Grenzen – wobei auch hier bereits über eine mögliche Verwendung von OSS diskutiert wird [10]. In den weniger kritischen Schichten wie Infotainmentsystemen sind OSS-basierte Systeme bereits im Einsatz, darunter Android Automotive und Automotive Grade Linux.

Differenzierende Automobil-Services als i-Tüpfelchen

13 Jahre nach Marc Andreessens oben zitiertem Aufsatz sind wir also über den Punkt hinaus, an dem man pauschal von der Automobil-Software spricht. Der Wandel, der in den vergangenen Jahrzehnten vereinfachend durch Schlagworte wie "Digitale Transformation" oder "Digitalisierung" beschrieben wurde, hat in der Autoindustrie längst stattgefunden; dass man als Automobilhersteller um Software-Entwicklung nicht mehr herumkommt, ist mittlerweile "Common Sense". Inzwischen ist es zielführender, zwischen generischer und differenzierender Software-Technologie zu unterscheiden. Während generische Technologie die Grundlage jedes Software-Defined Vehicles und ein potenzieller gemeinsamer Nenner unter zahlreichen Automobilherstellern ist, sind es – im Sinne einer immer stärkeren Kundenzentrierung – die differenzierenden Services, die den Markterfolg vorantreiben, da sie Mehrwert für den Kunden schaffen und Alleinstellungsmerkmale darstellen. So erwarten Kunden von einem modernen Fahrzeug etwa Anwendungen rund um Infotainment, Konnektivität, ADAS/AD-Funktionalität, intuitive und innovative Bedienkonzepte sowie regelmäßige Over-the-Air-Updates für neue oder verbesserte Funktionen. Käufer würden sogar soweit gehen, die Marke zu wechseln, um Zugang zu – aus ihrer Sicht – besseren Anwendungen und Funktionen zu erhalten [10]. Mit anderen Worten: Diese differenzierenden Faktoren sind als i-Tüpfelchen auf dem Fahrzeugmarkt entscheidend für den Geschäftserfolg der Automobilhersteller.

In einem zunehmend wettbewerbsintensiven und komplexen Markt für Anwendungen und Dienste wird ein solcher Grad an Spezialisierung und eine derartige Bandbreite an angebotenen Services allerdings nur erreichbar sein, wenn Automobilhersteller ihre Ressourcennutzung optimieren und sich die Kosten für die Entwicklung und Wartung generischer Bausteine oder gemeinsamer Nenner – hauptsächlich in den Software-Schichten zwischen der Hardware und den Applikationen – teilen. Es geht also darum, buchstäblich die Neuerfindung des Rades zu vermeiden.

Selbst die progressiven Automobilhersteller, die es ggf. schon (teilweise) geschafft haben, ihre Software-Architektur in Richtung SDV zu entwickeln, stellen fest, dass es ein immenser Aufwand ist, diesen Technologiestack zu entwickeln und noch viel mehr Aufwand, diesen Stack dann auch zu pflegen und zu warten. Und das alles für Enabling Software, also Technologie, die zwar erforderlich, aber nicht stark wettbewerbsdifferenzierend ist. Die Hersteller binden so einen Großteil ihrer Entwicklerressourcen, um das SDV-Fundament zu entwickeln und zu pflegen, anstatt diese Ressourcen für Software-Innovationen nutzen zu können. Hier bietet OSS die Möglichkeit der unkomplizierten Kooperation. Wo traditionelle Partnerschaften in der Automobilindustrie teilweise ein bis zwei Jahre der Intellectual-Property-Verhandlungen und -Vertragsgestaltung brauchen, bevor überhaupt mit der Arbeit angefangen werden kann, sind z. B. in der Eclipse SDV Working Group (s. nächster Abschnitt) schon über 30 Projekte in zwei Jahren entstanden.

Im aktuell stattfindenden Hype um OSS im Automobil geht es also nicht um die Nutzung von Technologie, die als Open Source zur Verfügung steht – was die Autoindustrie wie oben beschrieben auch schon seit Jahrzehnten gewohnt ist und macht –, sondern um das aktive Gestalten von automobilen Ökosystemen in Open Source und das gemeinsame Entwickeln von Standardtechnologie durch gemeinsame Beiträge zu Open-Source-Projekten. Dies klingt nach einem marginalen Unterschied, ist aber kulturell ein gigantischer Schritt – und zugleich eine gewaltige Chance für eine Branche, die schneller denn je von Software getrieben ist.

Die Folge: In großen Teilen der Automobilindustrie hat ein Umdenken in Sachen Zusammenarbeit und Wettbewerb eingesetzt, sodass sich die Branche insgesamt hin zu einer Ökosystem-fokussierten Struktur bewegt. Dies spiegelt sich in einem Anstieg an Kooperationen und Konsortien wider, die darauf abzielen, Interoperabilität zu ermöglichen und gemeinsame Standards zu entwickeln.

Mit vereinten Kräften zum Software-Defined Vehicle

OSS ist ein wesentlicher Katalysator für diesen Kulturwandel – weg von herstellerspezifischen Silo-Lösungen hin zu mehr Zusammenarbeit, zumindest dort, wo diese gemeinsamen Anstrengungen sinnvoll und Synergien bereits vorhanden sind. Denn die effektivste Möglichkeit, den oben genannten disruptiven Trends und Herausforderungen zu begegnen, besteht in der Implementierung gemeinsamer Software-Bausteine, die Automobilherstellern als Basis weiterer, differenzierter Features und Services dienen.

Dabei kristallisiert sich das Bedürfnis nach einer standardisierten, einheitlichen Plattform heraus: "Standardisierung ist entscheidend, um Austauschbarkeit zu gewährleisten und die Entwicklung für Automobilhersteller zu beschleunigen. Die Software-Komplexität nimmt derzeit rapide zu, und wir müssen ihre Entwicklung erleichtern. Daher werden kooperative Bemühungen zur Etablierung und Einhaltung von Standards von entscheidender Bedeutung sein", erklärte ein Branchenvertreter in einem kürzlich veröffentlichten Bericht [11].

Die europäische Initiative "Software-Defined Vehicle of the Future" (SDVoF) des FEDERATE-Projekts zielt darauf ab, in gemeinsamer Arbeit einen umfassenden Entwicklungsprozess zu schaffen, der in einer ersten Phase Hardware-Software-Abstraktion, in einer zweiten Phase ein Middleware- und API-Framework und in einer abschließenden Phase eine automatisierte DevOps-Toolchain umfasst [12]. Erwähnenswert ist auch die CCAM-Partnerschaft, deren erklärtes Ziel es ist, "zentralisierte, zuverlässige, cybersichere und erweiterbare elektronische Steuerarchitekturen für CCAM-Fahrzeuge zu entwickeln, die mit dem Cloud-Edge-Kontinuum verbunden sind." [13]

Abb. 2: Überblick über die Projektlandschaft der Eclipse SDV Working Group. © Eclipse Foundation

Die Eclipse SDV Working Group (s. Abb. 2), die derzeit mehr als 50 Mitgliedsorganisationen und um die 30 beteiligte Open-Source-Projekte zählt, hat sich zum Ziel gesetzt, eine offene Technologieplattform zu schaffen, die die Innovation von Software-Stacks in der Automobilindustrie durch den Einsatz von Open-Source-Projekten und offenen Spezifikationen fördert. Die Arbeitsgruppe verfolgt einen Code-first-, Bottom-up-Ansatz, bei dem teilnehmende Projekte individuelle Bausteine zu einer reichhaltigen Technologieplattform beitragen. Eclipse Kuksa beispielsweise arbeitet auf eine einheitliche "Vehicle API" hin und wird bereits in mehreren Open-Source-Automobil-Software-Communitys eingesetzt. Eclipse ThreadX stellt ein zertifiziertes Echtzeitbetriebssystem (Real-Time-Operating System, RTOS) bereit, das bereits auf zwölf Millionen Geräten deployt wurde. Eclipse OpenDuT sorgt für automatisiertes Testen und Validieren und ist ein hervorragendes Beispiel für eine erfolgreiche Zusammenarbeit mehrerer großer Akteure der Branche. Eclipse uProtocol bietet ein transportagnostisches, schichtbasiertes Kommunikationsprotokoll, das unabhängig von Einsatzort, Betriebssystem und Gerät ist und auf bestehende Automobil- und Internetstandards zurückgreift. Bei einem großen Automobilhersteller ist es in einer älteren Version bereits im Einsatz. Dass es nicht immer die Marktgiganten sein müssen, die ein Open-Source-Projekt lancieren und vorantreiben, zeigt das Beispiel eines weiteren Protokollprojekts, Eclipse Zenoh. Dieses wird wesentlich von zwei kleineren Unternehmen geprägt, die früh das Potenzial von Open Source für sich entdeckten.

Neben der Zusammenarbeit in Projekten bieten die neu gegründeten Special Interest Groups Gelegenheit zum Austausch innerhalb der Eclipse SDV Working Group. Sie helfen der Arbeitsgruppe insgesamt, am Puls der Zeit zu bleiben, indem sie neue Herausforderungen, Technologien und Trends identifizieren und proaktiv daran arbeiten. Beispielsweise hat sich erst kürzlich eine Special Interest Group rund um die Programmiersprache Rust formiert.

Das übergeordnete Ziel der Eclipse-SDV-Arbeitsgruppe ist eine harmonisierte SDV-Lösung, von der möglichst viele mitwirkende Unternehmen profitieren – selbstverständlich, indem sie sich aktiv durch Codebeiträge und Weiterentwicklung beteiligen, denn Open Source ist bekanntlich keine Einbahnstraße. Als ersten Schritt hat das Technical Advisory Committee der Eclipse SDV Working Group eine Full-Stack-Architektur-Standardisierung auf Basis von Open Source vorgeschlagen. Ziel ist es, einen gemeinsamen technologischen Kern zu schaffen, der als Grundlage für die kontinuierliche Weiterentwicklung einer standardisierten Softwareumgebung mit klar beschriebenen APIs dient und Zusammenarbeit, Portabilität und einfache Integration von Funktionen ermöglicht.

Die Eclipse SDV Working Group ist wiederum Teil der SDV Alliance, einer "Kollaboration der Kollaborationen", die aus drei weiteren Konsortien besteht: AUTOSAR, SOAFEE und COVESA.

In immer Software-lastigeren Fahrzeugen ist auch ein Umdenken in Bezug auf die Hardwareebene notwendig. Insbesondere muss das Onboard-Computing zentralisiert werden, da die Vernetzung der zunehmend voneinander abhängigen elektronischen Steuergeräte (ECUs) aufgrund von Latenzzeiten und weiterer Einschränkungen sonst nicht praktikabel wäre. Aus diesem Grund haben Unternehmen wie NXP, STMicroelectronics, Infineon, Bosch, Unibo/ETH, Fraunhofer IIS, PlanV, Axelera, BSC und andere das Vorhaben gestartet, eine RISC-V-Referenzarchitektur für die Automobilindustrie zu entwickeln, mit dem Ziel, ECUs zu zentralisieren und die Interoperabilität von Hardware und Software zu erleichtern [14].

Bottom-up trifft Top-down

Während selbstorganisierte Ökosysteme und Kooperationen dazu beitragen, herstellerspezifische Ansätze zu konsolidieren und einer Fragmentierung in der Automobilsoftware vorzubeugen, können Regierungen und öffentliche Institutionen aufgrund ihrer Neutralität und finanziellen Spielräume erheblich zur Beschleunigung des Wandels in der Branche beitragen. Innerhalb der Europäischen Union können politische Organe wie die Europäische Kommission ein neutrales Umfeld sowie Kapazitäten für Forschungsprojekte schaffen und den Austausch auf Augenhöhe zu übergreifenden Themen zwischen den wichtigsten Akteuren der Industrie fördern. Daher ist ein zweigleisiges Vorgehen entscheidend, um eine hocheffiziente und zuverlässige Grundlage für elektronische Steuerarchitekturen im Fahrzeug und Edge-Cloud-Kontrollarchitekturen zu entwickeln: ein Bottom-up-Ansatz, der bereits von Industriekooperationen, Allianzen und Konsortien verfolgt wird, und ein Top-down-Ansatz, bei dem Regierungsinstitutionen als Vermittler zwischen verschiedenen Kooperationen agieren, ein neutrales und faires Umfeld gewährleisten und die Standardisierung vorantreiben.

Das Software-Defined Vehicle ist längst ins Rollen gekommen und mehr als ein Buzzword. Zwar werden mehrere Evolutionsstufen – von "Software-enabled" bis "Software-defined" – durchlaufen werden müssen, ehe aus dem Hype eine Innovationsplattform entstehen kann, wie Moritz Neukirchner von Elektrobit betonte [15]. Fest steht aber: Mit dem Bedarf an Software im Automobil steigt auch der Bedarf an OSS – als Technologie, aber auch als Modell der zukünftigen herstellerübergreifenden Zusammenarbeit. Jetzt gilt es für alle Stakeholder, Silos aufzubrechen, die Kräfte zu bündeln und einen gemeinsamen Fahrplan zu entwerfen, um langfristig nicht auf der Strecke zu bleiben.

Quellen