The problem
Safety-relevant signals such as torque or brake requests pass through software and networks that are not developed to the same safety integrity. Corruption, lost or repeated frames, or frames from the wrong sender could cause hazardous behaviour. AUTOSAR E2E protection adds CRCs, counters and data IDs so the receiver can detect these faults, a standard measure in ISO 26262 safety concepts.
Objectives
- Identify communication faults relevant to a torque request signal.
- Implement E2E protection based on the published AUTOSAR E2E profiles.
- Implement the receiver check and state machine.
- Inject faults systematically and measure detection.
- Evaluate overhead and residual error considerations.
What you need
Tools and toolboxes
- STM32CubeIDE — Sender and receiver E2E library, CAN driver and RTE glue in C.
- AUTOSAR Blockset — The application components that send and receive the torque request through ports.
- Embedded Coder — Generating the application component code.
- Python with python-can — PC node implementing the other end and the fault injector.
- Wireshark — Optional: inspecting captured CAN traffic on Linux with SocketCAN.
From the EV Embedded Development Kit
- STM32F103C8T6 microcontroller unit (Arm Cortex-M3)
- CAN bus interface with screw terminal
- Analog potentiometer input
- 16×2 LCD
- RGB LEDs and a buzzer
- Serial UART interface
Software
- STM32CubeIDE with STM32 HAL
- MATLAB, Simulink, AUTOSAR Blockset and Embedded Coder
- Python 3 with python-can, NumPy and pandas
Extra parts and data
- USB-CAN adapter — The PC acts as the second ECU and as a fault injector on the bus.
- 120-ohm terminating resistor — Termination for the two-node bus if not already present.
Key concepts
- E2E profile
- A defined combination of CRC, counter, data ID and layout specified by AUTOSAR. Smaller profiles use an 8-bit CRC and a 4-bit counter for short CAN frames; larger ones use 16- or 32-bit CRCs.
- Data ID
- An identifier included in the CRC calculation but not sent, so a frame from a different sender or message fails the CRC check at the receiver (masquerade detection).
- Alive counter
- A counter incremented with each transmission. The receiver detects lost, repeated or out-of-order frames from the counter difference.
- E2E state machine
- A receiver-side state machine that turns per-frame check results into a status such as valid, invalid or no data, with windows that tolerate a configured number of errors.
Step-by-step guide
- 1
Define the safety context
Describe the function: a vehicle control unit on the PC sends a motor torque request every 10 ms over CAN to the kit acting as the inverter controller, which applies it to an emulated motor shown on the LCD. Identify hazards from communication faults, such as unintended acceleration from a corrupted or stale request. List the fault types to cover: corruption, repetition, loss, delay, insertion, wrong sequence and masquerade.
Checkpoint: A short hazard and fault list linking each fault type to its potential effect.
- 2
Choose the profile and layout
Study the AUTOSAR E2E protocol specification and choose a profile suitable for an 8-byte classic CAN frame, such as one with an 8-bit CRC and 4-bit counter. Define the frame layout: CRC byte, counter nibble, torque request with resolution and offset, and a request status field. Define the data ID for this message. Record the reasoning, including why a larger profile would suit longer or more critical messages.
Checkpoint: A frame layout drawing with CRC, counter, data ID and signal positions, and the profile rationale.
- 3
Implement the sender protection
Implement the protect function in C and in Python: increment the counter with wrap-around, write it into the frame, compute the CRC over the data ID and the payload in the order the profile defines, and insert it. Use the CRC polynomial and initial value the profile specifies. Check your CRC implementation against known test vectors from the specification or a reference implementation, in both languages.
Checkpoint: C and Python implementations produce identical CRCs and match the reference test vectors.
- 4
Implement the receiver check
Implement the check function: recompute the CRC with the expected data ID, compare it, then evaluate the counter difference from the last valid frame. Return per-frame statuses such as OK, repeated, wrong sequence, error and no new data. Configure the maximum allowed counter jump. Then implement the state machine with init, valid, invalid and no-data states, and windows for the number of OK and error results needed to change state.
Checkpoint: Unit tests cover every per-frame status and every state transition with crafted frame sequences.
- 5
Integrate with the components
Model sender and receiver application components in Simulink with AUTOSAR Blockset. Generate code for the receiver component on the STM32 and connect its Rte_Read to the E2E-checked value and status. The receiver component must apply the torque only when the state is valid and fall back to zero torque with a warning otherwise. Show state and torque on the LCD and the status on the RGB LEDs.
Checkpoint: Normal traffic gives valid state and correct torque, and stopping the sender drives the receiver to its safe fallback.
- 6
Build the fault injector
Write a Python fault injector that sits in the PC node's transmit path and, at configured rates or at scripted moments, flips random bits in the payload, repeats the previous frame, drops frames, delays frames, inserts extra frames, reorders frames, and sends a frame protected with a different data ID. Log every injected fault with its type and time so the receiver's reaction can be matched to it.
Checkpoint: A fault log covering each fault type, confirmed by capturing the bus traffic.
- 7
Measure detection and reaction
Run long tests for each fault type at several injection rates. For each injected fault, record whether the receiver detected it, the status it reported and the time from fault to safe reaction. Compute detection rate per fault type, for example a corruption is detected if the CRC fails. Measure how quickly the receiver returns to valid after faults stop, and check that it never applies an undetected faulty torque in the logs.
Checkpoint: A detection table per fault type with reaction times and recovery times.
- 8
Analyse residual errors and overhead
Calculate the theoretical probability that a random corruption passes an 8-bit CRC and compare with your observed undetected corruptions over the test volume. Discuss why multiple bit flips and the frame rate matter for residual error rate, and when a larger CRC profile is required. Measure CPU cycles for protect and check with the DWT counter, and the payload bytes used by E2E fields.
Checkpoint: Calculated and observed residual corruption rates, plus cycle and payload overhead figures.
- 9
Tune the state machine
Vary the state machine windows and the allowed counter jump and measure the trade-off: tighter settings react faster but cause more transitions to invalid under occasional benign losses, while looser settings tolerate losses but react more slowly. Choose settings from the fault tolerant time interval you assume for the torque function, and justify them with the measurements. Record the final settings in the receiver configuration with a comment explaining the reasoning.
Checkpoint: Plots of reaction time against false invalid transitions for the configurations tested, and the chosen settings.
- 10
Report
Document the safety context, profile choice, implementation, fault injection method, detection and reaction results, residual error analysis and tuning. Explain how E2E fits into an ISO 26262 safety concept, where it is one measure alongside others, and how production stacks configure E2E through transformers or libraries from ARXML. Provide all code, logs and scripts, together with the fault injector so others can repeat the tests.
Checkpoint: A report with detection results for every fault type and justified state machine settings.
Testing & validation
- CRC implementations checked against reference test vectors.
- Unit tests for every per-frame status and state transition.
- Detection rate and reaction time per injected fault type.
- Observed versus calculated residual corruption rate.
- Cycle and payload overhead of protection.
Expected results
An E2E-protected torque request between a PC node and the STM32 kit, with measured detection of all main communication fault types, a tuned receiver state machine and quantified overhead.
Research angle for your M.Tech thesis
Research questions: how do E2E profile choice and state machine settings trade reaction time, availability and residual error for safety-relevant CAN signals, and how do measured results compare with analytical residual error estimates? Metrics: detection rate per fault type, reaction and recovery times, false invalid transitions and cycle overhead. A systematic fault-injection study with released tools gives measurable results for an M.Tech thesis on communication safety.
Take it further
- Implement a larger CRC profile for a longer message and compare overhead.
- Add E2E protection to a signal group spanning two frames.
- Combine E2E with message authentication for security and compare roles.
- Configure E2E through AUTOSAR Blockset if your release supports it and compare generated code.
Viva and review questions
How does the data ID detect masquerade if it is not transmitted?
Sender and receiver both include their own data ID in the CRC. If a frame was built with another message's data ID, the receiver's CRC calculation gives a different result and the check fails.
What does the counter detect that the CRC does not?
Lost, repeated and out-of-order frames. A repeated frame has a valid CRC but the same counter value as the last one.
Why use a state machine instead of reacting to each frame?
Single losses can be benign. The state machine tolerates a configured number of errors before declaring the data invalid, balancing availability against reaction time.
Is E2E protection the same as security?
No. E2E detects random faults and errors in the communication path; it does not protect against a deliberate attacker who knows the CRC and data ID, which needs cryptographic authentication.
Learn it at DIYguru
These DIYguru courses and programmes teach what this project needs.