Ist die Autoindustrie SDV-ready?

Bei softwaredefinierten Fahrzeugen verlagert sich die Differenzierung von mechanischer Leistung und Funktionsumfang zu Produktionsbeginn hin zu den Softwarefähigkeiten über die gesamte Lebensdauer des Fahrzeugs, die durch häufige Updates oder die Aktivierung von Funktionen bereitgestellt werden.

Die Verlagerung hat direkte Auswirkungen auf die Hardware: Heutige verteilte ECU-Architekturen lassen sich zwar weiterhin für einfache Fahrzeuge verwenden. Sie wurden jedoch nicht für spätere Softwareänderungen konzipiert, die durchgeführt werden, nachdem die Plattform festgelegt und/oder das Fahrzeug auf dem Markt ist. Nun migrieren viele OEMs die Software aus bestehenden Steuergeräten auf einen größeren Controller mit hoher Rechenleistung und nutzen zonale E/E-Architekturen, um über Busse mit hoher Bandbreite (zunehmend Ethernet) mit dem Entscheidungscomputer sowie Edge-Sensoren und -Aktuatoren zu kommunizieren.

Dieser Artikel gibt einen Überblick über die wichtigsten Hardware-Bausteine, die zur Unterstützung eines SDV erforderlich sind, und erläutert, wie zonale und zentralisierte Architekturen effiziente OTA-Updates und digitale Erlebnisse ermöglichen. Außerdem wird untersucht, wie Automobilhersteller verschiedene Geschäftsmodelle anwenden, um die Transformation zu vollziehen. Auch kommt zur Sprache, wie der Antriebsmix und die Breite des Produktportfolios Hardware-Roadmaps ausbremsen können.

Was ist ein softwaredefiniertes Fahrzeug?

Obwohl sich der Begriff SDV mittlerweile etabliert hat, gibt es unterschiedliche Auffassungen hinsichtlich seiner tatsächlichen Bedeutung. S&P Global bietet Definitionen an, die entwickelt wurden, um die SDV-Readiness verschiedener OEMs mit unterschiedlichen Fahrzeugen sowohl charakterisieren als auch quantifizieren zu können. Diese Definitionen berücksichtigen die Softwarekompetenz eines Unternehmens, den eingesetzten Hardwaretyp sowie den Grad der Over-the-Air-Aktualisierbarkeit. S&P Global erfasst all diese Aspekte und kombiniert Datensätze, um eine Fahrzeugbewertung und ein SDV-Readiness-Ranking zu erstellen (Tabelle).

Die Rangliste gewichtet bestimmte Kriterien, um zu ermitteln, wie Fahrzeugarchitektur, Softwareintegration, Cybersicherheit und OTA-Fähigkeit in Serienprogrammen umgesetzt werden. Bewertet werden also der Typ der E/E-Architektur, das Backbone-Netzwerk, die Konfiguration der Zonen-Controller, der Reifegrad des Auto-Betriebssystems (OS), die Serviceorientierung auf Domänenebene, die Tiefe der Cybersicherheit über ECU- und Backend-Ebenen hinweg sowie die fahrzeugübergreifenden OTA-Befugnisse.

Betrachtet man das Ranking, fällt vor allem die Dominanz von Start-up-EV-Herstellern aus China wie Nio, LI und Xpeng sowie aus Nordamerika wie Tesla auf, die alle SDV-Level von 4 oder sogar 5 erreichen.

Interessant ist, dass unter den etablierten Herstellern Volvo mit Stufe 5 den zweiten Platz hinter Nio einnimmt. Beide Unternehmen erzielen im SDV-Index sehr hohe Werte, die auf einer Kombination aus effizientem Software- und Hardware-Design sowie fortschrittlicher OTA-Fähigkeit basieren, um beispielsweise Updates auf Basis von Flotten-Lernprozessen bereitzustellen und so regelmäßig neue Funktionen für neue und bereits auf der Straße befindliche Fahrzeuge zu entwickeln und zu verteilen. Sowohl Nio als auch Volvo verfügen über fortschrittliche Hardware und investieren angemessen in kontinuierliche Software-Innovation. Volvos erstes Fahrzeug mit einem SDV-Ranking von 5 ist der seit kurzem verfügbare EX60, der mit einem Zentralcomputer sowie Zonen, zum Beispiel zur Verwaltung einer Mischung aus nicht-sicherheitskritischer und sicherheitskritischer domänenübergreifender Funktionssteuerung, auf seiner SDV-Plattform der Generation 2 eingeführt wird.

Unter den anderen etablierten Herstellern steigt BMW auf SDV-Stufe 4 ein, basierend auf seinen neuen Fahrzeugen der NK-Plattform, die ab Oktober 2025 auf den Markt kommen und im Vergleich zu früheren Plattformen über Hardware- und Software-Upgrades verfügen.

