Development and Research of Vehicle Fault Diagnosi

Development and Research of Vehicle Fault

Diagnosis System

Hu Jie, Li Hongfei, Sheng Xiangzheng, Cao Kai, Yan Fuwu School of Automotive Engineer, Wuhan University of Technology

Wuhan, Hubei province, 430070, China

auto_hj@163.com

Abstract —The status of vehicle fault diagnosis protocols applied in the market is analyzed, and also are the problems of the hand-held diagnosis instruments. Through the way of combination of PC-style diagnosis software and Vehicle Communication Interface (VCI), the popular type of vehicle fault diagnosis system based on both K-line and Controller Area Network (CAN) is developed. The diagnosis system is divided into four layers (application layer 、network layer 、data link layer and physical layer) referred to the Open System Interconnection (OSI) network model to develop the KWP2000 protocol stack. In order to enhance the commonality of the system, protocol of application layer is implemented by PC-style diagnosis software, while protocols of network layer 、data link layer and physical layer are implemented by VCI. While developing PC-style diagnosis software, modular construction method is adopted to facilitate further upgrading and expansion. The test research in real vehicles proves that this system can not only perform well to diagnose the faulted vehicles, but also have the potential for further upgrading.

Keywords-KWP2000; vehicle communication interface; diagnosis software; vehicle fault diagnosis

I. I NTRODUCTION

With the accelerating development of in-vehicle networks, the diagnosis protocols used by automobile manufacturers become unified gradually [1]. The diagnosis protocol wildly applied in Europe is KWP2000 (Keyword Protocol 2000), which is the improvement and extension of the diagnosis protocol OBD-II (On Board Diagnostic II). It can not only realize the whole on board diagnostic services, but also satisfy the standard of EOBD (European On Board Diagnostic). Distinguished by the differences of physical layer and data link layer, KWP2000 is divided into two parts, ISO14230 (ISO/WD 14230-1~14230-4 [2~5]) based on K-line and ISO15765 (ISO/WD 15765-1~15765-4 [6~9]) based on CAN bus with their application layer protocol completely compatible with each other [10].

The diagnosis protocol based on K-line has been developed for ages, as a result, it has a comparatively large market share, especially for those relatively old vehicle types, they all adopted the K-line diagnosis protocol. However, the diagnosis protocol based on CAN bus is now been promoting rapidly due to its advantages such as high baud rate and non-destructive arbitration mechanism. Sometimes automakers even adopt different diagnosis protocols in the same car, for instance, engine control module, transmission control module and body control module conform to the protocol ISO15765

while safety control module conforms to the protocol ISO14230. Against the status quo, this paper developed an intelligent diagnostic tool that supports both ISO14230 and ISO15765, which can provide solution to the situation of coexisting of different diagnosis protocols.

II.

SCHEMATIC DESIGN OF DIAGNOSIS SYSTEM

The diagnostic device is composed of diagnostic interface circuit and scanning tool which needs hardware and software to support its normal operation. There are mainly two types of diagnostic device used in aftermarket, handheld and PC-style. With increasing complexity of electronic control systems on board, after-sales engineers’ demand for accurate diagnosis becomes more and more urgent. The traditional handheld diagnostic tool can not satisfy requirements of modern automotive diagnostics due to the shortcomings such as low diagnostic efficiency, upgrade problems and no ECU plash reprogramming caused by the restraints of processor performance and memory size. On the contrary, PC-style diagnosis system is becoming more and more popularized owing to PC’s increasing performance price ratio [11]. Considering the compatibility of application layer protocol and differences of other layers protocols, the diagnosis system which supports both ISO14230 and ISO15765 is divided into two parts, VCI (Vehicle Communication Interface) and diagnosis software runs on the computer. Because automakers can customize the specific diagnostic services, the application software must be modified when new diagnostic services need to be added. In order to solve the problem and for the convenience of further upgrading and commonality of VCI, while designing the diagnosis protocol stack, VCI implements the protocols of network layer, data link layer and physical layer while diagnosis software implements the protocol of application layer.

VCI is a kind of universal in-vehicle network communication interface which integrates network communication protocol. The hardware interface of VCI realizes physical connection and level translation. Meanwhile, it controls data exchange between diagnosis software and in-vehicle network. The diagnosis software provides human machine interface, it modularizes the diagnostic services of application protocol, including DTC (diagnostic trouble code), freeze frame, data flow monitoring, ECU flash reprogramming, actuator input/output test and so on. What’s more, the application software can display the diagnosis with

