Automotive ECU (body / chassis class)

A modern car has 50–150 ECUs. The flashy ones are the infotainment head unit (a Cortex-A Linux box) and the ADAS controller (Cortex-A + ML accelerators). The interesting ones — and the most numerous — are the body-control modules, BMS, chassis, brake, transmission, and engine controllers. These are safety-rated real-time systems running on Cortex-R or, increasingly, on safety-qualified Cortex-M variants.

At a glance

What "safety-rated" means in practice

A typical brake-control or steering ECU has to detect any single hardware fault and fail safe within 100 ms (the fault tolerant time interval, or FTTI). Mechanisms used in combination:

• Dual-core lockstep — two cores execute the same instructions; a comparator faults on mismatch. See Lockstep & ASIL.
• ECC SECDED on every RAM, every flash bank, every TCM, every bus interface.
• Memory protection unit (MPU) isolating ASIL partitions from QM partitions.
• Hardware watchdog windowed (catches "stuck" and "running too fast").
• Clock supervision — separate oscillator monitors the main clock.
• Voltage supervision — multiple comparators trip on out-of-spec rails.
• Built-in self-test (BIST) on boot, and optionally periodically while running.
• Plausibility checks in software — sensor outputs cross-checked against models.

The ECU you'll write firmware for typically reports an FMEDA (Failure Modes, Effects, and Diagnostic Analysis) document showing which random faults each mechanism catches and how that combines to claim ASIL-D coverage.

Block diagram

The CAN-FD bus

Almost every actuator and sensor in the car talks to its ECU over CAN-FD (the modern CAN, see CAN). A typical body-control bus:

  500 kbps arbitration · 2 Mbps data phase
 
  ECU             Function
  ─────────────────────────────────────────────
  BCM             body control (this ECU)
  DCM             driver door module
  PCM             passenger door module
  HVAC            climate control
  LCM             lighting control
  RCM             restraint control (airbag)
  WHEEL           steering-wheel buttons
  ...

Messages have fixed IDs and fixed dispatch tables. The ECU's network database (DBC file) defines:

• Which message IDs it transmits and at what cycle time (1 ms to 1000 ms).
• Which message IDs it receives and what action to take.
• Signal-level encoding (bit positions, scale, offset, units).

AUTOSAR's COM stack consumes these DBCs and generates the dispatch tables; you write only the application logic.

AUTOSAR Classic — the dominant software architecture

Almost every ASIL-rated ECU runs AUTOSAR Classic (CP), a layered architecture mandating:

   ┌──────────────────────────────────────┐
   │  Application Layer                    │  ← your code (SWCs)
   │   ┌──────────────────────────────┐    │
   │   │ Runnable: lambda(input, dt)  │    │
   │   └──────────────────────────────┘    │
   ├──────────────────────────────────────┤
   │  RTE (Runtime Environment)            │  ← generated glue
   ├──────────────────────────────────────┤
   │  Services (COM, NM, OS, DEM, DCM)     │
   ├──────────────────────────────────────┤
   │  ECU Abstraction                      │
   ├──────────────────────────────────────┤
   │  MCAL (microcontroller abstraction)   │  ← vendor-provided
   ├──────────────────────────────────────┤
   │  Hardware (MCU + drivers)             │
   └──────────────────────────────────────┘

Your application is a collection of Software Components (SWCs) with ports. The RTE is auto-generated from a configuration tool (DaVinci Configurator, EB tresos) and handles all inter-SWC communication. The OS is an OSEK/AUTOSAR-compliant scheduler with tasks, alarms, and resources — usually qualified to ASIL-D.

Writing AUTOSAR is unlike anything in consumer embedded. You spend more time in configuration GUIs than in C code, and a "release" involves regenerating tens of MBs of code from XML.

Cybersecurity (ISO 21434 + UNECE R155)

As of 2024, every new car sold in the EU must comply with UNECE R155 (cybersecurity management). The ECU side of this includes:

• Secure boot — every boot stage signed and verified. Cortex-R52's PACBTI + TrustZone-R help.
• Secure flashing — only signed firmware images accepted; rollback protection.
• HSM (Hardware Security Module) — separate cryptographic processor (often EVITA Full spec — a dedicated coprocessor with its own RAM/keys).
• Authenticated CAN — newer message specs include CMAC tags to prevent message injection.
• Intrusion detection — logging of anomalous message patterns; reported via DEM (Diagnostic Event Manager).

Compared to consumer IoT, automotive cybersecurity is much more codified, audited, and enforced.

Real ECU examples (publicly disclosed)

Note the shift: traditional ECUs use Infineon TriCore or Renesas RH850 (non-ARM proprietary cores). The newer "zonal" and "software-defined vehicle" architectures are converging on NXP S32G3 and NXP S32K3 which are ARM Cortex-R52 + Cortex-A53 combos.

ARM is currently a minority share of safety automotive but the market is moving in its direction.

Tooling reality check

Writing automotive firmware is very different from hobby/consumer embedded:

• Compiler must be certified — TI Code Composer with QualNet, IAR Functional Safety, Green Hills MULTI, Wind River Diab. GCC/LLVM is used (under packaging like AdaCore GNATPro) but less common.
• Build is hours, not seconds — full AUTOSAR builds with code generation take 30+ minutes; CI runs across hundreds of variants.
• Tools cost money — Vector CANoe (CAN simulation), DaVinci (AUTOSAR config), ETAS INCA (calibration): tens of thousands per seat.
• Changes are slow — adding a CAN signal involves DBC update, RTE regen, code change, calibration update, signoff. Days, not hours.

See also

• Cortex-R overview — what makes Cortex-R different.
• Lockstep & ASIL — the safety architecture.
• CAN — the dominant in-vehicle bus.
• TrustZone — for HSM and secure boot.
• TI — Hercules family for ASIL-D.
• Infineon — AURIX (TriCore, not ARM, but you'll meet it).
• AUTOSAR.org (external) — the standards body.