Zonale Architektur im Auto: 48-Volt-Bordnetz und Automotive Ethernet

Warum die Architektur vor dem einzelnen Bauteil kommt

Wer ein Steuergerät tauscht oder eine Leitung nachzieht, denkt meist in Bauteilen: dieser Sensor, dieses Relais, dieser Stecker. Die Zonenarchitektur denkt anders. Sie fragt zuerst, in welchem Bereich des Fahrzeugs ein Bauteil physisch sitzt. Erst danach folgt die Frage, welche Funktion es erfüllt. Ein Scheinwerfer, ein Fensterheber und ein Sitzmotor auf derselben Fahrzeugseite hängen deshalb nicht mehr an drei verschiedenen, funktional sortierten Steuergeräten. Sie hängen an einem gemeinsamen Zone Controller, der räumlich in ihrer Nähe verbaut ist. Diese Umstellung wirkt zunächst wie eine reine Verkabelungsfrage. Tatsächlich ist sie vor allem eine Frage der Verantwortung: Ein einziger Knoten übernimmt jetzt Leistung, Zustand und Datenweiterleitung für einen ganzen Fahrzeugbereich.

Für die Fehlersuche in der Zonenarchitektur hat das eine direkte Folge. Eine sichtbare Funktion – Licht, Fenster, Sitzverstellung – durchläuft in der Zonenarchitektur mehrere Ebenen, bevor sie beim Fahrer ankommt. Dazu gehören die physische Versorgung am Zone Controller, sein interner Schutz- und Schaltzustand, die Datenverbindung zur zentralen Rechenplattform und erst dann die eigentliche Anwendungslogik. Ein Fehlercode, der nach einer Änderung auftaucht, sagt für sich allein noch nicht, auf welcher dieser Ebenen die Ursache liegt. Genau darum lohnt es sich, Strom- und Datenarchitektur gemeinsam zu betrachten, bevor eine einzelne Komponente verdächtigt wird.

Von der Domäne zur Zone: was sich am Aufbau ändert

Die klassische Domänenarchitektur sortiert Steuergeräte nach Funktion: ein Antriebsstrang-Netzwerk, ein Komfort-Netzwerk, ein Infotainment-Netzwerk, jeweils mit eigenem Bus und eigenem Domänensteuergerät. Räumliche Nähe spielte dabei kaum eine Rolle. Ein Komfortsteuergerät für die Heckklappe konnte am anderen Ende des Fahrzeugs sitzen als das für die Türen, solange beide am selben logischen Netzwerk hingen. Die Zonenarchitektur kehrt dieses Prinzip um. Sie sortiert nach Ort statt nach Funktion. Wie dieser Wandel von der Domäne zur Zonensteuerung im Detail abläuft, ist ein eigenes Thema für sich. Hier zählt vor allem die Folge für Bordnetz und Datenbus.

Die Folge betrifft direkt zwei Dinge, um die es in diesem Beitrag geht: die Leistungsverteilung und den Datentransport. Statt langer Kabelstränge, die von einer zentralen Batterie quer durchs Fahrzeug zu jedem einzelnen Verbraucher laufen, versorgt ein Zone Controller die Verbraucher seiner Umgebung lokal, über eine kurze, überschaubare Leitungsführung. Und statt vieler einzelner Busleitungen zu jedem Domänensteuergerät bündelt ein Ethernet-Backbone den Datenverkehr zwischen den Zonen und der zentralen Rechenplattform. Beide Effekte zusammen sind der eigentliche Grund für den Umbau: kürzere, leichtere Kabelbäume und ein Datennetz, das mit steigender Datenmenge mitwächst. Eine neue Funktion braucht dadurch nicht mehr automatisch eine neue Leitung.

Der Zone Controller: ein Knoten für Strom und Daten zugleich

