Wird ein Fahrzeug mittlerweile durch Software definiert? Domain-Architektur und die SDV-Transformation

Elektrische Automobile-Technologien
Autor: Deniz Erkan
Erstellung: 14 Oktober 2026

Eine Architektur, die über hundert Steuereinheiten auf einige Zonalcontroller reduziert wird, erzeugt die Identität des Autos heute nicht mehr aus Stahl, sondern aus Code.

Diese Seite teilen

Ja: das Verhalten, die Eigenschaften und der Leistungscharakter des modernen Automobils werden heute in erster Linie durch Software definiert. Diese Transformation, die als softwaredefiniertes Fahrzeug (SDV) bezeichnet wird, verlagert die elektronische Architektur des Fahrzeugs von ECU-Stapeln zu Domänen- und Zonencontrollern, trennt Hardware und Software voneinander und gestaltet alles neu - vom Kabelbaumgewicht bis zu OTA-Updates.

Höhepunkte

Fahrzeuge von heute 100 und mehr Steuereinheiten enthalten können; neue Architekturen zielen darauf ab, diese Zahl um bis zu 20 % zu reduzieren.
Die Domänenarchitektur organisiert nach Funktion, die Zonenarchitektur nach physischem Standort.
In der Zonentopologie werden CAN XL (bis zu 20 Mbit/s) und Hochleistungs-Backbones wie Gigabit-Ethernet verwendet.
OTA-Updates sind eine grundlegende SDV-Fähigkeit, die durch die Hardware-Software-Entkopplung möglich wird.
Der Übergang erfolgt schrittweise: der erste Bereich ist die Karosserie-Domäne; ADAS, Antriebstrang und Fahrwerk können länger in der bestehenden Struktur bleiben.

Was genau ist ein softwaredefiniertes Fahrzeug?

Die Definition ist klar: Ein softwaredefiniertes Fahrzeug ist ein Fahrzeug, dessen Funktionalität und Verhalten in erster Linie durch Software und nicht durch Hardware bestimmt werden. Beim traditionellen Automobil wurde ein Merkmal durch ein speziell für diese Funktion gefertigtes Hardwareteil definiert; beim SDV kann dieselbe Hardware durch die darauf laufende Software unterschiedliche Funktionen annehmen. Selbst nach dem Verkauf des Fahrzeugs können neue Funktionen hinzugefügt, das Verhalten kalibriert und Fehler aus der Ferne behoben werden.

Die heutigen E/E-Architekturen bestehen aus 100 und mehr Steuereinheiten; neue Strukturen sparen bei der Anzahl der Steuereinheiten bis zu 20 % und bei Material und Hardware bis zu 10 %.
Bosch Mobility, Bewertung der E/E-Architektur

Die Zahlen dieses Satzes fassen das Ausmaß der Transformation zusammen. Das Problem ist nicht nur die Anzahl der Steuereinheiten: Jedes ECU bringt seine eigene Verkabelung, seinen eigenen Softwarestapel und seine eigene Validierungslast mit sich. Die SDV-Vision besteht darin, diese verstreute Struktur in ein System zu verwandeln, das die Software in einer einzigen konsistenten Schicht verwalten kann. Dafür muss die elektronische Architektur von Grund auf neu gedacht werden.

Von ECU zu Domänenarchitektur: Gruppierung nach Funktion

Die Zeit, in der jede kleine Funktion in einem Automobil über eine eigene elektronische Steuereinheit (ECU) verfügte, machte die Kabelbäume unmanagebar. Die Domänenarchitektur war die erste systematische Antwort darauf: Sie organisiert die Fahrzeugelektronik nach großen Funktionsbereichen wie ADAS, Infotainment, Antriebstrang, Karosserieelektronik, Fahrwerk und Sicherheit. Jede Domäne verfügt in der Regel über einen eigenen Prozessor, einen eigenen Softwarestapel, eine eigene Kommunikationsschnittstelle, eigene Sensoren und Aktoren und wird von einem Domänencontroller verwaltet.

Diese Struktur brachte gegenüber dem ECU-Chaos eine erhebliche Straffung mit sich. Doch je größer das SDV-Ziel wurde, desto deutlicher zeigten sich die Grenzen der Domänenarchitektur. Insbesondere die von autonomen Funktionen erzeugten Sensordaten brachten die Bandbreite der klassischen CAN-Netzwerke an ihre Grenzen. Außerdem hinterließ das Faktum, dass jede Domäne ihre eigenen Rechenressourcen mit sich führte, den Kabelbaum komplex und erschwerte die Skalierung der Software im gesamten Fahrzeug.

Zonale Architektur: Die Organisation wechselt von der Funktion zum Standort

Die zonale Architektur kehrt die Logik um: Die Elektronik wird nicht nach Funktion, sondern nach physischem Standort im Fahrzeug gruppiert. Das Fahrzeug wird in Zonen wie vorne links, vorne rechts, hinten links, hinten rechts und Kabine unterteilt; in jeder Zone sammelt ein zentraler Zonencontroller die Sensoren, Aktuatoren und die Stromverteilung dieser Zone und kommuniziert mit zentralen Hochleistungs-Rechenplattformen.

