Prognosen von McKinsey zufolge wird Software bis 2030 rund 30 Prozent des Werts eines Fahrzeugs ausmachen - angefangen bei Infotainment bis hin zu autonomem Fahren. Doch ein Auto ist kein Smartphone. Software im Auto muss höheren Ansprüchen an Sicherheit genügen. Da gilt auch für die genutzte Open Source Software.

In vernetzten Autos finden sich je nach Ausstattung bis zu 100 Millionen Zeilen Softwarecode. Vergleicht man diese Zahl mit den zwölf bis 15 Millionen Codezeilen eines Android-Betriebssystems oder den rund 50.000 Zeilen einer gewöhnlichen App für das iPhone, wird die Komplexität des Software-Managements in Fahrzeugen klar.

So ist es kein Wunder, dass Produktentwicklungszyklen für Autohersteller deutlich länger ausfallen. Die Entwicklung eines Infotainmentsystems für Fahrzeuge dauert in der Regel um die drei Jahre - ein Zeitraum, in dem leicht drei bis vier neue Versionen von Smartphones auf dem Markt erscheinen. Auch wenn der Vergleich zwischen Autobauer und Handy-Hersteller überzogen scheint, ist eines klar: Innovationen in der Automobilindustrie sind zu langsam und das Time-to-Market zu lang.

Grund dafür ist unter anderem die starke Fragmentierung der Infotainment-Landschaft. PC- und Notebook-Hersteller verwenden nicht jeder ein eigenes Betriebssystem, und Anwendungsentwickler müssen nicht jedes Mal sicherstellen, dass ihre Software mit jedem dieser Systeme kompatibel ist. Im Automotivsektor war das lange der Fall und Hersteller nutzten häufig eigene proprietäre Systeme, die mit einer benutzerdefinierten Version von Linux, QNX oder Windows Embedded erstellt wurden. Softwarecode wurde dabei sehr wenig wiederverwendet.

Innovationen brauchen Open Source

Open Source Software (OSS) spielt in Fahrzeugsystemen daher eine immer größere Rolle. Automobilhersteller setzen Open Source Software für Kerntechnologien wie das Infotainment-Betriebssystem ein, können so Zeit und Kosten sparen und sich stärker auf die Entwicklung neuer, wettbewerbsentscheidender Technologien fokussieren. Schätzungsweise ist bereits 50 bis 70 Prozent des Automotive Software Stacks Open Source. Besonders hoch ist der Anteil von OSS beispielsweise bei Middleware, also anwendungsneutralen Programmen.

Entsprechend wächst das Interesse für die GENIVI Alliance, die sich für den Einsatz von Open Source Software auf internationaler Ebene stark macht, oder die kollaborative Open-Source-Anwendungsplattform Automotive Grade Linux (AGL) der Linux Foundation. Erst im Frühjahr 2019 trat der Volkswagen-Konzern der AGL-Initiative bei, um den Einsatz von Open-Source-Technologien und Shared Software Development im Automotive-Markt zu beschleunigen.

Gemeinsam mit mehr als 130 Mitglieder wird nun an der Entwicklung eines vollständig offenen Software-Stacks für das vernetzte Auto gearbeitet. Die Plattform soll einen De-facto-Industriestandard bieten und der gesamten Branche an Automobilherstellern und Zulieferern dieselbe Codebasis zur Wiederverwendung bereitstellen - nicht nur für In-Vehicle-Infotainment- (IVI-) Anwendungen, sondern langfristig für die gesamte Software im Fahrzeug, einschließlich Kombiinstrument, Heads-Up-Display, Telematik, Advanced Driver Assistance Systems (ADAS) und autonomes Fahren.

Herausforderung OSS

Die Zunahme an OSS in der Automobilsoftware stellt zwangsläufig neue Herausforderungen an das Software-Management. Automobilhersteller (OEMs) beziehen Fahrzeugkomponenten und -subsysteme von Dutzenden von Lieferanten, die mit einer Reihe von Hard- und Softwareanbietern zusammenarbeiten. Diese sind wiederum stark in die Open Source Community eingebunden. Die Autoindustrie steht hier vor den gleichen Aufgaben wie andere Technologieunternehmen: Sie muss die Qualität der integrierten Softwarekomponenten sicherstellen und den Softwarecode nachverfolgen können, um sowohl die Lizenzierung auf ihre Compliance zu überprüfen, als auch Sicherheitslücken zu identifizieren und zu patchen.

