Learning roadmap

From the whole vehicle
down to a single pin

Every level answers the question the level above it raises. A car is a network — of what? Controllers. Made of what? A board. Running what? Nothing here appears before the thing that motivates it.

Part IThe descent

Nine levels, one continuous zoom

L0

Vehicle

What is a modern vehicle, really?

The car as one distributed computer

Start here because every later question is a subdivision of this one. A vehicle is not a machine with software added: it is a distributed real-time system whose nodes happen to be bolted to a chassis. Understanding that a door lock, a brake intervention and a lane-keep correction are all messages on a network is the shift that makes the rest of the domain legible.

Covered

  • E/E architecture
  • Distributed vs domain vs zonal
  • Power topology
  • Wiring harness
  • Weight, cost and why they drive design

You can then

  • Explain why a vehicle has a hundred computers instead of one
  • Read an architecture diagram and name what each block is for

L1

Domains

A hundred controllers — how are they organised?

How controllers are grouped

Functions cluster for three reasons: they share sensors, they share timing requirements, or they share a safety integrity level. Understanding the grouping explains why a gateway exists at all, and why the move to zonal architectures — grouping by physical location instead of by function — is the biggest structural change the industry has made in twenty years.

Covered

  • Central gateway
  • Domain controllers
  • Zonal architecture
  • Functional partitioning
  • Variant and platform handling
  • Service-oriented architecture

You can then

  • Place an unfamiliar ECU in the right domain and justify it
  • Explain what a gateway does and why it is the security choke point

L2

Networks

They are grouped — how do the groups communicate?

How controllers talk to each other

Each bus exists because the one before it was too slow, too expensive or too unpredictable for some function. CAN gives you arbitration without a master; LIN gives you a node for the price of a transistor; FlexRay gives you determinism; Ethernet gives you bandwidth for cameras. Most production faults live at the seams between them, which is why gateways are where the hard bugs are.

Covered

  • CAN and CAN FD
  • LIN
  • FlexRay
  • Automotive Ethernet
  • SOME/IP
  • DoIP
  • Arbitration and priority
  • Bit timing and sample point
  • Bus load
  • DBC, ARXML, LDF

You can then

  • Decode a CAN frame field by field from a raw trace
  • Choose the right bus for a function and defend the choice
  • Find the failing node in a trace without guessing

L3

The loop

What is happening inside one of those nodes?

What one controller actually does

A sensor turns something physical into a voltage. The ECU turns that voltage into a number, decides it is plausible, computes something, and drives an actuator or puts a message on the bus. A body controller and an ADAS controller differ in the middle step and in almost nothing else. Once this loop is internalised, an unfamiliar ECU stops being mysterious.

Covered

  • Sensors: speed, position, pressure, temperature, current
  • Camera, radar, lidar, ultrasonic
  • Signal conditioning and plausibility
  • Control laws and state machines
  • Actuators: motors, valves, relays, lamps
  • Arbitration between competing requests

You can then

  • Trace one function from sensor pin to actuator pin
  • Say where a fault could be injected at each stage of the loop

L4

The box

What is inside the box that runs the loop?

Opening one ECU

An ECU is a power supply, a microcontroller, some transceivers and a lot of protection. The parts that are not the MCU are the ones that cause the faults nobody can reproduce: a marginal regulator that browns out on cranking, a watchdog that resets during a long interrupt, a transceiver that will not leave standby. Reading a schematic is a software skill in this domain.

Covered

  • Microcontroller
  • System basis chip (SBC)
  • Voltage regulators and power sequencing
  • Bus transceivers
  • Watchdog and reset supervisor
  • Crystal, oscillator and clock tree
  • LED and lamp drivers
  • H-bridges and relay drivers
  • Connectors and pinout
  • EMC filtering, ESD and reverse-polarity protection

You can then

  • Read an ECU schematic and find the pin behind a signal name
  • Explain what an SBC does and why it is not just a regulator
  • Diagnose a reset loop from the hardware side

L5

The chip

And inside the part doing the deciding?

Inside the microcontroller

Automotive microcontrollers are not general-purpose parts. They have lockstep cores because a single core cannot be trusted with a safety function, hardware security modules because keys cannot live in flash, and a peripheral set built around motor control and networking. Knowing what is on the die tells you what the software layers above are actually abstracting.

Covered

  • Cores and lockstep
  • Flash, RAM and NVM emulation
  • Clock sources and PLL
  • Interrupt controller and priorities
  • DMA
  • Timers, PWM and capture
  • ADC and sampling
  • GPIO and alternate functions
  • CAN and Ethernet controllers
  • HSM and secure key storage
  • MPU and memory protection
  • Low-power and wake sources

You can then

  • Configure a peripheral from the reference manual, not from an example
  • Explain what lockstep protects against and what it does not
  • Reason about interrupt latency and priority inversion

L6

On-board buses

The MCU is not alone on the board — how does it reach the rest?

How chips on one board talk

CAN connects ECUs. SPI connects the MCU to the transceiver sitting next to it. They are different problems: one crosses metres of harness through an electrically hostile car, the other crosses two centimetres of PCB. Board-level buses are where an SBC is configured, where an external ADC is read, and where a debugger attaches.

