CAN Simulator for Automotive Industry

Petre Mihail - Stefanita1 ,

1 (Affiliation): dept. Electronics and Computing Science, Universitatea Transilvania from Brasov, UNITBV, BRASOV, Romania,
mihail-stefanita.petre@student.unitbv.ro

Abstract—The project presents the possibility of implementing The transmission medium consists in most implementations
a CAN-BUS type communication network integrated in the of a pair of twisted wires provided with termination resistors
communication modules present in cars. This paper aims to (terminators). Their value depends on the type of cables used.
control the ECU of a pre-tensioned seat belt, using an ARDUINO
UNO development platform, a CAN-BUS Shield and 2 control 120 Ohm terminators are used for UTP.
stations. Based on the hardware components used, a software For each device, the data in a frame is transmitted sequen-
application variant will be designed that will allow sending, tially but in such a way that if more than one device transmits
receiving and interpreting frames through the CAN-Bus from at the same time, the highest priority device can continue while
station 1 to the ECU and vice versa.
the others back off. Frames are received by all devices [Fig.
2], including by the transmitting device.
I. I NTRODUCTION
This paper presents the development (hardware and soft-
ware), implementation and testing of a real-time CAN Simu-
lator used in the automotive electronics industry.
The CAN simulator is designed to be able to configure
information messages, transmit and receive information frames
from a pre-tensioned belt ECU to a test program used within
the Autoliv company The following is the operating block
diagram of the CAN Simulator regarding the exchange of
information with the belt ECU [Fig. 1].

Fig. 2. Communication Network Through CAN Protocol

A twisted line consisting of cables of two unshielded wires

is the most commonly used physical transmission medium
in applications (uninterrupted UTP), on which a symmetrical
transmission of signals takes place. Typically, UTPs have wire
Fig. 1. Message Transmission via CAN Simulator cross sections between 0.34 mm2 and 0.6 mm2. The line
resistance must be less than 60 mOhm. [Fig. 3]
The actual purpose of the chosen demonstration application
is the theoretical study of the CAN protocol, but also the
physical implementation of a CAN Simulator to demonstrate
the importance and efficiency of using this protocol in the
automotive field.
A. About CAN Communication Protocol
CAN is a serial communication standard through a bus
for connecting electronic control units (ECUs) also known as
nodes. Two or more nodes are required in the CAN network
to communicate. The complexity of the node can range from
a simple I / O device to a built-in computer with a CAN
interface and sophisticated software. The node can also be a
gateway that allows a standard computer to communicate via
a USB or Ethernet port to devices on a CAN network. Fig. 3. Reference Levels for a CAN-Bus
 The maximum data rate is 1 Mbit / s. A maximum network
