Über die Hintergründe und Motivationen des Software-Defined-Vehicle (SDV)

Neben der Elektromobilität, dem automatisierten/autonomen Fahren und der Fahrzeugvernetzung ist das sogenannte "Software-Defined-Vehicle" (SDV) eines der Hauptaktionsfelder in der Transformation der Mobilitätsindustrie. Unter anderem wird in den sozialen Medien gerade (zum Zeitpunkt des Schreibens im Herbst 2025) intensiv darüber diskutiert, insbesondere im Kontext der Wettbewerbsfähigkeit der europäischen Automobilindustrie (vergleiche etwa den Autopreneur oder die deutsche Wirtschaftspresse).

Wir wollen mit dem vorliegenden Beitrag hier die Hintergründe und Motivationen aus unserer Sicht und unseren Erfahrung zusammenfassen. Denn Software ist kein Selbstzweck, sondern vielmehr ein Mittel zur Umsetzung moderner Fahrzeugfunktionen und Effektivitätssteigerungen in der Fahrzeugentwicklung. Hinter dem Software-Defined-Vehicle stecken mehrere Prinzipien, welche die Beherrschung der Komplexität aktueller und zukünftiger Fahrzeuge inklusive dem kooperativen, vernetzte, automatisierten Fahren massiv begünstigen, wenn nicht sogar erst ermöglichen.

Die Hauptmotivation hinter dem SDV ist die erhöhte Funktionalität der Fahrzeuge. Während diese beim Infotainment offensichtlich erscheint, gilt dies vor allem aber auch bei den primären Fahrfunktionen des Antriebstrangs, des Fahrwerks und bei den Sicherheitsfunktionen. Deren zeitgemäße Funktionalität wäre ohne Software-basierte, digitale Regelungssysteme nicht mehr realisierbar.

Wenn hier moderne Verfahren der Regelungstechnik und Künstlichen Intelligenz eingesetzt werden, können Funktionalitäten bis knapp an den Rand der physikalisch/mechanischen Machbarkeit umgesetzt werden.

Themen wie das automatisierte/autonome und das vernetzte Fahren sind ohne Fokus auf die Software überhaupt nicht denkbar und können in der Regel nur mehr mit entsprechenden Algorithmen und digitaler Datenverarbeitung abgebildet werden.

Bei Software lassen sich Verbesserungen und Adaptionen sehr viel einfacher und schneller implementieren und umsetzen, wie wenn Hardware-Komponenten betroffen sind. Damit sind SDV besser geeignet, um komplexe Problemstellungen durch schrittweise, iterative Verbesserungen inkrementell zu lösen. Insbesondere gilt dies natürlich für das autonome/automatisierte und vernetzte Fahren sowie allgemein in der Verkehrsautomatisierung.

Damit kann man etwa mit einem ersten Funktionsumfang starten, welcher noch geringe aber doch vorhandenen Mehrwert liefert und diesen dann schrittweise ausbauen. Dabei wird der Operational Design Domain der Funktion stetig erweitert bzw. die Funktion aus Daten im realen Betrieb trainiert und stetig verbessert. Das Implementierungsrisiko komplexer Funktionen bleibt dabei überschaubar und unter Kontrolle bzw. können nicht ausreichende Funktionalitäten schneller nachgebessert werden.

Die Realisierung der beschriebenen Funktionalität und Adaptivität erfolgt bei komplexen Problemen oft durch den Einsatz von Verfahren der Künstlichen Intelligenz, wie etwa Künstlichen Neuronalen Netzen. Einerseits ermöglichen diese herausragende Funktionalität gemäß Was ist das Besondere an Künstlichen Neuronalen Netzen. Andererseits ist Adaptivität und Lernfähigkeit eine Grundeigenschaft derartiger Verfahren.

Künstliche Neuronale Netze und andere Machine-Learning-Verfahren beinhalten aber auch spezielle Prozeduren wie eine laufende Validierung als integralen Bestandteil des Trainings- und Adaptionsprozess. Damit ergeben sich im Gegensatz zu traditionellen Vorgehensweisen auch andere, zyklische Prozessmodelle für Konzeption, Entwicklung, Implementierung, Validierung und Freigabe.

Neben den funktionalen Aspekten sind bei SDV demnach vor allem auch die dahinterliegenden Prozess-Modelle und Vorgehensweisen von Bedeutung.

