Für softwaredefinierte Fahrzeuge (SDV) fließen Milliarden in die Entwicklung von Softwarebasen, die sich kaum voneinander unterscheiden. Das Open-Source-Projekt Eclipse S-CORE macht diesen Schritt wirtschaftlicher.
Sven Kappel
Head of ETAS.NEXT & Project Lead Eclipse S-CORE
Herr Kappel, welche Pain-Points von OEMs adressiert S-CORE?
Heute baut nahezu jeder OEM eigene Software-Stacks für SDV; das führt zu Doppelentwicklungen, hohen Integrationsaufwänden und Schnittstellenbrüchen. Integration, Tool-Setup und Re-Validierung, auch mit Safety- und Security-Nachweisen, beginnen meist von vorn, wenn eine neue Fahrzeuggeneration entwickelt wird oder beim Wechsel von Plattformen oder Lieferanten.
Hier setzt S-CORE an. Durch die stabile, vorintegrierte Middleware zwischen Betriebssystem und Anwendungen müssen Entwicklungsprogramme nicht immer wieder bei null ansetzen.
Was ändert sich mit S-CORE konkret?
Entwicklungsteams starten mit S-CORE nicht mehr mit einem „leeren Blatt“, sondern nutzen eine geprüfte und dokumentierte Basis. Das beschleunigt die Umsetzung neuer Funktionen erheblich, weil der technische Unterbau stabil und verfügbar ist. Bei Security-Schwachstellen ermöglicht die Open-Source-Community zudem eine schnellere Entwicklung und Verteilung von Patches.
Warum wird diese Entwicklung gerade jetzt vorangetrieben?
Die technische Gesamtstruktur moderner Fahrzeuge wird komplexer, während der wirtschaftliche Spielraum schrumpft. Statt in Basissoftware müssen Automobilhersteller ihre Ressourcen vermehrt in differenzierende Funktionen und Merkmale wie Fahrassistenzsysteme oder User Experience investieren. Zudem stoßen klassische Spezifikationsstandards an Grenzen: Gleiche Spezifikationen werden unterschiedlich interpretiert. Ein Code-first-Ansatz reduziert diese Interpretationsspielräume deutlich.
Was genau ist S-CORE? Und was ist es bewusst nicht?
S-CORE ist weder ein Betriebssystem noch eine Applikation; es ist die Software-Schicht dazwischen: grundlegende Dienste wie Kommunikation, Logging und Monitoring, die jedes Steuergerät benötigt, die aber selbst nicht differenzierend sind.
Welche Rolle spielt ETAS im S-CORE-Projekt?
Zu Beginn lag unser Fokus auf dem Aufbau von Prozessen, Dokumentation und CI/CD-Pipelines, mit einer klaren Safety- und Security-Ausrichtung. Inzwischen bringen wir auch eigene Komponenten ein, etwa für Logging, Monitoring und Kommunikation. Darüber hinaus verstehen wir uns als kommerzieller Distributor. Wir übersetzen Community-Code in einen über Jahre wartbaren, supportfähigen Stack, inklusive Haftung und langfristiger Pflege.
Wie ist die Governance organisiert?
Maintainer und Committer entscheiden in ihren jeweiligen Teilbereichen über Beiträge. Darüber hinaus koordinieren Projektleitung und Architektur-Gremien die Gesamtlinie. Entscheidungen erfolgen über transparente Reviews und Feature-Anträge. Nichts passiert informell oder „per Zuruf“.
Behalten OEMs und Zulieferer mit dieser Open Source-Lösung noch Differenzierungsmöglichkeiten? Was bleibt proprietär?
Differenzierung findet auf der Anwendungsebene statt: bei Funktionen, Daten, Marken-UX und Fahrverhalten. Proprietär bleiben typischerweise IP-sensible Algorithmen und spezielle Optimierungen. Auch auf Distributor-Ebene gibt es Spielraum, etwa beim Performance-Tuning, bei Security-Paketen oder beim Tooling rund um Entwicklung und Test.
Wo entsteht der wirtschaftliche Hebel?
Auch wenn der Code offen verfügbar ist, ist die Serienfähigkeit nicht kostenfrei. Sie erfordert Integration, Zertifizierungsfähigkeit, Wartung und Support. Für OEMs sinken typischerweise Integrations- und Re-Validierungskosten, die Time-to-Market verbessert sich und Lock-in-Risiken nehmen ab.
ETAS begleitet hier OEMs und Tier-1:
Wir helfen bei der Architekturentscheidung und unterstützen beim Setup von Tool-Chain, Pipelines und Proof of Concept, bis hin zur Bewertung eines möglichen Serieneinsatzes.
