International Journal of Pure and Applied Mathematics

Volume 119 No. 7 2018, 1093-1099

ISSN: 1311-8080 (printed version); ISSN: 1314-3395 (on-line version)
url: http://www.ijpam.eu
Special Issue
ijpam.eu

Diagnostic feature automation and diagnostic

tool for In – Vehicle Infotainment (IVI) system
Deepti Susan John, Dr. V. Sathiesh Kumar, Prasath Ramalingam and Manikandan Murugesan

 manufacturers for testing the ECU.

Abstract— The In-Vehicle Infotainment (IVI) system is A diagnostic communication protocol defines what
becoming increasingly complex with the addition of more and diagnostic services in the ECU can be accessed through this
more features to make it more useful and entertaining to the protocol. The protocol used in this project is UDS (Unified
driver. Thus testing the IVI system has become a difficult task
Diagnostic Services) protocol and the ECU used is the IVI
which consumes a large amount of time. The automotive
manufacturers are permitted to use only licensed tools and system.
software for testing. In this paper, we have developed 2 new
methods of testing using the licensed software, Vector CANoe: (i) II. BASIC PRINCIPLE
a diagnostic tool to perform manual testing and (ii) a CAPL
The personal computer (PC) communicates with the IVI
script to perform automatic testing.
system using the CAN (Controller Area Network) protocol.
Index Terms— EOL testing, UDS standard, diagnostic tool, Since the CAN protocol is used, the PC can directly talk to the
diagnostic feature automation, CAPL script IVI system. The IVI system is a typical CAN node containing
the host controller, CAN controller, CAN transceiver and the
I. INTRODUCTION CAN bus. To connect the Vector CANoe software on the PC
to the CAN bus in the IVI system, the CANoe hardware is
T HE In - Vehicle Infotainment (IVI) system located at the
center of the car‟s dashboard provides useful information
such as vehicle alerts, navigation and entertainment in the
used.
The CANoe hardware serves 2 purposes:

form of music, videos and pictures to the user. Today IVI  Relay information from the PC to the IVI system
systems are becoming more complex as they are getting more  Convert the data sent by the PC into CAN frames
and more features to give the user an exhilarating experience which can be understood by the IVI system
while driving the vehicle. Due to the increased number of
features, testing of the IVI system has become a complex and
time consuming process. After the IVI system has been
designed, it needs to be tested by the automotive manufacturer
before integrating it into the vehicle. This type of testing done
at the manufacturing stage is referred to as EOL (End-Of-
Line) testing. Testing methods today make use of open source
programming languages such as python. However the
manufacturers are prohibited from using open source tools and Fig. 1. Basic block diagram
software for testing. Thus the objective of this project is to
develop two methods of testing: (i) Manual testing and (ii) In the proposed manual and automatic testing methods, the
Automatic testing for the IVI system using Vector CANoe, a software on the PC sends a request to the IVI system and the
proprietary software. The programming language used is IVI system responds with a positive or negative response as
CAPL (CAN Access Programming Language). To perform shown in Fig. 1. Based on this response, it is determined
manual testing, a diagnostic tool has been created. The whether the test has passed/ failed.
proposed diagnostic tool provides the manufacturers with 3
modes of request transmission and 15 Customizable Hot Keys III. UDS STANDARD
(CHKs). For performing automatic testing, a CAPL script has UDS has been standardized as ISO 14229 – 1. Some of the
been developed. The proposed CAPL script for diagnostic services defined by this standard have been mentioned below
feature automation completes the testing of the entire ECU along with their service ID (hexadecimal value):
(Electronic Controller Unit) in less time and with little human  Diagnostic session control (0x10)
effort. It also provides a lot of useful information to the  ECU reset (0x11)
manufacturers. As both these methods are developed using  Read DTC (0x19)
licensed software, they can be employed by automotive  Clear DTC (0x14)
 Read data by identifier (0x22)
 Write data by identifier (0x2E)

1093
International Journal of Pure and Applied Mathematics Special Issue

Diagnostic session control is used to request for the desired