extension of approximately 40 meters is allowed. At the
ends of the CAN network, the terminating resistances of
the bus contribute to the prevention of transient phenomena
(reflections). ISO 11898 specifies the maximum number of
CAN nodes as 32.
B. About ATMEGA328P microcontroller and ARDUINO UNO
board
The ATmega328 is a single-chip microcontroller created by
Atmel in the megaAVR family (later Microchip Technology
acquired Atmel in 2016). It has a modified Harvard architec-
ture 8-bit RISC processor core.
The Atmel 8-bit AVR RISC-based microcontroller combines
32 KB ISP flash memory with read-while-write capabilities, 1
KB EEPROM, 2 KB SRAM, 23 general purpose I/O lines, 32
general purpose working registers, three flexible timer/counters
with compare modes, internal and external interrupts, serial
programmable USART, a byte-oriented 2-wire serial interface,
SPI serial port, 6-channel 10-bit A/D converter (8-channels
in TQFP and QFN/MLF packages), programmable watchdog
timer with internal oscillator, and five software selectable
power saving modes. The device operates between 1.8-5.5
volts. The device achieves throughput approaching 1 MIPS
per MHz.
The Arduino Uno is an open-source microcontroller board
based on the Microchip ATmega328P microcontroller and de-
veloped by Arduino The board is equipped with sets of digital
and analog input/output (I/O) pins that may be interfaced
to various expansion boards (shields) and other circuits. The
board has 14 digital I/O pins (six capable of PWM output),
6 analog I/O pins, and is programmable with the Arduino
IDE (Integrated Development Environment), via a type B USB
cable. It can be powered by the USB cable or by an external 9-
volt battery, though it accepts voltages between 7 and 20 volts.
It is similar to the Arduino Nano and Leonardo. The hardware
reference design is distributed under a Creative Commons
Attribution Share-Alike 2.5.
Fig. 4. ARDUINO Uno and CAN-Bus Shield module
The CAN-BUS Shield used adopts MCP2515 CAN Bus
controller with SPI interface and MCP2551 CAN transceiver
to give for Arduino CAN-BUS capability.
II. I MPLEMENTATION OF THE DEMONSTRATIVE
APLICATION
For the implementation of the presented application, the
following was performed:
1. Hardware implementation
2. Software implementation
A. THE HARDWARE IMPLEMENTATION
For the implementation of the CAN communication sys-
tem, a development platform offered by ARDUINO with
ATMEGA328p microcontroller and a CAN-BUS V2.0 module
was used. It was decided to use an ARDUINO UNO devel-
opment platform because it allows the easy implementation
of remote communication protocols, such as CAN, and also
because the microcontroller offers sufficient resources to im-
plement the application.
The entire hardware implementation was achieved by inter-
connecting the components presented above. The centerpiece
of the entire CAN simulator architecture is the Arduino UNO
development board and the CAN-BUS Shield add-on board.
The secondary microcontroller on the ATmega 16U2 devel-
opment board is responsible for converting the signal from
the USB to a serial signal that is transmitted to the main
ATmega 328p microcontroller. In other words, the Atmega
16U2 microcontroller connects the laptop to the development
board. In the figure [Fig. 1] shows how to connect to the
control station 1 (laptop).
The assembly of the two boards is connected to the CAN
bus via a cable connected to the DB-9 socket. To make these
connections, it was necessary to make an adaptation because
the configuration of the pins in slot DB-9 specifies pin 3 for
CAN-H and pin 5 for CAN-L, while the CAN connector on
the bus has pins 7 for CAN-H configured and 2 for CAN-L.
I used 2 mother-father DB-9 jacks to adapt the pins.
The entire system also comprises the electronic belt control
unit and the control station 2 represented by a computer. The
connection of the internal testing program of the company
Autoliv to the CAN bus is made through a CANcase imple-
mented by Vector. It should also be noted that the electronic
control unit is connected to the belt retractor (mechanical
part), both being supplied by a 12.5 V voltage source. For the
qualification and disqualification of the motor disconnection
error (Motor Disconnected) two power cables will be used
(red - V + and black - GND), and the strategy is to suddenly
stop powering the mechanical retractor to the belts with pre-
tensioning and suddenly restart retractor power supply.
B. THE SOFTWARE IMPLEMENTATION
The entire software implementation was performed in an
integrated development environment (IDE) provided by Ar-
duino.
The Arduino programming environment makes it easy to
write code and has an easy way to write the program on the
Arduino UNO. It can run on Windows, Mac Os X and Linux.
The programming environment is made in Java, which can
process other open source programming languages. A program
written in this development environment provided by Arduino
is called a sketch.
A typical Arduino sketch written in C / C ++ is composed
of two functions that are compiled and linked in a main ()
program [Fig. 5 ]: • setup (): a function that is run only once at the information frames sent by the electronic belt control unit
the beginning of the program, when the settings are initialized. will be periodically displayed on the console. [Fig. 8]
• loop (): a function called repeatedly until the power supply
to the board is turned off.

Fig. 8. Loop() function

It should be specified that the built network contains

practically 3 nodes: the belt ECU, the assembly of the two
development boards and the testing program from the company
Autoliv. Thus, the frames sent by the ECU are ”seen” by both
the CAN simulator and the test program [Fig. 9] (the CAN
Fig. 5. Arduino IDE
network works on the principle of broadcasting - one node
sends, all others receive). The Autoliv test program can also
The software part consists of 3 programs, each of them send frames that the CAN simulator will consider.
achieving one of the proposed objectives. The CANreceive.ino
[Fig. 6] program aims to display all the information frames
sent by the belt ECU in the Arduino programming environment
console.
Some of the functions used in software development are
predefined by the Arduino development environment and the
libraries used: mcpcan.h and SPI.h.
A constant is defined for the input pin configuration and is
assigned the corresponding pin, also for SPI serial communi-
cation the pin for CS is set. Fig. 9. The information frames observed in the test program

