CAN Simulation is extremely useful at the time of development and testing automotive components before mass production. It also allows cost reduction by reducing shipment of multiple parts to different software houses at the time of development. This presentation allows you to understand the effectiveness in building a low cost can simulator.
2. Agenda
• Controller Area Network
• Physical Layer
• CAN Database
• CAN Simulation
• Hardware
• Software
• Demo
1/2/2021 CAN Simulation 2
3. Introduction
CAN provides an inexpensive, durable network
that helps multiple CAN devices communicate
with one another. An advantage to this is that
electronic control units (ECUs) can have a single
CAN interface rather than analog and digital
inputs to every device in the system. This
decreases overall cost and weight in automobiles.
There are plenty of commercial frameworks that
provides CAN stacks and hardware/software tools
necessary to develop proper CAN networks. But
they are very comprehensive and thus expensive.
So this project aims to provide a cost-effective
replacement for CAN Hardware and simulation
software
1/2/2021 CAN Simulation 3
5. Controller Area Network
1/2/2021 CAN Simulation 5
A Controller Area Network (CAN bus) is a robust vehicle bus standard designed to allow
microcontrollers and devices to communicate with each other's applications without a host
computer. It is a message-based protocol, designed originally for multiplex electrical wiring
within automobiles to save on copper, but can also be used in many other contexts.
• Is a serial networking technology for embedded solutions.
• Needs only two wires named CAN_H and CAN_L.
• Operates at data rates of up to 1 Megabit per second (8 Megabit per second in CAN FD).
• Supports a maximum of 8 bytes per message frame. (variable length in CAN FD)
• Does not support node IDs, only message IDs. One application can support multiple message IDs.
• Supports message priority, i.e. the lower the message ID the higher its priority.
• Supports two message ID lengths, 11-bit (standard) and 29-bit (extended).
• Does not experience message collisions
• Is not demanding in terms of cable requirements. Twisted-pair wiring is sufficient.
8. Physical Layer
1/2/2021 CAN Simulation 8
The mechanical aspects of the physical layer (connector type and number, colors, labels,
pin-outs) have yet to be formally specified. As a result, an automotive ECU will typically
have a particular—often custom—connector with various sorts of cables, of which two are
the CAN bus lines. Nonetheless, several de facto standards for mechanical implementation
have emerged, the most common being the 9-pin D-sub type male connector with the
following pin-out:
pin 2: CAN-Low (CAN−)
pin 3: GND (Ground)
pin 7: CAN-High (CAN+)
pin 9: CAN V+ (Power)
10. CAN Database
1/2/2021 CAN Simulation 10
CAN database files are text files that contain scaling information for CAN frames and signal
definitions. The file format will be usually *.dbc. For each signal, CAN databases define
rules for conversion to engineering units. The following data is stored in databases:
• Channel name
• Location (start bit) and size (number of bits) of the channel within a given message
• Byte order (Intel/Motorola)
• Data type (signed, unsigned, and IEEE float)
• Scaling and units string
• Range
• Default value
• Comment
11. Decoding raw data
1/2/2021 CAN Simulation 11
To understand what 'raw CAN data' looks like, see the below example CAN frame from a truck:
CAN ID Data bytes
0CF00400 FF FF FF 68 13 FF FF FF
If you have a CAN DBC that contains decoding rules for the CAN ID, you can 'extract' parameters
(signals) from the data bytes. One such signal could be EngineSpeed:
Message Signal Value Unit
EEC1 EngineSpeed 621 rpm
14. CAN Simulation
1/2/2021 CAN Simulation 14
CAN Simulation is extremely useful at the time of development and testing automotive
components before mass production. It also allows cost reduction by reducing shipment of
multiple parts to different software houses at the time of development. It enables to simulate
CAN signals such as ignition status, doors status or reverse gear by every automotive
developer without the presence of physical hardware.
16. Hardware
1/2/2021 CAN Simulation 16
For creating a low cost CAN Simulator, we are using a single board computer which is
capable of running a linux distro. Along with that, we needs CAN interface which connects
the SBC to automotive hardware. So we have choosen the below items
1. Raspberry Pi 4 Model B (4GB)
2. Aluminum Heatsink with Thermal Conductive Adhesive Tape
3. 3.5A 5V Raspberry Pi 4 Power Supply (USB-C)
4. 32GB MicroSD Card with Adapter
5. 2 Channel CAN BUS FD Shield (With RTC[Optional])
6. DB9 RS232 D-SUB Male Connector Adapter 9-pin Port (x2)
7. 2x20 40 Pin Stacking Female Header Kit
8. Hex Brass Spacer/Standoff + Nuts + Screws
9. Jumper Wire/dupont cable Multicolored M to F, M to M, F to F
17. Optional Hardware
1/2/2021 CAN Simulation 17
Below are the list of optional hardware
1. Argon Fan HAT for Raspberry Pi 4 – For Cooling the whole setup
2. Raspberry Pi Case
3. Micro HDMI to HDMI Cable – If you are connecting this to a display. Not required if using VNC
4. IIC I2C TWI 1602 Serial LCD Module Display – To display the IP address as no display is connected
5. Card Reader
6. CR 2016 3V Lithium Battery (for RTC)
7. 7” or 8.4” HDMI display – To avoid VNC connection
8. Wireless Keyboard & Mouse
18. 1/2/2021 CAN Simulation 18
Raspberry Pi 4, Power adapter, Heat Sink, 32 GB SDCard, Card Reader,
Screwdriver
23. Software
1/2/2021 CAN Simulation 23
Below are the software used to make the CAN Simulator up and
running.
• Raspberry Pi OS
• Qt 5.11
• Open-JDK
• Python 3.8
24. Drivers
1/2/2021 CAN Simulation 24
Below are the drivers used to make the CAN Simulator up and
running.
• CAN Bus Hat Driver
• RTC Driver
• Fan Hat Driver
• Can-utils
• Python-can
• CANDevStudio
25. SocketCAN
1/2/2021 CAN Simulation 25
SocketCAN uses the Berkeley socket API, the Linux network stack
and implements the CAN device drivers as network interfaces. The
CAN socket API has been designed as similar as possible to the
TCP/IP protocols to allow programmers, familiar with network
programming, to easily learn how to use CAN sockets.
CAN Simulator interfaces as based on SocketCAN
Note : There is also a virtual CAN driver for testing purposes which
can be loaded and created in Linux.
26. CAN Interface Setup
1/2/2021 CAN Simulation 26
Once hardware and software are installed, we need to setup the
CAN Interface using the ip link command. Bitrate, data bitrate, fd
and other parameters can be configured
sudo ip link set can0 up type can bitrate 1000000 dbitrate 8000000 restart-ms 1000 berr-reporting on fd on
sudo ip link set can1 up type can bitrate 1000000 dbitrate 8000000 restart-ms 1000 berr-reporting on fd on
sudo ifconfig can0 txqueuelen 65536
sudo ifconfig can1 txqueuelen 65536
27. CANdevstudio
1/2/2021 CAN Simulation 27
CANdevstudio is a software developed in Qt which allows the
developers to configure a CAN simulation using an Drag and
Drop interface. As it is an open source software, the source code
is available in Github. We need to configure it with qmake and
then compile it with make command in Raspberry Pi.
CANdevstudio supports SocketCAN and many other interfaces.
The software can be executed using the below command once it
is ready
./build/src/gui/CANdevstudio
28. CANdevstudio Components
1/2/2021 CAN Simulation 28
• CANDevice – We can choose the interface
• CANSignalData – we add the dbc file to this component and set the cycle and initial data
• CANSignalEncoder & CANSignalSender – We can send the a signal to the CAN Interface
• CANSignalDecoder & CANSignalViewer – Decodes the frame from CAN Interface and show it as
signal
• CANRawSender – We can send raw frames also instead of a signal
• CANLoad – We can see the load of the CAN Network
• CANRawFilter – This allows us to filter the required CAN Signals
• CANRawLogger – This allows us to log the CAN Data
31. Demo
1/2/2021 CAN Simulation 31
For demo purpose, we have connected the CAN0 and CAN1 interface of the CANTool and created a
project. In this, “CAN1 Device” is the simulation and the “CAN0 Device” is the receiving end.