International Journal of Computer Applications (0975 – 8887)

Volume 127 – No.16, October 2015

CAN based Simulator Design for Vehicles

Rohini Shinde Manisha Dale Gajanan Udas

M.E.S College of Engineering, M.E.S College of Engineering, Dept. of Advanced Technology,
Pune, Maharashtra, India Pune, Maharashtra, India TATA Technologies, Pune,
Maharashtra, India

ABSTRACT methodology of simulator design and its work flow is

Control Area Network (CAN) based Simulator is developed mentioned in section 3. Experimental results of the simulator
with help of LabVIEW platform which simulates the electrical are given in section 4 which gives the idea about all tests.
system inside the vehicle. This simulator is used to test the
android application running on the dashboard of a vehicle.
2. CAN MESSAGING PROTOCOL
Entire design is based on the CAN architecture, its messaging CAN is peer to peer network protocol. It provides maximum
system and functionality of the electronic control units speed up to 1Mbps. CAN cover the lower two layers of OSI
(ECUs) inside vehicles. Testing depth increased successfully model, which is data link and physical layer respectively. As
with proposed simulator. shown in Figure 1 individual node in network have access to
read and write data on the CAN bus.
General Terms
Embedded Systems, Communication and Networking,
Vehicle Transport Systems

Keywords
CAN, ECU, Messaging Protocol, Reception of frames, and
Transmission of frames.

1. INTRODUCTION
Every vehicle is having the dashboard. It is a control panel
placed in front of the driver of an automobile, which controls
the operation of the vehicle. The instrument cluster contains
gauges such as a speedometer, tachometer, odometer and fuel
gauge and indicators such as gearshift position. Electronic
control unit (ECU) is an embedded system that controls one or
more of the electrical systems in a motor vehicle. ECU reads
signal coming from sensors placed at various parts of the
vehicle and depending on this information, it controls various Figure 1: Control Area Network
important units for example engine and automated operations
CAN node may transmit and receive message frames but not
within the car. It also keeps a check on the performance of
simultaneously onto the network. An arbitration ID is unique
some key components used in the vehicle. As the comfort
throughout the network which labels the frame. If multiple
level in vehicle increases the number of ECUs gets increased
nodes try to transmit a message onto the CAN bus at the same
due to increased level of automation. Therefore the wiring
time, the node with the highest priority (lowest arbitration ID)
harness also gets complicated when we go for point to point
automatically gets bus access. Lower priority nodes must wait
communication of ECUs. With the use of CAN serial bus
until the bus becomes available before trying to transmit
wiring harness get reduced. The CAN bus standard was
again. In this way, we can implement CAN networks to ensure
introduced by the Robert Bosch as communication protocol in
deterministic communication among CAN nodes. Termination
vehicle network. The CAN is a multi-master serial bus used
resistor of value 120Ω is normally used to activate the CAN
for connecting several ECUs and dashboards [2, 3].
bus [1].
In order to make the instrument panel fully digital many
CAN specification 2.0B consist of standard frame and the
manufacturer are trying to build an android applications which
extended frame format as shown in Figure 2 and Figure 3.
will indicate all parameters of the vehicle. Every time it is not
Both the frames are almost same except the identifier field.
possible to test such application on field, by interfacing it with
Identifier extension (IDE) bit indicate whether it is standard or
vehicle. On field testing in development phase of digital
extended. Remote Transmission Request (RTR) differentiates
dashboard is very time consuming and costly method. Hence
between the data frame and remote frame.
it gives rise to the need of development of simulator that will
give the same environment in vehicle, which provides S 11 Bit R I R0 D 0 to 8 C A E I
information coming from ECUs in the form of message Identifier Byte
T D L Data R C O F
packets of CAN protocol. O
Proposed Simulator design is entirely based on the CAN 2.0B R E C C K F S
F
standard of messaging protocol which consists of standard
frame (11 bit identifier) and extended frame (29 bit
identifier)[1]. This paper consists of sections as follows: CAN Figure 2: Standard frame (11 bit Identifier)
protocol is explained in section 2, while the proposed

25
 International Journal of Computer Applications (0975 – 8887)
Volume 127 – No.16, October 2015

S 11 S I 18 R r r D 0 To C A E I
Bit Bit 1 0 L 8 C
Start
O R D T C Bytes R K O F
Ident Ident Data
F ifier R E ifier R C F S

