Eclipse S-CORE soll die Middleware im Software-defined Vehicle auf eine gemeinsame Open-Source-Basis stellen. Sven Kappel von ETAS und Markus Rettstatt von Mercedes-Benz Tech Innovation erklären im Interview, warum gemeinsamer Code Integration, Safety und Industrialisierung beschleunigen kann – und weshalb der eigentliche Wandel weniger technisch als kulturell ist.
Herr Rettstatt, Herr Kappel, was ist Eclipse S-CORE eigentlich – und welches Problem soll das Projekt lösen?
Markus Rettstatt: Im Kern adressiert S-CORE eine bislang fehlende gemeinsame Basis in der Middleware. Wir haben gesehen, dass viele Unternehmen an sehr ähnlichen Problemstellungen arbeiten. Wenn jeder diese Grundlagen separat entwickelt, entsteht enormer Mehraufwand. Durch die Zusammenarbeit in einem Open-Source-Modell reduzieren wir Integrationsaufwand und doppelte Grundlagenarbeit. OEMs und Partner können dadurch deutlich schneller von der Idee in Richtung Fahrzeug kommen.
Sven Kappel: Ergänzend geht es auch darum, eine stabile, langfristig nutzbare Basis zu schaffen. Wir wollen nicht bei jeder Fahrzeuggeneration wieder bei null anfangen, sondern eine Plattform etablieren, die sich über Generationen hinweg weiterentwickeln lässt und dabei ein gewisses Maß an Abwärtskompatibilität mitbringt. So reduzieren wir nicht nur den Aufwand in der Integration, sondern auch in der eigentlichen Entwicklung.
Herr Rettstatt, Sie arbeiten bei Mercedes-Benz Tech Innovation direkt an der Softwareentwicklung für den OEM. Wann war für Sie klar, dass Fahrzeugsoftware ohne offene Zusammenarbeit und Open Source langsam, teuer oder komplex wird?
Rettstatt: Die entscheidende Erkenntnis war, dass die eigentliche Differenzierung für OEMs am oberen Ende des Stacks entsteht, also dort, wo Funktionen kundenrelevant und markenprägend werden. Alles darunter ist im Grunde nicht differenzierende Basisarbeit. Genau dort haben wir aber gesehen, dass viele Akteure an denselben Problemen arbeiten. In Gesprächen mit Partnern und Zulieferern wurde immer deutlicher, dass in vielen Fahrzeugprogrammen sehr ähnliche technische Herausforderungen parallel gelöst werden. Das ist weder effizient noch nachhaltig. Deshalb war für uns klar: Es braucht eine gemeinsame Basis, und Open Source ist dafür ein sehr geeigneter Ansatz, weil er echte Zusammenarbeit auf Augenhöhe ermöglicht.
S-CORE ist ein Gemeinschaftsprojekt von OEMs, Zulieferern und Softwarepartnern. Was war in der Anfangsphase anspruchsvoller: die technische Einigung oder der kulturelle Wandel?
Kappel: Beides war anspruchsvoll, aber auf unterschiedliche Weise. Technisch lässt sich am Ende fast immer eine Lösung finden. Architekten diskutieren, bewerten Optionen und kommen irgendwann zu einer tragfähigen Entscheidung. Die größere Veränderung liegt aus meiner Sicht aber im kulturellen Bereich. In der Industrie ist man es zwar gewohnt, Open-Source-Komponenten in einzelnen Bereichen einzusetzen, etwa im Infotainment. Aber ein sicherheitsrelevantes Stack von Grund auf gemeinsam zu denken und zu entwickeln – inklusive Prozesse, Dokumentation und Qualitätsanforderungen –, das ist etwas anderes. Hinzu kommt: In einer offenen Community arbeiten plötzlich Unternehmen zusammen, die in anderen Bereichen durchaus im Wettbewerb stehen. Dass diese Firmen gemeinsam um die beste technische Lösung ringen und Wissen transparent teilen, ist eine echte kulturelle Veränderung. Wir haben dafür eine Grundlage gelegt, aber dieser Prozess ist nicht abgeschlossen. Im Idealfall wächst daraus eine breit getragene Community, die perspektivisch die gesamte Automotive-Industrie einbindet.
Im Kontext des Software-defined Vehicle fällt seit Jahren immer wieder ein zentrales Stichwort: Entwicklungsgeschwindigkeit. Wie kann Open Source die Time-to-Delivery tatsächlich verkürzen, ohne neue Abstimmungsrunden zu schaffen?
Rettstatt: Weil eine gemeinsame Codebasis sehr viel schneller skaliert als reine Abstimmung über Dokumente und Gremien. Wenn man sich nur über Spezifikationen verständigt, dauert es häufig lange, bis daraus belastbare Ergebnisse entstehen. Wenn man dagegen auf konkrete Code-Artefakte schaut, sieht man sehr schnell, was funktioniert und was nicht. Das beschleunigt Entscheidungen erheblich. Natürlich bewegen wir uns im regulierten Automotive-Umfeld. Deshalb kann man ein solches Modell nicht eins zu eins aus anderen Softwarewelten übernehmen. Wir haben unsere Code-First-Methodik bewusst so angepasst, dass sie architekturfokussiert bleibt und den Anforderungen der Automobilindustrie gerecht wird. Aber genau darin liegt der Vorteil: Wir kombinieren Entwicklungsdynamik mit industrieller Verlässlichkeit.
Kappel: Der große Unterschied liegt darin, dass klassische Zusammenarbeit in der Branche oft stark spezifikationsgetrieben ist. Zunächst wird über lange Zeit spezifiziert, dann wird implementiert, dann geliefert. Und erst danach können Entwickler differenzierender Funktionen wirklich aufsetzen. In einer Open-Source-Community wie S-CORE kann ein Entwickler dagegen sehr viel früher anfangen. Er lädt den Code herunter, arbeitet auf einer stabilen Basis und muss nicht erst warten, bis mehrere Stufen nacheinander abgeschlossen sind. Das verändert die Dynamik grundlegend. Auch Universitäten oder neue Partner können deutlich früher einsteigen. Entwicklung wird dadurch gemeinschaftlicher, paralleler und letztlich schneller. Wenn es dann noch gelingt, über Generationen hinweg auf dieser Basis aufzubauen, statt immer wieder von vorne zu beginnen, entsteht ein Geschwindigkeitsvorteil, der in der Industrie enorm relevant ist.
Wo geht denn in Fahrzeugprogrammen heute am meisten Zeit verloren?
Rettstatt: Der größte Zeitverlust entsteht bei Integration und Absicherung, nicht primär beim Schreiben von Code. Das hat viel damit zu tun, dass heute zahlreiche proprietäre Stacks zusammengeführt werden müssen, die nie wirklich gemeinsam gedacht wurden. Genau daraus entstehen Reibung, Nacharbeiten und enorme Validierungsaufwände.
Kappel: Und dieser Effekt wiederholt sich von Projekt zu Projekt. Wenn jedes Programm auf einer neuen Basis startet, beginnt auch der Absicherungsaufwand immer wieder von vorn. Wenn man dagegen auf einer stabilen, gemeinsam entwickelten Grundlage aufsetzt, muss man im Idealfall nur noch die Deltas absichern. Genau das ist ein zentraler Hebel. Hinzu kommt, dass wir in S-CORE den Anspruch haben, den Stack inklusive der Betriebssystemebene integrierbar zu machen. Das heißt: Der Public Release ist nicht nur theoretisch vorhanden, sondern praktisch lauffähig.
Sie haben bereits angesprochen, dass S-CORE bewusst den nicht differenzierenden Teil der Software adressiert. Wo verläuft diese Grenze in der Praxis?
Kappel: Grundsätzlich zwischen Basissoftware, Middleware und Anwendungssoftware. Die Anwendungssoftware ist der Bereich, in dem OEMs ihre eigentliche Differenzierung erzeugen – also dort, wo das Kundenerlebnis, Markenlogik und fahrzeugspezifische Funktionen entstehen. Der Unterbau darunter ist aus Sicht vieler Hersteller nicht der Bereich, in dem man sich strategisch unterscheiden muss. Genau deshalb ergibt es Sinn, diesen Teil gemeinschaftlich zu entwickeln. Trotzdem bleibt Raum für Differenzierung – auch für Zulieferer oder Distributoren. Das kann etwa über besonders performante Ausprägungen, ergänzende Tools oder Dienstleistungen rund um den Stack geschehen. Unser Ziel ist es, in der Community einen lauffähigen, belastbaren Stack bereitzustellen. Wie dieser dann industrialisiert, optimiert oder mit zusätzlichen Services versehen wird, kann weiterhin unterschiedlich ausfallen.
Rettstatt: Genau. OEM-spezifisch bleiben Produktlogik, Markenerlebnis und datengetriebene Funktionen. Diese Assets werden auch künftig klar getrennt bleiben. Aber bei der nicht differenzierenden Basis ergibt gemeinschaftliche Entwicklung schlicht mehr Sinn als parallele Einzelarbeit.
Herr Rettstatt, ist Open Source für Mercedes-Benz unter dem Strich bereits ein Beschleuniger – trotz zusätzlicher Governance-Anforderungen?
Rettstatt: Ja, unterm Strich ganz klar. Es verlangt mehr Disziplin in der Middleware-Governance, das ist keine Frage. Aber mittelfristig reduziert es Reibung, und langfristig ist es ein echter Skalierungshebel. Wichtig ist dabei, nicht nur den Stack selbst zu entwickeln, sondern immer auch seine Adaptionsfähigkeit im Blick zu behalten: Wie lässt sich das Ganze in realen OEM-Programmen einsetzen? Gerade an diesen Reibungspunkten hilft die offene Zusammenarbeit, weil architektonische Entscheidungen früher und fundierter getroffen werden können.
Herr Kappel, ETAS spricht sehr offensiv über aktive Mitgestaltung von Architektur und Implementierung. Wo sehen Sie derzeit den größten Hebel: in besserem Code, in besseren Toolchains oder in einem neuen Industrialisierungsmodell?
Kappel: Alle drei Aspekte sind wichtig, aber der größte Hebel liegt am Ende wohl tatsächlich im Industrialisierungsmodell. Besserer Code ist ein klarer Vorteil, schon weil in einer offenen Community mehr Augen auf denselben Code schauen. Gerade in Security-Fragen ist das ein wesentlicher Punkt. Ebenso zentral ist die Toolchain. Wer Safety, Compliance und Nachvollziehbarkeit ernst nimmt, braucht transparente Prozesse von der Anforderung über den Feature Request bis zur Delivery. Der eigentliche Durchbruch liegt aber darin, dass wir denselben Code industrialisieren. Das verändert die Rollen im Markt. Distributoren können sich stärker auf echte Mehrwerte konzentrieren, statt sich über die reine Basisimplementierung zu unterscheiden. Gleichzeitig bekommen OEMs mehr Flexibilität, weil sie nicht bei jedem Wechsel eines Partners ihre Anwendungssoftware neu aufsetzen müssen. Dazu kommt ein anderes Geschäftsmodell: weg vom rein lizenzbasierten Verkauf, hin zu kontinuierlicher Delivery und stärker serviceorientierten Modellen. Und genau an dieser Stelle sehen wir auch unsere Rolle: nicht nur als Mitgestalter in der Community, sondern als verlässlicher Partner, der diese Basis in reale Serienprojekte überführt. Für OEMs ist am Ende nicht nur entscheidend, dass der Code offen und technisch stark ist, sondern dass es Partner gibt, die Verantwortung in Industrialisierung, Integration, Absicherung und langfristigem Betrieb übernehmen.“
Welche Integrationsprobleme löst ein Layer wie S-CORE heute schon besser als klassische proprietäre Middleware-Stacks?
Rettstatt: Vor allem die vielen projektspezifischen Sonderanpassungen, die bei proprietären Ansätzen fast zwangsläufig entstehen. Wenn man an der Entwicklung des Stacks beteiligt ist, wird Integration deutlich vorhersehbarer. Schnittstellen werden robuster und wir achten sehr bewusst auf Interoperabilität mit etablierten Standards, etwa aus AUTOSAR oder COVESA. Die Idee ist nicht, Standards zu ignorieren, sondern sie sinnvoll mit einer codezentrierten Entwicklung zu verbinden.
Kappel: Die Middleware hat die Aufgabe, zwischen Betriebssystemen und Anwendungssoftware zu vermitteln. Wenn diese Schicht offen und transparent ist, lässt sie sich von unten ebenso sauber integrieren wie von oben. Genau daraus entstehen höhere Verlässlichkeit, mehr Transparenz und kontinuierliche Weiterentwicklung. Das ist gegenüber proprietären, isoliert gedachten Stacks ein wesentlicher Unterschied.
Sie sprechen bei S-CORE von iterativer, codegetriebener Entwicklung statt eines rein spezifikationsgetriebenen Ansatzes. Ist das der eigentliche Kulturbruch mit der klassischen Autoindustrie?
Kappel: Ja, das ist sicherlich einer der entscheidenden Punkte. In der Vergangenheit wurde in Gremien spezifiziert und anschließend in Unternehmen implementiert. Das Problem dabei ist, dass Spezifikationen interpretierbar sind. Zwei Implementierungen können sich auf denselben Standard beziehen und sich trotzdem unterschiedlich verhalten. Genau dieses Problem verringert sich, wenn die gemeinsame Codebasis das führende Artefakt ist. Dann reden wir nicht mehr über unterschiedlich ausgelegte Spezifikationen, sondern über denselben Code.
Rettstatt: Wichtige Spezifikationen verschwinden deshalb nicht. Aber das führende Element wird stärker das entwickelte Artefakt selbst. Von dort aus kann dann wiederum in Standards und Spezifikationen zurückgespiegelt werden. Das verändert die Logik der Zusammenarbeit deutlich.
S-CORE setzt aktuell sowohl auf C++ als auch auf Rust. Warum fahren Sie diesen zweigleisigen Ansatz?
Rettstatt: Rust spielt seine Stärken dort aus, wo sicherheitsrelevante Middleware-Komponenten und Nebenläufigkeit kritisch sind. C++ bleibt dort sinnvoll, wo Performance, bestehende Ökosysteme und Legacy-Integration dominieren. Wir können und wollen bewährten, serienreifen Code nicht einfach verwerfen. Mittelfristig wird Rust sicher an Bedeutung gewinnen, aber aktuell ist die parallele Unterstützung beider Sprachen der pragmatische Weg.
Kappel: Genau. Wenn wir bestehenden, serienreifen Code übernehmen, ergibt es keinen Sinn, ihn allein aus Prinzip nach Rust zu übersetzen. Wo wir dagegen neue Konzepte von Grund auf neu entwickeln, ist Rust häufig die naheliegende Wahl.
Am Ende geht es in der Automobilindustrie immer auch um Safety, Security und Serienreife. Wie verhindern Sie, dass die zu Beginn gewonnene Geschwindigkeit später durch Compliance- und Freigabeprozesse wieder verloren geht?
Kappel: Indem wir diese Themen von Anfang an mitdenken. Für uns war früh klar, dass S-CORE nur dann tragfähig ist, wenn Safety, Security, Prozesse und Dokumentation von Beginn an mitentwickelt werden. Genau deshalb ist der Prozess in S-CORE so aufgesetzt, dass ein Distributor daraus ein zertifizierbares Produkt ableiten kann. Wir formulieren das bewusst so: S-CORE selbst ist safety-zertifizierungsfähig, und ein Distributor macht daraus ein zertifiziertes Produkt für den OEM. Um das sicherzustellen, lassen wir unsere Prozesse regelmäßig extern auditieren. Mit Exida haben wir einen Partner an Bord, der uns seit Beginn begleitet und sowohl Entwicklungsprozesse als auch Artefakte prüft. So schaffen wir die Grundlage dafür, dass Industrialisierung und Zertifizierung später nicht zum Bremsklotz werden.
Zum Schluss der Blick nach vorn: Woran würden Sie den Erfolg von S-CORE in drei Jahren messen?
Rettstatt: Für mich wäre ein zentrales Erfolgskriterium, dass mehr Serienfahrzeuge denselben Kern nutzen. Außerdem wäre es ein starkes Signal, wenn Grundsatzdebatten über Middleware deutlich zurückgehen und Open Source im Fahrzeug nicht mehr als Sonderfall gilt, sondern als Normalität.
Kappel: Ich würde das gern um zwei Punkte ergänzen: Erstens eine wirklich florierende Community, die wächst – nicht nur in Europa, sondern global. Zweitens wäre es ein großer Erfolg, wenn S-CORE zu einem Ort wird, an dem Innovationen schnell in Richtung Industrialisierung gelangen. Das gilt auch für KI-getriebene Ansätze. Wenn neue Ideen nicht in einer reinen Experimentierkultur stecken bleiben, sondern über S-CORE zügig in die Serie kommen, dann haben wir viel richtig gemacht.
