ECU Basics & Vehicle Networks

TL;DR

A modern vehicle contains 70–100+ ECUs (Electronic Control Units), small embedded computers each responsible for one domain (brakes, doors, climate, battery). They communicate over vehicle networks: CAN (legacy workhorse, 1 Mbps), CAN FD (64-byte payloads, up to 8 Mbps data phase), LIN (cheap master-slave, 20 kbps for mirrors and seat heaters), FlexRay (deterministic but declining), and Automotive Ethernet (100 Mbps–10 Gbps backbone replacing everything). Your cockpit SoC sits at the center, bridging these worlds through QNX gateway services.

Every signal your AAOS app displays (vehicle speed, fuel level, door status) traveled across one of these networks before VHAL ever saw it. Understanding the bus layer is how you stop guessing and start debugging.

What Is an ECU?

An ECU (Electronic Control Unit) is a dedicated embedded computer that reads sensors, runs control algorithms, and commands actuators for a specific vehicle function.

Examples you interact with indirectly every day:

ECU	Function	Typical Network
Engine Control Module (ECM)	Fuel injection, ignition timing	CAN / CAN FD
Brake Control Module (BCM/ESP)	ABS, stability control, brake pressure	CAN (often ASIL-D)
Body Control Module	Door locks, interior lights, wipers	CAN + LIN
Battery Management System (BMS)	Cell monitoring, charging limits	CAN FD / Ethernet
Gateway ECU	Routes messages between network domains	Multi-bus
Cockpit Domain Controller	Your QNX + AAOS platform	Ethernet + CAN

Each ECU runs firmware, often AUTOSAR Classic on an MCU (Module 4), with its own boot image, calibration data, and diagnostic address.

Why 70–100+ ECUs?

In a distributed architecture (Module 2), OEMs placed one ECU per function for good reasons:

• Supplier modularity: Bosch ships the ABS ECU, Continental ships the gateway, you integrate both
• Fault isolation: a bug in the seat heater ECU doesn’t crash the engine controller
• Incremental cost: add a feature, add an ECU, no redesign of existing modules
• Safety partitioning: brake ECU certified to ASIL-D stays physically separate from infotainment

The downside? Integration hell. Signal routing, gateway tables, version compatibility, and diagnostic addressing across 100 ECUs is why automotive integration teams exist. SDV architecture (centralized compute) is partly a reaction to this ECU sprawl.

Mental Model

Think of ECUs as specialist employees in a company. The brake ECU is the safety officer — conservative, certified, never takes shortcuts. The body ECU is facilities management — doors, lights, climate. Your cockpit SoC is the executive office — it doesn’t do the specialist work, but it reads everyone’s reports and presents them to the driver (and to your Android apps via VHAL).

CAN Bus: The Legacy Workhorse

CAN (Controller Area Network), standardized as ISO 11898, has been the dominant automotive bus since the 1990s. If a vehicle network had a default choice for 30 years, it was CAN.

How CAN Frames Work

CAN is a multi-master, broadcast bus: any node can transmit, and all nodes receive every frame.

A standard CAN 2.0 frame contains:

Field	Purpose
Arbitration ID (11 or 29 bits)	Message priority and identity (lower ID wins)
Data Length Code (DLC)	0–8 bytes of payload
Data	The actual signal bytes
CRC	Error detection
ACK	Receivers acknowledge successful receipt

Arbitration is CAN’s elegant trick: if two nodes transmit simultaneously, they compare ID bits bit-by-bit. The node with the lower ID continues; the loser backs off and retries. No central scheduler needed. Priority is wired into the ID assignment.

CAN Limits

• Speed: Classic CAN tops out at 1 Mbps
• Payload: Maximum 8 bytes per frame
• Topology: Bus (linear with stubs), not a star
• Cost: Very low; CAN transceivers cost cents

Eight bytes sounds tiny, but engineers pack them efficiently. A vehicle speed signal might be 2 bytes inside a periodic frame broadcast at 10 ms intervals. Hundreds of signals share the bus through DBC files (signal databases) that define bit layouts.

Common Gotcha

CAN IDs are not IP addresses. You can’t “ping” a CAN node. An ID identifies a message, not a device. One ECU transmits many messages with different IDs. Diagnostic communication (UDS over ISO-TP) uses separate ID pairs for request/response, a topic for Module 9.

CAN FD: Bigger and Faster