Ein Zone Controller übernimmt in seinem Bereich mehrere Aufgaben gleichzeitig. Er bindet lokale Sensoren und Aktoren an und schaltet für sie die Leistung. Er überwacht ihren Zustand und transportiert die daraus entstehenden Daten über einen Ethernet-Backbone an eine zentrale Rechenplattform weiter. Genau diese Kombination aus Datenverteilung und Leistungsverteilung an einem einzigen Knoten unterscheidet ihn von einem klassischen Domänensteuergerät, das meist nur eine der beiden Aufgaben trägt.

Aktuelle Referenzsysteme aus dem Jahr 2026 zeigen diese Kombination sehr konkret. Nach Herstellerangabe verbindet das Referenzsystem NXP CoreRide Z248 zonale Datenverteilung mit einer 48-Volt-Leistungsverteilung in einem gemeinsamen Baustein. Ein solches Referenzdesign ist kein fertiges Serienprodukt. Es ist eine Vorlage, an der sich Fahrzeughersteller orientieren können, und die konkrete Umsetzung im jeweiligen Modell weicht davon ab.

Die praktische Konsequenz dieser Doppelrolle zeigt sich, sobald etwas ausfällt. Fällt die Versorgung einer Zone aus, verschwinden häufig mehrere, auf den ersten Blick unabhängige Funktionen gleichzeitig. Sie hängen alle am selben Zone Controller, nicht weil sie technisch zusammengehören. Bleibt umgekehrt die elektrische Versorgung stabil, während die Datenverbindung gestört ist, kann ein Aktor durchaus mit Strom versorgt sein und trotzdem softwareseitig nicht erreichbar bleiben. Diese Kombination aus Versorgungs- und Kommunikationszustand ist für die Ursachensuche oft aussagekräftiger als ein einzelner Fehlercode. Sie zeigt, auf welcher der beiden Ebenen das Problem tatsächlich sitzt.

Das 48-Volt-Bordnetz in der Zone – und warum es kein Hochvolt ist

Ein 48-Volt-Zweig innerhalb einer Zonenarchitektur ist kein Antriebssystem und kein Ersatz für das klassische 12-Volt-Netz. Er ist ein zusätzlicher Leistungspfad für Verbraucher, die mit 12 Volt an ihre Grenze kämen. Ein Zone Controller kann darüber Aktoren versorgen, die spürbar mehr Leistung brauchen als eine einzelne Leuchte oder ein Fensterheber. Ein eigenes Hochvoltsystem mit eigener Isolationsüberwachung wird dafür nicht nötig. Genau diese Zwischenstufe macht 48 Volt für eine Zonenarchitektur interessant: mehr Leistungsreserve als 12 Volt, aber ohne den Aufwand eines Hochvoltsystems. Wie Load Dump und Verpolung als Spannungsspitzen ein Bordnetz belasten, unabhängig von der Spannungsebene, zeigt der Beitrag Spannungsspitzen im Auto: Load Dump, Verpolung und Einschaltstrom.

Und genau hier liegt der erste von zwei Denkfehlern, die in diesem Beitrag noch ausführlicher zur Sprache kommen. 48 Volt wird in Gesprächen gern automatisch mit Hochvolt gleichgesetzt, weil beide Systeme über der klassischen 12-Volt-Ebene liegen. Ein 48-Volt-Bordnetz ist aber eine eigene Spannungsebene mit eigenen Anforderungen. Sie lassen sich weder aus dem 12-Volt-Netz noch aus einem Hochvoltsystem im Antriebsstrang ableiten. Wie diese 48-Volt-Ebene konkret mit dem klassischen 12-Volt-Bordnetz zusammenspielt und wo beide sich abgrenzen, ordnet der Beitrag 48-Volt-Bordnetz und 12-Volt-Koexistenz ein.