Zentrale SDV-Bausteine in der Hardware

Die SDV-fähige E/E-Architektur konsolidiert die Rechenleistung und die Software-Steuerungsalgorithmen, die zuvor in kleineren, verteilten Steuergeräten untergebracht waren, in weniger, dafür größeren Steuergeräten. Die Hauptkomponenten sind:

• Domain-Controller: Master-Controller koordinieren mehrere Steuergeräte in einer gemeinsamen Domäne wie Fahrwerk oder Karosserie. Diese Controller erweitern die einfache, verteilte Steuergeräte-Architektur auf eine Domänenarchitektur, die der gestiegenen Komplexität der Kommunikation und den Anforderungen an die Datenverarbeitung Rechnung trägt, beispielsweise durch ADAS-Sensoren oder moderne Cockpits. Domain-Controller verwenden Mikroprozessoren oder MCUs, abhängig von der Art der zu verarbeitenden Daten.

• Zonensteuergeräte: Steuergeräte, die sich physisch in bestimmten Fahrzeugbereichen wie zum Beispiel den Türen befinden, um lokale CAN- und LIN-E/A-Signale aus Edge-Netzwerken (Sensoren, Aktoren usw.) zu bündeln. Zonen-ECUs leiten die aggregierten Daten über ein einziges Kabel an die zentralen Entscheidungs-ECUs weiter, seien es Domänensteuerungen oder bereits ein Zentralcomputer. Zonen verfügen über eine oder mehrere MCUs für die lokale Verwaltung und können zudem die zentralen Domänen-Controller entlasten, um Verarbeitungsanforderungen auszulagern, sowie die lokale Stromverwaltung und Stromverteilung übernehmen – ein wesentliches Merkmal der Kabelbaumoptimierung. Eine E/E-Architektur mit Zonensteuergeräten wird als Zonenarchitektur bezeichnet und stellt eine erhebliche Veränderung gegenüber verteilten und domänenbasierten Designs dar.

• Zentralcomputer: Eine umfassend integrierte ECU, die mindestens zwei Domänen kombiniert, wird als Zentralcomputer bezeichnet. Ein Zentralcomputer setzt in der Regel einen oder mehrere Hochleistungs-Mikroprozessoren (System-on-Chip oder SoC) ein, je nach Domänenabdeckung, und hostet typischerweise (wenn auch nicht immer) Infotainment- und ADAS-Aufgaben, wodurch eine stärker zentralisierte Entscheidungsfindung und Koordination möglich ist.

In der Praxis werden effiziente SDV-Architekturen auf Zonenarchitekturen basieren, auch wenn einige japanische OEMs möglicherweise auf Zonendesigns verzichten wollen. Das Bild veranschaulicht den Einsatz der Zonenarchitektur als wesentliche Hardwarekomponente in effizienten SDV-Designs.

Wie unterstützt die Zonenarchitektur die Entwicklung eines SDV?

Die Zonenarchitektur wird häufig als Strategie zur Reduzierung des Verkabelungsaufwands und der Anzahl der Steuergeräte dargestellt. Ebenso spielt sie ihre Vorteile jedoch bei der Datenverteilung und Softwarebereitstellung aus. Je tiefer OTA-Fähigkeiten in das Fahrzeug vordringen, desto mehr Endpunkte erfordern sichere Update-Fähigkeiten, konsistente Diagnoseverfahren und zuverlässige Rollback-Möglichkeiten. Ein zonenbasierter Ansatz vereinfacht die Bereitstellung, indem er die Komplexität auf eine geringere Anzahl leistungsfähiger Knoten verlagert, die näher an den Endpunkten liegen – wodurch der Aufwand für die Koordinierung von Updates reduziert wird.

Zu den wesentlichen Vorteilen zählt auch die effiziente Datenverteilung über Hochgeschwindigkeits-Backbones, die zunehmend auf Ethernet basieren und aggregierte Sensordaten sowie Steuerungsnachrichten zwischen Zonen und der zentralen Recheneinheit mit weniger Protokollkonvertierungen übertragen können. Durch die Aggregation von E/A-Daten und die Verlagerung der Rechenleistung von Edge-Modulen auf Zonen-Controller oder zentrale Rechner können OEMs zudem die Anzahl der vorhandenen Steuergeräte, Steckverbinder und Kabelbaumverzweigungen reduzieren.