session in the ECU. The three sessions available are default,
programming and extended session. Each session enables a set
of diagnostic services and/or functionalities in the ECU. The
ECU is always in the default session. The programming
session enables all the diagnostic services needed for
programming the memory of the ECU. The extended session
provides a higher level of security than the other sessions and
therefore any service that causes any change to the ECU will
be enabled only in this session. The ECU remains in any
session other than the default session only for a few seconds.
ECU reset enables the manufacturer to reset the ECU. The
three types of reset provided are hard reset, key on-off reset
and soft reset. This service is enabled only in the extended
session.
Most modern vehicles today have the capability to detect Fig. 3. General positive response format
faults and store the corresponding fault codes in their memory.
These fault codes are referred to as Diagnostic Trouble Codes The negative response format shown in Fig. 4 is the same
(DTC). The Read DTC service allows the manufacturer to for all services. The response is negative if the value in 2 nd
read all the DTCs or the number of DTCs present in the byte is 0x7F. The negative response trouble code indicates
vehicle‟s memory. By knowing these DTCs, the manufacturer what error occurred.
can quickly identify and repair the faults. The Clear DTC
service is used to clear the DTCs in the memory.
The read and write data by identifier service is used for
requesting for diagnostic data to be read from or written to the
ECU. The identifier is commonly referred to as Parameter
Identifier (PID) and is used to specify what data has to be read
or written. For each ECU specification, there is a unique PID. Fig. 4. Negative response format
The write data by identifier service is enabled only in the
extended session. IV. CAN ACCESS PROGRAMMING LANGUAGE (CAPL)
The request can be a single frame or a multi-frame. The CAPL is pronounced as „Kapple‟. As it is an event based
general request format for all the services is shown in Fig. 2. programming language, the program is organized into sections
When there are multiple frames, frame numbers are used to called event procedures. When an event occurs such as key
distinguish the different frames. The frame number for frame press, switch activation, message reception etc, the
1 is 10, for frame 2 it is 21, for frame 3 it is 22 and so on. The corresponding event procedure is executed. If no event occurs,
data field is optional for both the request and response frames. the program will be idle. An example program is shown in
Fig. 5. When the key „a‟ is pressed, the code typed within the
curly braces will be executed.

on key ‘a’
{
// code
}
Fig. 5. An example CAPL program

V. PROPOSED DIAGNOSTIC TOOL

The panel for the diagnostic tool has been designed using a
separate application provided with Vector CANoe called the
Panel designer which is used for designing graphic panels. All
the controls i.e. buttons, drop down box, input-output box etc
Fig. 2. General request format
used in the panel must be assigned to environment variables
and these variables should be defined in the CANdb++ (CAN
A response is said to be positive if the 2nd or 3rd byte has a
Database) editor. Environment variables make the connection
value equal to the service id plus 40. The positive response
can be a single frame or multiple frames. The general positive between the controls on the panel and its associated CAPL
response format is shown in Fig. 3. code possible. Fig. 6 shows the environment variables
database that was developed for this project.

1094
International Journal of Pure and Applied Mathematics Special Issue

Fig. 8. Types of request transmission

In the general R/W section (shown in Fig. 9), the data

length of the request message is typed in the data length box.
Fig. 6. Environment variables database The data length need not be specified for services that have a
constant length request. From the service type drop down
The developed diagnostic tool shown in Fig. 7 provides the
menu, the desired service is selected. In the PID box, the PID
manufacturer with three ways to send a request (shown in Fig.
8). value can be typed. The request is typed in the boxes D0 – D7
which represents the 8 bytes of a frame. By using the „+‟ or „-‟
button, we can move from one frame to another. The save and
clear button is used to save the contents of the request into a
buffer and to clear all the entries in the general R/W section
respectively. The frame no box specifies the number of the
current frame. Initially the request ID and frame number will
be set as 0x750 and 1 respectively. When send request button
is pressed, the request is transmitted.

Fig. 9. General R/W section

In the direct transmission section (shown in Fig. 10), the

(a) request can be typed continuously leaving space between the
bytes in the „data to transmit‟ box instead of typing each byte
in a separate box as in the General R/W section. On clicking
the send button, the request is sent.

Fig. 10. Direct transmission section

Hot keys (shown in Fig. 11) ensure that the manufacturer no

(b)
longer needs to type the frequently used requests. By simply
Fig. 7. (a) Top and (b) bottom portion of the diagnostic tool pressing the key, the request saved in the key is transmitted.
Two kinds of hot keys have been provided:

1095
International Journal of Pure and Applied Mathematics Special Issue

 Fixed hot keys (FHK) – Frequently used requests are VII. RESULTS AND DISCUSSIONS
already stored in the key.
A. Diagnostic tool
 Customized hot keys (CHK) – Allows the