Read Receive
Figure 3: Extended Frame (29 bit Identifier) Generate Transmiss
ion or request
Arbitration IDs
If RTR is dominant bit (logic 0) it indicates it is a data frame frames
Reception
otherwise remote frame. Substitute Remote Request (SRR) Write
field which replaces the RTR in standard frame as placeholder
in extended frame. Four bits of Data Length Code (DLC) Generate Frame No
decides the number of data bytes present in data field. Cyclic Parameters
Redundancy Check (CRC) occupies 15 bits plus delimiter. Check for
Acknowledgement (ACK) consists of 2 bits which get Remote
overwritten by the receiving node with dominant bit, frame?
indicating an error free message has been sent. Start of the Construct Data
frame (SOF) uses dominant bit to assure the beginning of the Yes
Field
frame and end of the frame (EOF) field utilizes 7 bits. To
separate out two frames inter frame space (IFS) with 7 bits is Extract Arbitration
used. The proposed simulator design is based on these frame IDs
structures. Here the nodes are nothing but the ECUs and the Set frame Rate
data field of frame consist of the sensors data such as engine
temperature, coolant temperature, engine speed, odometer,
battery voltage etc[1]-[3]. Send ACK frame

3. PROPOSED METHODOLOGY Send frames over

In automobile test systems, it is essential to take account of CAN N/W
the test cost, efficiency, safety, duration and feasibility. Hence Send Delay
the development of simulator should be good enough so that it response as
exactly replicate the communication among the ECUs and per IDs
dashboard. The simulator should be efficiently designed in End
order to enhance the test quality. Figure 4 shows the concept
of simulator used for testing of android application running on
the dashboard tablet. Figure 5: Architecture of Proposed Method
3.1.1 Transmission of Frames
The CAN frame transmission means the writing of the
messages from simulator to the CAN network through which
dashboard is connected. As shown in Figure 5, first configure
the CAN port then set the arbitration Id followed by length of
data field and frame type that is nothing but the frame
parameters. The major part is the data field construction, in
this step according to the manufacturing specifications of
ECU messages, maintains the byte order of data, width of data
and starting bit position. The data can be engine speed, battery
voltage, battery current, fuel economy, motor speed etc. It is
necessary to maintain the frame rate which can be different for
different message frames. It can be achieved by using multiple
wait function in LABVIEW. At the end simulator sends the
Figure 4: Concept of proposed simulator. frames over the CAN network through which the digital
dashboard is connected.
3.1 Proposed Architecture
The proposed simulator designing process is done in two 3.1.2 Reception of Frames
modes. First mode consists of Message frame transmission Reading of the request frame for particular data from the
that means writing of ECU messages from simulator to dashboard to the simulator is nothing but the second part of
android application. The second mode is request frame proposed architecture as shown in Figure 5. For example
reception that includes reading of request coming from the reception indicates if user wants tire pressure information on
android application to the simulator and then sending its dashboard and he selects that option then this will be request
acknowledgement signal along with its appropriate response frame send to the simulator. In such case the simulator should
again to the application as shown in Figure 4. The detailed first send acknowledgement along with values related to tire
architecture of the proposed simulator is shown in Figure 5. pressure signal to the digital dashboard. While reading the
frame request, first check whether it is remote frame or not.
Remote frame is nothing but the request frame for data. Then
it is required to extract its arbitration Id to confirm about
which message frame has to send as response to that request.
Before sending response directly, first send the

26
 International Journal of Computer Applications (0975 – 8887)
Volume 127 – No.16, October 2015

acknowledgement for the request frame. After that for remote request send to simulator and its acknowledgement Id
processing purpose some delay is provided. The response is 3D0h along with data response belonging to 3E0h Id is send
nothing but transmission of the data frame respective to the by the simulator. Here when the request of 3B0h arrives to the
requested Id as shown in the architecture. simulator, it sends the ACK of 3D0h signal after that
simulator also sends data frame of 3E0h which consist of data
Proposed simulator can write all data frames sequentially and parameters like solar charge power, solar charging voltage and
also it can send the frames on demand, both facilities are current with the values set as shown in Figure 11. From
provided with this simulator. Figure 12, it is clear that there is successful reception of ACK
and data frame from the simulator.
4. EXPERIMENTAL RESULTS
To check the functionality of the simulator NI USB CAN Due to use of these proposed simulators for testing of digital
module and the PCAN module with LABVIEW platform can dashboards one can increase the test depths by increasing the
be used as shown in Figure 6. values of parameters as this is virtual testing environment.

