Steuergeräte im Auto: von der Domäne zur zonalen Architektur

Warum Steuergeräte neu geordnet werden

Ein Werkstattmeister öffnet heute einen Schaltplan und findet nicht mehr fünfzig kleine Kästchen mit fünfzig Funktionsnamen, sondern eine Handvoll größerer Blöcke, die nach Fahrzeugbereich benannt sind: vorne links, hinten, Dach. Das ist keine bloße Umbenennung, sondern eine tatsächliche Verschiebung der Systemgrenzen. Wo früher jede Funktion – Fensterheber, Sitzheizung, Türsteuerung – ihr eigenes kleines Steuergerät besaß, sitzt heute oft ein einziger Controller, der alles bedient, was sich physisch in seiner Nähe befindet. Der Wandel betrifft nicht nur Neuwagen mit auffälligen Zusatzfunktionen, sondern die komplette innere Ordnung des Fahrzeugs.

Für Diagnose, Nachrüstung und jede Art von Softwareänderung ist diese Ordnung entscheidend. Wer nicht weiß, ob ein Signal aus einem funktionsbezogenen oder einem ortsbezogenen Steuergerät stammt, sucht schnell am falschen Bauteil. Dieser Beitrag ordnet deshalb die drei Grundmuster – Domäne, Zone und zentrale Recheneinheit – sauber gegeneinander ab, bevor er zeigt, was sich für Retrofit und Tuning praktisch ändert.

Historisch war die Domänenarchitektur selbst schon eine Aufräumaktion. In den ersten Jahrzehnten der Fahrzeugelektronik bekam praktisch jede neue Funktion ein eigenes, kleines Steuergerät, unabhängig davon, ob eine vergleichbare Aufgabe im Auto schon existierte. Mit der Zeit wuchs die Zahl dieser Einzelsteuergeräte so stark, dass Hersteller begannen, verwandte Funktionen unter einem gemeinsamen Domänencontroller zu bündeln. Die zonale Architektur ist damit kein Bruch mit dieser Idee, sondern deren konsequente Fortsetzung entlang einer anderen Ordnungslogik.

Domänenarchitektur: eine Zentrale pro Funktion

Die Domänenarchitektur ordnet Steuergeräte nach Aufgabe, nicht nach Ort. Ein Antriebsstrang-Domänencontroller bündelt Motor-, Getriebe- und Ladefunktionen, ein Karosserie-Domänencontroller übernimmt Fensterheber, Beleuchtung und Zentralverriegelung, ein weiterer kümmert sich um Fahrwerk und Bremsen. Innerhalb einer Domäne kommunizieren die Teilfunktionen eng miteinander, weil sie fachlich zusammengehören. Über Domänengrenzen hinweg läuft der Austausch dagegen meist über einen zentralen Bus, der als gemeinsamer Verteiler dient.

Der Vorteil liegt in der klaren fachlichen Zuständigkeit: Ein Team für Fahrwerksfunktionen entwickelt und testet seinen Domänencontroller weitgehend unabhängig von der Infotainment-Abteilung. Der Nachteil zeigt sich beim Verkabeln. Ein Sensor im Kofferraum kann fachlich zur Karosseriedomäne gehören, obwohl der zuständige Controller vorne im Fahrzeug sitzt, und dann muss das Kabel eben quer durchs Auto laufen, egal wie weit die physische Strecke ist. Je mehr Funktionen ein Fahrzeug bekommt, desto mehr solcher langen, funktionsgebundenen Leitungen kommen zusammen – ein Muster, das an seine praktischen Grenzen stößt, sobald die Zahl der Sensoren und Aktoren weiter wächst.

Zonale Architektur: Nachbarschaft schlägt Funktion

Die zonale Architektur kehrt dieses Prinzip um. Statt nach Funktion wird nach Einbauort geordnet: ein Zone Controller vorne links, einer hinten rechts, einer im Dachbereich. Jeder davon bündelt alles, was in seiner unmittelbaren Umgebung an Sensoren und Aktoren hängt – unabhängig davon, zu welcher Fahrzeugfunktion es fachlich gehört. Ein Fensterheber, ein Blinkerrelais und ein Temperaturfühler in derselben Fahrzeugecke landen damit am selben Controller, auch wenn sie inhaltlich nichts miteinander zu tun haben.

