gesponsertOpen-Source-Software Gemeinsam entwickeln statt doppelt investieren

Gesponsert von

ETAS GmbH

Sven Kappel von ETAS erwartet den S-CORE-Release 1. 0 gegen Jahresende, erste Serienprojekte 2029/30. Im Interview erklärt er, warum er Open Source für die einzige sinnvolle Initiative hält.

Herr Kappel, Sie sind von Beginn an im S-CORE-Projekt aktiv. Wie bewerten Sie den aktuellen Stand?

Sven Kappel: Wir gehen jetzt mit großen Schritten in Richtung 1.0-Release, das gegen Ende dieses Jahres kommen wird. Das ist die Basis, auf der Produkte aufsetzen können. Auf diesem Major Release setzen wir als ETAS unsere Produktentwicklung auf. Einige Fahrzeughersteller haben RFQs, also Requests for Quotations, angefragt. Hierzu schreiben wir momentan offizielle Angebote, um in Richtung 2029/30 mit dem ersten S-CORE-Stack in Serie zu gehen. 

Welche Rolle nimmt ETAS im Projekt ein?

Insgesamt sind wir Nummer 2 unter den Code-Kontributoren. Wenn ich die OEMs weglasse, sind wir Nummer 1. Zu unseren Kernthemen, die wir beitragen, gehört alles, was in Richtung Security und Crypto geht. Dort haben wir eine große Kompetenz, die wir einbringen können. Ähnlich ist es bei Kommunikationsschnittstellen und Kommunikations-Gateways. Deshalb kommt das Thema SOME/IP-Gateway von uns. Und wir haben von Anfang an großen Wert auf Infrastruktur und Tooling gelegt. Denn wenn man daraus irgendwann Produkte bauen will, muss man eine gute Anbindung im Upstream und im Downstream an die Infrastruktur haben.

In Zukunft wird es noch einmal entscheidend sein, wenn erste Serienprojekte wirklich in Serie gehen. Dann kommt es vor allem darauf an, das ganze Thema Maintenance zur Verfügung zu stellen. Ich bin gespannt, wie sich das dann entwickelt, wenn wir gegebenenfalls verschiedene Varianten pflegen müssen. Wenn also die eine Variante in Serie geht und die andere sich weiterentwickelt: Wie baut man dann das Delivery darauf auf? Dabei haben wir als ETAS und in Summe auch als Bosch natürlich viel Erfahrung mit Variantenmanagement in Automotive-Software. 

Kollaboration in einem Open-Source-Software-Projekt ist für die Autoindustrie ziemliches Neuland.

Ich bin überzeugt, dass Open Source die einzige sinnvolle Initiative ist, um auf Code-Ebene zu standardisieren und nicht auf Spezifikationsebene. In der Community kommen Wettbewerber zusammen und können ohne kartellrechtliche Probleme über Anforderungen und Code sprechen – weil alles offen und öffentlich ist. Wir können einander reviewen und dabei unterstützen, Dinge zu entwickeln. Das ist Neuland. Aber man merkt schon heute, dass dadurch auch der eine oder andere Knoten gelöst werden kann, der vielleicht in der Vergangenheit da war. Außerdem ist Code überall gleich. Entwickler aus der ganzen Welt können sich auf der Code-Ebene etwa in den Sprachen C++ oder Rust austauschen. Das darf man nicht vernachlässigen. Bei unseren eigenen Mitarbeitern beobachte ich zudem, dass diese Form der Zusammenarbeit die Entwickler motiviert.

Viele Augen können mehr Schwachstellen entdecken. Darin liegt die Sicherheitschance von Open Source.

Wie wird das Projekt international angenommen?

Es gibt einen regen Austausch mit der PFA aus Frankreich und wir engagieren uns sehr stark in Richtung Japan. In Indien wurde eine eigene Special Interest Group zu S-CORE gegründet: Bharat SDV. Wir haben in Indien ein Stück weit die gleiche Struktur übernommen, mit S-CORE als Basis, um darauf auch für den indischen Markt eine Open-Source-Community zu etablieren. 

…fehlen noch Nordamerika und China.

In Nordamerika führen wir diverse Gespräche. Dort kommt es darauf an, wann sich die E/E-Architekturen ändern. Wir führen mit den großen OEMs Gespräche. Erst mit den neuen Architekturen wird dort auch das Thema S-CORE relevanter werden. In China ist es schwierig, sich mit Open-Source-Software zu positionieren. Aber, für chinesische Hersteller könnte S-CORE die Basis sein, damit sie im Rest der Welt Fahrzeuge verkaufen können und dürfen.