Fig.1 shows the entire architecture of diagnosis system, PC connects with VCI through USB bridge module or Bluetooth wireless module, while VCI connects to in-vehicle network through standard diagnostic connector. In this way, communication channel is established between PC and ECU. There are two types of messages transmitted in the communication channel, diagnostic message and non-diagnostic message. Diagnostic message means the requests and feedbacks correspond to the specific application services. Non-diagnostic message is used to set the communication parameters of VCI, such as diagnosis protocol, baud rate, identifier filter, etc. When the system works, PC sends diagnostic request to VCI, VCI packages the request to certain pattern prescribed by the protocol selected before and send the message to in-vehicle network, each ECU which connects to the network will check the target address or identifier of the message and decide which kind of response should be replied, positive response, negative response or discard the request. During the ECU response sequence, the response message transmit to VCI will be pretreated and then send to PC, PC will analyze the response and display the

diagnostic results with numeric or graphic curve.

Figure 1.Schema of entire architecture of diagnosis system

III.VEHICLE COMMUNICATION INTERFACE

A.Hardware

As is shown in the VCI section of Figure 1, the architecture

of hardware is composed of nine portions: digital core circuit,

K-line interface circuit, CAN bus interface circuit, USB

circuit, Bluetooth circuit, SD card driver circuit, real time

clock circuit, voltage conversion circuit and human-machine

interface circuit.

The control core of VCI is Freescale’s 16-bit

microprocessor of HCS12 series. The voltage switch chip

MC33290 is used to realize the level translation between

RS232 and K-line. The CAN bus interface is composed of

CAN controller and CAN transceiver, HCS12 integrates CAN

controller which fully complies the standard CAN 2.0A/B. The

chip PCA82C250 is selected as the CAN transceiver to

implement physical connection between CAN controller and

CAN bus. Considering the space limitations of USB cable, the

Bluetooth module is added into VCI to communicate with PC,

VCI can identify whether USB or Bluetooth is adapted by

customer automatically without need of manual switching. The

raw diagnostic data is stored in SD card with timestamps

acquired from real time clock chip DS1302.

B.Firmware

Firmware is the software that resides in the flash of

microprocessor which implements the protocols of network

layer and data link layer. Firmware design is the most

complicated but important task during the development of

diagnosis protocol stack. There are two parts, main program

and ISRs (Interrupt Service Routine), which work

collaboratively when firmware runs. Firstly, Main program

initializes all the hardware modules. Then, it detects which

way VCI takes to communicate with PC through identifying

the state of an I/O port that connects to the chip CP2102, if the

connection is established through USB cable, CP2102 will set

the corresponding port in high status. Otherwise, low status

will be set to indicate the Bluetooth communication mode.

Finally, the diagnosis protocol must be selected. Meanwhile,

through AT commands, the communication parameters

correspond to the selected protocol can be set. The ISRs

receive the diagnostic requests send by PC, package the

requests into messages conform to the selected diagnosis

protocol, and send the messages to the in-vehicle network.

They also controls the data exchange between VCI and ECU,

ECU response frames will be saved in the buffer before all the

frames for a single request are received. After a complete

response is received, VCI will send them to PC with additional

timestamps.

Figure 2.Network structure of layers of VCI

As is shown in Fig.2, Hierarchical design is applied to

build the structure of firmware referred to the ISO/OSI

network model. The whole system can be divided into four

layers from top to bottom as mentioned above, application

layer, network layer, data link layer and physical layer. Each

layer achieves desired functions independently, receives

services from lower layer and provides service interfaces for

the upper.

1)ISO14230 implementation

Figure 3.Flowchart of implementation of protocol ISO14230

Fig.3 shows the implementation of protocol ISO14230 with flowchart. Serial port of VCI receives diagnostic service request from PC, and then package it into a complete frame with additional data bytes. We can see in Table 1, a complete frame includes three parts: (1) header; (2) data bytes; (3) checksum. The header consists of maximum 4 bytes depends on the format byte, target and source address are optional for use with multi node connections. An optional separate length byte allows a frame length more than 63 bytes. After packing the data field, checksum must be added to the frame end, which is calculated by adding all the bytes excluding the checksum.

Before any communication between VCI and ECU can take place, the communications link must be established through an initialization process. There are two types of initialization: “5-baud initialization” and “fast initialization”. Here we adopt the second initialization type. The fast initialization process is shown in Fig.4, maintaining the voltage at low level and at high level for 25ms successively after ECU is powered for at least 300ms. Follow the first falling edge, VCI sends a Start Communication service request at the normal 10.4 K baud rate. The initialization process is complete after ECU positively response to the prior Start Communication service request. After the successful initialization, VCI must shake hands periodically with ECU to indicate it is present. The shaking hands is achieved by a timer of microprocessor with the period adjustable ranged from 1ms to 5000ms. During the diagnosis, if ECU does not response before P2 (Time between tester request and ECU response or two ECU responses) expires, request failed will be indicated to PC. Otherwise, if ECU responses normally, the response will be transmitted to PC for further analysis, and both the request and response with timestamps will be save in SD card.

