SocketCAN CAN and CAN FD Communication on Linux

Demonstrates CAN and CAN FD communication using Linux SocketCAN — no physical CAN hardware required.

A Virtual CAN interface (vcan0) is used to create a software-based CAN network. Three independent nodes are implemented in C: a Vehicle ECU, a Dashboard ECU, and a Logger ECU. A separate CAN FD implementation is also included to demonstrate the differences between Classical CAN and CAN FD.

The goal of this project is to understand how CAN communication can be developed, tested, monitored, and debugged entirely in a Linux environment before connecting real CAN hardware.

---

Table of Contents

• System Architecture
• Technologies Used
• Project Structure
• Software Requirements
• Setting Up the Virtual CAN Interface
• Classical CAN Implementation
• Vehicle ECU
• Dashboard ECU
• Logger ECU
• CAN Message Filtering
• Unknown CAN Message Detection
• Transmission Rate Study
• Node Failure Detection
• CAN FD Implementation
• Classical CAN vs CAN FD
• Building the Project
• Running the Classical CAN Demonstration
• CAN FD Demonstration
• Learning Challenges Completed
• Key Learning Outcomes
• Future Improvements
• Author
• License

---

System Architecture

flowchart TB
    subgraph Linux["Linux System"]
        VCAN(("vcan0<br/>Virtual CAN Interface"))
        VE["Vehicle ECU<br/><i>Transmitter</i>"]
        DE["Dashboard ECU<br/><i>Receiver</i>"]
        LE["Logger ECU<br/><i>Recorder</i>"]

        VE -- "TX: Speed, RPM, Temp" --> VCAN
        VCAN -- "RX" --> DE
        VCAN -- "RX" --> LE
    end

Loading

All three applications communicate through the same vcan0 interface via SocketCAN raw sockets. Multiple applications can receive the same CAN traffic simultaneously.

Node	Role	CAN IDs Used
Vehicle ECU	Transmitter	0x100, 0x101, 0x102
Dashboard ECU	Receiver / Decoder	0x100, 0x101, 0x102
Logger ECU	Recorder (all traffic)	All (0x100–0x1FF, etc.)

---

Technologies Used

• C
• Linux
• SocketCAN
• Virtual CAN
• Classical CAN
• CAN FD
• GCC
• Make
• Linux Raw CAN Sockets

---

Project Structure

SocketCAN-CANFD-Linux/
|
|-- vehicle_ecu/
|   |-- vehicle.c
|   |-- vehicle_fd.c
|
|-- dashboard_ecu/
|   |-- dashboard.c
|   |-- dashboard_fd.c
|
|-- logger_ecu/
|   |-- logger.c
|   |-- logger_fd.c
|
|-- include/
|   |-- can_ids.h
|
|-- docs/
|
|-- logs/
|
|-- Makefile
|-- README.md
|-- .gitignore

---

Software Requirements

• GCC compiler
• Make
• SocketCAN support
• iproute2
• can-utils

Developed and tested on Ubuntu Linux.

---

Setting Up the Virtual CAN Interface

Physical CAN hardware is not required for this project.

1. Load the Virtual CAN kernel module

sudo modprobe vcan

2. Create the virtual CAN interface

sudo ip link add dev vcan0 type vcan

3. Enable the interface

sudo ip link set up vcan0

4. Verify the interface

ip -details link show vcan0

The interface should appear as vcan0.

---

Classical CAN Implementation

The Classical CAN implementation uses Linux Raw CAN sockets and the struct can_frame structure. The maximum CAN payload is 8 bytes.

The Vehicle ECU transmits vehicle parameters using three CAN identifiers:

CAN ID	Signal	DLC	Range
0x100	Vehicle Speed	2	0 to 120 km/h
0x101	Engine RPM	2	800 to 5000 rpm
0x102	Coolant Temperature	1	20 to 120 °C

• Vehicle Speed — encoded as a 16-bit value using two data bytes
• Engine RPM — encoded as a 16-bit value
• Coolant Temperature — transmitted using one data byte

---

Vehicle ECU

The Vehicle ECU generates continuously changing vehicle parameters and transmits them through vcan0:

• Vehicle Speed
• Engine RPM
• Coolant Temperature

Values are varied within realistic ranges to simulate changing vehicle conditions.

---

Dashboard ECU

The Dashboard ECU receives CAN messages and decodes the payload according to the CAN message definitions.

Example output:

====================================
      VEHICLE DASHBOARD ECU
====================================
Speed        : 65 km/h
Engine RPM   : 2450 rpm
Temperature  : 88 C
Vehicle ECU Status : ONLINE
====================================

The Dashboard ECU also implements a communication timeout mechanism. If no Speed message is received for more than two seconds, the following warning is displayed:

WARNING: Vehicle ECU Offline

---

Logger ECU

The Logger ECU listens to CAN traffic on vcan0 and records received messages, including:

• Timestamp
• CAN identifier
• Payload length
• Payload data

Example log:

Timestamp,CAN_ID,DLC,Payload
10:20:15,0x100,2,41 00
10:20:15,0x101,2,92 09
10:20:15,0x102,1,58

