Domain-Based: Grouping by Function

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 urban planning by district. This page covers the architecture you’re most likely working in right now, and the bus topology behind your daily QNX/AAOS debugging.

Common Gotcha

“Our car uses Ethernet, so it’s zonal” is a common assumption, and it’s often wrong. 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).

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.

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?

A. By physical location in the vehicle (front-left, rear-right)B. By functional area (powertrain, body, chassis, ADAS, infotainment)C. In a single centralized HPC with no local controllersD. One ECU per feature with no consolidation

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

A. LIN bus onlyB. Automotive Ethernet with protocols like SOME/IP and DoIPC. FlexRay exclusivelyD. Direct CAN wiring from every domain to every other domain

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

A. It replaces the central gateway ECUB. It serves as the infotainment/cockpit domain controllerC. It is a zonal controller for the front-left vehicle cornerD. It runs only the ABS firmware