Merkmal	Domain-Architektur	Zonale Architektur
Organisationsprinzip	Nach Funktion (Antriebsstrang, ADAS, Karosserie...)	Nach physischem Standort (vorne links, hinten rechts...)
Rechenressourcen	Domänenspezifische Verarbeitung	Konsolidierte zentrale/verteilte Verarbeitung
Verkabelung	Komplexer, langer Kabelbaum	Reduzierte Verkabelung und Gewicht
Anzahl der ECUs	Sehr viele ECUs	Wenige Zonencontroller + zentraler Rechner
Software-Flexibilität	Schwer skalierbar für SDVs	Hohe Software-Flexibilität

Der Gewinn ist konkret und messbar: Das Gewicht des Kabelbaums sinkt, Punkt-zu-Punkt-Verbindungen nehmen ab, der Aufwand für Fahrzeugarchitektur und Systemvalidierung vereinfacht sich. Noch wichtiger ist, dass sich Sensor- und Aktuatorentwürfe vom zentralen Rechenknoten entkoppeln; dadurch trennen sich die Update-Zyklen für Hardware und Software, und ein Sensordesign kann über mehrere Fahrzeuggenerationen hinweg verwendet werden.

Was macht ein Zonencontroller? Aufgabenverteilung und Verhältnis zur Hardware

Zonal mimaride kablolar kısaldıkça araç hafifler, sigortalar yerini yarı iletken anahtarlara bırakır ve güç artık bölge bölge yönetilir.

Der Schlüssel zur zonalen Architektur ist der Zonencontroller, der dafür verantwortlich ist, zahlreiche Aktuatoren und Sensoren mit der zentralen Verarbeitungs-ECU zu verbinden. Dieser Controller ist nicht nur eine Datensammelbox; er kann Echtzeit-Regelkreise auf sich selbst ausführen, die Geräte in seiner Zone verwalten und gefilterten, priorisierten Verkehr an das Backbone senden. Laut einer ingenieurstechnischen Bewertung von Ti muss der MCU des Zonenmoduls hohe Echtzeitleistung, großen Speicher, Virtualisierungsunterstützung für verschiedene ASIL-Stufen, Hochgeschwindigkeitskommunikation zum Backbone sowie viele kostengünstige Peripherieschnittstellen wie CAN FD und LIN bieten.

Wie wird die Stromverteilung dezentralisiert?

In der Domain-Architektur wird die Stromversorgung über zentrale Stromverteilungskästen mit Sicherungen und Relais verteilt. In der zonalen Struktur wird die Verteilung dezentralisiert: Ein einziger Stromstrang wird von der Batterie zur Zone geführt, und das Zonenmodul verteilt die Stromversorgung an die Module dieser Zone. Kurze Stromkabel bedeuten direkt Gewicht und Kostenersparnis. Zudem übernehmen halbleiterbasierte intelligente Sicherungen die Funktion der Schmelzsicherungen; High-Side-Schalter mit I²t-Kennlinie bieten weniger Sicherungsvariabilität und optimiertere Kabelquerschnitte. Der intelligente Stromverteilungskasten, bestehend aus MCU, High-Side-Schaltern und Transceivern, wird zu einer Einheit, deren Konfiguration per Software erfolgt: Der gleiche Kasten kann in jeder Zone, an die Last angepasst, verwendet werden.

Entkopplung von physischer und logischer E/A

Zonale Module bündeln die logischen Ein-/Ausgabefunktionen mehrerer ECUs an einer zentralen Stelle und reduzieren so die Verkabelungskomplexität; die physischen Positionen von Sensoren und Aktuatoren bleiben dabei erhalten. Einen Schritt weiter werden die Endgeräte "intelligent": Die lokale Schaltung bewältigt den Zustandsinformationsfluss und führt die Fehlerdiagnose durch. Vereinfachte Protokolle wie CAN FD Light können sogar den Bedarf an einem separaten MCU an manchen Endknoten beseitigen. Diese Entkopplung, bei der die Hardware gleich bleibt und die Aufgabe per Software definiert wird, ist das technische Rückgrat des SDV.

Datenbus im zonalen Fahrzeug: Bandbreite, Timing und Cybersecurity

Sensorfusion und KI-Arbeitslasten machen es erforderlich, die zonale Topologie auf Hochbandbreiten-Backbones aufzubauen: PCIe, bis zu 20 Mbps Datenrate erreichendes CAN XL mit bestehender CAN-Kompatibilität und Gigabit-Ethernet. Die eigentliche Herausforderung liegt über der Bandbreite hinaus im Timing; kurze Steuerungsnachrichten, ADAS-Sensordaten und Infotainment-Traffic haben sehr unterschiedliche Latenz-, Jitter- und Synchronisationsanforderungen. Grobe Richtwerte: Für Audio gelten Ziele im Millisekundenbereich, für die Leistungsübertragung und die Chassiskontrolle im Mikrosekundenbereich.