Ein Nachteil ist, dass Domänen-/HPC-Rechenleistung und Ethernet-Backbones kostspielig sein können. Kosten, Redundanzanforderungen, thermisches Design und Fertigungskomplexität steigen – was insbesondere für OEMs mit großen, preissensiblen Segmenten eine Herausforderung darstellt. So erzielen zwar einige OEMs nachweisbare Fortschritte in Richtung SDV-Reife, die ehrgeizigen E/E-Roadmaps anderer Automobilhersteller haben jedoch unter den erheblichen Herausforderungen gelitten – nicht zuletzt aufgrund von Faktoren wie Unternehmensstruktur, Altportfolio und Gesamtkultur.

Selbst entwickeln oder kaufen?

OEMs kommen zunehmend zu dem Schluss, dass SDV-Hardware – und der darauf laufende Software-Stack – strategisch zu wichtig sind, um vollständig ausgelagert zu werden. Der Markt bietet jedoch mehrere tragfähige Modelle, die jeweils mit unterschiedlichen Risiken und Zeitplänen verbunden sind.

Ein Beispiel für ein Unternehmen, das alles intern entwickelt, ist Nio – ähnlich wie Tesla oder Rivian. Die Domänenarchitektur von Nio aus dem Jahr 2022 wurde als SDV-Level 2 eingestuft. Innerhalb von nur zwei weiteren Jahren hat sich die Architektur zu einem Zentralcomputer mit zwei leistungsstarken Zonen-Controllern weiterentwickelt, die in der Lage sind, Workloads mit unterschiedlicher Kritikalität auszuführen, die Sicherheits- und Karosseriefunktionen umfassen. Im Jahr 2025 listete S&P Global Nio als erstes Fahrzeug auf, das SDV-Level 5 erreichte, noch vor Tesla und anderen großen chinesischen BEV-Herstellern.

Wie Tesla entwickelt auch Nio seine eigenen Zonen- und Zentralcomputer-ECUs sowie einen ADAS-Prozessor. Hardware-Upgrades schreiten viel schneller voran als bei den meisten etablierten OEMs. Ein möglicher Nachteil ist, dass die eigene Entwicklung aller Komponenten zu einer hohen F&E-Belastung führt, die bei geringen Fahrzeugzahlen – wie sie bei Nio der Fall sind – die Gewinnmargen schmälert. Aus diesem Grund prüft Nio verschiedene Geschäftsmodelle wie Technologie-Lizenzvereinbarungen, ähnlich wie Leapmotor und Xpeng es mit Dienstleistungsverträgen mit Stellantis bzw. Volkswagen getan haben.

Auch Leapmotor beeindruckt mit seiner schnellen Weiterentwicklung der E/E-Architektur. Durch den Einsatz von Zonen und einen Zentralcomputer, der vier Domänen steuert, konnte das Unternehmen einen Kilometer an Kabeln sowie 20 Steuergeräte einsparen.

Die Bemühungen von General Motors und Ford, das SDV eigenständig weiterzuentwickeln, sind natürlich lobenswert, machen jedoch deutlich, dass bestimmte Aspekte des SDV-Designs in Bezug auf Software und Hardware eine hohe finanzielle Belastung hinsichtlich der Entwicklungskosten und der Abstimmung des Produktportfolios mit sich bringen. Auch OEMs wie Volkswagen, Stellantis, Renault und Toyota müssen erschwingliche Fahrzeuge für verschiedene Fahrzeugsegmente, Märkte und Antriebsarten anbieten, und es ist nahezu unmöglich, eine neue E/E-Architektur zu entwickeln, die auf alle Segmente skalierbar ist.

Die Vielfalt an Architekturen wird also zwangsläufig bestehen bleiben und die Skalierungsvorteile verwässert werden. Die zusätzlichen Kosten werden jedoch als akzeptabel angesehen, sofern man mit dem SDV eine Generation intelligenter Fahrzeuge hervorbringen kann, die einerseits die Kunden anspricht und andererseits den Kreislauf sich nur langsam entwickelnder, starrer Entwicklungsplattformen durchbrechen kann.

Fords Strategieanpassung für 2025 erfolgte, nachdem das Unternehmen zu viel Geld für zu geringe Fortschritte bei der Entwicklung einer SDV-Hardware-Software-Kombination ausgegeben hatte, die für die gesamte Fahrzeugpalette geeignet gewesen wäre. Der ursprüngliche Plan (Ford Networked Vehicle Version 4 oder FNV4) sah einen einheitlicheren SDV-Ansatz vor, wurde jedoch schließlich zurückgefahren, um ab 2027 nur noch einige wenige kleinere BEVs mit einem Tesla-ähnlichen Zonenansatz anzuvisieren. Der Rest der Flotte – einschließlich volumenstarker Fahrzeuge wie dem F-150 Lightning – wird weiterhin auf einer flexiblen Domänenarchitektur basieren.