TABLE I. M ESSAGE STRUCTURE OF KWP2000 BASED ON K-LINE

Header Data byte checksum Fmt TA1 SA1 Len1 SId2 Data CS

Max. 4 bytes Max. 255 bytes 1 byte

1: Bytes are optional, depending on the format byte; 2: Service identifier.

p

Figure 4.Procedures of fast initialization of ISO14230

2)ISO15765 implementation

Fig.5 shows the implementation of protocol ISO15765 with flowchart. CAN frame is a kind of short frame and bytes in its data field must be less than or equal to 8, so four types of Network Protocol Data Unit (N_PDU) are defined in the network layer protocol to transmit longer messages. Table 2 shows the four types of N_PDU. Transmission of messages up to six (in case of extended or mixed addressing) or seven (in case of normal addressing) data bytes is performed via transmission of Single Frame. Transmission of longer messages is performed via segmentation of the message and transmissions of multiple N_PDUs which are First Frame and Consecutive Frames. While transmitting longer messages, the flow control mechanism ensures the data synchronization between VCI and ECU; meanwhile, the timeout mechanism with timeout parameters (N_Bs and N_Cr) allows detection of transmission failures. N_Bs means time until reception of the next Flow Control and N_Cr means time until reception of the next Consecutive Frame. After sending the First Frame, VCI starts the N_Bs timeout timer, if ECU does not response before N_Bs expires, error detection will be indicated to PC and all the left Consecutive Frames will be discarded. Otherwise, the FS in the received Flow Control will decide how to proceed the message transmission. If FS=0, VCI will continue to send Consecutive Frames whose quantity depends on the parameter BS, VCI must stop the transmission when BS is reached and wait for a new Flow Control; if FS=1, VCI will wait for a new Flow Control and restart N_Bs timer; if FS=2, VCI will abort the transmission of segmented message.

Figure 5.

Flow chart of implementation of protocol ISO15765

The reception mechanism of VCI also depends on the message length. When received Single Frame, the diagnostic data will be extracted from it and transmitted to PC. When received First Frame of longer message, VCI will send the default Flow Control and start the N_Cr timeout timer. If ECU does not transmit Consecutive Frames before N_Cr expires, the transmission will be aborted and VCI will enter into timeout handling process, else the following Consecutive Frames will be saved into receiver buffer temporarily. During the reception, VCI transmits a new Flow Control once the number of already received Consecutive Frames reaches BS. If a Consecutive Frame is received with an incorrect sequence number, then the message reception will be aborted and error detection must be indicated to PC. When the received message length counts up to FF_DL, VCI reorganizes the message and transmit the reassembled bytes to PC.

TABLE II.

4 TYPES OF PROTOCOL DATA UNIT DEFINED BY ISO15765

Definition Byte1

Byte2 Byte3

High nibble

Low nibble

Single frame(SF) 0 SF_DL 1

N/A

N/A First frame(FF) 1 FF_DL 2 N/A Consecutive frame (CF) 2 SN 3 N/A N/A Flow control frame(FC)

3

FS 4

BS 5

STmin 6

1 Single frame data length;

2 First frame data length;

3 Sequence number;

4 Flow status;

5 Block size;

6 Separation time min.

IV. DIAGNOSIS SOFTWARE

Diagnosis software is programmed with Visual Basic. While programming, modular construction method is adopted to facilitate further upgrading and expansion. As is shown in Fig. 6, the software is composed of five modules, human machine interaction (HCI) module, communication module, diagnostic application module, data management module,

diagnostic help module. All the modules coordinate with each other to achieve specific diagnostic services. HCI module identifies which diagnostic service is selected according to the user’s operations, diagnostic application module confirms the selected diagnostic service and generates the corresponding diagnostic message. Communication module encrypts the message and then sends it to VCI. After receiving the ECU response messages which are pretreated by VCI, diagnosis software will deliver them to the analytic functions and display the diagnosis with numeric lists or graphic curves through HCI module. Meanwhile, maintenance guidance can be acquired from diagnostic help database with the displayed diagnosis. What’s more, remote fault diagnosis interface are opened up in order to meet the needs of OBDIII fault diagnosis system. Diagnosis software can transmit the real-time diagnostic data through the internet or 3G network to remote expert system, remote expert will support the local diagnosis based on symptoms and real-time data with a strong knowledge base. After landing the system, user selects the vehicle type and ECU that is expected to be diagnosed. The diagnosis software will figure out the diagnosis protocol the selected ECU used and initialize a connection automatically. After the initialization, all diagnostic services mentioned above can be accessed. Fig.7 shows some running interfaces of PC diagnosis

software.

Figure 6.