Das kürzt die Leitungswege spürbar, weil kaum noch ein Kabel quer durchs Fahrzeug laufen muss. Der Zone Controller wandelt die lokal gesammelten Signale in ein gemeinsames Datenformat um und reicht sie über eine zentrale Verbindung weiter. Was mit diesen Daten inhaltlich passiert – etwa ob ein Fensterheber blockiert oder eine Sitzheizung zu heiß wird –, entscheidet in einer konsequent zonalen Architektur meist nicht mehr der Zone Controller selbst, sondern eine Recheneinheit weiter oben in der Kette. Genau an dieser Stelle entsteht eine Verwechslung, die einen eigenen Abschnitt verdient.

Warum ein Zone Controller kein Domain Controller ist

Ein Zone Controller und ein Domain Controller lösen unterschiedliche Aufgaben, auch wenn beide Begriffe nach Ähnlichem klingen. Der Domain Controller trägt die fachliche Logik einer Funktion: Er weiß, wann eine Sitzheizung abschalten muss oder wie ein Fensterheber auf einen Einklemmschutz reagiert. Der Zone Controller dagegen kennt vor allem seinen Standort. Er sammelt Rohsignale, prüft sie auf Plausibilität, versorgt angeschlossene Geräte mit Strom und reicht alles gebündelt weiter – die eigentliche Entscheidung trifft in einer konsequent zonalen Architektur häufig eine andere Ebene.

Wer beide Rollen gleichsetzt, unterschätzt, wie stark sich die Softwarelogik gerade verschiebt. Eine Fahrzeuggeneration kann äußerlich zonal wirken, weil die Verkabelung Fahrzeugbereichen folgt, während die fachliche Logik weiterhin in Blöcken organisiert ist, die inhaltlich den alten Domänen entsprechen. Nur laufen diese Blöcke jetzt eben als Software auf einer zentralen Recheneinheit statt auf einem eigenen Steuergerät. Die physische Aufteilung und die fachliche Aufteilung sind zwei getrennte Ebenen, die sich unabhängig voneinander entwickeln können und in der Praxis selten exakt gleichzeitig umgebaut werden.

Central Compute: wo die Rechenlast heute hinwandert

Central Compute bezeichnet eine kleine Zahl leistungsfähiger Rechenplattformen, die einen großen Teil der fachlichen Logik übernehmen, die früher auf viele einzelne Domänencontroller verteilt war. Statt zehn spezialisierter Steuergeräte mit jeweils eigener Hardware und eigenem Softwarestand läuft die entsprechende Funktion als eine von mehreren Anwendungen auf einer gemeinsamen Recheneinheit. Für den Hersteller bedeutet das: Eine neue Funktion lässt sich per Software ergänzen, ohne zwingend neue Hardware zu verbauen. Für Diagnose und Werkstattpraxis bedeutet es etwas anderes, nämlich dass ein einzelner Fehlercode nicht mehr automatisch ein einzelnes physisches Bauteil bezeichnet.

Die Zone Controller werden in diesem Modell zu Randknoten: Sie sammeln, wandeln um, schalten Strom und geben weiter, treffen aber immer seltener selbst die inhaltliche Entscheidung. Diese Verschiebung – weg von vielen kleinen Entscheidungsträgern, hin zu wenigen großen – ist der eigentliche Kern des Wandels. Zonal beschreibt nur die räumliche Verkabelung, Central Compute beschreibt, wohin die Software zieht. Beide Bewegungen passen zusammen, sind aber technisch unabhängig voneinander und müssen einzeln bewertet werden, wenn ein Fahrzeug eingeordnet werden soll.

Warum „weniger Steuergeräte“ die falsche Kennzahl ist

Die verbreitete Annahme, ein Zonenkonzept bedeute automatisch weniger Steuergeräte, hält der genaueren Prüfung nicht stand. Eine zonale Verkabelung allein tauscht nur die Anordnung: Aus vielen über das Fahrzeug verteilten Funktionscontrollern werden wenige, nach Ort sortierte Zone Controller. Die Gesamtzahl kann dabei sogar gleich bleiben, wenn jede Zone weiterhin einen eigenen kleinen Prozessor für ihre lokale Vorverarbeitung braucht. Die tatsächliche Reduktion entsteht erst, wenn zusätzlich die fachliche Logik vieler einzelner Domänencontroller auf wenige Central-Compute-Plattformen zusammengeführt wird.

