The problem
Application components exchange signals, but the CAN bus carries frames. The AUTOSAR communication stack, COM, PDU Router, CAN Interface and CAN Driver, packs signals into PDUs, schedules their transmission and monitors reception. Configuring it wrongly causes wrong values, missing frames or bus overload, so engineers need to understand the mapping well.
Objectives
- Define signals, I-PDUs and frames for an EV body or dashboard message set.
- Specify packing, byte order and transmission modes.
- Implement a layered signal-to-frame path on the STM32 kit.
- Implement reception with deadline monitoring.
- Verify frames, cycle times and timeout handling from the PC.
What you need
Tools and toolboxes
- AUTOSAR Blockset — The application component that writes and reads signals through RTE ports.
- Embedded Coder — Generating the component code for the STM32.
- STM32CubeIDE — The hand-written COM, PduR and CanIf layers, CAN driver and RTE glue.
- Python with python-can and cantools — Sending and decoding frames from the PC using a DBC file.
- Wireshark — Optional: viewing CAN traffic captured through SocketCAN on Linux.
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 and cantools
Extra parts and data
- USB-CAN adapter — Lets the PC act as the second node: sending, receiving and timing frames.
- 120-ohm terminating resistor — A two-node CAN bus needs termination at both ends if the kit and adapter do not provide it.
Key concepts
- Signal and I-PDU
- A signal is one value, such as vehicle speed. An I-PDU is the data unit COM builds by packing several signals at defined bit positions; CanIf sends it as a CAN frame.
- Byte order
- Signals spanning bytes can be packed little-endian (Intel) or big-endian (Motorola). Sender and receiver must agree, or values come out scrambled.
- Transmission modes
- Periodic sends every cycle; direct sends when a signal changes; mixed does both. Mode choice trades bus load against latency.
- Deadline monitoring
- The receiver checks that a PDU arrives within a timeout. If not, COM can substitute a default value and notify the application.
Step-by-step guide
- 1
Define the message set
Define four or five PDUs for a small EV body network: VehicleStatus from the kit with speed from the potentiometer, gear and ready flag; WarningStatus with warning bits; and from the PC, BatteryInfo with SOC and pack temperature and a ChargerStatus message. For each signal record start bit, length, byte order, factor, offset, unit, range and initial value. For each PDU record the CAN identifier, length and transmission mode.
Checkpoint: A signal and PDU table with every field filled in for every signal.
- 2
Write the DBC and ARXML descriptions
Write the message set as a DBC file, which tools such as cantools and Vector CANdb++ read, and check it by loading it with cantools and encoding and decoding sample values. Optionally express the same signals in an AUTOSAR system description, in which I-SIGNAL, I-SIGNAL-I-PDU and FRAME elements with their mappings appear, to see how AUTOSAR represents the same information. Keep the DBC as the single source for the PC side.
Checkpoint: cantools encodes and decodes each message with the expected raw bytes for hand-calculated examples.
- 3
Build the application component
Model a small DashboardLogic component in Simulink with AUTOSAR Blockset: it reads battery SOC, temperature and charger status through receiver ports and writes vehicle status and warnings through sender ports, with a 10 ms timing event. Add logic that raises a warning on high temperature or low SOC. Generate code and keep the Rte_Read and Rte_Write calls; you will implement them in the next step.
Checkpoint: Generated code for the component with one Rte call per port, compiled for the STM32.
- 4
Implement the layered stack
In C on the STM32, implement thin layers that follow the AUTOSAR responsibilities: a COM layer with Com_SendSignal and Com_ReceiveSignal that pack and unpack signals into PDU buffers using the table from step 1; a PduR layer that routes PDU IDs; a CanIf layer that maps PDU IDs to CAN identifiers and hardware objects; and the CAN driver using the bxCAN peripheral. Implement the RTE calls on top of COM.
Checkpoint: Unit tests on the PC build of COM pack and unpack every signal to the same bytes as cantools.
- 5
Implement transmission modes
Run a COM main function every 10 ms that handles transmission: periodic PDUs at their cycle times, such as 100 ms for VehicleStatus, and a direct or mixed mode for WarningStatus so a new warning is sent at once, with a minimum delay between sends to avoid flooding. Track pending transmissions and confirmations from the CAN driver. Display the current speed and warnings on the LCD.
Checkpoint: On the bus, VehicleStatus appears every 100 ms and WarningStatus appears immediately on a new warning.
- 6
Implement reception and timeouts
On reception, CanIf identifies the PDU by CAN identifier and passes it through PduR to COM, which unpacks signals and marks them as updated. Add deadline monitoring: if BatteryInfo does not arrive within three times its cycle time, COM substitutes a defined timeout value and sets a status the application reads. Make the application light a red LED and sound the buzzer on a battery message timeout.
Checkpoint: Stopping BatteryInfo from the PC triggers the timeout reaction within the configured time.
- 7
Build the PC test node
Write a Python script with python-can and cantools that sends BatteryInfo and ChargerStatus at their cycle times with values from a test profile, logs everything received with timestamps, and decodes it with the DBC. Add test functions: check decoded values against expected ones, measure cycle-time jitter for each periodic PDU, and pause sending to test timeouts. Save logs as CSV and use Wireshark on Linux if you want a graphical view.
Checkpoint: The script reports decoded values, cycle times with jitter and timeout behaviour in one run.
- 8
Test byte order and edge cases
Add a signal that crosses a byte boundary in Motorola byte order and one in Intel order, and test encoding at minimum, maximum and out-of-range values. Deliberately configure the PC side with the wrong byte order and record the decoded values, to show what this common integration error looks like. Measure bus load from frame lengths and cycle times and compare with the measured traffic.
Checkpoint: Correct decoding for both byte orders at range limits, and documented symptoms of a byte-order mismatch.
- 9
Report
Document the message set, DBC, layered stack design, transmission and reception behaviour, test results and bus load. Explain how a production stack differs: COM, PduR and CanIf are generated from ARXML configuration by tools such as Vector DaVinci Configurator or EB tresos, with many more features such as signal groups and update bits. Provide the firmware, DBC and test scripts.
Checkpoint: A report with test evidence for packing, timing and timeouts, and the full source package.
Testing & validation
- COM packing and unpacking matches cantools for all signals.
- Measured cycle times and jitter for periodic PDUs.
- Immediate transmission of direct-mode PDUs on change.
- Timeout detection and substitute values on missing PDUs.
- Correct handling of both byte orders at range limits.
Expected results
A working signal-to-frame path on the STM32 kit that follows the AUTOSAR COM stack layering, with verified packing, transmission modes and deadline monitoring.
Take it further
- Add update bits and signal groups for consistent multi-signal updates.
- Add E2E protection to a safety-relevant PDU.
- Generate the COM configuration tables automatically from the DBC.
- Add a gateway that routes a PDU from one CAN identifier to another.
Viva and review questions
Why have separate COM, PduR and CanIf layers?
Each has one job: COM handles signals, PduR routes PDUs between modules and buses, and CanIf abstracts the CAN hardware. This lets the same application and COM configuration run on different buses and controllers.
What happens if sender and receiver use different byte orders?
Multi-byte signals decode to wrong values, often plausible-looking ones, which makes the error hard to spot without tests at known values.
Why limit how often a direct-mode PDU can be sent?
A rapidly changing signal could otherwise flood the bus and delay other messages, so a minimum delay between transmissions is enforced.
Learn it at DIYguru
These DIYguru courses and programmes teach what this project needs.