Covered

  • SPI
  • I²C
  • UART
  • SENT
  • PSI5
  • JTAG and SWD
  • Master and slave roles
  • Clock polarity and phase
  • Addressing and bus contention
  • Chip select and framing

You can then

  • Choose between SPI and I²C for a given peripheral and justify it
  • Bring up an unfamiliar chip over SPI from its datasheet alone
  • Say why a board bus is not a vehicle bus

L7

The signal

What is a bus, physically?

Down to voltage and time

Every abstraction above rests here. A frame is a voltage difference sampled at a particular instant; a bit error is a sample taken at the wrong moment or on a line that was not driven cleanly. The engineers who can move between this level and the software are the ones who close the intermittent faults.

Covered

  • Logic levels and differential signalling
  • Rise time and slew rate
  • Sample point and synchronisation
  • Termination and reflections
  • Ground offset
  • Noise, coupling and EMC
  • ESD and transients

You can then

  • Read a bus waveform on a scope and identify a bit error
  • Explain why a bus works on the bench and fails in the vehicle

L8

Instruments

How do you actually see any of this?

What you look at each level with

Tools are taught here rather than first because a tool without a question is just an interface. A bus analyser answers L2 questions, a debugger answers L5 questions, a scope answers L7 questions. Knowing which one to reach for is most of the skill.

Covered

  • CANoe, CANalyzer, Vehicle Spy
  • Wireshark for automotive Ethernet
  • CANape and INCA for calibration
  • Lauterbach TRACE32
  • Logic analyser
  • Oscilloscope
  • DaVinci and EB tresos
  • ODX and OTX tooling

You can then

  • Pick the right instrument for a fault instead of guessing
  • Capture evidence somebody else can act on
Part IIThe climb

Back up through the software

Same ECU, now viewed as software. AUTOSAR only makes sense after the descent, because by then you have seen what it is abstracting.

Startup & bootloader

Secure boot

Reset vector to main(), memory layout, and the flash bootloader that lets an ECU be reprogrammed in the field without a soldering iron.

  • Startup code and linker scripts
  • Memory map and sections
  • Bootloader / application split
  • UDS-based reprogramming
  • Recovery from a failed flash
  • Secure and authenticated boot

Drivers & MCAL

AUTOSAR

Registers wrapped into portable drivers — the layer where the chip stops being visible to everything above it.

  • Port, DIO, ADC, PWM drivers
  • SPI and CAN drivers
  • Configuration versus code
  • Why generated code looks the way it does
  • Vendor integration and ECU abstraction

OS & scheduling

OSEK / AUTOSAR OS

Tasks, priorities and the timing guarantees a control loop depends on.

  • Tasks, events and alarms
  • Pre-emption and priority inversion
  • Cyclic tasks and jitter
  • Interrupts versus tasks
  • Stack sizing and overflow detection

BSW, RTE & components

AUTOSAR Classic

Communication, memory and mode management — plus the RTE that lets application code stop caring where a signal came from.

  • COM stack and PDU routing
  • NVM and the memory stack
  • Mode management and network management
  • Software components, ports, interfaces
  • RTE generation

Application & control

Function

The feature itself: control laws, state machines, arbitration, plausibility.

  • Model-based versus handwritten
  • Fixed-point arithmetic and scaling
  • Calibration, XCP and A2L
  • Diagnosis of your own function
  • Degradation and safe states

Diagnostics

ISO 14229 · SAE J1979

How an ECU explains itself to a tester, a workshop and a regulator, years after it shipped.

  • UDS services and sessions
  • Security access
  • DTCs, freeze frames, ageing
  • Routine control and I/O control
  • OBD monitors and readiness
  • ODX and diagnostic databases
Part IIICutting across every layer

The disciplines

Not extra topics bolted on at the end — each one reappears at every level of the descent, which is how they should be taught.

Cybersecurity, layer by layer

Which surface exists at which layer, and which control answers it. Defence in depth reads as a table because that is what it is.

LayerSurfaceReachControl
Backend & cloudOTA server, fleet APIs, build pipelineRemoteSigning infrastructure, supply-chain integrity
Off-board linkCellular, Wi-Fi, Bluetooth, V2X, key fob RF, TPMSRemoteAuthenticated channels, rolling codes, pairing hygiene
Rich ECUHead-unit apps, media parsers, USB, browserProximitySandboxing, hardened parsers, verified boot
GatewayRouting between domains, DoIP entry pointRemoteFirewall rules, domain isolation, rate limiting
In-vehicle busCAN injection, replay, bus floodingPhysicalSecOC message authentication, intrusion detection
DiagnosticsOBD port, aftermarket dongles, service toolsPhysicalSecurity access, session control, role separation
ECU firmwareFlash extraction, downgrade, debug portsPhysicalSecure boot, JTAG lock, rollback protection
SiliconKey storage, side channel, fault injectionPhysicalHSM, tamper detection, key lifecycle

Functional safety

ISO 26262

Proving a system fails in a way that does not hurt anybody — and having the evidence trail to show it.

  • Hazard analysis and risk assessment, ASIL allocation
  • Safety goals decomposed to software requirements
  • Freedom from interference between mixed-ASIL software
  • Fault injection and diagnostic coverage targets