Wie ein 48-Volt-Netz im Zusammenspiel mit dem klassischen 12-Volt-Bordnetz beim Mildhybrid genutzt wird, welchen Nutzen es dort stützt und wo seine Grenzen liegen, ist an anderer Stelle ausführlich eingeordnet. Dieser Beitrag betrachtet 48 Volt bewusst nicht als Antriebskomponente, sondern als architektonisches Element: als Leistungspfad, den ein Zone Controller neben seiner Datenverteilung führt. Beide Sichtweisen ergänzen sich, beantworten aber unterschiedliche Fragen.

Automotive Ethernet als Rückgrat der Zonenarchitektur

Ein Ethernet-Backbone verbindet die Zone Controller im Fahrzeug mit der zentralen Rechenplattform und untereinander. Für diesen Beitrag zählt weniger, mit welcher genauen Bitrate oder über welches konkrete Kabelpaar dieser Datenverkehr läuft. Wichtiger ist, welche Rolle das Netz in der Gesamtarchitektur übernimmt: Es bündelt Daten, die früher über viele einzelne, funktional getrennte Busse liefen, auf einer gemeinsamen Infrastruktur. Ein Fehler in dieser Infrastruktur wirkt sich deshalb potenziell auf mehrere Zonen gleichzeitig aus. Ein Fehler auf einem klassischen Einzelbus blieb dagegen meist auf ein Steuergerät oder eine kleine Gruppe davon begrenzt. Wie sich ein solcher Busfehler über Masse, Terminierung und Wake-up eingrenzen lässt, zeigt der Beitrag CAN-Bus-Fehler finden: Masse, Terminierung und Wake-up prüfen.

ISO 21111-1 gilt 2026 weiterhin als veröffentlichte Grundlage für In-Vehicle Ethernet im Fahrzeug. Gleichzeitig entwickelt sich die zugehörige Normenserie laufend weiter. Einzelne Teile befinden sich in Überarbeitung oder werden ersetzt. Wer sich auf einen bestimmten Stand beruft, sollte deshalb angeben, welcher Teil der Serie gemeint ist und wann er zuletzt geprüft wurde. Ein pauschaler Verweis auf „Automotive Ethernet nach ISO“ trägt für eine technische Aussage zu wenig.

Welche physische Übertragungsart in welchem Fahrzeugbereich üblich ist und welche Datenrate sie jeweils trägt, ist für die technischen Standards selbst wichtig. Dazu ist an anderer Stelle eine eigene Einordnung zu den gängigen Automotive-Ethernet-Standards hinterlegt. Dieser Beitrag bleibt bei der Architekturfrage: warum ein Backbone überhaupt existiert und wie er sich zur Zonenaufteilung des Fahrzeugs verhält. Die physikalischen Details der einzelnen Leitung sind nicht sein Thema.

Serviceorientierte Kommunikation: was sich mit AUTOSAR Adaptive ändert

Mit dem Ethernet-Backbone ändert sich auch, wie Steuergeräte miteinander sprechen. AUTOSAR Adaptive, in der Fassung R25-11, beschreibt serviceorientierte Kommunikation auf Basis von Ethernet. Statt fest verdrahteter Botschaften auf einem klassischen Bus fragt ein Steuergerät dabei einen Dienst an, den ein anderes Steuergerät im Netzwerk anbietet, und bekommt die Antwort darüber zurück. Dasselbe Dokument nennt außerdem CAN XL als mögliche physische Option, um solche Ethernet-Dienste über eine Leitung zu tunneln, die ursprünglich aus der klassischen CAN-Welt stammt. Diese Architekturentscheidung ist etwas anderes als ein einzelnes Diagnoseprotokoll auf einer Leitung. Sie betrifft, wie Dienste im ganzen Fahrzeug gefunden und angesprochen werden, nicht nur, wie eine einzelne Nachricht codiert ist.

Welche Rolle SOME/IP und DDS dabei jeweils spielen und was sich dadurch gegenüber klassischer, signalbasierter Kommunikation ändert, ist in einem eigenen Beitrag beschrieben. Für die Zonenarchitektur ist vor allem wichtig, dass ein Kommunikationsproblem jetzt an sehr unterschiedlichen Stellen entstehen kann. Möglich sind die physische Leitung, der Netzwerk-Switch, die IP-Ebene, die Dienstsuche selbst oder erst die Anwendung, die den Dienst am Ende nutzt. Ohne eine saubere Trennung dieser Ebenen wird jede Fehlersuche zum Zufallstreffer.