Fig. 6. CANreceive.ino

The setup () function includes the initialization section

of the MCP2515 microcontroller, setting the baud rate and
configuring the CAN0 INT pin as input. [Fig. 7]

Fig. 10. Arduino Serial Monitor Frames

Fig. 7. Setup() function
The loop () function refers to how to receive data from
the ECU and the ability to display each frame with the
appropriate ID type. Following the running of this program,
CANSendReceiveExtendedDiagnosticRequest.ino refers to
the ability of the CAN simulator to periodically send infor-
mation frames to the belt ECU and test program. Also, the
function of receiving the answer from the electronic control
unit to the simulator was implemented. For example, I sent a
diagnostic request, and the response I received was positive.
The formation of the diagnosis request, respectively the
extraction of the information corresponding to the positive
answer was done according to the ISO 15765 standard. It
should be specified that the request and the response are made
on a frame with an extended ID, this being specified by the
developers of the automotive project in which the experiment
was performed. [Fig. 12]
The microcontroller initialization function is identical to that
of the first program. The continuous loop () function contains
the send part and the receive part of the frames. [Fig. 11]
an error message that specifies the exact type of error. In order
to be able to carry out this program, the information related to
the bytes corresponding to the error in the information frame
sent by the ECU to the CAN simulator is required. The motor
disconnection error is defined as the byte with index 5 on
the information frame with the standard ID 0x143. Therefore,
after running the program, you will notice the change of this
byte depending on the qualification or disqualification of the
error.
The initialization part is identical to that of the first two
programs, and there are two conditions in the continuous
loop: the first in which the frames received from the ECU are
displayed if the error is not qualified, and the second condition
refers to the display of frames in case of qualified error
together with an appropriate message. The second condition
is presented in the figure [Fig. 13]

Fig. 11. Arduino Serial Monitor Frames

Fig. 13. Loop() function

It is observed that on the frame with the ID 0x143 the byte

with index 5 has the value in hexadecimal 0x7F if the error
is not qualified, and when it qualifies it changes its value in
0x5F. [Fig. 14]

Fig. 12. Arduino Serial Monitor Frames

In the last part of the software implementation, we devel-

oped a software program CheckDTCOn0x143Frame.ino that
has the ability to query in real time a frame received from the
belt ECU with the ID 0x143. This frame is configured within
the current project to display whether or not certain errors are
qualified.
These errors are mapped at the bit or byte level in the
data segment of the frame, according to specifications given
by the developers. For the realization of this program, we
considered the error rating of MotorDisconnected (the name
defined by the developers). The error qualification strategy
consists in the sudden interruption of the belt motor supply,
the qualification time being instantaneous. The error is also
disqualified instantly by restarting the belt motor supply.
Therefore, the software program works as follows:
The CAN simulator receives periodic frames from the belt Fig. 14. Status of the AEC show in Arduino Serial Monitor
ECU, and when the engine disconnect error qualifies, the
frames with differential information are displayed along with
 III. C ONCLUSION
1. Regarding the testing process in the automotive industry,
the use of the CAN communication standard is the best
alternative compared to other procedures such as LIN commu-
nication. CAN offers advantages both in terms of information
transmission speed and bus error management.
2. The implementation of the CAN Simulator presented in
this paper offers an alternative in terms of communicating an
electronic control unit of a belt with a control station.
3. The CAN simulator allows the sending, in real time, of
some information frames both to the belt ECU and to a test
program used internally in the company Autoliv.
4. Through the interface provided by the Arduino program-
ming environment, the information frames received from the
ECU can be displayed in real time on the control station 1.
5. Based on the information displayed in real time, a check
is made regarding the qualification / disqualification status of
an error according to the given specifications.
6. The CAN simulator allows to send a diagnostic request
on the CAN bus to the electronic pretensioner belt control unit
and to receive a positive response to this request.

R EFERENCES
[1] Controller Area Network / www.elearning.vector.com
[2] Can-protocol-Tutorial / www.kvaser.com
[3] International Standard ISO 11898-1 / ***
[4] CAN - Cursuri interne Autoliv / ***
[5] CAN-BUS Shield / www.sparkfun.com
[6] CAN-BUS Shield / www.wiki.seed.cc