• Fehlende Rückverfolgbarkeit: In der Regel kennen Unternehmen weniger als zehn Prozent der OSS-Komponenten, die in ihren Produkten eingesetzt werden. Eine typische Anwendung enthält jedoch oft Hunderte von Open Source-Paketen. Hier gibt es enormen Aufholbedarf, Software nach OSS zu scannen, diese zu identifizieren und in einer Software-Bill-of-Material festzuhalten. Andernfalls lassen sich keine Updates durchführen und Software-Compliance-Vorgaben erfüllen. Die Analyse der Softwarekomponenten (Software Component Analysis) zeigt auf, welche Source Libraries von den Entwicklern genutzt werden und welche Drittanbieter-Bibliotheken standardmäßig damit verknüpft sind. Dabei lässt sich der genaue Anteil des übernommenen Codes innerhalb des proprietären Quellcodes prozentual bestimmen.

• Unterschiedliche Produktlebenszyklen: Während neue Software-Releases durchschnittlich vier bis acht Mal im Jahr veröffentlicht werden, bringen Hersteller gerade alle vier bis sieben Jahre ein neues Automodell auf den Markt. Der Produktlebenszyklus unterscheidet sich damit grundlegend. Hier gilt es, mit dem Tempo der Softwareindustrie mitzuhalten, und auch für bereits am Markt eingeführte Fahrzeuge über entsprechende Plattformen für Software-Management und -Deployment Sicherheits-Updates bereitzustellen, neue Technologie anzubieten oder zusätzliche Services freizugeben.

• Softwarelizenzierung: Open Source Software ist nicht gleich "freie Software". Auch sind Lizenzierungen zu beachten. Das gilt insbesondere für auf Linux basierte Geräte, die der General Public License (GPL) unterliegen. Danach sind Entwicklerteams bei der Nutzung verpflichtet, den Quellcode aller Produkte und Komponenten, in denen sie GPL-lizenzierte, unveränderte oder veränderte Komponenten verwenden, offenzulegen. Jede Lizenz kann zudem mit einer Ausnahme verbunden sein. Noch komplexer wird es, wenn die Einhaltung von GPL - und damit die Weitergabe des Quellcodes an die Nutzer - mit anderen Lizenzverpflichtungen (zum Beispiel für kommerzielle Software) im Widerspruch steht. Daher empfiehlt es sich, die Software-Compliance im Vorfeld gründlich zu überprüfen. Gleichzeitig beschäftigt Hersteller die Frage, wie sie trotz Offenlegung nach GPL & Co. ihr geistiges Eigentum schützen können.

• Software Vulnerabilities: Jede Software hat Sicherheitslücken und braucht in regelmäßigen Abständen Updates, um Schwachstellen zu patchen. Die Veröffentlichung einer Vulnerability mit hohem Sicherheitsrisiko kann für Hersteller mit einem enormen Zeitaufwand verbunden sein. Zumal jeder erneute Vorfall eine weitere Suche auslöst und das Entwickler- und Test-Team von seiner eigentlichen Arbeit abhält. Der gesamte Softwarecode muss schnellstmöglich auf die Schwachstelle untersucht werden - sowohl in bereits ausgelieferten als auch im Auslieferungszustand befindlichen Fahrzeugen. Dabei darf das Bereitstellen und Patchen von Anwendungen natürlich keinesfalls die Kundenzufriedenheit beeinflussen.

Kenne Deinen Code!

Das Management von OSS ist unverzichtbar, wollen Hersteller von den Vorteilen von Open Source profitieren. Können Sie sämtlichen GPL-Code in Ihren Fahrzeugen nennen? Führen Sie Software-Stücklisten (BOMs)? Nutzen Sie angreifbare Versionen von Apache Struts 2 oder OpenSSL? Läuft die Software Composition Analyse automatisiert ab? Und sind Sie zu hundert Prozent compliant, was OSS angeht?
Wer Software entwickelt oder diese in Fahrzeuge integriert, sollte diese Fragen problemlos beantworten können. Ist das nicht der Fall, sollten Hersteller sich schleunigst über entsprechende Prozesse, Richtlinien, Schulungen und Werkzeuge für eine sichere Open-Source-Strategie Gedanken machen.