International Journal of Pure and Applied Mathematics

Transcription

1 Volume 119 No , ISSN: (printed version); ISSN: (on-line version) url: ijpam.eu 1 Diagnostic feature automation and diagnostic tool for In Vehicle Infotainment (IVI) system Deepti Susan John, Dr. V. Sathiesh Kumar, Prasath Ramalingam and Manikandan Murugesan 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 T 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 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) 1093

2 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. 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 2 nd 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. on key a { // code } Fig. 5. An example CAPL program Fig. 2. General request format A response is said to be positive if the 2 nd or 3 rd 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. 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. 1094

3 3 Fig. 8. Types of request transmission 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). 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 Fig. 7. Top and bottom portion of the diagnostic tool 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 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. A. Diagnostic tool VII. RESULTS AND DISCUSSIONS 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. 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. Fig. 12. ECU reset request and ECU reset response 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. 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. 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 1096

5 5 Fig. 13. Write request and 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). 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). Fig. 14. Request is saved to CHK 12 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. Fig. 15. Information about each test is displayed and Result for CAPL based diagnostic feature automation 1097

6 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 9 th National Conference on Signal Processing, Communication and VLSI Design (NCSCV 17), Anna University, Regional Campus, Coimbatore, pp , March [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 , June [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 , September [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 , July [5] J. R. Wagner, Failure mode testing tool set for automotive electronic controllers, IEEE Transactions on Vehicular Technology, vol. 43, pp , February [6] T. M. Cummings and M. J. Hall, Vehicle diagnostics A system view, Proceedings of the International Congress on Transportation Electronics, Vehicle Electronics in the 90 s, pp , Oct [7] Jie Hu, Fuwu Yan, Jing Tian, Pan Wang and Kai Cao, Developing PCbased automobile diagnostic system based on OBD system, 2010 Asia- Pacific Power and Energy Engineering Conference (APPEEC), pp. 1-5, March [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 [9] P. Greening, On-board diagnostics for control of vehicle emissions, IEE Colloquium on Vehicle Diagnostics in Europe, February [10] Swathi K and S M Narasimhan, Implementation of diagnostics module in car-infotainment system, International Journal of Scientific & Engineering Research, vol. 6, pp , May [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 , [12] Hela Lajmi, Habib. M. Kammoun and Adel. M. Alimi, Advanced control units diagnostic based on Ethernet for smart cars, th International Conference on Advanced Logistics and Transport (ICALT), pp , [13] Piet Engelke and Hermann Obermeir, Funding project DIANA Integrated diagnostics for the analysis of electronic failures in vehicles, th IEEE European Test Symposium (ETS), pp. 1-1, May [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 , October [15] Anca Lupei and Loredana Stanciu, Application for UDS automated test generation, 2016 IEEE 11th International Symposium on Applied Computational Intelligence and Informatics (SACI), May [16] Alexandros Mouzakitis, Nataraja Muniyappa, Richard Parker and Shamal Puthiyapurayal, Advanced automated onboard vehicle diagnostics testing, UKACC International Conference on Control 2010, September [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 [18] Supriya Kelkar and Raj Kamal, Adaptive fault diagnosis algorithm for Controller Area Network, IEEE Transactions on Industrial Electronics, Volume 61, Issue 10, pp , October Deepti Susan John completed her B.E in Electronics and Communication Engineering from Anna University in 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

7 1099

8 1100