Skalierbarkeit wird zum Schlüsselfaktor
Was bedeutet das SDV für Zulieferer und OEMs?
Software Defined Vehicles verschieben die Anforderungen in der Automobilindustrie. Entscheidend ist nicht allein, welche Funktionen entstehen, sondern ob Software über Projekte, Plattformen und Fahrzeuglinien hinweg beherrschbar skaliert.
Das Software Defined Vehicle ist längst kein Zukunftsbild mehr. In vielen Unternehmen hat die operative Realität begonnen: Softwareanteile steigen, Update-Fähigkeit wird zur Voraussetzung, Entwicklungszyklen verkürzen sich, und OEMs treiben die Zentralisierung von E/E-Architekturen, Fahrzeugplattformen und Schnittstellen voran. Für Zulieferer ist das eine tiefgreifende Veränderung. Denn mit dem Fahrzeug wandelt sich neben dem Produkt auch die Logik, nach der entwickelt, integriert, getestet und geliefert wird.
Die Debatte richtet sich oft auf die OEM-Perspektive: auf neue digitale Erlösquellen, Over-the-Air-Updates oder das Rennen um die nächste Fahrzeuggeneration. Für Zulieferer stellt sich die Lage anders dar. Sie müssen neue Software- und Integrationsanforderungen erfüllen, parallel mehrere Herstellerlogiken bedienen und gleichzeitig bestehende Programme stabil weiter betreiben. Darin liegt die eigentliche Herausforderung: Das SDV zwingt nicht nur zu neuen Funktionen, sondern zu einer Weiterentwicklung des Engineering-Betriebs. Entscheidend wird künftig sein, ob Software über Programme, Plattformen und Herstellergrenzen hinweg beherrschbar skaliert werden kann. Genau daran messen OEMs zunehmend die Entwicklungsfähigkeit ihrer Lieferkette.
Voraussichtlich werden OEMs im Jahr 2035 mehr als die Hälfte ihres Umsatzes mit softwarebasierten Funktionen und Mobilitätsdienstleistungen erwirtschaften. Das zeigt: Software wird in Fahrzeugarchitekturen, Entwicklungsprozessen und der späteren Betriebslogik zur bestimmenden Größe. Für Zulieferer reicht es damit immer seltener aus, einzelne Softwarebausteine in bestehende Fahrzeugarchitekturen zu integrieren. Gefragt sind Software- und Systembeiträge, die sich in zentrale Plattformarchitekturen, standardisierte Schnittstellen und kontinuierliche Release-Prozesse einfügen lassen.
Vom Bauteil zur Plattformlogik
Über Jahrzehnte war die Arbeitsteilung in der Automobilindustrie klar definiert: Komponenten, ECUs und Funktionen wurden entlang definierter Lastenhefte entwickelt und zu festen Meilensteinen integriert. Diese Logik verschwindet nicht, sie verliert aber an Eindeutigkeit. Je stärker Fahrzeuge zu softwarebasierten Plattformen werden, desto früher greifen Architekturentscheidungen, API-Design, Middleware-Fragen und Integrationsprozesse ineinander.
KPMG verweist auf fragmentierte Architekturen, langsame Update-Prozesse und ungeeignete Betriebsmodelle als zentrale Hürden auf dem Weg zum SDV. Für Zulieferer ist das hochrelevant: Wenn sich Wertschöpfung stärker auf Softwareplattformen, Datenflüsse, OTA-Pipelines und zentrale Compute-Strukturen verlagert, verändert sich auch ihre Rolle. Sie liefern dann nicht mehr nur eine klar umrissene Funktion, sondern Beiträge für eine durchgängige Software- und Systemlogik, die von Wiederverwendbarkeit, Interoperabilität, synchronen Integrationsständen und Versionierbarkeit lebt.
Damit steigt der Druck auf die Entwicklungsorganisationen. Was früher als lokales Engineering-Problem innerhalb eines Steuergeräts lösbar war, wird heute schnell zu einer Frage der Gesamtarchitektur. Änderungen an einer Funktion berühren Build-Ketten, Freigabestände, Cybersecurity-Anforderungen, Safety-Nachweise nach ISO 26262 und mehrere Entwicklungsdomänen zugleich. Der Aufwand verschiebt sich damit in Richtung Systemintegration, Konfigurationsmanagement und Lifecycle-Beherrschung.
Architekturentscheidungen werden früher und langfristiger wirksam. Fehler in Toolchain, Integration oder Variantenmanagement lassen sich später nicht mehr lokal korrigieren, sondern wirken sich über Programme, Plattformen und Release-Zyklen hinweg aus. Der Aufwand verschiebt sich deshalb zunehmend in Richtung Systemintegration, Konfigurationsmanagement und Lifecycle-Beherrschung.
Warum die Toolchain zur strategischen Infrastruktur wird
In vielen Zuliefererorganisationen zeigt sich dieser Wandel zuerst in der Entwicklungsumgebung. Gewachsene Tool-Landschaften, manuelle Übergaben zwischen Teams, inkonsistente Datenstände und OEM-spezifische Sonderwege bremsen die Geschwindigkeit dort, wo das SDV mehr Tempo verlangt. Das Problem ist selten das einzelne Tool. Das Problem ist, dass Requirements, Engineering, Softwareentwicklung, Modellierung, Simulation, Test, Freigabe sowie Safety- und Security-Nachweise oft nicht durchgängig miteinander verbunden sind.
Damit wird die Toolchain selbst zur strategischen Infrastruktur. Sie entscheidet zunehmend darüber, ob Software wiederverwendbar, integrierbar und über mehrere Fahrzeugprogramme hinweg skalierbar betrieben werden kann. Aus einer operativen Entwicklungsumgebung wird damit ein zentraler Wettbewerbsfaktor.
Wer Software schneller und verlässlicher entwickeln will, braucht eine belastbare Integrationslogik über den gesamten Engineering-Prozess hinweg. Dazu gehören Traceability, Variantenmanagement, automatisierte Tests und Continuous Integration. Der eigentliche Hebel liegt dabei nicht im einzelnen Werkzeug, sondern in einer Entwicklungsarchitektur, die Zusammenarbeit, Transparenz und Wiederverwendung unterstützt.
Das World Economic Forum beschreibt diesen Wandel als Übergang zu einer integrierten Software Factory mit kontinuierlichen Entwicklungs-, Test- und Deployment-Prozessen. Für den Automotive-Alltag heißt das nicht, klassische IT-Modelle einfach zu kopieren. Embedded-Entwicklung bleibt sicherheitskritisch, hardwareabhängig und regulatorisch gerahmt. Deshalb müssen Toolchains im SDV-Kontext robuster, durchgängiger und über Systemgrenzen hinweg anschlussfähig werden.
DevOps im Automotive-Umfeld – aber industrietauglich
Der Ruf nach DevOps ist folgerichtig, greift aber zu kurz, wenn er abstrakt bleibt. Im Automotive-Umfeld geht es nicht um die einfache Übertragung von Praktiken aus der Enterprise-IT. Ein sicherheitskritisches, homologationspflichtiges Produkt mit langen Lebenszyklen folgt anderen Zwängen als eine Web-Anwendung. Trotzdem führt am Grundprinzip kaum ein Weg vorbei: Entwicklung, Integration, Test und Betrieb müssen enger zusammenrücken.
Dazu gehören Continuous Integration, automatisierte Quality Gates, frühere Validierung und klar definierte Release-Prozesse. Besonders relevant wird dabei die Virtualisierung. Das WEF verweist ausdrücklich auf virtualisierte Testumgebungen und hardwareunabhängigere Entwicklungsmodelle als zentrale Bausteine für SDV-Reife. Für Zulieferer ist das ein Schlüssel. Je früher Funktionen gegen stabile Schnittstellen, simulierte Umgebungen sowie SIL- und HIL-Setups entwickelt werden können, desto geringer wird die Abhängigkeit von späten physischen Integrationsschritten.
Transformation im laufenden Betrieb
Die besondere Schwierigkeit liegt weniger im Zielbild selbst als vielmehr im Weg dorthin. Kaum ein Unternehmen kann das laufende Geschäft pausieren, um seinen Entwicklungsbetrieb neu aufsetzen. Bestehende Kundenprojekte, gewachsene Fahrzeugprogramme und etablierte Tool- und Prozesslandschaften bleiben Realität. Die Transformation muss also unter Last stattfinden.
Genau darin liegt für viele Zulieferer die eigentliche SDV-Herausforderung. Nicht die Entwicklung einzelner Funktionen entscheidet über den Erfolg, sondern die Fähigkeit, bestehende Entwicklungslandschaften schrittweise in ein skalierbares Software- und Integrationsmodell zu überführen.
Ein zusätzliches Tool, ein separates Softwareteam oder eine isolierte Pilotlinie für Virtual Validation als punktuelle Ergänzung können kurzfristig helfen, erhöhen langfristig aber oft die Komplexität. Entscheidend ist deshalb, an den Stellen anzusetzen, die spätere Skalierung erst ermöglichen: bei standardisierbaren Schnittstellen, durchgängiger Traceability, testbaren Integrationspfaden und einer Governance, die Software, Functional Safety und Cybersecurity enger zusammenführt.
Das bedeutet konkret: Änderungsmanagement, Freigabeprozesse und Sicherheitsnachweise müssen so verzahnt sein, dass sie nicht als parallele Bürokratien laufen, sondern als integrierter Bestandteil des Entwicklungsbetriebs.
Mit dem SDV verändern sich damit auch die Anforderungen an Zusammenarbeit in der Lieferkette. Technische Exzellenz bleibt unverzichtbar, reicht aber allein nicht mehr aus. Ebenso wichtig wird die Fähigkeit, komplexe, kontinuierlich weiterentwickelte Entwicklungsökosysteme stabil zu steuern. Solche Programme verlangen Erfahrung an der Schnittstelle von Engineering, Plattformarchitektur, Delivery-Modell und Transformation im Bestand – also dort, wo technische Zielbilder mit gewachsenen Liefer- und Betriebsrealitäten zusammengeführt werden müssen.
Wer das kann, wird zum verlässlichen Entwicklungspartner – nicht nur als Lieferant einzelner Funktionen, sondern als Integrator, der Plattformlogik, Release-Fähigkeit und Betriebsstabilität zusammenhält. Das ist die neue Qualifikation, die OEMs in der Lieferkette suchen.
Der Entwicklungsbetrieb wird zum Wettbewerbsfaktor
Das Software Defined Vehicle verändert nicht nur die technische Architektur des Fahrzeugs. Es verändert die Art, wie Zulieferer entwickeln, integrieren, testen und ausliefern. Künftig reicht es nicht mehr aus, einzelne Funktionen bereitzustellen. Entscheidend wird, ob Software über Programme, Plattformen und Herstellergrenzen hinweg beherrschbar skaliert werden kann.
Wer dafür die notwendigen Voraussetzungen schafft – von integrierten Toolchains über durchgängige Traceability bis hin zu belastbaren Integrations- und Release-Prozessen – wird zum strategischen Entwicklungspartner der OEMs. Wer das nicht leistet, liefert weiterhin Funktionen, kann aber immer schwerer zur Plattformlogik beitragen, auf der das Software Defined Vehicle der Zukunft basiert.
Der Autor
Mario Jesse, ATOS Deutschland.
Mario Jesse
ist Head of Sales Discrete Manufacturing & Automotive bei Atos Deutschland. Er begleitet Unternehmen in den Bereichen Manufacturing und Automotive bei Fragen rund um Plattformarchitekturen, Datenhoheit, offene Standards und die industrielle Umsetzung neuer Software- und KI-Modelle. Zuvor verantwortete er verschiedene Führungsrollen in Service Operations, Delivery und Sales, wodurch er Transformationsvorhaben sowohl aus betrieblicher als auch aus strategischer Perspektive einordnet.