5. CONCLUSION
In this paper successful development of the CAN based
Simulator with LABVIEW is achieved. It is efficiently used
for testing of the android application running on the dashboard
of the Vehicle. Designing of the writing algorithm of CAN
message with accurate periodicity is carried out successfully.
Also implementation of receiving of request frames and its
response generation for standard as well as extended frame
format is completed.
The advantage of virtual test system is mainly the cost
reduction. The tests are reproducible for N number of times
without loss of data. Increased test depth is achieved with
proposed simulator with the help of scaling.
Given simulator is designed with CAN protocol which can be
extended to higher level protocols such as J1939 in future.
Also the system can be extended by giving generic simulators
Figure 6: Experimental Set up for various vehicles.
The simulator is connected with the tablet via NI CAN USB 6. ACKNOWLEDGEMENT
for testing of the dashboard application. But for experimental The authors would like to acknowledge Mr. Prasanta Sarkar,
purpose we can use the set up shown in Figure 6. Complete TATA Motors and TATA Technologies, Pune for their
simulator design is carried out in LabVIEW platform. The guidance and support.
front panels of simulators for two different vehicles are
indicated in Figure 7 and Figure 9 as a Simulator A and 7. REFERENCES
Simulator B. As the number of ECUs inside vehicle changes [1] Steve Corrigan, Introduction to the Controller Area
then number of CAN messages and associated signals Network (CAN), Texas Instruments, Texas, Application
generated by the simulator also get changed. Rep., July 2008.
In Figure 7, one of the parameter is engine oil pressure which [2] Controller Area Network (CAN) Overview, National
is set as 109 KPa and this parameter belong to the Id Instruments Co., Austin, Aug 2014.
18FEE001h. The traced output with PCAN view is as shown
in Figure 8, where 6D data of message 18FEE001h is [3] Vinodh Kumar, Ramesh J, “Automotive In Vehicle
indicated. As (6D)16=(109)10, which confirms the successful Network Protocols,” International Conf. on Computer
transmission of the parameters through simulator to CAN Communication and Informatics, Coimbatore, India, Jan
network. Also the cycle time shows the frame rate achieved 2014.
by the message in Figure 7. [4] Yang Zhu, Hao Hu, Guoqing Xu, Zhiguo Zhao,
Similarly the functionality of Simulator B can be understood “Hardware-In-the-Loop Simulation of Pure Electric
using the Figure 9 and Figure 10. The various parameters Vehicle Control System,” IEEE Computer Society, 2009.
belonging to particular message Ids are indicated in Figure10. [5] Uwe Kiencke, Lars Nielsen, Automotive Control
Total 12 messages with different data fields are shown. Let us Systems For Engine, Driveline, and Vehicle, 2nd ed.,
take example of battery voltage which is set to value 204V Springer, New York, pp. 99-177.
and it is send over 23h Id. It can be traced its transmitted value
[6] CAN, NI-CANTM Hardware and Software Manual,
by observing 023h Id data in Figure 10. On 4th and 5th byte
National Instruments Co., Austin, July 2013.
number (00 CC)16 is obtained which is equivalent to the value
(204)10. Similarly the engine temperature is sending over 281h [7] CAN Physical layer for industrial applications, CAN in
Id with the value of 1120 on 4th byte. In Figure 10, value (00 Automation (CiA), version 3.0.0, February 2010.
70)16 ensures the successful transmission of Engine [8] G. Lipovszki, P. Aradi “SIMULATING COMPLEX
temperature. SYSTEMS AND PROCESSES IN LabVIEW,” Journal
To ensure the proper reception of request frames and the of Mathematical Sciences, Springer, Vol. 132, No. 5,
appropriate response, PCAN USB view software is used from 2006.
which it can send the dummy request Id to the simulator via
CAN network. As shown in Figure. 12 the 3B0h Id is the

27
 International Journal of Computer Applications (0975 – 8887)
Volume 127 – No.16, October 2015

8. APPENDIX

Figure 7: Front Panel of Simulator A for a vehicle

Figure 8: Traced output of simulator A

28
 International Journal of Computer Applications (0975 – 8887)
Volume 127 – No.16, October 2015

Figure 9: Front Panel of Simulator B for a Vehicle

Figure 10: Traced output of simulator B

29
 International Journal of Computer Applications (0975 – 8887)
Volume 127 – No.16, October 2015

Figure 11: Front panel of Receiving of frames

Figure 12: Traced output with PCAN

IJCATM : www.ijcaonline.org 30