„Autobauer sind von Haus aus keine Software-Unternehmen"

Herr Plagge, das Ziel der Software-Defined-Vehicle Working Group der Eclipse Foundation ist es, ein Forum für Einzelpersonen und Organisationen zu schaffen, um Open-Source-Lösungen für die weltweiten Märkte der Automobilindustrie zu entwickeln und zu fördern. Welche Rolle spielt Open-Source-Software für die Zukunft des SDV und der Automobilindustrie?

Man müsste eher andersherum fragen: Welche Zukunft hat eine völlig fragmentierte Technologielandschaft in einer Automobilindustrie, die einem immer stärkeren Wettbewerbs-, Kosten- und Innovationsdruck ausgesetzt ist – bei gleichzeitig steigender Softwarekomplexität? Man muss sich nur einmal vor Augen führen, dass gängige Betriebssysteme wie Linux, Windows und OS X mehr gemeinsamen Code enthalten als mehrere hundert Millionen Codezeilen an Fahrzeugsoftware zweier verschiedener Hersteller. Dass es alles andere als nachhaltig und skalierbar ist, wenn jeder seine eigenen Lösungen im stillen Kämmerlein entwickelt, liegt auf der Hand. Open-Source-Software ermöglicht es Unternehmen, schneller Innovationen zu entwickeln, um diesem Wettbewerbsdruck gerecht zu werden. Ziel sollte es dabei immer sein, Interoperabilität und gemeinsame Standards zu schaffen. Das ist nicht nur für die Flexibilität und Anpassungsfähigkeit an Marktanforderungen essenziell, sondern auch, um als Unternehmen für die entsprechenden Talente attraktiv zu sein. Denn ein Grundstock an Standardtechnologien erhöht für Fachkräfte die Chance, mit ihren Skills kompatible Stellen in der Automobilbranche zu finden und in diesen schneller produktiv zu sein.

Zu den Mitgliedern der Eclipse Foundation zählen die Großen der Branche wie Bosch, Mercedes-Benz, Cariad oder SAP. Wie wird die Zusammenarbeit zwischen den verschiedenen Mitgliedsunternehmen organisiert und koordiniert?

Mit ihren zwanzig Jahren Erfahrung hat die Eclipse Foundation einiges an Best Practices nicht nur im Management von Open-Source-Projekten, sondern auch in der Zusammenarbeit in verschiedenen Industry Collaborations gesammelt. Die Kooperation folgt klar definierten Governance-Regeln, die für jedermann transparent und, besonders wichtig, identisch sind. Zusätzlich steht es den Communities frei, sich im Rahmen der existierenden Eclipse Foundation Governance eigene Regeln zu geben. So hat zum Beispiel die SDV Working Group für sich die folgenden neun Prinzipien definiert:

Wie würden Sie die Hauptziele der Software Defined Vehicle Working Group zusammenfassen und wie sollen diese Ziele in den kommenden Jahren erreicht werden?

Das übergeordnete Ziel ist es, Open-Source-Implementierungen der Kernkomponenten für Software Defined Vehicles zu schaffen. Unterstützend werden Prozesse für verschiedene SDV-bezogene Open-Source-Projekte wie Qualitätsmanagement, funktionale Sicherheit, Lieferkettensicherheit etc. etabliert. Die Rahmenbedingungen der Eclipse Foundation für die Erreichung dieser Ziele zu schaffen und einzuhalten – etwa Werte wie „Code-first“, Transparenz, Offenheit, Zusammenarbeit auf Augenhöhe und Meritokratie – ist dabei eine Grundvoraussetzung.

BMW ist erst kürzlich der SDV Working Group der Eclipse Foundation beigetreten und bringt über zwanzig Jahre Erfahrung an In-House Software-Entwicklung in die Initiative ein. Wo liegt mit Blick auf das SDV der Sweet Spot zwischen Eigenentwicklung und Outsourcing?

