We are gonna use socketCAN for the simulation infrastructure. It will operate on VCAN0.

A brief introduction to socketCAN:

This is a wrapper on networking layers in the Linux kernel that allows us to control CAN signals/messages. It operates on top of TCP/IP. It sends frames over the network.

Our PEAKCan uses socketCAN, and so does the CANable. Every time we do cansend can0 123#DEADBEEF we are packaging a CAN frame to be sent over TCP/IP to the CAN file descriptor; this is then converted into a hardware signal by the CAN device (PEAKCan/CANable).

SocketCAN supports two modes, broadcast manager and raw mode. My plan is to use the broadcast manager in the server because it supports these features:

• Schedule transmission at different frequencies. This will let us simulate the CAN bus easily.

• Offloading everything to the Linux kernel! Why create threads to TX data at some frequency when we can reduce overhead by using the kernel space directly?

The client will use raw mode to be functionally the same as the hardware. This will allow us to manually write/read data.

SocketCAN - Controller Area Network — The Linux Kernel documentation

Server

Use broadcast manager with Jinja? Maybe we can autogenerate a broadcast manager initializer depending on how many nodes we are simulating. This way we can mock the entire bus using the YAMLs. Especially since I plan on adding a “cycle_speed” feature to CAN autogeneration.

Client:

Use raw