Wie stark diese Konsolidierung ausfallen kann, zeigt ein einfaches Rechenbeispiel, ohne dass daraus ein Anspruch auf ein bestimmtes Fahrzeug entsteht: Führt ein Architekturkonzept 36 vorher getrennte Steuergeräte auf 19 zusammen, sinkt die Zahl um rund 47 Prozent – eine reine Modellrechnung, keine Herstellervorgabe. Ähnliche Modelle für die Verkabelung selbst kommen häufig auf eine Reduktion im Bereich von einem Drittel, wenn die längsten funktionsgebundenen Leitungen wegfallen. Beide Werte hängen vollständig davon ab, wie viele vorher getrennte Funktionen tatsächlich zusammengelegt werden. Als pauschale Kennzahl für „zonal“ taugen sie deshalb nicht, weil sie je nach Fahrzeug und Baureihe stark schwanken.

Vom CAN-Verbund zum Ethernet-Backbone

Klassische Domänenarchitekturen kommunizieren größtenteils über CAN-Busse: robust, seit Jahrzehnten bewährt, aber mit begrenzter Übertragungsrate. Solange jede Domäne überwiegend mit sich selbst spricht, reicht das aus. Sobald aber ein Zone Controller die gebündelten Rohdaten mehrerer Sensoren an eine zentrale Recheneinheit weiterreichen muss – und diese wiederum Ergebnisse an mehrere Zonen gleichzeitig zurückschickt –, wächst die Datenmenge auf der zentralen Strecke deutlich über das hinaus, was ein klassischer CAN-Bus wirtschaftlich sinnvoll transportieren kann.

Deshalb setzen moderne E/E-Architekturen zunehmend auf Ethernet als Rückgrat zwischen Zonen und Zentralrechner. Die internationale Norm ISO 21111-1 beschreibt Begriffe und Grundlagen des Fahrzeug-Ethernets, während die AUTOSAR-Spezifikation für die adaptive Plattform serviceorientierte Kommunikation auf dieser Basis beschreibt. An den Rändern der Architektur, dort wo einzelne Sensoren oder einfache Schalter angebunden sind, bleiben CAN und verwandte Bussysteme dagegen oft bestehen, teils auch als CAN XL mit höherer Datenrate. Ein modernes Fahrzeug ist also selten rein CAN- oder rein Ethernet-basiert, sondern kombiniert beide Techniken je nach Position in der Architektur.

Warum die Umstellung in Etappen passiert

Kaum ein Fahrzeug springt in einem Schritt von der reinen Domänenarchitektur zur vollständigen Zonen- und Zentralrechnerstruktur. Eine komplette Neuordnung der Steuergeräte-Landschaft ist an eine neue Fahrzeugplattform gebunden, und Plattformen laufen typischerweise viele Jahre. Hersteller führen zonale Elemente deshalb häufig zunächst dort ein, wo der Nutzen am größten ist, etwa im Bereich mit der dichtesten Verkabelung, während andere Fahrzeugbereiche noch nach dem alten, funktionsbezogenen Muster arbeiten.

Ein aktuelles Beispiel für ein durchgängig zonales Referenzsystem ist die 2026 vorgestellte Plattform CoreRide Z248 des Halbleiterherstellers NXP, die eine zonale Datenverteilung mit einer entsprechenden Stromverteilung im selben Konzept zusammenführt – ein Hinweis darauf, dass eine zonale Architektur selten nur die Datenleitungen betrifft. Was das im Einzelnen für die Bordnetzauslegung eines Fahrzeugs bedeutet, ist ein eigenes Thema und wird hier bewusst nicht vertieft. Für die Einordnung eines konkreten Fahrzeugs zählt vor allem eines: Eine Mischform aus alten und neuen Prinzipien ist der Normalfall, keine Ausnahme, und beide Prinzipien können in ein und demselben Auto nebeneinander existieren.

Zwei Fahrzeuge im Vergleich: alt und neu nebeneinander

Stell dir zwei Schaltpläne nebeneinander auf dem Werkstatttisch vor. Der erste gehört zu einem Kompaktwagen aus der Mitte der 2010er-Jahre: fünf oder sechs Domänencontroller, dazwischen Dutzende kleiner Satellitensteuergeräte für einzelne Funktionen, verbunden über mehrere CAN-Stränge, die quer durchs ganze Fahrzeug laufen. Jede Leitung folgt einer Funktion, nicht einer Fahrzeugseite. Der zweite Plan gehört zu einer aktuellen Plattform aus der zweiten Hälfte der 2020er-Jahre: drei oder vier Zone Controller, ein bis zwei zentrale Recheneinheiten und ein Ethernet-Backbone, das diese Knoten verbindet. Die kleinen Satellitensteuergeräte sind größtenteils verschwunden, ihre Aufgaben laufen jetzt als Software auf der zentralen Plattform.