Im Software-Engineering gibt es eine Reihe von etablierten und bewährten Prozess-Modellen für die Entwicklung und laufende, kontinuierliche Verbesserung. Ganz egal ob V-Modell, Wasserfall-Modell oder moderne agile Prozess-Modelle, all diesen ist gleich, dass die Entwicklung Top-Down aus den Anforderungen heraus getrieben wird.

Derartige Top-Down-Vorgehensmodelle sind weitaus effektiver als das sonst weit verbreitete Bottom-Up-Vorgehens (vgl. dazu Top-Down vs. Bottom-Up). Dies gilt insbesondere bei komplexen Systemen wir dem automatisierten oder vernetzten Fahren.

Wesentlich dabei ist aber nicht nur das anforderungsgetriebene Vorgehen, sondern auch, dass eine Produktentwicklung nicht Projekt-orientiert für jede neue Produktversion erfolgt, so wie es bei der Entwicklung der verschiedenen Fahrzeugmodelle in der Automobilindustrie traditionell üblich war. Vielmehr soll die System-(Weiter)-Entwicklung kontinuierlich und Prozess-orientiert erfolgen. D.h. stetige Verbesserungen und Funktionserweiterungen und Verbesserungen werden laufend in die Entwicklung eingebracht und es wird stetig an Funktionserweiterungen weitergearbeitet. Diese werden dann laufend implementiert.

Die strikte Formalisierung der Prozesse hat den weiteren Vorteil, dass damit eine weitgehende Automatisierung einfacher umsetzbar sind und die Organisation effizienter arbeiten kann.

Die Prozesse des Software-Engineering enthalten noch einen weiteren wichtigen Aspekt, welcher im kontinuierlichen Testen und der Aufrechterhaltung einer ständigen Implementierbarkeit liegt.

Dies bedeutet, dass die vollständige System-Funktionalität durch umfassende Tests abgesichert wird, welche regelmäßig (idR mindestens täglich) über das gesamte System ausgeführt wird. Wenn so auch nur kleine Änderungen eingebracht werden, sieht man sofort, ob und welche Auswirkungen diese auf das Gesamt-System haben. Dadurch kann man an lokalen Verbesserungen arbeiten, ohne Angst von gefährlichen Seiteneffekten haben zu müssen. Dies ermöglicht eine stetige Verbesserung in komplexen Systemen und Funktionen durch sofortige Transparenz der Auswirkungen, welche auch über den eigenen Arbeitsbereich hinausgehen.

Durch diese ständige und umfassende Test-Absicherung in Kombination mit passenden automatisierten Implementierungsprozessen, ist man so in der Lage ständig neue Stände und stetige Verbesserungen freizugeben und zu implementieren.

Derartige Test beziehen sich natürlich nicht nur auf den spezifizierten Software-Teil, sondern normalerweise auf das gesamt System und auch auf die rein funktionale Ebene. Diese Tests erfolgen dann beispielsweise in Form eines Szenario-Managements, wo die gewünschte System-Funktionalität für alle relevanten Szenario beispielbasiert u.a. über Simulationen der gewünschten Funktion festgelegt wird (vergkeich dazu etwa Scenario-Management-as-a-Service).

Um die entsprechenden Synergien und Funktionalitäten umsetzen zu können, welche sich aus dem SDV-Ansatz ergeben, benötigt es natürlich passende Architekturen, welche die Vereinheitlichung von Teilfunktionen für eine passende Modularisierung ermöglichen. Eine Architektur-zentrierte Sicht ist also einer der Schlüssel zum wirtschaftlichen Erfolg und Grundvoraussetzung (bzw. umgekehrt potenzieller Verhinderer) für die Skalierbarkeit über möglichste viele Einheiten.

Die Architektur sollte sich dabei aber primär an der angestrebten Funktionalität und logischen Inhalten ausrichten und nicht wie traditionell an Hardware-Komponenten und Organisationseinheiten.

Früher war es meist üblich, dass die System-Architektur über die Aktoren und Sensoren bestimmt waren. Software war dabei ein Anhängsel der Sensoren. Dies spiegelte sich dann auch in den Organisationsstrukturen wieder, welche sich nach den Aktoren und mechanischen Komponenten ausrichtete.