Wenn wir über Open Source und die Eclipse-SDV-Working-Group-Aktivitäten sprechen, wäre die relevantere Frage eher die nach dem Sweet Spot zwischen den Wettbewerbs-differenzierenden und den nicht-Wettbewerbs-differenzierenden Anteilen eines Softwarestacks. Die nicht-differenzierenden Anteile lassen sich dann kollaborativ im Zusammenspiel der relevanten Player gemeinsam entwickeln, wie dies auch in der SDV Working Group passiert. Diese Kollaboration ist aber dann mitnichten ein Outsourcing im Sinne von „jemand anderes macht“, sondern eine gemeinsame Anstrengung im Sinne von „wir entwickeln gemeinsam“. Die Eigenentwicklung konzentriert sich dann auf die vor Kunde differenzierenden Funktionen, also die Funktionen, die vom Käufer bzw. Fahrer eines Fahrzeugs wahrnehmbar sind und das Markenerlebnis ausmachen. Die Definition, wo sich die Trennlinie oder der Sweet Spot zwischen diesen beiden Teilen eines Stacks befindet, ist gerade Gegenstand hochgradig spannender Diskussionen in unserer Community und wird gegebenenfalls für verschiedene OEMs auch verschiedene Antworten haben.

Wie stellen Sie sicher, dass die entwickelten Softwarelösungen branchenübergreifend kompatibel und interoperabel sind?

Open-Source-Software zielt von Natur aus auf Kompatibilität ab, da sie nicht herstellerspezifisch entwickelt wird, sondern mit dem Fokus auf verschiedene Anwendungsfälle und die Schaffung von Schnittstellen zu anderen Technologien und Mehrwerten außerhalb der eigenen Domäne. Die Nutzung von Softwaretechnologien auf dem neuesten Stand – wie Containertechnologien, moderne Programmiersprachen sowie Prozesse und Methoden für Entwicklung und Testung – sowie die Kompatibilität mit den aktuellsten Versionen sind entscheidend für die Wettbewerbsfähigkeit der entstehenden Software, insbesondere in einem hart umkämpften und unter starkem Innovationsdruck stehenden Markt. Eclipse SDV Blueprints zeigen, wie das Zusammenspiel mehrerer Technologien und Projekte funktionieren kann. Interoperabilität wird von Anfang an als „built-in feature“ mitgedacht. Daneben können die Mitgliedsunternehmen im Rahmen der Eclipse Foundation Governance auch gemeinsam an Spezifikation arbeiten. Als sogenannter ISO JTC1 PAS Submitter hat die Eclipse Foundation dann die Möglichkeit, eine so gemeinsam im Rahmen der Eclipse Foundation entwickelte Spezifikation in eine ISO-Norm zu überführen. Als Beispiel kann hier zum Beispiel die ISO/IEC202376:2023 dienen, bei der die eigentliche Spezifikation im Rahmen der Sparkplug Working Group bei der Eclipse Foundation entstanden ist.

Rivian und Volkswagen gaben kürzlich Pläne zur Gründung eines gemeinsamen Joint Ventures bekannt, in dem neue Architekturen für das Software-Defined Vehicle entwickelt werden sollen. Es scheint, als wäre Softwaretochter Cariad an dieser schwierigen Aufgabe gescheitert. Worin liegt die Schwierigkeit der SDV-Entwicklung, die viele OEMs so herausfordert?

Traditionelle Automobilhersteller sind von Haus aus keine Softwareunternehmen. Ford-CEO Jim Farley betonte in einem Interview, dass Autounternehmen noch nie Software entwickelt hätten, sie schrieben die Software, mit der Autos betrieben würden, zum allerersten Mal selber. Besonders traditionsreiche und bisher erfolgreiche Unternehmen stehen vor großen Herausforderungen, während jüngere Unternehmen ohne Legacy-Systeme, die von Grund auf neu starten, im Vorteil sind. Die Komplexität von Software, Anwendungslandschaften und Architekturen nimmt stetig zu. Gleichzeitig wächst der Fokus auf Kundenzentrierung, und die Erwartungen der Kunden steigen – angetrieben durch herausragende Benutzererfahrungen und fortschrittliche Consumer-Technologien wie künstliche Intelligenz und Augmented Reality. Hinzu kommt, dass Software im Auto sicher sein muss. Wenn die App auf dem Handy abstürzt, sind die Konsequenzen üblicherweise überschaubar. Für die Implementierung eines Fahrerassistenzsystems im  Auto ist ein solcher Ausfall schlicht nicht vorstellbar. In einer solchen dynamischen Umgebung wird Zusammenarbeit unverzichtbar. Durch sie lässt sich die Komplexität im nicht-wettbewerbsdifferenzierenden Teil des Softwarestacks reduzieren und die frei werdenden Ressourcen können dazu genutzt werden, im Sinne von Nutzererlebnis bessere Funktionen schneller zu implementieren.