Classic–Adaptive Gateway: Bridging CAN Signals to SOME/IP Services

The problem

Vehicles will run Classic AUTOSAR ECUs on CAN for many years alongside Adaptive computers on Ethernet. Gateways translate between signal-based CAN frames and service-based SOME/IP, and they must preserve timing, detect stale data and filter what may cross. This project builds such a gateway with real CAN hardware on one side and services on the other, then measures what translation costs.

Objectives

• Define a CAN database and a mapping from signals to SOME/IP events and methods.
• Program the kit STM32 as a CAN node sending periodic signals and receiving commands.
• Implement the gateway on Linux with SocketCAN and vsomeip.
• Add freshness, range and rate checks on translated data.
• Measure translation latency, jitter and behaviour during CAN faults.

What you need

Key concepts

Signal-to-service mapping

Rules that say which CAN signals form which SOME/IP event or field, how they are scaled and how often they are sent.

Freshness check

The gateway tracks the time since each CAN frame last arrived; if it exceeds a timeout, the service marks the data invalid instead of repeating an old value.

Event aggregation

Several CAN frames can be combined into one service event, which reduces message count but adds waiting delay if frames arrive at different times.

Bus-off

A CAN controller that sees too many transmit errors disconnects itself from the bus; the gateway must detect this and report loss of data.

Step-by-step guide

1. 1

   Define the signals and mapping

   Write a DBC file with three frames from the kit ECU: VehicleSpeed at 20 ms (speed from the potentiometer, scaled), PedalStatus at 10 ms and EcuStatus at 100 ms with a rolling counter. Add a command frame LampCommand from the gateway. Then write the mapping table: VehicleDynamics event from VehicleSpeed and PedalStatus, EcuHealth field from EcuStatus, and a SetLamp method mapped to LampCommand. State latency and freshness requirements.

   Checkpoint: A DBC file that loads in cantools and a mapping table with rates and requirements.

2. 2

   Build the kit CAN node

   Configure the STM32 bxCAN at 500 kbit/s and set the kit's DIP switches for CAN, potentiometer, LCD and LEDs. Send the three frames from a timer at their periods, encoding signals according to the DBC, with the rolling counter incremented each EcuStatus frame. Receive LampCommand with a hardware filter and drive the RGB LEDs. Show speed and counter on the LCD. Connect the USB-CAN adapter with correct termination.

   Checkpoint: candump on the Linux host shows all three frames at their periods with correct decoded values in cantools.

3. 3

   Read CAN on the gateway

   On Linux, bring up the CAN interface with ip link at 500 kbit/s and write a C++ reader using a raw SocketCAN socket with kernel receive timestamps enabled (SO_TIMESTAMP). Decode signals using code generated or checked against the DBC with cantools, so scaling errors are caught. Keep the latest value and arrival time per frame in a thread-safe store. Check bus load on the Linux side with canbusload from can-utils to confirm it matches your calculation.

   Checkpoint: The gateway log shows decoded speed and pedal values matching the LCD and cantools output.

4. 4

   Offer services

   Using vsomeip, offer a VehicleSignals service with the VehicleDynamics event, EcuHealth field and SetLamp method. Choose a publishing strategy: send VehicleDynamics on every PedalStatus frame, or at a fixed 20 ms with the latest values. Implement both as options for comparison. Include each signal's validity flag and age in the event payload so consumers know how fresh the data is.

   Checkpoint: A test consumer receives VehicleDynamics and EcuHealth with values and ages matching the CAN side.

5. 5

   Implement the reverse path

   Handle the SetLamp method: check the requested value against the allowed range, check a minimum interval between commands to avoid flooding the CAN bus, encode it into LampCommand and send it with SocketCAN. Return success or a specific error to the caller. Only allow mapped commands to cross; any other request is rejected and logged, which acts as a simple gateway firewall.

   Checkpoint: Calling SetLamp from the consumer changes the kit's RGB LED colour; out-of-range and too-frequent requests are rejected.

6. 6

   Add plausibility and freshness checks

   Mark VehicleDynamics invalid if PedalStatus has not arrived for three periods. Check that the EcuStatus rolling counter increments by one; flag repeated or skipped counters. Add a range check on speed and a rate-of-change check that rejects impossible jumps. Report check failures in the EcuHealth field so consumers can react. Write unit tests for each check with recorded frame sequences.

   Checkpoint: Unit tests pass, and stopping the kit's transmissions sets the invalid flag within the specified time.

7. 7

   Measure translation latency

   Measure latency from the CAN kernel receive timestamp to the SOME/IP send, and to the consumer receive, over 10,000 frames for both publishing strategies. Measure command latency from method call to the CAN frame seen by candump. Plot distributions and report median and 99th percentile. Compare the extra delay of fixed-rate publishing with the reduction in message count. Synchronise logging on one host clock so timestamps from both sides can be compared directly.

   Checkpoint: Latency distributions for both strategies and the command path, with message counts per second.

8. 8

   Inject CAN faults

   Disconnect the CAN wire briefly, remove termination, and hold the kit in reset, observing the gateway's reaction each time. Force a bus-off condition by sending frames with no other node acknowledging and check that the gateway detects the controller state through SocketCAN error frames. Record detection times and whether the service reports invalid data instead of stale values in every case.

   Checkpoint: A fault table with detection times and service reactions for each injected CAN fault.

9. 9

   Report

   Document the DBC, mapping, firmware, gateway design, checks, latency results and fault tests. Discuss what a production gateway adds: AUTOSAR PDU Router and signal gateway configuration on the Classic side, SecOC and E2E protection, and a security policy for routing. State the limitations of a two-node bench bus and a general-purpose Linux host. Include the DIP-switch settings and wiring photographs so the bench can be rebuilt quickly.

   Checkpoint: A report with wiring diagram, mapping table, measured results and fault behaviour.

Testing & validation

• Decoded values match DBC scaling on both sides.
• Freshness, counter, range and rate checks tested with recorded sequences.
• Translation and command latency distributions for both publishing strategies.
• Fault detection times for disconnection, missing termination, reset and bus-off.
• Rejection of unmapped and out-of-range commands.

Expected results

A working CAN-to-SOME/IP gateway between the kit ECU and Linux services, with freshness and plausibility checks, a filtered command path and measured translation latency and fault behaviour.

Take it further

• Add an E2E protection profile on the SOME/IP events and test corruption detection.
• Generate the mapping code automatically from the DBC and a mapping file.
• Add CAN FD and compare throughput.
• Add a second kit node and test arbitration effects on gateway latency.

Viva and review questions

Learn it at DIYguru

These DIYguru courses and programmes teach what this project needs.