„Durch offene Auto-Software können wir massiv Kosten sparen"

Im Handelsblatt erschien kürzlich ein Leitartikel, in dem über eine angebliche neue Einsicht der deutschen Autobauer berichtet wurde. Es hieß dort, dass ein Betriebssystem für Autos nun doch als zu komplex gesehen werde und deshalb eine Kooperation mit erfolgreichen Tech-Konzernen wie Google unausweichlich erschiene. Ich halte viele der Argumente im Artikel für substanziell falsch – auch wenn ich mich dabei für meinen langjährigen Arbeitgeber Google freue und sowohl die Aussicht für die Autoindustrie als auch die fundamentale Bedeutung von Partnerschaften im digital vernetzten Zeitalter für absolut richtig halte.

Bei Auto-Betriebssystemen existieren fundamentale Missverständnisse

Aber erlauben Sie, dass ich hier speziell zwei Punkte kritisch aufnehme: Wer das von Google entwickelte Auto-Betriebssystem Google Automotive Services (GAS) nutzt, habe kaum noch Gestaltungsspielraum bei der Entwicklung des Infotainment-Systems im Auto und verliere zudem die Kontrolle über die Daten, heißt es im Artikel. Hier wurde nun wirklich einiges tiefgreifend nicht verstanden: Zunächst gibt es einen fundamentalen Unterschied zwischen den Auto-Betriebssystemen mit denen die Kernfunktionen des Fahrzeugs wie Bremsen oder Lenkung realisiert werden und jenen, die das Infotainment und die Konnektivität antreiben. Google ist nur bei letzterem involviert. Zweitens, die vielbeschworene Kontrolle über die Daten sollte doch wohl vor allem beim Nutzer liegen. Grundsätzlich ist hier festzuhalten, dass der Nutzer darüber entscheiden sollte, wer Zugang zu Fahrzeug- und Infotainment-Daten hat. Hier ist es doch sehr wahrscheinlich, dass Fahrzeugdaten mit den Herstellern und Infotainmentdaten mit den jeweiligen App-Anbietern geteilt werden, aber nicht jeweils beide mit beiden. Im letzten Jahrzehnt hat sich um unsere Smartphones herum ein sehr ausgeklügeltes Daten-Ökosystem entwickelt, bei dem die Betriebssystemanbieter sehr klare Regeln befolgen (müssen) - und normalerweise keinerlei Zugang zu den Daten der App-Anbieter haben. Diese Spielregeln werden sich wahrscheinlich auch in der Mobilitätsindustrie verbreiten. 

Software-Produktion folgt anderen Gesetzmäßigkeiten

Realitätsfern fand ich weiterhin folgende Rechnung: in einem Premium-Neuwagen werde Software genutzt, die etwa 500 Millionen Zeilen Code umfasse - und wenn man nun davon ausgehe, dass ein Entwickler circa 100 Zeilen Code am Tag schreibe, dann wäre laut Handelsblatt die Eigenentwicklung rein mathematisch offensichtlich nicht zu schaffen. Diese Rechnung erscheint jedoch aufgrund zweier Faktoren nicht richtig: Zunächst könnten 5.000 Entwickler in rund fünf Jahren (1.000 Arbeitstage) durchaus diese Menge an Code schreiben.

Aber vor allem veranschaulicht die Rechnung eine antiquierte Betrachtungsweise, die eher mit der Planung der Rohstoffproduktion einer Industrieanlage vergleichbar ist als mit den heutigen komplexen und agilen Prozessen von Software-”Produktion”. Sie ist schlicht unbrauchbar, um Wissensarbeit an einem hochkomplexen Ökosystem zu beschreiben, dessen Entwicklungsprodukt am Ende - im Gegensatz zu Hinterachsen - kostenfrei replizierbar ist.

Softwareentwickler sind (wie alle guten Ingenieure) faul. Es wird in den allermeisten Fällen, definitiv bei Betriebssystemen, auf bestehende (Open-Source-)Bibliotheken aufgebaut, die den Löwenanteil der Code-Zeilen ausmachen. So ist bei den genannten 500 Millionen Code-Zeilen nicht ersichtlich, ob der gleiche Code in mehreren Steuergeräten bei dieser Zählung als Summe betrachtet wird, wenn beispielsweise der Linux-Betriebsystemkern mit seinen 30 Millionen Codezeilen auf fünf Steuergeräten und zusätzlich in sechs virtuellen Umgebungen zum Einsatz kommt. Es geht nicht um die Anzahl der Zeilen, es geht um Architektur und Schnittstellen, die das jeweilige Ökosystem charakterisieren.

Die Kostenexplosion bei Software kann verhindert werden

Wirklich beeindruckend fand ich zugleich die Prognose von McKinsey, dass der Markt für automobile Software in acht Jahren rund 84 Milliarden Dollar schwer sein werde. Dabei entfielen laut der Analyse etwas mehr als die Hälfte der Kosten auf Softwareentwicklung, 35 Prozent auf Validierung - also das Prüfen des Codes in Bezug auf Qualitäts- und Sicherheitsstandards - und gut 15 Prozent auf die Integration - also das Anpassen von Software auf ihre konkrete Anwendung in den jeweiligen Fahrzeugen.

Logischerweise muss jeder Hersteller den letzten Punkt selbst tragen. Bei der Entwicklung der Kernfunktionalitäten jedoch können Autobauer hervorragend durch Open-Source-Programme kooperieren und so jeweils Kosten in der Größenordnung von 50 Prozent einsparen – und den erheblichen Aufwand in der Akquise von Mitarbeitenden wie auch in der Steuerung hochkomplexer Entwicklungsprozesse deutlich reduzieren. Natürlich wollen alle OEMs ihre Software auch differenzieren und dafür sollten erhebliche eigene Ressourcen eingeplant werden. Aber Kernfunktionalitäten wie kooperatives Fahren, Cybersecurity oder auch Interoperabilität für Verkehrsfluss sollten im Interesse der Kunden und der Gesellschaft sowieso gemeinsam und in Koopetition entwickelt werden.

Wenn wir nun noch bedenken, dass in diesem Szenario der Großteil der Software-Validierungskosten zwischen den Akteuren aufgeteilt werden könnte, dann entsteht ein wirklich attraktives Bild: Ein Sparpotenzial von gut 50 Prozent oder 44 Milliarden Dollar, welches außerdem zu sicheren, interoperablen Kernlösungen führt. Für die Differenzierung der einzelnen Marken durch attraktive User Interfaces und Extras werden dadurch zugleich auch größere Ressourcen freigesetzt und so insgesamt mehr Kundennutzen mit weniger ökonomischen und ökologischen Aufwendungen möglich.

An der 42 Wolfsburg / Berlin haben wir uns - gemeinsam mit unseren Partnern wie Volkswagen, Microsoft, Bosch und vielen mehr - aufgemacht, diesen Weg zu erkunden. Open Education, Open Source und Open Innovation sind der Schlüssel für eine nachhaltige, sichere, interoperable – und bei all dem – kosteneffiziente Digitalisierung unserer zukünftigen Mobilitätsökosysteme.