ECU Basics & Vehicle Networks

Intermediate10 min read

Assumes: 0.1 Anatomy of an SoC

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. Think of it as automotive plumbing: you don’t need to be a plumber to use a faucet, but when the water stops flowing, you’d better know which pipe to check. This page is your pipe map.

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
ESP / Brake Control Module	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, ASIL-D certified, never takes shortcuts, and definitely not invited to happy hour. The body ECU is facilities management — doors, lights, climate, the unglamorous work that everyone notices only when it breaks. 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). When something goes wrong, the executive office gets blamed first.

Mnemonic: CAN = everyone talks, everyone listens (office open floor plan). LIN = one boss, many workers (call center). Ethernet = the highway (move fast, carry lots).

Think About It

Two ECUs on the same CAN bus send at the exact same time. What happens?

Reveal Answer

CAN arbitration resolves the collision without corrupting either frame. Both nodes drive the bus simultaneously during the arbitration ID field; at each bit, a dominant 0 wins over recessive 1. The node with the lower arbitration ID continues transmitting; the loser detects the mismatch, backs off, and retries after the winner finishes. No central master is needed — priority is wired into ID assignment.

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

Beginner thinks CAN IDs work like IP addresses — you can “ping” a node by its ID. If only. CAN would be much easier to debug.

Reality: a CAN ID identifies a message, not a device. One ECU transmits many messages with different IDs. There’s no “hey node 42, are you alive?” built in. Diagnostic communication (UDS over ISO-TP) uses separate ID pairs for request/response — a topic for Module 9.

Common Gotcha

Beginner thinks automotive Ethernet is just regular Ethernet with different connectors.

Reality: different PHY (100BASE-T1 single-pair vs four-pair), different connectors (HSD vs RJ45), different wake/sleep (partial networking, sleep/wake-on-link), and stricter EMC requirements (CISPR 25). You can’t plug your laptop into the vehicle backbone and expect it to behave like office Ethernet.

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 (full-duplex)
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.

• Module 0.7 (Physical Interfaces): The physical layer — transceivers, termination resistors, and connectors — that CAN and Ethernet ride on is covered in Module 0.7.

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. A seat heater and power mirror are most likely connected via which network?

Recall

A. FlexRay dual-channel redundant bus providing deterministic schedulingB. LIN — low-cost master-slave bus at ~20 kbps for simple body peripheralsC. CAN FD at 8 Mbps data phase for high-throughput sensor aggregationD. Automotive Ethernet (1000BASE-T1) with TCP/IP for bandwidth headroom

2. Approximately how many ECUs does a modern premium vehicle typically contain, and why did OEMs historically accept that count?

Recall

A. 1–2 ECUs; automakers fully centralized compute starting in the early 1990sB. 70–100+ ECUs; one per function enabled supplier modularity and fault isolationC. 200–300 ECUs; regulations mandate a separate processor for every sensor inputD. 5–10 ECUs; consolidation was preferred because fewer nodes improve fuel economy

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

Applied

A. To support Ethernet-compatible IP addressing on the serial bus layerB. Because LIN already occupied the master-slave model in the spec familyC. To allow multi-master access where the lowest ID wins bus priorityD. To reduce total wiring cost by completely eliminating the master node

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

Applied

A. Chassis ECU → Bluetooth Classic → AAOS navigation app listenerB. Chassis ECU → FlexRay → AMSS modem bridge → AAOS speed serviceC. Chassis ECU → CAN/CAN FD → Gateway → Ethernet → QNX → VHAL → AAOSD. Chassis ECU → LIN sub-bus → Android kernel CAN socket directly

5. A BMS ECU needs to report 48 bytes of per-cell voltage data at 10 ms intervals. Classic CAN (8-byte max) would require six frames per cycle. Most practical bus upgrade without jumping to full Automotive Ethernet?

Applied

A. Bluetooth Low Energy — wireless link offloads cell data to a gatewayB. LIN at 20 kbps — simpler transceivers handle bulk telemetry dataC. FlexRay — time-triggered schedule mandated for all battery systemsD. CAN FD — 64-byte payloads at up to 8 Mbps data phase fit the need

6. During bench testing, you flash an ADAS controller via DoIP on Ethernet in 90 seconds. A legacy body ECU on CAN still requires 45 minutes via ISO-TP. Flashing the body ECU via DoIP fails with timeout, but ADAS DoIP works. Most likely root cause?

Synthesis

Connects to: Module 8 — Build, Flash & Update

A. Body ECU CAN transceiver hardware is fundamentally Ethernet-incompatibleB. Gateway DoIP-to-CAN-UDS routing is misconfigured for the body ECU addressC. Body-domain ECUs lack flash memory regions and cannot accept any updatesD. CAN bus speed at 1 Mbps is unconditionally too slow for DoIP forwarding

Further Reading

• Bosch Semiconductors — CAN IP Modules — Bosch CAN controller IP documentation tracing the protocol lineage that ISO 11898 standardized for automotive vehicle networks.
• CAN in Automation (CiA) — CAN Knowledge — Industry consortium resources on CAN, CAN FD, and CiA device profiles used across automotive ECUs.
• ISO 11898-1 — Road vehicles — Controller area network (CAN) — International standard for CAN data link layer and physical layer requirements.
• LIN Consortium — LIN Specification Package — Official LIN bus specification for low-cost master-slave peripheral networks in body electronics.
• OPEN Alliance — Automotive Ethernet Specifications — Industry specs for 100BASE-T1 and 1000BASE-T1 single-pair Ethernet replacing CAN/FlexRay backbones.
• AUTOSAR — Classic Platform Communication Stack — Overview of AUTOSAR COM, PDU routing, and gateway patterns used on ECUs connected to vehicle buses.
• ISO 13400 — Road vehicles — Diagnostic communication over Internet Protocol (DoIP) — Ethernet-based diagnostics standard for fast ECU flashing and gateway translation from CAN-UDS.
• Vector Informatik — CAN Database (DBC) Format — Practical reference for DBC signal databases that define how CAN frame bits map to vehicle signals like speed and gear state.