diagnostic feature automation and diagnostic tool for in

1

Abstract— The In-Vehicle Infotainment (IVI) system is

becoming increasingly complex with the addition of more and

more features to make it more useful and entertaining to the

driver. Thus testing the IVI system has become a difficult task

which consumes a large amount of time. The automotive

manufacturers are permitted to use only licensed tools and

software for testing. In this paper, we have developed 2 new

methods of testing using the licensed software, Vector CANoe: (i)

a diagnostic tool to perform manual testing and (ii) a CAPL

script to perform automatic testing.

Index Terms— EOL testing, UDS standard, diagnostic tool,

diagnostic feature automation, CAPL script

I. INTRODUCTION

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

form of music, videos and pictures to the user. Today IVI

systems are becoming more complex as they are getting more

and more features to give the user an exhilarating experience

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

software for testing. Thus the objective of this project is to

develop two methods of testing: (i) Manual testing and (ii)

Automatic testing for the IVI system using Vector CANoe, a

proprietary software. The programming language used is

CAPL (CAN Access Programming Language). To perform

manual testing, a diagnostic tool has been created. The

proposed diagnostic tool provides the manufacturers with 3

modes of request transmission and 15 Customizable Hot Keys

(CHKs). For performing automatic testing, a CAPL script has

been developed. The proposed CAPL script for diagnostic

feature automation completes the testing of the entire ECU

(Electronic Controller Unit) in less time and with little human

effort. It also provides a lot of useful information to the

manufacturers. As both these methods are developed using

licensed software, they can be employed by automotive

manufacturers for testing the ECU.

A diagnostic communication protocol defines what

diagnostic services in the ECU can be accessed through this

protocol. The protocol used in this project is UDS (Unified

Diagnostic Services) protocol and the ECU used is the IVI

system.

II. BASIC PRINCIPLE

The personal computer (PC) communicates with the IVI

system using the CAN (Controller Area Network) protocol.

Since the CAN protocol is used, the PC can directly talk to the

IVI system. The IVI system is a typical CAN node containing

the host controller, CAN controller, CAN transceiver and the

CAN bus. To connect the Vector CANoe software on the PC

to the CAN bus in the IVI system, the CANoe hardware is

used.

The CANoe hardware serves 2 purposes:

Relay information from the PC to the IVI system

Convert the data sent by the PC into CAN frames

which can be understood by the IVI system

Fig. 1. Basic block diagram

In the proposed manual and automatic testing methods, the

software on the PC sends a request to the IVI system and the

IVI system responds with a positive or negative response as

shown in Fig. 1. Based on this response, it is determined

whether the test has passed/ failed.

III. UDS STANDARD

UDS has been standardized as ISO 14229 – 1. Some of the

services defined by this standard have been mentioned below

along with their service ID (hexadecimal value):

Diagnostic session control (0x10)

ECU reset (0x11)

Read DTC (0x19)

Clear DTC (0x14)

Read data by identifier (0x22)

Write data by identifier (0x2E)

Diagnostic feature automation and diagnostic

tool for In – Vehicle Infotainment (IVI) system

Deepti Susan John, Dr. V. Sathiesh Kumar, Prasath Ramalingam and Manikandan Murugesan

T

International Journal of Pure and Applied MathematicsVolume 119 No. 7 2018, 1093-1099ISSN: 1311-8080 (printed version); ISSN: 1314-3395 (on-line version)url: http://www.ijpam.euSpecial Issue ijpam.eu

1093

2

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

faults and store the corresponding fault codes in their memory.

These fault codes are referred to as Diagnostic Trouble Codes

(DTC). The Read DTC service allows the manufacturer to

read all the DTCs or the number of DTCs present in the

vehicle‟s memory. By knowing these DTCs, the manufacturer

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.

The write data by identifier service is enabled only in the

extended session.

The request can be a single frame or a multi-frame. The

general request format for all the services is shown in Fig. 2.

When there are multiple frames, frame numbers are used to

distinguish the different frames. The frame number for frame

