Da die Automobilindustrie den Schritt von der SDV-Vision zur
Serienumsetzung schaffen will, verlagert sich der Druck von der Verfügbarkeit
der Technologie hin zu Integrationsfähigkeit, Governance und langfristiger
Plattformdisziplin. Offene Software-Grundlagen, skalierbare Ökosysteme und
konsistente Betriebsmodelle werden somit zu entscheidenden Faktoren einer
Branche unter Druck.
Dr. Thomas Irawan, Präsident und Vorsitzender der
Geschäftsführung von ETAS, wird diesen Themenkomplex gemeinsam mit Dr.
Christian Salzmann von BMW auf dem AUTOMOBIL-ELEKTRONIK Kongress 2026 adressieren – in einer Doppelkeynote, die den
Branchenauftrag bereits im Titel trägt: „Eclipse S-CORE
– Speed, Efficiency, Community in Open Source: Time to Deliver“.
Im Vorfeld der Veranstaltung in Ludwigsburg haben wir mit
Dr. Irawan über das Betriebsmodell, Plattformentscheidungen und Abstimmungsfragen
im Ökosystem gesprochen, die nötig sind, um SDV- und KI-Strategien zu
skalieren.
Hr. Dr. Irawan, was wird in den nächsten drei bis fünf
Jahren der größte Engpass sein, um SDV- und KI-Strategien in skalierbare,
industrialisierte Fahrzeugplattformen zu überführen?
Der größte Engpass wird nicht die Verfügbarkeit der
Technologie sein. Die Kerntechnologien für softwaredefinierte und KI-fähige
Fahrzeuge sind weitgehend bereits vorhanden. Der eigentliche Engpass wird die
Fähigkeit der Industrie sein, ihr Betriebsmodell und ihr Ökosystem so
aufeinander abzustimmen, dass sich diese Technologien im großen Maßstab
industrialisieren lassen. In den kommenden drei bis fünf Jahren wird der Erfolg
weniger davon abhängen, wer die fortschrittlichsten einzelnen
KI-Anwendungsfälle hat, sondern vielmehr davon, wer Architektur, Organisation
und Partner in ein skalierbares Umsetzungsmodell zusammenführen kann. Anders
gesagt: Die Herausforderung ist nicht die Innovation selbst, sondern die
koordinierte Industrialisierung.
Das wurde für mich auf meiner jüngsten Reise nach China sehr
greifbar. Auffällig war dort nicht nur das Entwicklungstempo, sondern auch eine
andere architektonische Logik und Herangehensweise. In vielen westlichen
Automotive-Programmen bewegt sich die Branche noch immer von einer hardwarezentrierten Historie hin zum softwaredefinierten Fahrzeug, wobei KI
häufig als zusätzliche, vor allem funktionsbasierte Schicht obenauf gesetzt
wird. In China nähern sich einige führende chinesische
OEMs dem Fahrzeug bereits stärker aus einer KI-nativen Perspektive. Dort
sehen wir zunehmend, dass KI-Anforderungen Architekturentscheidungen in der
Software beeinflussen und die Softwarearchitektur dann die Hardware definiert.
Ich würde das nicht als Frage darstellen, bei der die eine
Seite richtig und die andere falsch liegt. Es ist weitgehend ein Spiegel
unterschiedlicher Ausgangspunkte und verschiedener historischer Zwänge. Aber es
verdeutlicht eine entscheidende Verschiebung: Künftige Wettbewerbsfähigkeit
wird weniger davon abhängen, bestehenden Systemen Intelligenz hinzuzufügen,
sondern davon, Hardware, Software, Daten und KI von Anfang an als eine
kohärente Architektur zu entwerfen. Genau dort liegt der eigentliche Engpass.
Um in diesem Umfeld erfolgreich zu sein, brauchen
Unternehmen mehr als starke Einzeltechnologien. Sie brauchen ein deutlich
softwarezentrierteres Betriebsmodell, frühere funktionsübergreifende
Entscheidungen, schnellere Integrationsschleifen und eine wesentlich engere
Zusammenarbeit zwischen OEMs, Zulieferern, Halbleiterunternehmen,
Cloud-Anbietern und Infrastrukturpartnern. Im SDV-Zeitalter ist die
Leistungsfähigkeit des Ökosystems zu einer zentralen Wettbewerbsfähigkeit
geworden. Wenn das Ökosystem nicht abgestimmt ist, bricht Skalierbarkeit
zusammen – bei Geschwindigkeit, Kosten, Qualität und Lifecycle-Management. Wenn
es abgestimmt ist, können Unternehmen Innovation in wiederholbare,
industrialisierte Plattformen überführen.
Meine Sicht darauf ist daher sehr klar: Der größte Engpass
in den nächsten drei bis fünf Jahren wird im Betriebsmodell und in der
Abstimmung des Ökosystems liegen – also in der Fähigkeit, Architektur,
Governance, Entwicklungsprozesse und Partner auf einer gemeinsamen Software-
und KI-Basis auszurichten.
Wie sich
SDV-Plattformen industrialisieren lassen
Welche heute getroffene Entscheidung wird am stärksten
bestimmen, wo künftig Wertschöpfung im automobilen Ökosystem entsteht?
Die wichtigste Entscheidung ist diese: wie ein OEM
definiert, wo er sich differenzieren will und wo er standardisiert. Die
strategische Frage lautet nicht mehr einfach nur, wem die Software gehört. Die
eigentliche Frage ist, wer die Teile des Fahrzeugerlebnisses kontrolliert, die
die Marke wirklich prägen. Genau dort wird künftig Wertschöpfung entstehen.
Die Gewinner werden nicht die Unternehmen sein, die
versuchen, jede Software-Schicht selbst zu entwickeln. Es werden jene sein, die
die nicht differenzierende Basis standardisieren und ihre eigenen Ressourcen
auf das konzentrieren, was das Fahrzeug einzigartig macht – vom Fahrverhalten
und automatisierten Funktionen über User Experience und Komfort bis hin zu
KI-gestützten Diensten.
Deshalb sind offene, produktionsreife Grundlagen so wichtig.
Wenn OEMs aufhören, den grundlegenden Software-Stack – Middleware,
Betriebssystemschichten, Kommunikations-Frameworks, Hardware-Abstraktion –
immer wieder neu zu erfinden, können sie knappe Engineering-Kapazitäten auf die
Funktionen lenken, die der Kunde sieht und erlebt.
Aus meiner Sicht sollten OEMs also nicht versuchen, alles
selbst zu programmieren. Sie müssen Architekten des Ganzen sein. Sie sollten
starke Partner und offene Ökosysteme für die Commodity-Schichten nutzen und
gleichzeitig die Kontrolle über die funktionale Logik behalten, die den
Charakter des Fahrzeugs definiert.
Einfach gesagt: Die Basis standardisieren, die
Differenzierung schützen. Diese Entscheidung wird bestimmen, wo im künftigen
automobilen Ökosystem Wertschöpfung verortet ist.
Wo SDV- und
E/E-Architekturansätze an ihre Grenzen stoßen
An welchen Stellen bleiben aktuelle Ansätze für SDVs und
E/E-Architekturen der nächsten Generation in realen Programmen noch hinter den
Anforderungen zurück?
Aktuelle Ansätze für SDVs und E/E-Architekturen der nächsten
Generation scheitern nicht an mangelndem Anspruch. Sie scheitern daran, wie sie
integriert, industrialisiert und über die Zeit hinweg aufrechterhalten werden.
Eine große Schwäche in realen Programmen ist nach wie vor
die späte Integration. Hardware, Basissoftware, Middleware, Anwendungen und
cloudbezogene Komponenten werden oft parallel entwickelt, aber nicht früh genug
gegen ein stabiles Architekturziel integriert. Dadurch treten kritische
Abhängigkeiten, Performance-Probleme und Schnittstellenkonflikte erst spät im
Programm auf – zu einem Zeitpunkt, an dem ihre Behebung deutlich teurer und
störender ist. Das führt zu Verzögerungen, Nacharbeit und erheblichen Umsetzungsrisiken.
Ein zweites Problem sind fragmentierte Stacks. Viele
aktuelle SDV-Ansätze sind noch immer ein Flickenteppich herstellerspezifischer
Lösungen, hardwaregebundener Software-Schichten und teilweise inkompatibler
Frameworks. Auf Prototypenebene mag das funktionieren, doch beim Skalieren über
Plattformen, Fahrzeuglinien und Generationen hinweg wird es zu einem
ernsthaften Hindernis. Fragmentierung reduziert die Wiederverwendung, erhöht
den Validierungsaufwand und erschwert die konsistente Weiterentwicklung des Gesamt-Stacks.
Damit kommen wir direkt zur dritten Lücke: die
Lifecycle-Belastung. In vielen Fällen ist der Stack vor allem für den SOP
ausgelegt, aber nicht ausreichend für den gesamten darauffolgenden
Lebenszyklus. Sobald Software über viele Jahre gewartet, aktualisiert,
abgesichert, zertifiziert und unterstützt werden muss, wird architektonische
Fragmentierung zu einem wesentlichen Kosten- und Komplexitätstreiber. Was zum
Start noch beherrschbar wirkt, kann über einen Fahrzeuglebenszyklus von zehn
bis fünfzehn Jahren extrem belastend werden.
Meine Sicht ist daher: Aktuelle Ansätze bleiben häufig
hinter den Anforderungen zurück, weil Integration zu spät erfolgt, der
Technologie-Stack zu fragmentiert bleibt und die langfristige
Lifecycle-Belastung noch immer unterschätzt wird. Die
eigentliche Herausforderung liegt nicht darin, die SDV-Vision zu definieren –
sie liegt darin, einen Stack aufzubauen, der sich früh integrieren, konsistent
skalieren und über die Zeit effizient managen lässt.
Was zeichnet in der Praxis eine skalierbare
Software-Plattform für SDVs aus?
In der Praxis muss eine skalierbare Software-Plattform für
SDVs Konsolidierung ermöglichen, ohne die Sicherheit zu beeinträchtigen. Das
ist der eigentliche Maßstab. OEMs können Software-Komplexität nicht weiter
dadurch beherrschen, dass sie einfach mehr ECUs, mehr Schnittstellen und mehr
Verkabelung hinzufügen. Eine skalierbare Plattform muss es ermöglichen,
unterschiedliche Funktionen kontrolliert, sicher und wartbar auf
zentralisierter Rechenleistung auszuführen.
Aus ETAS-Sicht braucht es dafür drei Dinge. Erstens: starke
Isolation. Wenn sicherheitskritische Funktionen wie Bremsen, Lenken oder ADAS
gemeinsam mit Infotainment und KI-getriebenen Diensten auf derselben Hardware
laufen, ist Trennung nicht verhandelbar. Zweitens: intelligente Middleware. Middleware ist das Rückgrat, das Anwendungen, Dienste und
Kommunikation über Domänen hinweg verbindet. Sie ermöglicht sichere
Interaktion, unterstützt das Sicherheitskonzept und schafft die Grundlage für
Wiederverwendung und Portierbarkeit. Drittens: deterministische
Konnektivität. In zonalen und zentralisierten Architekturen hängt
Skalierbarkeit von vorhersagbarem Kommunikationsverhalten ab, insbesondere
dort, wo sicherheitsrelevante Daten und Timing-Anforderungen eine Rolle
spielen.
Das eigentliche Ziel ist sichere Konsolidierung im
industriellen Maßstab. Wenn das gelingt, können OEMs Komplexität reduzieren,
Wiederverwendung verbessern, Updates in nicht sicherheitskritischen Domänen
beschleunigen und eine Plattform aufbauen, die über den gesamten
Fahrzeuglebenszyklus beherrschbar bleibt. Genau daran arbeiten wir bei ETAS: an
der produktionsreifen Software-Grundlage, die die SDV-Vision in eine
sicherheitszertifizierbare Realität überführt.
Warum ETAS S-CORE
in seine Vehicle Software Platform Suite bringt
Wo haben aktuelle Software-Ansätze noch Schwierigkeiten,
Wiederverwendung und langfristige Wartbarkeit zu liefern?
Sie haben immer dort Schwierigkeiten, wo Software nicht als
langfristiges industrielles Asset behandelt wird. Die erste Hürde ist die
Hardware-Abhängigkeit. Noch immer ist zu viel Software zu eng an bestimmte
Silizium- oder Plattformentscheidungen gebunden. Sobald sich die Hardware
ändert, bricht Wiederverwendung weg und Teams sind gezwungen, weit mehr zu
portieren oder neu aufzubauen, als eigentlich nötig wäre.
Die zweite Hürde ist Lifecycle-Disziplin. In der
Automobilindustrie muss Software deutlich mehr als ein Jahrzehnt wartbar
bleiben. Das erfordert reproduzierbare Toolchains, robustes Versionsmanagement
und Update-Fähigkeit, lange nachdem sich die ursprüngliche Entwicklungsumgebung
verändert hat.
Das dritte Problem ist begrenzte Transparenz. Wenn es über
Schnittstellen und Abhängigkeiten hinweg nicht genügend Transparenz gibt,
verlangsamt sich die Integration, die Flexibilität sinkt und OEMs geraten
selbst bei kleineren Änderungen in Abhängigkeit von externen Roadmaps.
Und schließlich häufen viele Programme noch immer technische
Schulden an, weil sie auf den Marktstartzeitpunkt statt auf Modularität und
langfristige Weiterentwicklung optimiert sind. Das reduziert die
Wiederverwendung über Fahrzeuglinien hinweg und macht Systeme über die Zeit
schwerer und teurer in der Wartung.
Der Kernpunkt lautet also: Die Branche hat große
Fortschritte dabei gemacht, mehr Software ins Fahrzeug zu bringen, aber noch
nicht genug Fortschritte bei der Industrialisierung von Software. Erst mit
offenen, standardisierten Grundlagen und einer stärkeren Entkopplung von
Hardware und Software kann Software wirklich wiederverwendbar, wartbar und
generationenübergreifend skalierbar werden.
Was war die größte unerwartete Herausforderung auf dem
Weg zu einer industriefähigen S-CORE-Plattform?
Die größte Herausforderung – und vielleicht jene, die viele
unterschätzt haben – bestand nicht darin, schnell genug eine offene Grundlage
aufzubauen. Sie bestand darin, diese offene Grundlage in etwas zu verwandeln,
das die Automobilindustrie tatsächlich in Serienprogrammen im großen Maßstab
einsetzen kann. Offene Zusammenarbeit schafft Geschwindigkeit. Im
Automotive-Bereich reicht Geschwindigkeit allein aber nicht aus.
OEMs brauchen
Nachverfolgbarkeit, stabile Versionierung, Integrationsqualität, Safety- und
Cybersecurity-Tauglichkeit sowie langfristige Wartbarkeit. Genau das macht den
Unterschied zwischen Community-Code und einer industriellen Plattform. Genau dort schafft ETAS Mehrwert. Wir sehen S-CORE als eine gemeinsame offene Grundlage für die Industrie.
Kunden brauchen jedoch mehr als nur Zugriff auf Open-Source-Komponenten. Sie
brauchen eine produktionsreife Distribution, die konsistent paketiert,
nachvollziehbar versioniert, in industrielle Toolchains integriert und mit
modernen Entwicklungs- und Validierungsprozessen abgestimmt ist.
Deshalb bringen wir S-CORE in die ETAS Vehicle Software
Platform Suite ein. Unsere Rolle besteht nicht nur darin, zum offenen Ökosystem
beizutragen, sondern es zu industrialisieren – und Kunden dabei zu helfen, eine
offene Middleware-Grundlage in etwas zu verwandeln, das sich über den gesamten
Fahrzeuglebenszyklus hinweg einsetzen, warten und skalieren lässt. In einem Satz lautet die größte Herausforderung: eine
vielversprechende offene Initiative in eine vertrauenswürdige, industriefähige
Plattform für die automobile Serienproduktion zu transformieren.
