CAN Bus:
Principles
and practice
Fundamentals of automotive communication and interactive test examples.
ExploreHow do you test and validate automotive networks?
Anıl Mirap · 29 October 2026CAN Bus enables electronic control units in a vehicle to exchange data over a shared communication bus. This article explains the network structure, message interpretation and the effects of communication faults on system behaviour through a vehicle-speed example. Interactive applications illustrate the concepts, while supplementary technical notes examine testing and validation methods in greater detail.
Four chapters progressing from fundamental concepts to testing methods, with supplementary technical notes.In-vehicle
communication.
A vehicle has electronic control units for systems such as the engine, brakes and instrument display. These embedded systems, known as electronic control units (ECUs), exchange the data required for their functions over a network.
How does speed reach the display?
CAN stands for Controller Area Network. It uses a shared communication bus: a connected unit broadcasts speed as a message, and units such as the instrument display receive and use that information. This reduces the need for a separate point-to-point connection for every piece of information.
The diagram represents two control units connected by the CAN_H and CAN_L conductors. The transmission animation illustrates data transfer. The transport, interpretation and function tabs explain three stages of the communication process.
Transport: The message is broadcast on the shared bus. An acknowledgement, or ACK, indicates that at least one unit received it correctly.
Technical notes: engineering rationale and implementation
Seeing a frame is different from verifying a function
A trace filled with continuously arriving frames is reassuring. It does not establish that the receiving application uses the right information. A CAN acknowledgement indicates that at least one node received the frame correctly; it does not prove acceptance by the intended application or completion of the requested action. [1]
Consider vehicle speed transmitted to a display. The frame can be present while an incorrect scale, outdated signal definition, frozen value or delayed application task produces the wrong behaviour. I would separate three questions: Was the data transported? Was it interpreted correctly? Did the function respond correctly and on time?
The speed signal and test case in this article are fictional examples designed to make the method concrete. Numerical acceptance criteria are illustrative rather than taken from a manufacturer's specification; approved requirements govern real projects.
Start with a requirement, before choosing a tool
‘The speed message must work’ is not a testable requirement. Define the source ECU, receiver, network segment, message and signal definitions, valid range, update behaviour, latency limit and fault response. Record DBC, hardware, software and calibration versions at the start. Otherwise, two tests with the same name may concern different systems.
In our fictional example, an 8-byte Classical CAN message with identifier 0x180 carries vehicle speed every 20 ms. Its first two bytes contain an unsigned little-endian speed field with a scale of 0.01 km/h and zero offset. A separate field carries validity information. These definitions are not a real vehicle's message map.
Our illustrative acceptance criterion is this: after 100 ms without new valid data since the last valid reception, the receiver must mark speed unavailable within a further 10 ms. Recovery requires three consecutive valid messages. Define the event that starts the 100 ms timer, behaviour exactly at the threshold, and the observation point used to measure the additional response time.
Message structure
and interpretation.
A message contains fields such as an identifier and data. The identifier helps receivers recognise the message. Bytes in the data field carry numbers. A byte contains 8 bits; a bit is the smallest unit of information and takes the value 0 or 1. Classical CAN carries up to 8 data bytes in one message.
Experiment: decode a CAN message
Changing the byte values and byte order illustrates the conversion from raw data to a physical value.
(B₀ + B₁ × 256) × 0.01
Unsigned · 16 bit · offset 0A DBC file defines the signals contained in a message. It specifies which bytes encode speed and how the raw numerical value is converted into km/h. In this experiment, 10 and 27 are hexadecimal numbers. In the chosen order they represent the raw value 10000; multiplying by 0.01 gives 100 km/h. Changing the byte order illustrates how the interpretation rule affects the result.
Why are there resistors at the ends of the cable?
Termination resistors help reduce signal reflections from cable ends. This model uses 120 Ω at each end; together in parallel they measure 60 Ω. Changing the resistor count illustrates the parallel-equivalent relationship.
Model of a powered-down conventional high-speed CAN segment. A 60 Ω reading alone does not establish signal integrity.
Technical notes: engineering rationale and implementation
The physical layer: Interpreting termination resistance
Begin with the correct segment, wiring, power supply, connectors and topology. On a conventional, powered-down high-speed CAN segment with a 120 Ω termination at each end, approximately 60 Ω is expected between CAN_H and CAN_L. Do not transfer this rule directly to low-speed CAN or different termination architectures. Follow the manufacturer's service method and measure resistance with power removed. [2]
A reading near 120 Ω can be consistent with a missing termination; about 40 Ω can indicate an additional parallel termination. Neither result establishes the root cause on its own. The measurement location, disconnected nodes and segment architecture matter. A 60 Ω reading also does not establish signal integrity under operating load.
Use an oscilloscope to examine the differential waveform, reflections, edge distortion and changes associated with the fault. Judge the waveform against the relevant transceiver, bitrate and physical-layer requirements, rather than a single ideal-looking screenshot. If moving a connector increases errors, correlate that event with timestamped traffic and error records.
Converting bytes into physical values with a DBC
A DBC defines signal bit position, length, byte order, signedness, scale and offset. The basic conversion is physical value = raw value × scale + offset. A correct message identifier therefore does not establish correct signal interpretation. [3]
For our example, first bytes 0x10 and 0x27 represent the little-endian raw value 0x2710, or 10000. With the 0.01 scale, this is 100 km/h. Reversing the interpretation produces 0x1027, or 4135, and a displayed value of 41.35 km/h. Perfectly regular traffic can coexist with a serious application error.
Test zero, valid lower and upper boundaries, adjacent representable values and defined invalid codes separately. Reserved values must not be treated as real speeds. Check receiver filtering, message length and multiplexor selection where applicable. If both the test decoder and the ECU use the same incorrect definition, their agreement is not independent verification. Manually check at least one known byte example.
Communication loss
and system response.
How long should a receiver trust the last value it saw? This question turns a communication test into a system-behaviour test.
The time control allows comparison of message loss, invalid data and recovery after three valid messages.
Experiment: test the timeout
Last valid reception at t = 0. Scrub through time to inspect the receiver's decision.
Last valid data age: 120 ms.
Messages stop after t = 0. The receiver becomes unavailable at 100 ms.
Illustrative transmission period
Timeout since last valid data
Consecutive valid receptions for recovery
How should the display handle missing information?
A communication test examines normal information flow and interruptions under controlled conditions. Our example expects a message every 20 ms, or 50 times a second. After 100 ms without valid information, the receiver marks the data unavailable. This waiting limit is called a timeout. Waiting for three valid messages after communication returns is our example recovery rule; actual vehicle timings and responses depend on requirements.
Technical notes: engineering rationale and implementation
Timing: an average period can conceal the worst delay
Period describes the interval between transmissions; jitter describes variation in that interval. End-to-end latency covers the path from the source event to the receiver's use of the result. Reporting these as one metric obscures the problem. The sender task, queue, arbitration, gateway and receiver task can each contribute delay.
A nominal 20 ms message can average 20 ms over a long recording while suffering a critical delay during a short traffic burst. Measure maximum interval, distribution, consecutive missed updates and functional response alongside averages. Percentiles are useful, but a hard deadline violation cannot be averaged away.
When comparing timestamps from separate devices, document clock synchronisation and measurement uncertainty. A CAN trace alone cannot reveal the receiving application's response; an appropriate observation signal, ECU measurement or external output recording is needed. Vary traffic priority and burst patterns as well as load percentage. Do not assume a universal load threshold below which every network is safe.
Fault injection tests the response, not just the failure
Fault injection should challenge a specific requirement, rather than produce arbitrary traffic. Suppressing a target message, introducing a delay, sending a defined invalid value and freezing data represent different fault classes. Each scenario needs a precondition, controlled fault, observable response and cleanup step.
Invalid data is not the same as missing data. If invalid messages arrive every 20 ms, a timeout that watches only packet arrival may be reset indefinitely. Does the acceptance criterion refer to the last message or the last valid message? This distinction belongs at the centre of the test design.
An incorrect application CRC in the payload is also different from a CAN protocol CRC fault on the wire. A normal CAN interface generally generates protocol fields itself. Bit-level corruption or electrical short-circuit simulation requires suitable fault-injection hardware. Perform these activities on an authorised, protected test setup, rather than on a moving vehicle.
Verify error passive, bus-off and recovery separately
CAN controllers use error counters to limit fault propagation. Error passive and bus-off are different states; a bus-off node does not participate in normal communication. A missing message in a log is not proof of bus-off. Record controller state and available error counters independently. [4]
Observe fault onset, loss of communication, the application's response, network re-entry after fault removal and functional recovery as separate events. A node reappearing in a trace does not by itself establish that the application has safely returned to normal operation.
Recovery strategy depends on project requirements. An ECU that repeatedly resets may briefly return and then fail again; a short observation window could misclassify this as success. Include repeated fault-recovery cycles, power-cycle behaviour, diagnostic records, and checks for jumps or stale data when the function resumes.
E2E protection: Assessing data freshness and consistency
Depending on the selected profile, application-level E2E protection combines mechanisms such as counters, Data IDs and CRCs. Repetition, sequence errors and corruption require assessment beyond CAN frame checks. Timeout handling must be evaluated together with the profile and calling architecture. The AUTOSAR 4.3.1 document cited here is a conceptual reference, not a replacement for the release applicable to a project. [5]
A frozen counter is different from a constant physical signal. A stationary vehicle can legitimately report zero speed indefinitely; lack of value change alone does not establish a failed sensor. Keep sample freshness, protection status and application handling separate. A CRC is also not a cryptographic mechanism for authenticating the sender.
Worked case: what should a display do when speed data disappears?
Use a source simulator, the display ECU under test and an observation interface. First transmit 100 km/h every 20 ms. Establish that the receiver reaches its valid state and uses the correct value. Do not proceed with fault injection if this initial condition cannot be demonstrated.
Mark the last valid reception as t0 and stop only message 0x180 while other traffic continues. Under our illustrative requirement, the unavailable state must appear no earlier than t0 + 100 ms and no later than t0 + 110 ms. This window follows from our hypothetical criterion; it is not a universal automotive limit. Include measurement resolution and clock-alignment error in the verdict.
Next, send a single valid message and become silent again. The display must not return to normal because three consecutive valid messages have not yet arrived. Then test recovery using three regular valid messages. The specification must also define whether an intervening invalid message resets this sequence. Repeat around the timeout boundary, with no data ever received after startup, and under different traffic conditions.
Test design
and verification.
Testing compares expected behaviour with the observed result. Verification checks whether specified requirements are met; validation examines suitability for intended use. For a speed display, this includes the right value, timely updates and an understandable response to interruptions.
- 01
Requirement
Which behaviour, under which condition, within what time?
- 02
Controlled test
Use the same version, initial state and input to create comparable conditions.
- 03
Observation
Correlate traffic with application response on one timeline.
- 04
Result and record
Compare the expected and observed results alongside the relevant records.
CAN communication involves message transmission, interpretation by the receiver and use by the application. Test design connects the expected behaviour at each stage with observable acceptance criteria.
Technical notes: engineering rationale and implementation
MIL, SIL, HIL and vehicle tests answer different questions
Model-in-the-loop can challenge behavioural logic early. Software-in-the-loop examines software behaviour in a simulated environment. Hardware-in-the-loop exercises a real ECU with controlled environmental inputs, making hardware-software interactions observable. Each setup has limits in model fidelity, timing and accessible fault types.
A test without real transceivers and cabling cannot verify physical reflections. A simulation without the target ECU cannot fully establish scheduling on its processor. Passing HIL also does not establish validation across all vehicle operating conditions. The plan should connect every claim to an appropriate environment and state the remaining uncertainty.
Platforms such as CANoe support communication analysis, simulation and automated testing. [7] Tool selection does not replace coverage design. A smaller interface and script may be sufficient for a simple bench test, while multiple ECUs, diagnostics and precise timing can require a different setup. The criterion is repeatable observation of the required behaviour, not the product name.
What changes in a CAN FD test plan?
Classical CAN carries up to 8 data bytes; CAN FD supports up to 64. CAN FD supports separate bit timing for arbitration and data phases. Record nominal bitrate, data bitrate and bit-rate switching for the actual configuration. Knowing only the nominal bitrate is insufficient. [6]
Extend the plan to signals beyond byte eight, length encoding, padding, selected DLC values and receiver buffer behaviour. Exercise traffic patterns that mix maximum-length payloads with short frames. Higher data bitrate does not automatically reduce every function's latency: payload distribution and timing need to be measured again.
On mixed networks, establish that every relevant controller and tool supports the frame types used. A CAN FD label alone does not guarantee the selected speed across every topology. Where a gateway performs conversion, include the transfer of data length, freshness and fault status to the other network.
Reproducing test conditions through automation
A useful automated test establishes its initial state, verifies preconditions, applies a stimulus, collects timestamped observations, makes a rule-based decision and cleans up. A diagnostic state or simulator left active by one test must not contaminate the next. If traffic is randomised, preserve the seed and configuration.
Prefer relevant event triggers over sleeping for a fixed interval and reading a display. If the test setup failed to transmit its stimulus, classify that as an infrastructure problem rather than an ECU failure. Mixing failed, blocked and invalid executions into one red status makes corrective decisions harder.
Regression scope can follow the changed signal, its receivers and shared network effects, while retaining an agreed baseline for critical fault responses. Test count alone is not a success metric. Show which requirement was demonstrated, under which conditions, and with which evidence.
Preparing reviewable test evidence
A completion record should identify the requirement, test case, hardware, software, calibration, network database, connections, tool settings, measurement conditions, expected outcome and actual result. Correlate raw traffic, relevant scope captures, application state and diagnostic records to the same event. Remove personal or confidential vehicle data from shared examples.
Verification asks whether specified requirements are met. Validation asks whether those requirements and the resulting behaviour are suitable for the intended use. A display that meets its written specification yet misleads the driver with stale speed data may expose a requirement problem as well as a testing concern.
Report excluded conditions, open defects, deviations and residual risks alongside passing tests. A successful CAN test alone does not establish functional-safety compliance or whole-vehicle validation. A defensible engineering conclusion keeps the scope of its claim aligned with the evidence supporting it.
Inspect the example test matrix
| Scenario | Stimulus | Observation | Expected result | Risk addressed |
|---|---|---|---|---|
| Normal communication | 100 km/h every 20 ms | Decoded speed and validity | Correct value in a valid state | Wrong scale / byte order |
| Target-message loss | Suppress only 0x180 | Time since last valid reception | Unavailable in 100–110 ms in this example | Accepting stale data |
| Invalid data stream | Invalid signal every 20 ms | Valid-data timeout | Invalid packets do not renew freshness | Incorrect timeout reset |
| Partial recovery | One valid message, then silence | Transition to normal | Wait until three-message condition is met | Premature recovery |
| Traffic burst | Controlled priority and load pattern | Maximum delay and deadline | Approved timing requirements remain satisfied | A violation hidden by averages |
References and further reading.
These experiments are deterministic educational models for a fictional speed message. They contain no real vehicle data or ECU measurements. Approved project requirements and applicable standards govern real testing.
- [1] KvaserCAN Frame Types — acknowledgement and frame semantics
- [2] KvaserHow to test if your CAN termination works correctly
- [3] CSS ElectronicsCAN DBC File Explained — signal decoding
- [4] KvaserCAN Error Handling — detection and error confinement
- [5] AUTOSARE2E Communication Protection Library — CP 4.3.1 (conceptual reference)
- [6] Linux Kernel DocumentationSocketCAN — CAN FD driver support and bit timing
- [7] VectorCANoe — communication analysis, simulation and automated testing
Understanding CAN starts with following the journey of a message. Examining transport, interpretation and application behaviour together makes the purpose of automotive network testing and validation clearer.
Back to more articles