manufacturer to save any request that he wants to the An example of how a request is sent and received in the
key. 15 such keys have been provided. Two check general R/W section is shown in Fig. 12. The ECU reset
boxes are present: General R/W and Direct service is selected from the service type drop down list and the
transmission. If the General R/W check box is ticked, value 3 is typed in D0 to request for the sub-function - soft
it indicates that the message typed in the General reset as shown in Fig. 12(a). On clicking send request button,
R/W section needs to be saved to the key. The same the values entered are put into the CAN request frame (Fig. 2)
applies to the Direct transmission check box as well. and transmitted. The positive response received is shown in
Fig. 12(b).

(a)

(b)
Fig. 12. (a) ECU reset request and (b) ECU reset response

Fig. 13 shows an example for a write request using a fixed

Fig. 11. Hot keys section hot key. Before a write request is sent, the request for
extended session is sent. Once a positive response is received,
In all the three sections, single and multiple frames can be the write request is sent. In this example we are changing the
transmitted and received accurately. The response from the preset value of the tuner. A positive response indicates that the
IVI system will always be displayed in the message data preset value has changed. The same can be observed in the IVI
(payload) sub-section of the General R/W section. system.

VI. PROPOSED DIAGNOSTIC FEATURE AUTOMATION

The developed CAPL script automatically tests all the
diagnostic features in the IVI system. When the CAPL script
is run, the requests are sent one after the other to the IVI
system and the responses received are displayed. The
advantage of automatic testing is that it reduces the amount of
time and effort required for testing. The developed CAPL
script takes approximately 1 minute 40 seconds to test all
features of the IVI system.

Provides useful information to the manufacturer such as:

 Information about each test
 Result of test – Pass/ Fail
 Total no of tests
 No of tests that passed/ failed
 Response received (Single and multiple frames)
 List of tests that failed (a)
 No of tests that failed due to a particular error

1096
International Journal of Pure and Applied Mathematics Special Issue

(b) (b)
Fig. 13. (a) Write request and (b) write response Fig. 14. (a) Request is saved to CHK 12 (b) On pressing CHK 12, the
request saved in it is transmitted
Fig. 14 shows an example for Customizable Hot Keys
(CHK). The request is typed in the „data to transmit‟ box of B. CAPL based diagnostic feature automation
the Direct transmission section. The send button has a dual
functionality. It not only sends the request but it also saves the The result for CAPL based diagnostic feature automation is
request into a buffer. The Direct transmission check box is shown in Fig. 15. The amount of time taken is shown at the
selected to indicate that the request typed in the Direct bottom right corner of the window in Fig 15(b).
transmission section needs to saved to the desired CHK. A text
box is provided near each CHK, for typing the name/ purpose
of the CHK, so that the manufacturer knows what he has
saved in the CHK. On clicking the desired CHK, the request is
saved in it (shown in Fig. 14(a)). After saving the request, the
check box is deselected and now whenever the CHK is
pressed and the request is transmitted and the response
received can be viewed in the General R/W section (shown in
Fig. 14(b)).

(a)

(a)

(b)

Fig. 15. (a) Information about each test is displayed and (b) Result for
CAPL based diagnostic feature automation

1097
International Journal of Pure and Applied Mathematics Special Issue