1 is 10, for frame 2 it is 21, for frame 3 it is 22 and so on. The

data field is optional for both the request and response frames.

Fig. 2. General request format

A response is said to be positive if the 2nd

or 3rd

byte has a

value equal to the service id plus 40. The positive response

can be a single frame or multiple frames. The general positive

response format is shown in Fig. 3.

Fig. 3. General positive response format

The negative response format shown in Fig. 4 is the same

for all services. The response is negative if the value in 2nd

byte is 0x7F. The negative response trouble code indicates

what error occurred.

Fig. 4. Negative response format

IV. CAN ACCESS PROGRAMMING LANGUAGE (CAPL)

CAPL is pronounced as „Kapple‟. As it is an event based

programming language, the program is organized into sections

called event procedures. When an event occurs such as key

press, switch activation, message reception etc, the

corresponding event procedure is executed. If no event occurs,

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.

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

used in the panel must be assigned to environment variables

and these variables should be defined in the CANdb++ (CAN

Database) editor. Environment variables make the connection

between the controls on the panel and its associated CAPL

code possible. Fig. 6 shows the environment variables

database that was developed for this project.

on key ‘a’ { // code

}

International Journal of Pure and Applied Mathematics Special Issue

1094

3

Fig. 6. Environment variables database

The developed diagnostic tool shown in Fig. 7 provides the

manufacturer with three ways to send a request (shown in Fig.

8).

(a)

(b)

Fig. 7. (a) Top and (b) bottom portion of the diagnostic tool

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.

The data length need not be specified for services that have a

constant length request. From the service type drop down

menu, the desired service is selected. In the PID box, the PID

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

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

longer needs to type the frequently used requests. By simply

pressing the key, the request saved in the key is transmitted.

Two kinds of hot keys have been provided:


1095

4

Fixed hot keys (FHK) – Frequently used requests are

already stored in the key.

Customized hot keys (CHK) – Allows the

manufacturer to save any request that he wants to the

key. 15 such keys have been provided. Two check

boxes are present: General R/W and Direct

transmission. If the General R/W check box is ticked,

it indicates that the message typed in the General

R/W section needs to be saved to the key. The same

applies to the Direct transmission check box as well.

Fig. 11. Hot keys section

In all the three sections, single and multiple frames can be

transmitted and received accurately. The response from the

IVI system will always be displayed in the message data

(payload) sub-section of the General R/W section.

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

No of tests that failed due to a particular error

VII. RESULTS AND DISCUSSIONS

A. Diagnostic tool

An example of how a request is sent and received in the

general R/W section is shown in Fig. 12. The ECU reset

service is selected from the service type drop down list and the

value 3 is typed in D0 to request for the sub-function - soft

reset as shown in Fig. 12(a). On clicking send request button,

the values entered are put into the CAN request frame (Fig. 2)

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

hot key. Before a write request is sent, the request for

extended session is sent. Once a positive response is received,

the write request is sent. In this example we are changing the

preset value of the tuner. A positive response indicates that the

preset value has changed. The same can be observed in the IVI

system.

(a)


1096

5

(b)

Fig. 13. (a) Write request and (b) write response

Fig. 14 shows an example for Customizable Hot Keys

(CHK). The request is typed in the „data to transmit‟ box of

the Direct transmission section. The send button has a dual

functionality. It not only sends the request but it also saves the

request into a buffer. The Direct transmission check box is

selected to indicate that the request typed in the Direct

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)

(b)

Fig. 14. (a) Request is saved to CHK 12 (b) On pressing CHK 12, the request saved in it is transmitted

B. CAPL based diagnostic feature automation

The result for CAPL based diagnostic feature automation is

shown in Fig. 15. The amount of time taken is shown at the

bottom right corner of the window in Fig 15(b).

(a)

(b)

Fig. 15. (a) Information about each test is displayed and (b) Result for

CAPL based diagnostic feature automation


1097

6

C. Hardware implementation

Fig. 16 shows the overall hardware implementation.

Fig. 16. Overall hardware implementation

VIII. CONCLUSION