General Motors seinerseits liegt mit seinem ersten Zonen-Design etwa ein Jahr im Verzug; dieses soll etwa 2028 oder 2029 im Cadillac Escalade zum Einsatz kommen. GM hat die ersten neuen E/E-Designs für Zentralcomputer intern entwickelt und zeigt damit, wie OEMs daran arbeiten, die Rolle der Tier-1-Zulieferer auf die reine Auftragsfertigung zu reduzieren, anstatt die gesamte Produktentwicklung zu kontrollieren.

Partnerschaften als Weg in die Zukunft

Volkswagen hat sich für Joint Ventures entschieden, um die Verzögerungen auszugleichen, die bei seiner Softwaretochter CARIAD bei der Entwicklung der Software für die SSP-Plattform für BEVs entstanden sind. Für Märkte außerhalb Chinas arbeitet Volkswagen mit Rivian zusammen. Das Unternehmen wird eine Basis-SDV-Software in Verbindung mit zonenspezifischer Hardware für Volkswagen, Audi und andere Fahrzeuge bereitstellen, die auf der SSP-Plattform basieren sollen.

Die VW-Gruppe umfasst vier Marken mit unterschiedlichen Antriebsarten und Marktsegmentierungen. Während die Rivian-Lösung für BEVs geeignet ist, bleibt die Frage nach SDV-Varianten für Hybridfahrzeuge, BEVs mit Range Extender und Fahrzeugen mit Verbrennungsmotoren offen – sie steht nicht im Fokus von Rivian.

Die erste zonale E/E-Architektur von Rivian soll noch in diesem Jahr im Rivian RT2 zum Einsatz kommen, während das erste darauf basierende Volkswagen-SDV – der ID.1. – 2027 folgen soll. Die SSP-Plattform von VW soll schließlich 2028 oder 2029 an den Start gehen, zwei bis drei Jahre später als ursprünglich geplant, und voraussichtlich im ID.Golf zum Einsatz kommen.

Für den chinesischen Markt agiert VW China eigenständig und lagert die SDV-Entwicklung an Xpeng aus, das seine eigene, auf Zonen und zentraler Rechenleistung basierende »China Electronic Architecture« sowie eine in China vorhandene Lieferkette für die wichtigsten Halbleiter nutzen wird. Dieses Konzept beschleunigt die Markteinführung von VW-Modellen, die auf die Erwartungen des chinesischen Marktes zugeschnitten sind, zum Beispiel Level 2+ inklusive Stadtnavigation, fortschrittlichem Infotainment und häufigen Updates.

BMW ist bei der SDV-Einführung auf Kurs geblieben, indem das Unternehmen umsichtig auf einer bereits weit fortgeschrittenen E/E-Grundlage aufbaute. Das verbesserte E/E-Design für die Plattform der »Neuen Klasse« umfasst vier Domänencontroller und zwei einfache Zonencontroller für Karosseriefunktionen sowie E-Sicherungen zur Gewichtsreduzierung des Kabelbaums: im Vergleich zu früheren Modellen wurden 600 m Verkabelung eingespart. Eine Erkenntnis ist, dass eine konservative, skalierbare Architektur gegenüber einer disruptiven E/E-Neugestaltung von Vorteil sein kann, sofern sie schneller und/oder in größerem Umfang in der gesamten Flotte eingesetzt werden kann.

Fazit

Das SDV erfordert neue Hardware, um eine flexible E/E-Architektur zu ermöglichen. Dies stellt neue Anforderungen an die OEMs: Sie müssen über ausreichende Rechenkapazitäten verfügen, um zukünftige Funktionen zu unterstützen, die Software kontinuierlich weiterzuentwickeln und einen beständigen Cybersicherheitsschutz vor Angriffen zu gewährleisten. Dies geht einher mit einer Netzwerktopologie, die das unabhängige Aktualisieren Dutzender verteilter Steuergeräte unabhängig voneinander vermeidet.

Das SDV-Rennen werden diejenigen gewinnen, die die Hardwarekonsolidierung mit der Softwareausführung in Einklang bringen. Doch aufgrund der Anforderungen an die Cybersicherheit ist dies ein Rennen, das niemals enden wird. Die OEMs treten daher in eine neue, spannende und vor allem disruptive Phase ihrer Entwicklungsgeschichte ein – weg vom mechanischen zum softwaregesteuerten System. Dabei muss sich jeder Akteur mit einer gewissen Altlast auseinandersetzen, die er unweigerlich mitbringt und die über den Erfolg seiner SDV-Readiness entscheidet.

Die Autoren

Richard Dixon
ist Senior Principal Analyst bei S&P Global Mobility.

Manuel Tagliavini
ist Principal Analyst bei S&P Global Mobility.

Matchmaker+ Anbieter zum Thema

zu Matchmaker+

Lesen Sie mehr zum Thema