Generated log files are excluded from Git tracking (.gitignore) since they are runtime-generated data.

---

CAN Message Filtering

SocketCAN provides CAN filtering at the socket level. The Dashboard ECU can be configured to receive:

1. All CAN messages
2. Only Vehicle Speed messages
3. Only Engine RPM messages

A CAN filter is configured using struct can_filter and the CAN_RAW_FILTER socket option:

struct can_filter filter;

filter.can_id = SPEED_ID;
filter.can_mask = CAN_SFF_MASK;

setsockopt(sock,
           SOL_CAN_RAW,
           CAN_RAW_FILTER,
           &filter,
           sizeof(filter));

This allows the application to process only the messages it requires.

---

Unknown CAN Message Detection

An additional CAN message with an undefined identifier can be introduced during testing, for example:

CAN ID: 0x200

• The Logger ECU records the message because it observes CAN traffic independently of message definitions.
• The Dashboard ECU does not decode the message because 0x200 is not defined in the application.

This demonstrates how an application can handle unsupported CAN identifiers without affecting normal communication.

---

Transmission Rate Study

Different transmission intervals were tested to observe their effect on system behavior:

1000 ms
500 ms
100 ms
50 ms
10 ms

A lower transmission interval results in more frequent CAN frames, faster dashboard updates, faster log file growth, and increased application activity.

A transmission interval of approximately 100 ms provides a suitable balance for this demonstration.

---

Node Failure Detection

The Vehicle ECU was terminated while the Dashboard ECU and Logger ECU remained active. After the Vehicle ECU stopped transmitting:

• No new CAN messages were received
• The Dashboard ECU retained the last received values
• The Logger ECU remained active but did not receive new frames
• CAN traffic observed using candump vcan0 stopped

This demonstrates that applications must implement their own timeout mechanism to detect communication loss.

sequenceDiagram
    participant V as Vehicle ECU
    participant B as vcan0 Bus
    participant D as Dashboard ECU
    participant L as Logger ECU

    V->>B: Speed / RPM / Temp frames
    B->>D: Deliver frames
    B->>L: Deliver frames
    Note over V: Vehicle ECU terminated
    D->>D: No frame for 2s → "WARNING: Vehicle ECU Offline"
    L->>L: Remains active, no new entries logged

Loading

---

CAN FD Implementation

A separate CAN FD implementation is included in the project. CAN FD uses:

struct canfd_frame

instead of the Classical CAN:

struct can_frame

CAN FD supports a payload of up to 64 bytes, compared with 8 bytes in Classical CAN. This project's CAN FD implementation uses a 16-byte payload.

CAN FD is enabled through the SocketCAN socket option:

int enable_canfd = 1;

setsockopt(sock,
           SOL_CAN_RAW,
           CAN_RAW_FD_FRAMES,
           &enable_canfd,
           sizeof(enable_canfd));

The CAN FD Dashboard receives and decodes the 16-byte frame, while the CAN FD Logger records the complete payload.

---

Classical CAN and CAN FD Comparison

Parameter	Classical CAN	CAN FD
Maximum payload	8 bytes	64 bytes
Payload used in this project	Up to 8 bytes	16 bytes
Frame structure	CAN	CAN FD
Data rate	Fixed	Flexible
Large data transfer	Less efficient	More efficient

---

Building the Project

Go to the project directory:

cd ~/SocketCAN_Project

Build the Classical CAN applications:

make

The resulting executables are:

vehicle
dashboard
logger

---

Running the Classical CAN Demonstration

Start the Vehicle ECU:

./vehicle

Start the Dashboard ECU in another terminal:

./dashboard

Start the Logger ECU in another terminal:

./logger

CAN traffic can also be observed using:

candump vcan0

---

CAN FD Demonstration

The CAN FD applications are:

vehicle_fd
dashboard_fd
logger_fd

They use struct canfd_frame and support payloads larger than the Classical CAN 8-byte limit.

---

Learning Challenges Completed

#	Experiment
1	CAN traffic observation
2	CAN message filtering
3	Unknown message detection
4	Transmission rate study
5	Node failure study
6	CAN FD exploration
7	Basic communication diagnostics

---

Key Learning Outcomes

This project provided practical experience with:

• Linux SocketCAN
• Virtual CAN interfaces
• CAN raw sockets
• CAN frame structure
• CAN identifiers and payloads
• CAN message filtering
• Multiple CAN applications
• CAN traffic monitoring
• CAN data logging
• Communication timeout detection
• Classical CAN
• CAN FD
• Software-only CAN development

---

Future Improvements

• DBC file based message decoding
• UDS diagnostic communication
• CAN error frame monitoring
• CAN traffic replay
• Graphical dashboard
• CAN bus statistics
• Physical CAN hardware integration
• Automated testing
• Additional CAN FD message types

---

Author

Sanket Chavan Electronics and Telecommunication Engineering AISSMS Institute of Information Technology, Pune

---

License

This project was developed for academic and learning purposes.