Two methods of testing: a diagnostic tool to perform

manual testing and a CAPL script for performing automatic

testing of the diagnostic features in the IVI system have been

developed. The tool has been developed to make the

manufacturer‟s work easier by providing new features like

three options for sending requests and 15 customizable hot

keys. Diagnostic feature automation using CAPL script

completes the testing of the IVI system within a short period

of time and requires less human effort. Thus the motivation to

help the automotive manufacturers to test the IVI system

manually and automatically using licensed tools and software

has been achieved.

REFERENCES

[1] Deepti Susan John, Dr. V. Sathiesh Kumar, Prasath Ramalingam and Manikandan Murugesan, “In – Vehicle Infotainment (IVI) system diagnostic tool”, in Proceedings of 9th National Conference on Signal Processing, Communication and VLSI Design (NCSCV‟17), Anna University, Regional Campus, Coimbatore, pp. 486 – 491, March 2017.

[2] Giovanni Betta, Domenico Capriglione, Antonio Pietrosanto and Paolo Sommella, “A Methodology to Test Instrument Software: An Automotive Diagnostic System Application,” IEEE Transactions on Instrumentation and Measurement, vol. 57, pp. 2733-2741, June 2008.

[3] Shankar. C. Subramanian, Swaroop Darbha and K. R. Rajagopal, “A diagnostic system for airbrakes in commercial vehicles”, IEEE Transactions on Intelligent Transportation Systems, vol. 7, no. 3, pp. 360-376, September 2006.

[4] Rajesh Rajamani, Adam. S. Howell, Chieh Chen, J. Karl. Hedrick and Masayoshi Tomizuka, “A complete fault diagnostic system for automated vehicles operating in a platoon”, IEEE Transactions on Control Systems Technology, vol. 9, no. 4, pp. 553-564, July 2001.

[5] J. R. Wagner, “Failure mode testing tool set for automotive electronic controllers”, IEEE Transactions on Vehicular Technology, vol. 43, pp. 156-163, February 1994.

[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-

Pacific Power and Energy Engineering Conference (APPEEC), pp. 1-5, March 2010.

[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 Exposition on Electrical and Power Engineering, pp. 820-824, October 2012.

[15] Anca Lupei and Loredana Stanciu, “Application for UDS automated test generation,” 2016 IEEE 11th International Symposium on Applied Computational Intelligence and Informatics (SACI), 12-14 May 2016.

[16] Alexandros Mouzakitis, Nataraja Muniyappa, Richard Parker and Shamal Puthiyapurayal, “Advanced automated onboard vehicle diagnostics testing”, UKACC International Conference on Control 2010, September 2010.

[17] Alexandros Mouzakitis, Anand Nayak and Shamal Puthiyapurayal, “Automated fault diagnostics testing for automotive electronic control units deploying hardware-in-the-loop”, UKACC International Conference on Control 2010, pp. 1-6, September 2010.

[18] Supriya Kelkar and Raj Kamal, “Adaptive fault diagnosis algorithm for Controller Area Network,” IEEE Transactions on Industrial Electronics, Volume 61, Issue 10, pp. 5527 – 5537, October 2014.

Deepti Susan John completed her B.E in Electronics and

Communication Engineering from Anna University in 2015.

She is an alumnus of Meenakshi Sundararajan Engineering

College, Chennai, India. She is currently pursuing M.E in

VLSI design and Embedded systems at Anna University –

Madras Institute of Technology Campus, Chennai, India and is

doing her internship at Visteon Technical and Services Centre

Pvt. Ltd, Chennai, India.

Dr. V. Sathiesh Kumar is an Assistant Professor, Department

of Electronics Engineering, Anna University - Madras Institute

of Technology Campus, Chennai, India.

Prasath Ramalingam is a senior software design engineer at

Visteon Technical and Services Centre Pvt. Ltd, Chennai,

India.

Manikandan Murugesan is a software project manager at

Visteon Technical and Services Centre Pvt. Ltd, Chennai,

India.


1098

diagnostic feature automation and diagnostic tool for in

Documents