Drei Denkfehler, die in zonalen Systemen teuer werden

Drei Fehlannahmen tauchen in der Praxis besonders häufig auf. Sie entstehen, wenn jemand an eine Zonenarchitektur mit den Gewohnheiten eines klassischen, funktional sortierten Fahrzeugnetzes herangeht. Die erste: Ein Netzwerkfehler wird untersucht, ohne vorher die Versorgung des betroffenen Zone Controllers zu prüfen. Dabei kann ein instabiler Datenlink genauso gut Folge einer schwankenden Spannung sein wie eine eigenständige Netzwerkstörung. Wie sich ein solcher Spannungsabfall im 12-Volt-Netz unter Last messen lässt, zeigt der Beitrag Fehler 12-V-Bordnetz: Spannungsabfall und Masse unter Last messen. Die zweite: Eine intelligente Sicherung, die einen Verbraucher aktiv überwacht und selbstständig schaltet, wird gedanklich mit einer klassischen Schmelzsicherung gleichgesetzt, die nur passiv auslöst. Beide schützen einen Stromkreis. Sie tun das aber auf grundsätzlich verschiedene Weise und melden ihren Zustand unterschiedlich an das System.

Der dritte Denkfehler betrifft die Spannungsebene selbst. 48 Volt wird, wie im Abschnitt zuvor beschrieben, automatisch als Hochvolt behandelt, nur weil es über 12 Volt liegt. Alle drei Fehlannahmen haben in der Zonenarchitektur eine gemeinsame Ursache. Moderne Fahrzeugsysteme besitzen mehrere Schutz- und Abstraktionsebenen übereinander. Wer nur eine davon kennt, überträgt ihre Regeln unbewusst auf die anderen. Ein Diagnosewerkzeug kann zum Beispiel einen fehlenden Zugriff auf ein Steuergerät melden, obwohl es elektrisch und im Netzwerk technisch erreichbar wäre. Nur die nötige Freigabe für diesen konkreten Dienst fehlt dann. Woran sich ein Steuergerät, das nicht antwortet, von einer echten Gateway-Störung unterscheiden lässt, zeigt der Beitrag Steuergerät kommuniziert nicht: Gateway, Topologie prüfen.

Wie eine Störung durch die Ebenen wandert

Weil eine sichtbare Funktion in der Zonenarchitektur mehrere Ebenen durchläuft, lohnt sich eine Fehlersuche, die rückwärts arbeitet statt vorwärts zu raten. Zuerst steht die sichtbare Funktionsstörung – ein Fenster reagiert nicht, ein Licht bleibt aus. Danach folgt der Blick auf den Dienst- oder Kommunikationszustand: Ist der zuständige Zone Controller im Netzwerk überhaupt erreichbar, und bietet er den erwarteten Dienst an? Erst danach folgt die Versorgung, und ganz am Ende der elektrische Grundzustand des Bordnetzes selbst.

Dieser Rückwärtsweg verhindert einen typischen Denkfehler. Ein nachgelagerter Fehlercode wird sonst fälschlich zum eigentlichen Ursprung erklärt, obwohl er nur eine Folge einer weiter vorn liegenden Ursache ist. Für einen belastbaren Vergleich in der Zonenarchitektur braucht es außerdem dieselben Randbedingungen: denselben Fahrzeugmodus, eine vergleichbare Versorgung, eine definierte Zeitspanne nach dem Aufwachen des Systems und einen dokumentierten Softwarestand. Erst wenn eine Beobachtung unter diesen gleichen Bedingungen reproduzierbar bleibt, wird aus einer einzelnen Auffälligkeit eine belastbare Aussage über die tatsächliche Ursache.

