Car electronics basics
You test screens, but the screens only show what the rest of the car tells them. This chapter explains how a car's computers talk to each other, in the simplest possible way.
- A car has many small computers called ECUs.
- They talk to each other on a shared line called CAN.
- The screen shows only what it hears on CAN (speed, temperature, warnings).
- The DBC file is the dictionary that explains every message.
- On a test bench, a PC with CANoe pretends to be the rest of the car.
Think of it like a WhatsApp group. Every ECU posts messages in the group. The cluster reads the messages it needs and ignores the rest.
See it as a picture: Speed path · CAN group · DBC formula · Test bench · Try the CANoe lab
ECU: the small computers inside a car
A modern car is not one computer. It is 50 to 100 small computers, each doing one job. Each one is called an ECU (Electronic Control Unit). One controls the engine, one the brakes, one the airbag, one the screens, and so on.
| ECU | What it does | Why you care as an HMI tester |
|---|---|---|
| Instrument cluster (IPC) | Runs the display behind the steering wheel | You test it: speed, telltales, warnings |
| Head unit (IVI) | Runs the centre screen: media, phone, navigation, settings | You test it |
| Body control module (BCM) | Lights, doors, wipers, often the outside temperature | Sends many signals the screens display (door open, lights on) |
| Engine / motor control (ECM) | Controls the engine or electric motor | Sends RPM, engine warnings |
| ABS / ESC | Brakes and stability control | Sends wheel speed; its faults become red/amber telltales |
| Airbag (SRS) | Airbags and seatbelt sensors | Seatbelt warning, airbag telltale |
| Gateway | Passes messages between different networks, like a router | If it filters a message, the screen never gets it |
| Telematics (TCU) | Mobile internet, emergency call, online services | Connectivity icons, online features |
| ADAS ECU (camera/radar) | Driver assistance: lane keeping, adaptive cruise | Its warnings appear on the cluster and HUD |
| BMS (in electric cars) | Battery management | Battery %, range, charging screens |
How ECUs talk: the car's networks
ECUs are connected by wires that form networks, also called buses. Different jobs need different speeds, so a car has several kinds.
| Network | Speed (rough) | Used for | Easy way to remember |
|---|---|---|---|
| CAN (Controller Area Network) | up to 1 Mbit/s, often 500 kbit/s | Most normal messages: speed, gear, temperature, warnings | The main road of the car |
| CAN FD (Flexible Data-rate) | 2–5 Mbit/s data phase | Same as CAN but more data per message (up to 64 bytes) | A wider main road |
| LIN (Local Interconnect Network) | up to 20 kbit/s | Simple, cheap parts: window switches, steering-wheel buttons, mirrors | A small side street |
| FlexRay | 10 Mbit/s | Timing-critical systems (older premium cars) | A railway with a strict timetable |
| Automotive Ethernet | 100 Mbit/s – 1 Gbit/s+ | Cameras, displays, big data, software updates, diagnostics (DoIP) | The motorway |
CAN in detail (the most important network)
Imagine a WhatsApp group where every ECU is a member. Every message is seen by everyone. Each ECU only reads the messages it needs and ignores the rest. Messages don't have a sender name; they have a number, the message ID. Everyone knows "message 0x3A5 is the temperature message".
What is inside one CAN message (frame)
- ID: 11 bits (standard) or 29 bits (extended). Written in hex, e.g.
0x3A5. The ID is also the priority: if two ECUs talk at the same time, the lower ID wins and goes first. That's why brake messages have low IDs. - Data: up to 8 bytes in classic CAN (64 in CAN FD). Several signals are packed into these bytes.
- Cycle time: most messages repeat at a fixed rhythm, e.g. every 100 ms. Some messages are sent only when something happens (event messages, e.g. a button press).
- Two wires: CAN-High and CAN-Low. The bus needs a 120 Ω resistor at each end (bench tip: a missing resistor = strange errors).
Hex numbers in 60 seconds
Car tools show numbers in hexadecimal ("hex"), a way of counting with 16 digits: 0–9 and then A=10, B=11, C=12, D=13, E=14, F=15. The prefix 0x means "this is hex".
| Hex | How to calculate | Normal number |
|---|---|---|
0x0A | 0×16 + 10 | 10 |
0x5A | 5×16 + 10 | 90 |
0xC8 | 12×16 + 8 | 200 |
0xFF | 15×16 + 15 | 255 (the biggest value of one byte) |
0x1388 | two bytes: 19×256 + 136 | 5000 |
You never need to do this in your head at work; tools convert it. But knowing the idea helps you read traces and explain values in bug reports.
Signals and the DBC file
The data bytes are just numbers. The DBC file is the dictionary that says what they mean: "byte 0 of message 0x3A5 is the outside temperature; multiply by 0.5, subtract 40, the unit is °C". One value like this is a signal.
For every signal, the DBC defines:
| Field | Meaning | Example (Outside_Temp) |
|---|---|---|
| Name | Signal name | Outside_Temp |
| Message / ID | Which message it is in | Ambient_Info, 0x3A5 |
| Start bit, length | Where in the data bytes, how many bits | bit 0, 8 bits (= byte 0) |
| Byte order | Intel (little-endian) or Motorola (big-endian) | Intel |
| Factor (scale) | Multiply the raw number by this | 0.5 |
| Offset | Then add this | −40 |
| Min / Max | Valid range | −40 … 85 °C |
| Unit | Unit of the real value | °C |
| Value table | Special raw values with names | 0xFF = "SNA" (Signal Not Available) |
| Receivers | Which ECUs read it | Cluster, HeadUnit, Climate |
The only formula you need
real value = raw value × factor + offset
raw value = (real value − offset) ÷ factorTrace shows data byte 0 = 0x5A = 90. Real temperature = 90 × 0.5 + (−40) = 5.0 °C. This is how you prove in a bug report "the signal really was 5.0 °C".
Another: speed raw 0x1388 = 5000, factor 0.01, offset 0 → 50.00 km/h.
Try it: CAN signal decoder
Type a raw hex value, the factor and the offset from the DBC. Or use a preset.
Three signal situations you must always test
| Situation | What it means | What the screen should do (typical) |
|---|---|---|
| Valid value | A normal number inside the allowed range | Show it correctly |
| SNA / invalid | "Signal Not Available": the sender says "my sensor is broken or I have no value yet" (often all bits set, like 0xFF) | Show dashes (“--”) or a fault warning. Never show a fake number like 87.5 °C (that is 0xFF decoded blindly) |
| Timeout | The message stops arriving (cable cut, sender ECU dead or asleep) | After the defined time (e.g. 5 missed cycles), treat it as a fault. Never freeze on the last value. |
Safety-relevant messages often carry an alive counter (a number that increases 0,1,2…15 with each message) and a checksum/CRC. This is called E2E protection (end-to-end). If the counter stops or the checksum is wrong, the receiver must ignore the message and show a fault. Testers inject wrong counters on purpose to test this.
From the sensor to the screen
Let's follow the outside temperature on its journey. At every step something can go wrong. That's why, when a screen shows a wrong value, you check the trace (what was on the bus) to find out where the problem is.
"When the screen shows a wrong value, I first check the CAN trace. If the correct value arrives on the bus but the screen is wrong, the problem is in the HMI software. If the value on the bus is already wrong, the problem is in the sending ECU, and I assign the ticket to that component."
Power and ignition: KL30, KL15 and power modes
Many bugs appear when the car is switched on, off, or wakes up. So you must understand power.
| Term | Meaning | Easy way to remember |
|---|---|---|
| KL30 | Permanent battery power (+12 V), always on even when the car is parked | "30 is always there" |
| KL15 | Ignition power: on only when the ignition is on | "15 = key turned" |
| KL31 | Ground (0 V, minus) | The return wire |
| KL R / ACC | Accessory (radio) position: some things work, engine off | "Listening to radio in the parking lot" |
"KL" comes from the German word Klemme (terminal). German car makers use these names everywhere.
Power modes (the car's "states")
- Sleep / Off: car locked, ECUs sleeping to save battery.
- Wake-up: door unlocked; ECUs wake and the network starts.
- Accessory: some screens on, engine off.
- Ignition ON: all systems on; the cluster does its bulb check (all telltales light briefly).
- Crank: starting the engine; battery voltage dips (to around 6–9 V for a moment).
- Run / Drive.
- Ignition OFF → after-run → sleep: screens may stay on a short time, then everything sleeps together (this "sleep together" coordination is called network management).
What to test around power
- Ignition cycle: off → on. Does Bluetooth reconnect? Does the last music source resume? Are settings kept?
- Sleep / wake: after sleeping, does the screen wake correctly, or freeze/black screen?
- Low voltage: normal battery is about 12–14.5 V. Test at low voltage (e.g. 9 V) and during a crank pulse. The screen may reset, but must recover correctly.
- Boot time: time from ignition on until the screen is usable, and until the rear camera is visible.
- Power loss (KL30 off): odometer, clock, settings must survive.
Where you test: SIL, HIL and the real car
| Level | What it is | Pros / cons |
|---|---|---|
| SIL (Software-in-the-Loop) | The software runs on a PC, with a simulated screen. No real hardware. | Fast and cheap; misses hardware problems |
| HIL (Hardware-in-the-Loop) | The real ECU hardware (head unit, cluster) on a bench; a PC simulates the rest of the car | Realistic and controllable. This is where you'll work most |
| Vehicle | A real prototype car | Most realistic; expensive, slow, less controllable |
What a HIL test bench looks like
Bench parts and what they are for
- ECUs under test: head unit and cluster (the real hardware, called the "target").
- Test PC with simulation (CANoe), automation (e.g. Robot Framework) and log tools.
- CAN/LIN/Ethernet interface: the box that connects the PC to the car network (e.g. Vector VN1630, VN5620).
- Programmable power supply: provides 12 V and can simulate low voltage.
- Relay box: switches KL15 (ignition) and KL30 by software, so tests can do ignition cycles.
- Peripherals: test phones (iPhone and Android), USB sticks with test music, GPS simulator, antenna, speakers/microphone.
- Camera / video grabber: records the screen for evidence and for automated image checks.
- Remote access: for remote benches — remote desktop, VPN, webcam, remote power switch.
"A HIL bench with the real head unit and cluster, a programmable power supply with a relay box for KL15 and KL30, a Vector CAN interface and a PC with CANoe for signal simulation and trace recording. Phones and USB sticks for media and Bluetooth tests, and a camera for evidence. [We also had remote benches that we accessed through remote desktop, with a webcam and remote power control.]"
Diagnostics: DTCs and UDS (intermediate)
Every ECU keeps a list of problems it noticed, like a notebook of errors. Each problem is a DTC (Diagnostic Trouble Code). A diagnostic tool can read and clear this list, read the software version, and even install new software. The language these tools speak is called UDS.
DTCs
- Format like
P0301,B1234,C0035,U0155. The letter shows the area: P = powertrain, B = body, C = chassis, U = network/communication. - Example:
U0155= "lost communication with instrument panel cluster". - Why you care: when you test a sensor failure, the expected result often includes "DTC is stored". After the test you clear DTCs so the next test starts clean.
UDS services you might hear about
| Service ID | Name | What it does (plain words) |
|---|---|---|
0x10 | Diagnostic Session Control | Switch the ECU into a special mode (default, extended, programming) |
0x11 | ECU Reset | Restart the ECU |
0x14 | Clear Diagnostic Information | Delete stored DTCs |
0x19 | Read DTC Information | Read the list of DTCs |
0x22 | Read Data By Identifier | Read a value, e.g. software version, serial number |
0x2E | Write Data By Identifier | Write a value, e.g. variant coding |
0x27 | Security Access | Unlock protected functions with a key |
0x31 | Routine Control | Start a routine, e.g. self-test |
0x34 / 0x36 / 0x37 | Request Download / Transfer Data / Transfer Exit | Used to flash new software |
0x3E | Tester Present | "I'm still here" message to keep the session open |
A positive answer has the service ID + 0x40 (0x22 → answer 0x62). A negative answer starts with 0x7F and a reason code, e.g. 0x7F 22 31 = "request out of range". Diagnostics over Ethernet is called DoIP; the socket in every car is the OBD port.
For a 1–2 year HMI test role, you only need to know what DTCs are, that you read and clear them with a diagnostic tool, and roughly what UDS is. Don't go deeper unless asked.
Variants, samples and software versions
- Variant: the same car model is sold in many versions: EU/US/China, left/right-hand drive, basic/premium, with or without HUD. Software checks variant coding (a configuration stored in the ECU) to know which features to show. A bug may appear in only one variant, so always write the variant in bug reports.
- Hardware samples: prototypes mature in stages: A-sample (early, rough), B-sample (functional), C-sample (near production), D-sample (production tools). Write the sample in bug reports too.
- Software version: every build has a version number (e.g. 24.3.1 or a long ID). You find it in an engineering/hidden menu, through diagnostics (UDS 0x22) or in the flashing tool. Always write it in bug reports and test results.
- SOP (Start of Production): the date the factory starts building the car. Everything important must be fixed before SOP. After SOP, updates happen by workshop or OTA (over-the-air, like a phone update).
Quick answers for the interview
What is an ECU?
An Electronic Control Unit: a small embedded computer in the car that controls one function, like the engine, brakes, airbag or the cluster display. A modern car has 50–100 ECUs that talk over networks like CAN.
What is CAN?
Controller Area Network, the most common in-car network. ECUs send short messages with an ID and up to 8 bytes of data (64 with CAN FD). Every ECU sees all messages and picks the ones it needs. Lower IDs have higher priority. Signals inside the messages are described in a DBC file.
What is the difference between CAN and LIN?
CAN is faster (up to 1 Mbit/s) and used for most ECU communication; any node can send. LIN is slow (up to 20 kbit/s) and cheap, used for simple parts like switches and mirrors, with one master that controls the slaves.
What is HIL testing?
Hardware-in-the-Loop: the real ECU hardware is tested on a bench while a simulator provides all the signals from the rest of the car. It's realistic, repeatable, and you can create situations that are dangerous or hard in a real car, like sensor failures.
What is a DBC file?
A database file that describes the CAN messages and signals: ID, position in the data, factor, offset, range, unit and special values. Tools like CANoe use it to show real values like "5.0 °C" instead of raw bytes.
What is signal simulation and why do we need it?
On a test bench the real car isn't there, so a tool like CANoe sends the signals the other ECUs would send: speed, gear, temperature, warnings. This lets us test any situation on demand, including boundaries and failures, in a repeatable way.