Domain-Based: Grouping by Function

Intermediate9 min read

Assumes: 2.1 Distributed Architecture

TL;DR

Domain-based architecture groups ECUs by function into Domain Controller Units (DCUs): powertrain, body, chassis, ADAS, and infotainment. Each DCU is a more powerful SoC or MCU that runs multiple apps that used to live in separate boxes. A central gateway routes between domains over an Automotive Ethernet backbone, while CAN/LIN still handle local I/O inside each domain. Most cars on the road today use this model, including the platform your SA8155P/SA8295P runs on.

If distributed architecture is suburban sprawl, domain-based architecture is the city that hired an urban planner — finally. This page covers the architecture you’re most likely working in right now, the bus topology behind your daily QNX/AAOS debugging, and why “it works on my bench” is the most dangerous sentence in automotive integration.

Common Gotcha

Beginner thinks “our car uses Ethernet, so it’s zonal.”

Reality: most domain-based architectures added an Ethernet backbone between functional domains years before zonal controllers appeared. Ethernet alone doesn’t mean zonal. Look at where compute is placed: grouped by function (domain) or by physical location (zonal).

Common Gotcha

If you debug a body signal by tracing the infotainment Ethernet path first, you’ll miss that it still originates on a local CAN/LIN bus inside the body domain.

Domain architecture keeps local I/O on legacy buses. The cockpit SoC sees an aggregated version — not the raw sensor wire. Start at the domain controller, not the HMI.

The Five Domains

OEMs slice the vehicle into functional domains. Names vary by manufacturer, but the pattern is consistent:

Domain	Consolidates	Typical Compute	Key Buses
Powertrain	Engine, transmission, exhaust, hybrid/EV management	High-performance MCU (Aurix, RH850)	CAN, CAN FD
Body	Doors, seats, lighting, mirrors, wipers	MCU or mid-range SoC	CAN, LIN
Chassis	ABS, steering, suspension, stability	Safety MCU (ASIL-D capable)	CAN, FlexRay
ADAS	Cameras, radar, lidar fusion, AEB	Vision SoC + safety MCU	Ethernet, CAN
Infotainment / Cockpit	Cluster, center stack, audio, connectivity	Qualcomm SA8155P/SA8295P	Ethernet, USB, MOST (legacy)

Each domain controller absorbs what used to be 5–15 separate ECUs. The body domain might still have satellite LIN nodes (door switches, seat motors), but the decision logic lives in the DCU. One way to remember: group by duty (function), not direction (location).

Inside a Domain Controller

A DCU is not just a faster ECU. It’s a mini computer:

• Multi-core SoC or MCU running hypervisor or AUTOSAR Adaptive
• Multiple OS instances: e.g., QNX for cluster + AAOS for IVI in the cockpit domain
• Local CAN/LIN controllers for sensor/actuator I/O
• Ethernet MAC for backbone communication
• Hardware security module (HSM) for secure boot and key storage

The cockpit/infotainment domain is where your daily work lives. That “head unit” is a domain controller running a hypervisor stack on a Snapdragon SoC, not a standalone radio ECU.

Mental Model

Domain architecture is a city organized by district. Powertrain is the industrial zone. Body is residential. Chassis is the road authority. ADAS is the surveillance bureau. Infotainment is downtown entertainment. Each district has a city hall (DCU) that manages local affairs. A regional transit hub (central gateway + Ethernet backbone) connects the districts — you don’t run a dedicated wire from every house in Body to every factory in Powertrain.

Mnemonic: Group by function: all body stuff together, all powertrain stuff together — like departments in a company.

Think About It

Your HVAC controls are slow to respond after a software update to the infotainment system. In a domain architecture, where do you look?

Reveal Answer

Start on the cross-domain path, not the HVAC hardware: Body DCU (HVAC logic on local CAN/LIN) → Ethernet/SOME/IP or gateway forwarding → Cockpit DCU → VHAL → HMI app. The IVI update likely broke service subscriptions, signal mappings, or VHAL property IDs — not the body domain firmware. Confirm the body bus still shows normal HVAC frames before touching the infotainment stack.

Network Topology: Ethernet Outside, CAN Inside

Domain architecture introduces a two-tier network:

Tier 1: Automotive Ethernet Backbone (Between Domains)

• 100BASE-T1 / 1000BASE-T1 single-pair Ethernet
• Carries high-bandwidth data: camera streams, OTA payloads, diagnostic bulk transfer
• Protocols: SOME/IP, DoIP (Diagnostics over IP), AVB/TSN for time-sensitive streams
• Connected through a central gateway or Ethernet switch