Fünf Signale, die erst gemeinsam ein Bild ergeben

Für eine Zonenarchitektur gehören mindestens fünf Größen in eine gemeinsame Betrachtung. Dazu zählen die Versorgungsspannung der Zone, der Status ihrer elektronischen Sicherung, der Zustand der Datenverbindung, der tatsächlich fließende Laststrom und der Wach- oder Schlafzustand des betroffenen Steuergeräts. Keine dieser Größen ist für sich allein beweiskräftig. Ein Statuswert ohne den passenden Zeitpunkt sagt zum Beispiel wenig darüber aus, was ein Ereignis wirklich ausgelöst hat, wenn kurz zuvor ein Softwareupdate, ein Spannungseinbruch oder eine neu erteilte Diagnosefreigabe stattgefunden hat.

Sind mehrere Steuergeräte an einer Beobachtung beteiligt, müssen ihre Zeitbasen ausreichend genau zueinander passen. Sonst erscheinen Ereignisse scheinbar in der falschen Reihenfolge, und die Ursachenkette wird verwechselt. Ein Kommunikationsfehler kann außerdem Folge eines Schlafzustands sein, nicht dessen Ursache. Ein Zone Controller, der gerade erst aufgewacht ist, meldet sich im Netzwerk mit einer gewissen Verzögerung, und diese Verzögerung darf nicht sofort als Ausfall gedeutet werden. Ein brauchbarer Datensatz beantwortet deshalb drei einfache Fragen: Was war vor dem Ereignis stabil? Was änderte sich unmittelbar davor? Und welche der fünf Größen bestätigt oder widerlegt die erste Vermutung unabhängig von den anderen?

Größenordnungen statt Scheingenauigkeit: was eine Modellrechnung zeigt

Die folgenden fünf Rechenbeispiele für die Zonenarchitektur sind bewusst einfache, nachvollziehbare Modelle. Sie sollen Größenordnungen sichtbar machen, nicht ein reales Fahrzeug simulieren, und sie ersetzen keine Herstellerangabe für ein konkretes Modell. Ein Quotient kann zeigen, ob eine Reserve oder eine Auslastung plausibel in der richtigen Größenordnung liegt – mehr nicht.

Modell	Ausdruck	Ergebnis	Einheit
Leistungsreserve einer Zone	Grenzwert minus tatsächliche Last	480	W
Spannungsfall auf der Zuleitung	Strom mal Leitungswiderstand	0,42	V
Verlustleistung im Leiter	Strom zum Quadrat mal Widerstand	14,7	W
Auslastung eines Zone Controllers	belegte Kanäle geteilt durch verfügbare Kanäle	0,79	Anteil
Wakequote im Testfenster	tatsächlich aufgewachte Geräte geteilt durch erwartete	0,83	Anteil

Wichtig ist bei allen fünf Modellen die Trennung zwischen der Rechnung und dem echten Messwert. Nur weil ein Quotient plausibel aussieht, ist er noch keine Bestätigung, dass ein reales Bauteil im Fahrzeug tatsächlich in diesem Bereich arbeitet. Bei Anteilswerten wie Auslastung oder Wakequote lohnt sich zusätzlich ein zweiter Blick darauf, ob Zähler und Nenner überhaupt dieselbe Bezugsgröße verwenden. Genau an dieser Stelle entstehen in technischen Texten häufig Zahlen, die präzise aussehen, aber die falsche Frage beantworten.

Was Nachrüstung in einer Zonenarchitektur verändert

Ein nachgerüstetes Bauteil kann technisch einwandfrei funktionieren und trotzdem neue Abhängigkeiten in eine Zonenarchitektur einbringen. Dazu zählen andere Aufwachzeiten als die Serie, ein zusätzlicher Gateway-Umweg für seine Daten, ein veränderter Diagnosepfad, ein abweichender Softwarestand oder schlicht eine zusätzliche Last am Zone Controller, für die dessen Leistungsreserve nicht kalkuliert war. Ein Zone Controller verwaltet in der Zonenarchitektur Strom und Daten gemeinsam. Deshalb wirkt sich eine solche Änderung selten isoliert aus, sie betrifft potenziell alles, was am selben Knoten hängt.

