The problem
A damaged harness, a bad connector or a misbehaving ECU can create CAN errors in an EV. Error confinement is meant to isolate a faulty node, but the same mechanism can be abused to force a healthy node off the bus. Engineers need measured data on detection time, recovery time and the effect on other nodes.
Objectives
- Monitor transmit and receive error counters and error states in real time
- Inject physical-layer faults and controlled bit errors at the hardware level
- Measure time to error-passive, time to bus-off and recovery time under different recovery policies
- Propose and test a detection rule for deliberate bus-off attacks
What you need
From the EV Embedded Development Kit
- STM32F103C8T6 microcontroller unit (Arm Cortex-M3)
- CAN bus interface
- General output relay (NO / COM / NC)
- Serial UART interface
- 16×2 LCD
- RGB LEDs and a buzzer
Software
- STM32CubeIDE with HAL CAN and GPIO
- Embedded C
- Python with pandas and matplotlib for state timelines
- Proteus (optional) for the injector timing logic
Extra parts
- A second kit — Used as the fault injector, with its CAN transmit pin driven as a GPIO, and as a victim or observer node.
- USB-CAN adapter — An independent bus monitor that logs error frames and traffic from outside the nodes under test.
- Oscilloscope or logic analyser — To see injected bits and error flags at the bit level and verify injection timing.
Key concepts
- Error counters
- Every node keeps a transmit error counter (TEC) and receive error counter (REC); the STM32 exposes them in the CAN_ESR register along with the last error code.
- Error states
- A node is error-active below 128, error-passive when a counter exceeds 127, and bus-off when TEC exceeds 255, at which point it stops transmitting.
- Bus-off recovery
- A bus-off node may rejoin after detecting 128 occurrences of 11 consecutive recessive bits; on bxCAN this is automatic if ABOM is set, otherwise software must re-initialise.
- Bus-off attack
- An attacker that overwrites recessive bits in a victim's frames causes bit errors that raise the victim's TEC until it goes bus-off, silencing it.
Step-by-step guide
- 1
Plan faults and safety
List the faults to study: missing termination, a CANH-CANL short, an open wire, a node with the wrong bit rate, and targeted bit errors on chosen identifiers. Everything here is low voltage, but still put a series resistor in any fault path and connect the injector only to the CAN lines. For each fault, write the expected TEC and REC behaviour from the standard's rules, so every experiment tests a prediction. Agree the wiring diagram and fault list with your supervisor before building.
Checkpoint: A fault list with expected state transitions and a wiring diagram approved by your supervisor.
- 2
Set up the nodes and monitoring
Configure two or three nodes at 125 kbit/s to start with, because a slower bit rate makes bit-level injection easier. Enable notifications for error warning, error passive, bus-off and last error code, and in HAL_CAN_ErrorCallback read TEC, REC and LEC from the CAN->ESR register. Stream counter samples every millisecond over UART with a timer timestamp, and show the error state on the LCD and RGB LED. Run the bus healthy for an hour first to prove the baseline is clean.
Checkpoint: A healthy bus shows TEC and REC at zero for an hour and the monitor logs steady traffic.
- 3
Inject physical-layer faults with the relay
Wire the kit's general output relay so that a GPIO can either remove one termination resistor or bridge CANH and CANL through a small resistor. Drive the relay with timed pulses from a timer and log the exact command time, allowing for the relay's mechanical delay, which you should measure on the oscilloscope. Observe the effect on all nodes and on the USB-CAN monitor. Repeat each fault many times so you can report the spread of detection and recovery times.
Checkpoint: Removing termination or bridging the lines produces repeatable error-frame bursts, logged with fault start times.
- 4
Build the bit-level injector
On the second kit, configure the CAN TX pin as a push-pull GPIO and the RX pin as an EXTI input, so the MCU drives the transceiver directly. Detect the falling edge of start of frame, then use a timer started from that edge to count bit times and drive a dominant bit at a chosen position. Sample the identifier bits first and inject only into frames with the target identifier. Allow for stuff bits when counting positions, or the injected bit will land in the wrong place.
Checkpoint: The oscilloscope shows the injected dominant bit landing in the intended bit position within a fraction of a bit time.
- 5
Measure error escalation
Inject an error into every frame of a victim identifier. Each transmit error adds 8 to the victim's TEC and each successful frame subtracts 1, so record how many frames it takes to reach error-passive at 128 and bus-off beyond 255. Repeat with injection into every second, fourth and tenth frame. Compare the measured frame counts with counts predicted from the rules, and explain any difference, such as the special cases in the standard for errors during error flags.
Checkpoint: Measured frames-to-bus-off match the rule-based prediction for each injection rate.
- 6
Compare recovery policies
Test three recovery policies on the victim: automatic bus-off management with the ABOM bit set, manual re-initialisation after a fixed delay, and manual recovery with exponential back-off. For each, measure time from bus-off to the first successful transmission and count how often the victim is knocked off again while the attack continues. Discuss the trade-off between availability, where quick recovery is better, and resilience under attack, where back-off reduces the time the bus is disturbed.
Checkpoint: A table of recovery times and re-bus-off counts for each policy.
- 7
Measure effects on other nodes
While one node is under attack, measure the latency and loss of every other node's messages and watch their REC values. Check whether error frames and retransmissions push healthy nodes into error-passive, and whether error-passive nodes add longer recovery sequences that delay traffic further. Compare each bystander's latency distribution with the fault-free baseline from the earlier soak test, and state clearly whether the attack affects only its target or the whole bus.
Checkpoint: Latency and loss of bystander messages are logged and compared with the fault-free baseline.
- 8
Design a detection rule
Propose a detector that runs on each node. For example, many bit errors on the node's own transmitted identifiers within a short window, while frames from other nodes are received cleanly, point to targeted injection rather than a wiring fault, which would affect all traffic. Implement it in firmware using the LEC field and your own transmit records, set a diagnostic fault code, and alert with buzzer and LED. Keep the rule simple enough to explain in a viva.
Checkpoint: The detector flags targeted injection and does not flag the physical-layer faults in your test set.
- 9
Evaluate the detector
Build a test matrix of attacks at several injection rates and target identifiers, plus each physical-layer fault from the earlier steps, with many repeats of each. Run the proposed detector and a simple baseline that only thresholds TEC. Report detection rate, false alarms and time to detection for both, as a confusion matrix and a distribution plot. Discuss the cases where the detector failed and what extra information would have caught them.
Checkpoint: A confusion matrix and detection-time distribution for the proposed rule and the baseline.
- 10
Report and reproducibility
Document the injector design and its measured timing accuracy, the full test matrix, the results and the limits of the study, such as a single bit rate, a small bus and one controller type. Package the injector firmware, monitoring firmware and analysis scripts with instructions, so another lab with two kits and a USB-CAN adapter could rerun the experiments. Include state-timeline figures that show TEC, REC and error state against time for representative runs.
Checkpoint: A thesis chapter with state-timeline figures, recovery comparison and detector evaluation.
Testing & validation
- Injection accuracy verified on an oscilloscope
- Frames-to-error-passive and frames-to-bus-off compared with rule-based predictions
- Recovery time and re-bus-off counts per recovery policy
- Detector confusion matrix against physical faults and attacks
Expected results
A low-cost CAN fault-injection testbed with bit-level timing, measured error-confinement behaviour that is checked against the standard, a comparison of recovery policies, and a tested rule to tell targeted bus-off attacks from wiring faults.
Research angle for your PhD
Research questions: how closely do real controllers follow error-confinement rules under targeted and random faults, which recovery policy balances availability against repeated bus-off, and can a node-local detector distinguish attacks from physical faults? Metrics: frames and time to bus-off, recovery time, bystander latency, detection rate, false-alarm rate. Baselines: automatic recovery, counter-threshold detection. A publishable result combines a reproducible, cheap injector with measured data and a detector evaluated across a clearly defined fault and attack set.
Take it further
- Raise the bit rate to 500 kbit/s and characterise injector timing limits
- Add a CAN controller with different recovery behaviour, through a USB-CAN adapter, to compare implementations
- Combine detection with a gateway that isolates the attacking segment
Viva and review questions
How much does TEC change per error and per success?
A transmit error normally adds 8 and each successful transmission subtracts 1, so a node with errors in every frame reaches bus-off after about 32 attempts.
What does bus-off mean for the node?
Its TEC exceeded 255 and it must stop transmitting until it sees 128 occurrences of 11 recessive bits and is allowed to rejoin.
Why inject at 125 kbit/s first?
Each bit lasts 8 microseconds, which gives a GPIO and timer on the STM32 enough margin to place a dominant bit accurately.
How do you tell an attack from a wiring fault?
A wiring fault affects all identifiers, while targeted injection hits one node's frames while others pass cleanly, so error distribution by identifier separates them.