Schematic diagram of functional modules of diagnosis software

Figure 7.

Software interfaces of diagnosis software

V. E XPERIMENT RESEARCH

In order to test the reliability of the diagnostic system, a sedan which is still in the development stage is picked as the testing object. Fig. 8 shows the test environment of diagnosis system. The sedan’s electronic control system consists of six major portions: engine management system, antilock braking system, transmission control module, instrument control module, body control module, airbag control module. Among these modules, the airbag control module conforms to ISO14230 while the others conform to ISO15765. During the test, all the modules are tested one by one to confirm that the system can achieve its function accurately. For verifying the practicality of diagnosis system, we went to a repair shop and purposely select a faulty car. The fault car has following

symptoms.

Figure 8.

Test environment of diagnosis system

Symptoms: (1) poor engine performance; (2) surge, sluggish acceleration, frequent accelerated stall; (3) deterioration of emissions.

Troubleshooting: Connect the diagnostic system to the in-vehicle network, after the initialization reading the DTCs and the corresponding freeze frames from engine management system. The only DTC is P0122 which is explained as throttle position sensor short to ground or line break. Then we read the corresponding freeze frame, in the freeze frame, the parameter throttle position is 0% while the other parameters are normal. So we determined preliminarily the fault location to the throttle position sensor. Based on the pre-determined fault location, several relevant real-time parameters are read and recorded, including throttle position, engine speed, intake manifold absolute pressure, mass air flow. Then the software inquired the database with the DTC and displayed the maintenance guidance. Follow steps of the guidance: (1) Switch the key on but do not start the engine, step on the acceleration pedal to the fully open position and the software shows the throttle position opening is 82%; (2) Start the engine, read the parameters throttle position sensor voltage. While stepping on the acceleration pedal, the throttle position sensor voltage first increased and then suddenly dropped to 0.24V. So we determined signal transmission may lost between ETC (Electronic Throttle Control) and ECU. Check the connection

wire according to the vehicle electrical circuit diagram and we found that the signal wire and ground wire are damaged. Replaced the wiring harness and the fault is excluded.

VI. C ONCLUSION

(1) Against the status of coexisting of ISO14230 and ISO15765 in the current market, the general vehicle fault diagnosis system is developed. Considering the limited functionality and low efficiency of traditional hand-held diagnostic tool, the system is designed to consist of two mutually independent portions: VCI and PC diagnosis software.

(2) Because ECU manufacturers can customize their application layer protocols independently, the application layer protocols are implemented by PC diagnostic software. Meanwhile, VCI takes hierarchical design to implement the protocols of lower layers to improve its universality. Through the modular design of PC diagnosis software and hierarchical design of VCI, upgrading and extension of the diagnosis system can be easily realized.

(3) The real vehicle testing proves that the system can not only help to after-sale services, but also reflects a good performance. The system opens up remote fault diagnosis interface, which can be used for developing internet-based remote diagnostic services to satisfy requirements of development tendency.

R EFERENCES

[1] Zhang Hong, Zhan De-kai, Lin Chang-jia. Design of vehicle fault

diagnosis system based on CAN bus[J]. Automotive Engineering, 2008, 34(1): 934-937.

[2] ISO/WD14230-1, Road Vehicles-Diagnostic Systems-Keyword Protocol 2000-Physical Layer[S], 1997.

[3] ISO/WD14230-2, Road Vehicles-Diagnostic Systems-Keyword Protocol 2000-Data Link Layer[S], 1997.

[4] ISO/WD14230-3, Road Vehicles-Diagnostic Systems-Keyword Protocol 2000-Implementation [S], 1997.

[5] ISO/WD14230-4, Road Vehicles-Diagnostic Systems-Keyword Protocol 2000-Requirements for Emission Related Systems [S], 1997.

[6] ISO/WD15765-1, Road Vehicles-Diagnostic Systems-Diagnostics on CAN –General Information [S], 2004.

[7] ISO/WD15765-2, Road Vehicles-Diagnostic Systems-Diagnostics on CAN –Network Layer Services[S], 2004.

[8] ISO/WD15765-3, Road Vehicles-Diagnostic Systems-Diagnostics on CAN –Application Layer Services[S], 2004.

[9] ISO/WD15765-4, Road Vehicles-Diagnostic Systems-Diagnostics on CAN –Requirements for Emission Related Systems[S], 2004. [10] Liu Guo-quan, Zhang Bo-ying, Song Wei-feng. The analysis and

development test of protocol KWP2000[J].Automobile Technology, 2006,(5):20-24.

[11] Cao Wei, Cai Wei-yi, Yao Jia-ling, et al. Study on the key technique of

PC-based vehicle fault diagnosis[J].Journal of Nanjing Forestry University (Natural Science Edition), 2010,34(1):113-116.