C. Hardware implementation Pacific Power and Energy Engineering Conference (APPEEC), pp. 1-5,
March 2010.
Fig. 16 shows the overall hardware implementation. [8] P. O‟Reilly, “An overview of the potential contribution of diagnostics to
improving vehicle safety and reducing vehicle emissions”, IEE
Colloquium on Vehicle Diagnostics in Europe, February 1994.
[9] P. Greening, “On-board diagnostics for control of vehicle emissions”,
IEE Colloquium on Vehicle Diagnostics in Europe, February 1994.
[10] Swathi K and S M Narasimhan, “Implementation of diagnostics module
in car-infotainment system,” International Journal of Scientific &
Engineering Research, vol. 6, pp. 1025-1028, May 2015.
[11] C. Sasikumar, Rohit Agrawal, Saurabh Gupta, Saurabh Gupta and Ravi
Maheshwari, “Built in self-test for fault tolerant real time in-vehicle
networks through automotive diagnostics,” 2011 International
Conference on Emerging Trends in Networks and Computer
Communications (ETNCC), pp. 379 – 382, 2011.
[12] Hela Lajmi, Habib. M. Kammoun and Adel. M. Alimi, “Advanced
control units diagnostic based on Ethernet for smart cars,” 2015 4th
International Conference on Advanced Logistics and Transport (ICALT),
pp. 269 – 274, 2015.
[13] Piet Engelke and Hermann Obermeir, “Funding project DIANA –
Integrated diagnostics for the analysis of electronic failures in vehicles”,
2012 17th IEEE European Test Symposium (ETS), pp. 1-1, May 2012.
[14] Monica Sălcianu and Cristian Fosalau, “A new CAN diagnostic fault
simulator based on UDS protocol,” 2012 International Conference and
Fig. 16. Overall hardware implementation Exposition on Electrical and Power Engineering, pp. 820-824, October
2012.
[15] Anca Lupei and Loredana Stanciu, “Application for UDS automated test
VIII. CONCLUSION generation,” 2016 IEEE 11th International Symposium on Applied
Two methods of testing: a diagnostic tool to perform Computational Intelligence and Informatics (SACI), 12-14 May 2016.
manual testing and a CAPL script for performing automatic [16] Alexandros Mouzakitis, Nataraja Muniyappa, Richard Parker and Shamal
Puthiyapurayal, “Advanced automated onboard vehicle diagnostics
testing of the diagnostic features in the IVI system have been testing”, UKACC International Conference on Control 2010, September
developed. The tool has been developed to make the 2010.
manufacturer‟s work easier by providing new features like [17] Alexandros Mouzakitis, Anand Nayak and Shamal Puthiyapurayal,
three options for sending requests and 15 customizable hot “Automated fault diagnostics testing for automotive electronic control
keys. Diagnostic feature automation using CAPL script units deploying hardware-in-the-loop”, UKACC International Conference
on Control 2010, pp. 1-6, September 2010.
completes the testing of the IVI system within a short period
[18] Supriya Kelkar and Raj Kamal, “Adaptive fault diagnosis algorithm for
of time and requires less human effort. Thus the motivation to Controller Area Network,” IEEE Transactions on Industrial Electronics,
help the automotive manufacturers to test the IVI system Volume 61, Issue 10, pp. 5527 – 5537, October 2014.
manually and automatically using licensed tools and software
has been achieved. Deepti Susan John completed her B.E in Electronics and
Communication Engineering from Anna University in 2015.
REFERENCES She is an alumnus of Meenakshi Sundararajan Engineering
[1] Deepti Susan John, Dr. V. Sathiesh Kumar, Prasath Ramalingam and College, Chennai, India. She is currently pursuing M.E in
Manikandan Murugesan, “In – Vehicle Infotainment (IVI) system VLSI design and Embedded systems at Anna University –
diagnostic tool”, in Proceedings of 9th National Conference on Signal
Processing, Communication and VLSI Design (NCSCV‟17), Anna Madras Institute of Technology Campus, Chennai, India and is
University, Regional Campus, Coimbatore, pp. 486 – 491, March 2017. doing her internship at Visteon Technical and Services Centre
[2] Giovanni Betta, Domenico Capriglione, Antonio Pietrosanto and Paolo Pvt. Ltd, Chennai, India.
Sommella, “A Methodology to Test Instrument Software: An
Automotive Diagnostic System Application,” IEEE Transactions on Dr. V. Sathiesh Kumar is an Assistant Professor, Department
Instrumentation and Measurement, vol. 57, pp. 2733-2741, June 2008.
[3] Shankar. C. Subramanian, Swaroop Darbha and K. R. Rajagopal, “A
of Electronics Engineering, Anna University - Madras Institute
diagnostic system for airbrakes in commercial vehicles”, IEEE of Technology Campus, Chennai, India.
Transactions on Intelligent Transportation Systems, vol. 7, no. 3, pp.
360-376, September 2006. Prasath Ramalingam is a senior software design engineer at
[4] Rajesh Rajamani, Adam. S. Howell, Chieh Chen, J. Karl. Hedrick and Visteon Technical and Services Centre Pvt. Ltd, Chennai,
Masayoshi Tomizuka, “A complete fault diagnostic system for
automated vehicles operating in a platoon”, IEEE Transactions on India.
Control Systems Technology, vol. 9, no. 4, pp. 553-564, July 2001.
[5] J. R. Wagner, “Failure mode testing tool set for automotive electronic Manikandan Murugesan is a software project manager at
controllers”, IEEE Transactions on Vehicular Technology, vol. 43, pp. Visteon Technical and Services Centre Pvt. Ltd, Chennai,
156-163, February 1994. India.
[6] T. M. Cummings and M. J. Hall, “Vehicle diagnostics – A system
view”, Proceedings of the International Congress on Transportation
Electronics, 1990. Vehicle Electronics in the 90‟s, pp. 473-479, Oct
1990.
[7] Jie Hu, Fuwu Yan, Jing Tian, Pan Wang and Kai Cao, “Developing PC-
based automobile diagnostic system based on OBD system”, 2010 Asia-

1098
1099
1100