Welche Geschäftsmodelle möchten Sie daraus entwickeln, die ETAS dann kommerzialisiert?

Der Code, also der S-CORE-Stack als Public Release, ist „safety certifiable“. Alle Informationen sind vorhanden, damit eine Firma wie ETAS daraus ein zertifiziertes Produkt machen kann. Für dieses Produkt haften wir, geben Maintenance und Support. Wir helfen bei der Integration und geben Tools dazu. Dafür haben wir ein Geschäfts- und ein Preismodell entwickelt, mit dem wir das in den ersten SOP-Projekten monetarisieren werden.

Ein OEM könnte die Themen auch allein abarbeiten.

Ja, natürlich könnte er das. Aber im Moment geht es darum, die Kosten im Blick zu behalten – also das richtige Verhältnis zwischen Nutzen und Kosten zu finden. Wir haben genügend Doppelentwicklungen im Markt. Wir sind davon überzeugt, dass wir mit S-CORE einen deutlich günstigeren Stack liefern können. Der funktioniert aber nur, wenn er skaliert. Das wissen die OEMs auch. Wenn jetzt jeder OEM wieder etwas Eigenes machen würde, wäre das in Summe für die Industrie definitiv nicht kostenoptimiert.

Wie steht der S-CORE-Stack zu Autosar und Autosar Adaptive?

AUTOSAR Classic bleibt für etablierte Steuergerätearchitekturen wichtig. Darüber hinaus bleiben standardisierte Kommunikations- und Diagnoseschnittstellen relevant. Bei AUTOSAR Adaptive bin ich skeptisch. Der Standard hat nie die Skalierung erreicht wie sein Classic-Pendant. Viele OEMs haben begonnen, Dinge selbst zu entwickeln, auf Basis von POSIX-Betriebssystemen. Das Zweite ist, und davon sind wir große Verfechter, das Thema Geschwindigkeit. In S-CORE kann ich mich viel schneller auf eine gemeinsame Entwicklung einigen, als ich das jemals in einem Standardisierungsgremium könnte. Das ist immer dann ein Vorteil, wenn es um Funktionalitäten geht. AUTOSAR hat seine Stärken in der Kommunikation: dort wo Steuergeräte miteinander reden oder in der Diagnose.

Wie sicher ist Open-Source-Software im Sinne von Cybersecurity?

Open Source bietet gute Voraussetzungen für Sicherheitsprüfungen: Der Code ist einsehbar und kann von unterschiedlichen Experten untersucht werden. Entscheidend ist aber, dass diese Prüfung tatsächlich stattfindet und Schwachstellen konsequent behoben werden. Ich habe hier ganz andere Möglichkeiten und Experten, die ich sonst vielleicht nie zusammenbekäme, wenn ich rein proprietär entwickle. Ich bin der Meinung, das Security-Konzept muss so gut sein, dass der Code offenliegen kann und ich trotzdem kein Problem bekomme. Deshalb ist die Open-Source-Community eher ein Vorteil als ein Nachteil.

Wie verändert der Einsatz von KI die Zusammenarbeit in Open-Source-Communities?

Massiv. Das fängt bereits bei den Pull Requests an. In anderen, größeren Open-Source-Communities werden mittlerweile sehr viele Pull Requests automatisch generiert. Die Community muss im ersten Schritt diese Anfragen strukturieren und priorisieren. Das verändert die Arbeit in der Community. Wir brauchen neue oder veränderte Methoden und Prozesse, um die wichtigen Pull Requests herauszufiltern. Wir müssen es schaffen, diese Anzahl an generierten Pull Requests zu bewältigen. Auf Code-Ebene geht es darum, an welcher Stelle der Mensch eingreift und entscheidet, ob die Software serienreif ist, also die Frage nach dem Human-in-the-Loop. Hier ist es wichtig, dass ich einen Distributor wie ETAS habe, der das garantiert und die Software pflegt.

Haben Sie ein Beispiel?

Wenn ein KI-Agent Code schreibt und ein anderer Agent reviewt ihn: Kann ich so etwas nach Automotive-Prozessen freigeben? Ich glaube, in diese Richtung müssen wir denken. Hier geht es um die Safety-Ebene, deshalb braucht es einen Human-in-the-Loop, der entscheidet, dass ich damit in Serie gehen kann.