Um diese verschiedenen Traffic-Klassen in einem einzigen Netzwerk zu transportieren, bietet sich Ethernet-basiertes Time-Sensitive Networking (TSN) als Lösung an. Standards wie Zeitsynchronisation (IEEE 802.1AS), zeitkritisches Traffic-Shaping (802.1Qbv), Express-Traffic (802.3br), Frame Pre-emption (802.1Qbu) und Redundanz (802.1CB) garantieren für kritische Daten deterministische Latenzen. Auf der Sicherheitsseite sind ISO 26262-Unterstützung, redundante Kommunikationswege, Sicherheitsspartitionierung und Fehlererkennung entscheidend; auf der Cybersecurity-Seite sind es der Standard ISO/SAE 21434, die UNECE-Vorschriften sowie Verschlüsselungs- und Authentifizierungsmechanismen auf niedriger Ebene wie MACsec. Da die zonale Architektur die Netzwerke zentralisiert, werden auch Ethernet-basierte Angriffsmethoden anwendbar; im Fall einer Sicherheitsverletzung stellt der Zusammenbruch des Konzepts der E/A-Rechenentkopplung ein individuell zu bewertendes Risiko dar.

Wie ermöglicht die Hardware-Software-Entkopplung OTA-Updates?

Das OTA-Update ist in den meisten SDV-Diskussionen das erste, woran man denkt, aber es ist keine Fähigkeit für sich; es ist eine Folge der Architektur. Ein unterbrechungsfreies Update kann nicht bereitgestellt werden, ohne dass die Software über eine Hardware-Abstraktionsschicht (HAL) von bestimmten Chips entkoppelt und die Fahrzeugfunktionen in unabhängige, wiederverwendbare, lose gekoppelte Dienste aufgeteilt werden (serviceorientierte Architektur, SOA). Die Entkopplung umfasst auch die Isolierung von Software mit unterschiedlichen Sicherheitsniveaus voneinander.

Die konkrete Bedeutung ist diese: Die Zonen-Architektur verlagert die Echtzeit-Regelkreise in die Zonenmodule und überträgt die Kontrolle über die hochwertige Software-Wartung durch OTA/FOTA-Updates und permanente Cloud-Anbindung an den Hersteller. Feinabstimmungen wie die Abschaltung ungenutzter Module bei Elektrofahrzeugen werden durch diese Struktur ebenfalls erleichtert. Letztlich ist die Software eines Elektrofahrzeugs mehr als nur ein Update-Kanal: Sie ist die Definitionsschicht, die die Ausstattungsmerkmale, Sicherheitssysteme und den Leistungscharakter des Fahrzeugs bestimmt. Das Fahrzeug beginnt, einem verteilten Rechenzentrum auf Rädern zu ähneln; die Wertschöpfungskette stützt sich auf Software, Rechenleistung und Systemarchitektur.

Wie Schnell Verläuft der Umstieg und Reicht die Zonale Architektur Aus?

Der Übergang wird schrittweise erfolgen. Die Karosserie-Domain enthält eine Vielzahl verteilter Aktuatoren und Sensor-ECUs und ist daher der erste Bereich, der auf die Zonen-Architektur umgestellt wird; der Übergang von ADAS, Antriebsstrang und Fahrwerksregelung kann wegen ihres sicherheitskritischen Charakters länger dauern. Die seit 2017 stattgefundene Evolution auf den Ebenen MCAL, BSW und Anwendungsschicht zeigt, dass es sich nicht um ein technisches Projekt, sondern um einen branchenweiten Mentalitätswandel handelt.

Auch eine ausgewogene Betrachtung ist geboten. Die zonale Architektur reorganisiert das Fahrzeug physisch; die logische und softwareseitige Seite (SOA, HAL, Cybersicherheit) muss zusätzlich gelöst werden - allein das Neuanordnen der Kabel macht ein Fahrzeug nicht softwaredefiniert. Die Marktvolumenprognosen variieren je nach Scope-Definitionen erheblich; unterschiedliche Zahlen zum Markt für E/E-Architekturen ergeben sich daraus, was gezählt wird (nur Rechenplattformen oder die gesamte verteilte Elektronik). Zudem sollte nicht vergessen werden, dass Halbleiter- und Lösungsanbieter als Beteiligte des Übergangs von diesem Wandel naturgemäß profitieren.

Das Ergebnis ist eine klare ingenieurtechnische Balance: Die Softwaredefiniertheit des Fahrzeugs ist nur möglich, wenn ein neues Hardwarekonzept auf Basis von Domain- und Zonencontrollern, entkoppelte Software-Ebenen und ein deterministischer, sicherer Daten-Backbone gleichzeitig existieren. Das OTA-Update ist die sichtbarste Frucht dieser integrierten Struktur; die eigentliche Revolution liegt darin, dass die Hardware des Fahrzeugs ihre Aufgabendefinition an die Software überträgt.