CAN FD (CAN with Flexible Data-Rate), standardized as ISO 11898-1:2015, extends classic CAN for modern bandwidth needs.

Feature	Classic CAN	CAN FD
Max payload	8 bytes	64 bytes
Arbitration phase	Up to 1 Mbps	Up to 1 Mbps (backward compatible)
Data phase	Same as arbitration	Up to 8 Mbps
Backward compatible	—	CAN FD nodes can coexist on a bus with classic CAN nodes (with caveats)

CAN FD is the upgrade path for ECUs that need more data (ADAS sensor summaries, BMS cell reports, firmware transfer during flashing) without jumping to Ethernet.

LIN Bus: The Cheap Helper

LIN (Local Interconnect Network) is a master-slave serial bus for low-bandwidth, non-critical peripherals.

Property	Value
Speed	Up to 20 kbps
Topology	Single master (usually body ECU), up to 15 slaves
Cost	Extremely low; simpler transceivers than CAN
Typical use	Mirrors, seat heaters, window switches, rain sensors, ambient lighting

LIN slaves are dumb; they respond when polled by the master. No arbitration, no multi-master complexity. The body ECU acts as LIN master and translates relevant data onto CAN for the rest of the vehicle.

FlexRay: Deterministic but Dying

FlexRay was designed for deterministic, fault-tolerant communication, primarily for chassis and powertrain systems that needed guaranteed timing (e.g., steer-by-wire prototypes, active suspension).

Property	Value
Speed	Up to 10 Mbps
Topology	Dual-channel bus (redundancy)
Determinism	Static time slots (guaranteed latency)
Cost	High; expensive transceivers and tooling
Status	Declining; largely replaced by Automotive Ethernet in new designs

FlexRay solved a real problem (deterministic timing), but Ethernet with TSN (Time-Sensitive Networking) now offers similar guarantees at lower cost. You’ll encounter FlexRay in older premium platforms but rarely in new SDV designs.

Automotive Ethernet: The Backbone

Automotive Ethernet (IEEE 802.3 variants over single-pair or multi-pair cabling) is the backbone replacement for CAN/FlexRay in modern and next-gen architectures. 100BASE-T1 runs at 100 Mbps over a single twisted pair, typical for ADAS sensor links and domain controller interconnect. 1000BASE-T1 scales to 1 Gbps on the same single-pair cabling, handling high-bandwidth camera data and cockpit domain controller links. 2.5/5/10GBASE-T1 pushes 2.5–10 Gbps over single or multi-pair cabling for next-gen SDV central compute and multi-camera fusion.

Why Ethernet wins:

• Bandwidth: camera streams alone need hundreds of Mbps
• Familiarity: IP, TCP/UDP, VLANs; skills transfer from IT networking
• Service-oriented middleware: SOME/IP, DDS, gRPC ride on Ethernet (Module 3)
• Switching: star topology with switches replaces bus contention

Your cockpit SoC has Automotive Ethernet ports that connect to the vehicle backbone. QNX runs gateway services that bridge Ethernet ↔ CAN for signals that legacy ECUs still speak.

SOME/IP, DoIP, and the Ethernet Stack

Raw Ethernet is just frames. Automotive stacks add layers: VLANs segment traffic (ADAS vs diagnostics vs IVI), SOME/IP provides service discovery and RPC over UDP/TCP, DoIP (Diagnostics over IP, ISO 13400) replaces CAN-based UDS for fast flashing and diagnostics. Your QNX gateway may terminate DoIP on Ethernet and translate to CAN-UDS for legacy ECUs, a common integration pattern.

Comparison Table

Property	CAN / CAN FD	LIN	FlexRay	Automotive Ethernet
Speed	1 Mbps / up to 8 Mbps (FD data)	20 kbps	10 Mbps	100 Mbps – 10 Gbps
Payload	8 / 64 bytes	8 bytes	254 bytes	1500+ bytes (MTU)
Topology	Bus	Bus (master-slave)	Dual bus	Star (switched)
Access method	Multi-master, CSMA/CA	Master-slave	Time-triggered + event	Switched (CSMA/CD)
Cost	Low	Very low	High	Medium
Determinism	Best-effort	Best-effort	Guaranteed slots	TSN extensions
Typical use	Powertrain, chassis, body signals	Mirrors, seats, switches	Legacy chassis (declining)	Cameras, ADAS, domain controllers, diagnostics
Your daily touch	VHAL signal sources, gateway logs	Indirect (via body ECU)	Rare (legacy platforms)	Inter-domain communication, DoIP flashing