Cybersecurity

ISO/SAE 21434 · UNECE R155

Type approval now depends on it. Without a certified CSMS a vehicle cannot be sold in the UNECE markets.

  • TARA — threat analysis and risk assessment
  • Secure boot, authenticated diagnostics, key management
  • HSM integration and secure onboard communication
  • CSMS process, evidence and audit readiness

Penetration testing

Authorised engagements

Attacking your own vehicle before somebody else does — on a bench, under a signed scope of work.

  • Bus fuzzing and diagnostic service abuse
  • Firmware extraction and static analysis
  • Wireless surface testing: Bluetooth, Wi-Fi, RF
  • Findings mapped back to the TARA that missed them

AI & machine learning

ISO 21448 (SOTIF)

Perception models that behave in weather, at night, and on the edge cases no requirement anticipated.

  • Sensor fusion across camera, radar and lidar
  • Model deployment to automotive silicon under latency budgets
  • SOTIF: hazards from performance limitation, not from faults
  • Data pipelines, labelling and scenario coverage

Diagnostics

ISO 14229 · SAE J1979

What the technician, the regulator and the flashing tool all depend on, long after the vehicle ships.

  • UDS services, sessions and security access
  • DTC strategy, freeze frames and ageing
  • Flash bootloader design and recovery paths
  • OBD emissions monitors and readiness

End-of-line

Production

The last station before a vehicle leaves the plant, running to a cycle time measured in seconds.

  • EOL test sequences and pass/fail criteria
  • Series flashing and variant coding
  • Line-side tooling and station integration
  • Traceability records for every unit built
Part IVIdea to end of line

How a thought becomes a part number

01

Concept & requirements

A customer wish becomes a specification somebody can be held to. Where most defects are actually created.

02

Architecture & design

Function allocated to ECUs, signals to buses, interfaces frozen so teams can work in parallel.

03

Implementation

Handwritten and generated code, configuration and calibration — against a coding standard and a review gate.

04

Verification ladder

MIL, SIL, PIL, HIL, bench, vehicle. Each rung catches what the one below it cannot see.

05

Validation & release

Does it solve the original problem, in the real world, at temperature — and is the evidence complete.

06

Production & field

Start of production, ramp, field data, OTA updates, and diagnostics that keep working for a decade.

End of line, for one ECU

Bare board to shippable unit, at a cycle time measured in seconds. Rarely taught anywhere — and a large share of graduate roles.

  1. 01

    SMT & reflow

    Components placed and soldered onto the bare PCB

    —

  2. 02

    AOI / X-ray

    Optical and X-ray inspection of joints and placement

    Catches: Tombstones, solder bridges, voids under BGAs

  3. 03

    In-circuit test

    Bed-of-nails test against the netlist

    Catches: Shorts, opens, wrong or missing components

  4. 04

    Bootloader flash

    First code onto a blank part, over JTAG or a programming header

    Catches: Dead or unprogrammable silicon

  5. 05

    Application flash

    Series software over the production bus, using UDS

    Catches: Flash failures, wrong software version

  6. 06

    Variant coding

    Parameter set and calibration written for this exact build

    Catches: Wrong market, wrong feature set

  7. 07

    Functional test

    Stimulate every input, measure every output

    Catches: Driver faults, connector faults, wiring errors

  8. 08

    Diagnostic clear

    Read DTCs, clear them, confirm clean and check readiness

    Catches: Latent faults from earlier stations

  9. 09

    Traceability

    Serial number, software versions and results recorded

    Catches: Nothing — but it is what a recall depends on

Part VBeyond the syllabus

What actually makes a graduate employable

The gaps that show up in interviews and first projects. None of them are a certificate.

Read a trace without guessing

Given 40,000 frames and a complaint, find the failing node. The most testable skill in the domain.

Use a debugger properly

Breakpoints, watchpoints, trace buffers, reading a stack after a hard fault — not printf.

Read a schematic and a datasheet

Find the pin, the register, the erratum. Software engineers who can do this are worth double.

Work the way a supplier works

Version control, review, CI against real targets, and a defect report somebody can act on.

Build something demonstrable

A CAN node on cheap hardware beats any certificate in an interview, because it cannot be faked.

Know which level you are debugging at

Most wasted days are spent looking for a hardware fault in software, or the reverse.

Which instrument answers which question

LevelInstrumentAnswers
L2CANoe / CANalyzerWhat is on the bus, and when?
L2Vehicle SpyMulti-bus capture and replay
L2WiresharkEthernet and SOME/IP traffic
L2Diagnostic tester / ODXWhat does the ECU report?
L3CANape / INCAWhat is the control loop doing internally?
L5Lauterbach TRACE32Where is the code, and how did it get there?
L6Logic analyserIs the SPI transaction well formed?
L7OscilloscopeWhat does the signal actually look like?
StackDaVinci / EB tresosHow is the BSW configured?

Start at the top.
Work down.

The courses follow this order. Everything we publish is free to read, so you can begin before you spend anything.

Browse coursesRead the guides