Tier 2: CAN/LIN/FlexRay (Within Domains)

• Legacy ECUs and smart actuators still connect locally
• Domain controller acts as bus master and signal aggregator
• Publishes consolidated signals to the Ethernet backbone

flowchart TB
    subgraph Vehicle["Domain-Based E/E Architecture"]
        CGW["Central Gateway<br/>Ethernet Switch + Router"]

        subgraph PT["Powertrain Domain"]
            DCU_PT["Powertrain DCU"]
            PT_CAN["CAN / CAN FD"]
            DCU_PT --- PT_CAN
        end

        subgraph Body["Body Domain"]
            DCU_Body["Body DCU"]
            Body_LIN["CAN / LIN"]
            DCU_Body --- Body_LIN
        end

        subgraph Chassis["Chassis Domain"]
            DCU_Chassis["Chassis DCU"]
            Chassis_CAN["CAN / FlexRay"]
            DCU_Chassis --- Chassis_CAN
        end

        subgraph ADAS["ADAS Domain"]
            DCU_ADAS["ADAS DCU"]
            ADAS_ETH["Ethernet + CAN"]
            DCU_ADAS --- ADAS_ETH
        end

        subgraph IVI["Infotainment / Cockpit Domain"]
            DCU_IVI["Cockpit DCU<br/>SA8155P / SA8295P<br/>QNX + AAOS"]
            IVI_IO["USB · Display · Audio"]
            DCU_IVI --- IVI_IO
        end

        CGW <-->|"Automotive Ethernet<br/>SOME/IP · DoIP"| PT
        CGW <-->|"Automotive Ethernet"| Body
        CGW <-->|"Automotive Ethernet"| Chassis
        CGW <-->|"Automotive Ethernet"| ADAS
        CGW <-->|"Automotive Ethernet"| IVI
    end

Why Domains Won (For Now)

Domain consolidation delivered real wins without requiring a full vehicle redesign:

Benefit	How
Fewer ECUs	70+ → 25–40 (domain DCUs + remaining satellites)
Higher bandwidth	Ethernet enables camera data, OTA, connected services
Software scale	Cockpit DCU runs full OS stacks (Linux, QNX, Android)
Supplier model preserved	Each domain can still be a different Tier-1 (Bosch chassis, Harman/Visteon cockpit)
Incremental migration	OEMs consolidated one domain at a time over model years

This Is Where Most Cars Are TODAY

If you’re working on a 2020–2026 production vehicle with a Qualcomm cockpit platform, you’re almost certainly in a domain-based architecture:

• Your SA8155P/SA8295P is the infotainment/cockpit domain controller
• QNX runs cluster and safety-adjacent functions in a VM
• AAOS runs the center stack and apps
• Vehicle speed, gear position, and telltales arrive via SOME/IP or gateway-routed CAN signals converted to Ethernet
• Body and chassis functions still live in their own domain DCUs, reached through the central gateway

The domain model is the current steady state. Not the past, not the far future.

Where You'll See This

Domain architecture shows up constantly in your workflow:

• Vehicle property APIs in AAOS (e.g., CarPropertyManager): abstracted signals that originated in another domain’s CAN bus
• SOME/IP service discovery logs: your cockpit domain subscribing to powertrain or body services
• DoIP routing during diagnostics: the gateway forwarding UDS requests to the correct domain DCU
• Hypervisor VM layout: QNX and AAOS sharing one cockpit DCU, not separate ECUs
• Ethernet packet captures between domains when signals are missing or stale

When debugging “IVI doesn’t show vehicle speed,” trace the path: Chassis/Powertrain CAN → Domain DCU → Ethernet/SOME/IP → Gateway → Cockpit DCU → VHAL → App.

AUTOSAR Adaptive vs Classic in Domain Controllers

AUTOSAR Classic still runs on many domain satellite nodes and some DCUs (especially powertrain/chassis MCUs). AUTOSAR Adaptive targets high-performance DCUs running POSIX OS (Linux/QNX) with service-oriented communication over SOME/IP. Your cockpit stack may mix both: Classic AUTOSAR on a safety MCU within the ADAS domain, Adaptive services on the infotainment SoC. The domain controller is the natural home for Adaptive. It has the compute headroom Classic ECUs never had.

Connect the Dots

Module 0 mapped the SoC city inside your chip. This page maps the vehicle city at the network level. Your cockpit SoC is one district’s city hall. Module 2.3 (Zonal) reorganizes the same functions by physical location instead of function type. Module 2.4 (Centralized) pushes compute even further, but domain architecture is the bridge most OEMs are standing on today.