Vehicle Network Topology

Modern vehicles use a hybrid topology: not one bus, but a hierarchy.

flowchart TB
    subgraph COCKPIT["Cockpit Domain Controller (Your Platform)"]
        QNX["QNX Gateway Services"]
        AAOS["AAOS / VHAL"]
    end

    subgraph ETH["Automotive Ethernet Backbone (100M–1G+)"]
        ADAS["ADAS Domain Controller"]
        TELE["Telematics Unit"]
        CAM["Camera ECUs"]
    end

    subgraph CAN_HIGH["CAN / CAN FD Buses"]
        ECM["Engine / Motor ECU"]
        BMS["Battery Management"]
        ESP["Brake / ESP ECU"]
        GW["Central Gateway ECU"]
    end

    subgraph LIN_BUSES["LIN Buses"]
        BODY["Body Control Module (Master)"]
        MIRROR["Mirror Modules"]
        SEAT["Seat Heater Modules"]
        WINDOW["Window Switches"]
    end

    QNX <-->|"Ethernet"| ETH
    QNX <-->|"CAN / CAN FD"| GW
    AAOS --> QNX
    GW <-->|"CAN"| ECM
    GW <-->|"CAN FD"| BMS
    GW <-->|"CAN"| ESP
    GW <-->|"CAN"| BODY
    BODY <-->|"LIN 20kbps"| MIRROR
    BODY <-->|"LIN"| SEAT
    BODY <-->|"LIN"| WINDOW
    ADAS <-->|"Ethernet"| CAM
    TELE <-->|"Ethernet"| QNX

Reading the diagram: Your platform sits at the convergence point. Ethernet carries high-bandwidth data (cameras, ADAS). CAN/CAN FD carries control signals from powertrain and chassis ECUs. LIN handles cheap peripherals off the body module. The gateway ECU (sometimes integrated into your cockpit controller) translates between domains.

Connect the Dots

Module 0 mapped the inside of the SoC. This page maps the outside: how that SoC connects to the rest of the vehicle. Module 2 shows how E/E architecture evolved from “one ECU per function on CAN” to “domain controllers on Ethernet.” Module 3 covers SOME/IP, the service layer that runs on top of this Ethernet backbone. Module 6’s VHAL is the API that exposes CAN/Ethernet signals to your Android apps.

What to remember

1. An ECU is a dedicated embedded computer; modern vehicles have 70–100+ of them.
2. CAN is the legacy multi-master bus (1 Mbps, 8-byte frames); CAN FD extends to 64 bytes and 8 Mbps.
3. LIN is cheap master-slave for simple peripherals; FlexRay is deterministic but declining.
4. Automotive Ethernet is the modern backbone; your cockpit SoC bridges it to legacy CAN via QNX gateway services.

Where You'll See This

You’ll encounter vehicle networks constantly:

• CAN signal debugging: DBC files define which bits mean “vehicle speed.” Gateway misconfiguration shows up as stale or zero values in VHAL.
• DoIP flashing: Ethernet-based diagnostics for fast ECU reprogramming during bench testing.
• Gateway logs on QNX: canfd / socketcan traces showing frame IDs, timing, and errors.
• Network architecture reviews: which signals move from CAN to Ethernet in the next platform generation.

When a tester reports “speedometer stuck at zero but nav GPS speed works,” think CAN signal path (cluster gets speed from chassis ECU via gateway), not Android GPS.

Check Your Understanding

1. Why does CAN use arbitration based on message ID rather than a central bus master?

A. To reduce wiring cost by eliminating the master nodeB. To allow multi-master operation where the highest-priority message (lowest ID) wins without a schedulerC. Because LIN already uses a master-slave model and CAN needed to differD. To support Ethernet-compatible addressing

2. A seat heater and power mirror are most likely connected via which network?

A. Automotive Ethernet (1000BASE-T1)B. FlexRay dual-channel busC. LIN (master-slave, ~20 kbps)D. CAN FD at 8 Mbps

3. Your cockpit SoC receives vehicle speed from a chassis ECU. In a modern architecture, the most likely path is:

A. Chassis ECU → CAN/CAN FD → Gateway → Automotive Ethernet → QNX → VHAL → AAOSB. Chassis ECU → LIN → directly to Android kernelC. Chassis ECU → FlexRay → AMSS modem → AAOSD. Chassis ECU → Bluetooth → AAOS app