Der Unterschied zeigt sich am deutlichsten, wenn eine Funktion ausfällt, die früher ein eigenes Bauteil hatte. Beim älteren Fahrzeug führt die Fehlersuche direkt zu einem einzelnen, klar benannten Steuergerät. Beim neueren Fahrzeug muss zuerst geklärt werden, ob der Fehler in der lokalen Zone entsteht, auf dem Übertragungsweg liegt oder in der Software der zentralen Recheneinheit steckt. Das macht die Fehlersuche nicht grundsätzlich schwerer, verlangt aber ein anderes gedankliches Modell – eines, das zwischen Ort, Übertragung und Software unterscheidet, statt einfach dem Bauteilnamen zu folgen.

Was Retrofit und Tuning in der neuen Ordnung bedeuten

Wer heute ein zusätzliches Steuergerät nachrüstet oder eine bestehende Software verändert, greift selten noch in ein isoliertes Bauteil ein. Ein neues Modul kann an einem Zone Controller hängen, der gleichzeitig Signale für mehrere unabhängige Funktionen bündelt, oder es kann eine Kommunikationsverbindung mitnutzen, deren Kapazität für einen ganz anderen Datenverkehr berechnet war. Genau deshalb dokumentiert eine saubere Nachrüstung nicht nur das eingebaute Teil, sondern auch den Zustand davor und danach. Ohne diesen Vergleich lässt sich später kaum noch feststellen, was am Fahrzeug ursprünglich verbaut war.

Umbauten am eigenen Fahrzeug. Ob ein Umbau auf öffentlichen Straßen betrieben werden darf, entscheidet der Genehmigungszustand des Fahrzeugs — die Genehmigung des Teils, der Einbau nach ihren Auflagen und, wo nötig, die Abnahme durch eine dafür zuständige Stelle. Solange diese Kette nicht vollständig ist, gehört der Umbau auf Privatgelände, Testflächen und in nicht öffentliche Bereiche.

Rechtlich betrifft das vor allem Änderungen, die die genehmigte Fahrzeugart verändern, eine Gefährdung anderer Verkehrsteilnehmer erwarten lassen oder das Abgas- oder Geräuschverhalten verschlechtern – und ausdrücklich auch Softwareänderungen an bereits zugelassenen Fahrzeugen. Wo diese Kette einmal unterbrochen ist, hilft es wenig, dass sich die Ursache dank der neuen Architektur technisch sauber erklären lässt. Die Einordnung im Detail, mit dem vollständigen Wortlaut der einschlägigen Vorschrift, steht im Abschnitt am Ende dieses Beitrags.

Wie du die Architektur eines Fahrzeugs grob einordnest

Ein verlässliches Anzeichen ist das Baujahr der zugrunde liegenden Plattform, nicht das Modelljahr des einzelnen Fahrzeugs. Neue Plattformen, die ab etwa Mitte der 2020er-Jahre entwickelt wurden, planen zonale und zentrale Elemente von Anfang an ein. Ältere Plattformen mit mehrfachen Modellpflegen tragen dagegen meist noch die ursprüngliche Domänenstruktur, selbst wenn einzelne Funktionen später ergänzt wurden. Ein zweiter Hinweis steckt in der Benennung der Steuergeräte im Schaltplan oder im Diagnosewerkzeug: Heißt ein Steuergerät nach einer Funktion, etwa „Fensterheber vorne links“, spricht das für eine Domänenlogik. Heißt es dagegen nach einem Fahrzeugbereich, etwa „Zone vorne links“, ist das ein deutliches Indiz für ein Zonenkonzept.

Ein dritter Anhaltspunkt ist die Zahl der physisch getrennten Steuergeräte im Vergleich zur Zahl der bedienten Funktionen. Wachsen die Funktionen deutlich schneller als die Steuergeräte, ist das ein Hinweis auf Central Compute im Hintergrund. Diese drei Anzeichen ersetzen keine systematische Diagnose und schon gar keine Herstellerunterlagen. Sie helfen lediglich, ein Fahrzeug grob einzuordnen, bevor eine tiefere technische Bewertung beginnt. Für Änderungen an diesen Systemen gilt derselbe rechtliche Rahmen wie für jeden anderen Auto-Umbau.

Häufige Fragen

Einordnung: wo die Regeln stehen

Dieser Abschnitt sammelt die rechtlichen und technischen Fundstellen, die im Beitrag oben angesprochen werden, ausführlich, damit die Aussagen im Fließtext knapp bleiben können.