What to remember

1. Domain-based = group by function into ~5 DCUs: powertrain, body, chassis, ADAS, infotainment.
2. Ethernet backbone between domains, CAN/LIN within domains: two-tier networking.
3. Central gateway routes cross-domain traffic (SOME/IP, DoIP, signal forwarding).
4. Most production vehicles today, including your Qualcomm cockpit platform, use this model.

Check Your Understanding

1. In a domain-based architecture, how is compute primarily organized?

Recall

A. In a single centralized HPC with no local domain controllers at allB. By functional area: powertrain, body, chassis, ADAS, and infotainmentC. One dedicated ECU per feature with zero consolidation across functionsD. By physical location in the vehicle such as front-left and rear-right zones

2. What network topology is typical BETWEEN domains in a domain-based architecture?

Applied

A. FlexRay dual-channel links between every pair of domain controllersB. Automotive Ethernet backbone carrying SOME/IP services and DoIPC. Direct CAN wiring from every domain controller to every other oneD. LIN bus used exclusively for all cross-domain inter-DCU traffic

3. Where does your Qualcomm SA8155P/SA8295P fit in a domain-based architecture?

Recall

A. It runs ABS firmware exclusively for chassis safety domain logicB. It acts as a zonal I/O controller for the front-left vehicle cornerC. It serves as the infotainment and cockpit domain controller SoCD. It completely replaces the central gateway ECU in the architecture

4. HVAC controls are slow to respond after an infotainment software update, but the HVAC hardware worked fine before. In a domain-based architecture, where should you investigate first?

Applied

A. Cross-domain path: body CAN → DCU → Ethernet/SOME/IP → cockpit → VHALB. Replace the wiper motor — it shares LIN with the HVAC blower nodeC. Reflash every powertrain ECU — engine RPM directly affects cabin tempD. Disable Automotive Ethernet — domain architectures only use CAN buses

5. A colleague says: 'Our vehicle has 1000BASE-T1 Ethernet, so we must be zonal.' What is the best correction?

Applied

A. Correct — the presence of Ethernet always indicates zonal architectureB. Incorrect — domain architectures adopted Ethernet before zonal emergedC. Correct — the terms zonal and domain are completely interchangeableD. Incorrect — 1000BASE-T1 is only used for OTA payload delivery to ECUs

6. Vehicle speed displays as stale on the cluster after a SOME/IP service registry change, but a CAN logger on the chassis domain bus shows valid speed frames. What cross-domain path failure is most likely?

Synthesis

Connects to: Module 3 — Signals to Services

A. The cockpit SoC replaced all domain controllers in a single model yearB. The LIN bus exceeded its 20 kbps maximum specification on that segmentC. Chassis DCU→Ethernet/SOME/IP→cockpit subscription path broke mid-chainD. The chassis ABS ECU lost its ASIL-D certification and shut itself down

Further Reading

• Bosch Mobility — Domain Computer — Bosch’s domain controller product line consolidates powertrain, body, and ADAS functions — a concrete example of the five-domain model described on this page.
• Continental Automotive — Vehicle Architecture and Networking — Continental’s architecture resources cover domain controller integration, Automotive Ethernet backbones, and cross-domain communication patterns.
• AUTOSAR Adaptive Platform — Service-Oriented Architecture — Official Adaptive platform spec where high-performance domain controllers run ara::com services over SOME/IP on POSIX OS (Linux/QNX).
• OPEN Alliance — Automotive Ethernet Specifications — The industry consortium defining 100/1000BASE-T1 single-pair Ethernet physical layer used as the inter-domain backbone in domain-based architectures.
• Qualcomm — Snapdragon Digital Chassis and Cockpit Platforms — Product documentation for the SA8155P/SA8295P cockpit domain controllers referenced as the infotainment DCU in this module.
• Vector — Automotive Ethernet and SOME/IP — Protocol-level guide to the Ethernet + SOME/IP + DoIP stack that connects domain controllers across the vehicle backbone.
• IEEE 802.1 — Time-Sensitive Networking (TSN) — TSN standards (802.1AS, 802.1Qbv) increasingly used on domain Ethernet backbones for deterministic cross-domain traffic like camera streams and safety data.
• NXP — S32 Platform for Domain and Zone Controllers — NXP’s domain controller reference designs showing multi-core MCU/SoC consolidation for powertrain, body, and chassis domains.