Genau deshalb wird jede Nachrüstung an einem zonal aufgebauten Bordnetz als Systemänderung dokumentiert, nicht nur als eingebautes Bauteil. Dazu gehören der Vorher- und Nachher-Zustand, die Möglichkeit zur Rückrüstung und eine klare Zuordnung, wer die Änderung vorgenommen hat. Das reduziert später die Gefahr, bei einem Software-Update oder einer Diagnose nicht mehr zu wissen, welcher Zustand ursprünglich zur Serienausstattung gehörte.

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.

Das gilt unabhängig davon, ob sich am Ende überhaupt eine technische Beanstandung feststellen lässt. Sobald ein Bauteil dauerhaft in eine Zone eingebunden wird, die Leistung schaltet und sicherheitsrelevante Daten weiterleitet, ist die Frage nach der Betriebserlaubnis zu klären. Das gilt, bevor das Fahrzeug wieder im öffentlichen Straßenverkehr bewegt wird. Wo Schutzmechanismen, Airbag-, Brems- oder Lenkfunktionen, ein Hochvoltsystem oder genehmigungsrelevante Software berührt werden, endet dieser Beitrag bewusst vor dem eigentlichen Eingriff. Er erklärt, warum ein Zustand entsteht und welche Daten zur Fachdiagnose gehören. Wie Schutzfunktionen umgangen werden, erklärt er nicht.

Abgrenzung zu Nachbarthemen

Dieser Beitrag behandelt ausdrücklich die Vernetzungsarchitektur: Zonen, den Zone Controller, das 48-Volt-Bordnetz als architektonisches Element und den Ethernet-Backbone. Er behandelt bewusst nicht die intelligente Sicherung als einzelnes Bauteil und ihre Absicherungslogik. Dazu gehört, wie eine solche Sicherung im Detail auslöst, wie sie sich von einer klassischen Schmelzsicherung technisch unterscheidet und wie die Stromverteilung im Fahrzeug im Kleinen aufgebaut ist. Dieses Thema ist eigenständig und wird an anderer Stelle behandelt. Diese Abgrenzung hält die Zonenarchitektur als eigenes Thema sauber von ihren Bauteilen getrennt.

Ebenso außen vor bleiben das klassische Diagnoseprotokoll auf einem einzelnen Bus und die Sensorik von Fahrassistenzsystemen. Beides sind eigene Themenfelder mit eigenen Fragestellungen, die eine Zonenarchitektur zwar nutzt, aber nicht selbst beschreibt. Interne Verweise in diesem Beitrag führen deshalb von der Architekturfrage zur jeweiligen Nachbarebene, nicht umgekehrt: von der Zone zur Kommunikationsart, von der Domänenfrage zur Zonenfrage, vom Datenbus zu seinen physischen Standards. Der Link ersetzt keinen eigenen Beitrag zum Nachbarthema. Er markiert nur, wo die Systemgrenze verläuft.

Häufige Fragen

Einordnung: wo die Regeln stehen

Die Fundstellen stehen hier gebündelt, damit der Fließtext ohne Paragrafenketten und ohne Normzitate auskommt. Das Normzitat zu § 19 StVZO ist zeichengenau gegen die amtliche Fassung auf gesetze-im-internet.de geprüft, abgerufen und archiviert am 19.09.2026. Die technischen Quellen zu Zonenarchitektur, 48-Volt-Referenzdesign, Automotive Ethernet und AUTOSAR sind im Klartext genannt, wie es die Projektregeln für Herstellerquellen seit dem 7. September 2026 vorsehen. Wo ein Abrufversuch scheiterte, ist das ausdrücklich vermerkt.