Research and Development of Vehicle Fault Diagnostic Protocol ISO15765

2011 International Conference on Transportation, Mechanical, and Electrical Engineering December 16-18, Changchun, China Research and Development of Vehicle Fault Diagnostic Protocol ISO15765 Aidong Xu, Lili Liu, Yan Song, Ya Zhou Shenyang Institute of Automation Chinese Academy of Science Shenyang, China E-mail: {xad,liulili,songyan,zhouya}@sia.cn Abstract In this paper, CAN based vehicle fault diagnostic protocol ISO15765 is introduced, and the architecture of ISO15765 is analyzed. The paper provides the overall design of the ISO15765 protocol stack, the software realizations of each layer of ISO15765 are also introduced. Lower layers provide interfaces to higher layers. The development of internal operation of each layer adopts modular design. The result of the experiment shows that the protocol stack provided by the paper satisfies ISO15765 standard and general fault diagnosis requirements. and configuration for ECU. The Figure1 shows the structure of ISO15765. Keywords- ISO15765; Higher layer protocol; Fault diagnostic; CAN I. INTRODUCTION Nowadays, CAN bus is a popular fieldbus, it has become the main vehicle electronic system bus, CAN based fault diagnosis system gets more attention. ISO15765 [1] is an international standard for diagnosis in CAN based vehicles system, it has been established in order to define common requirements and implement unified diagnostic services (UDS) [2] for vehicle diagnostic system on a CAN communication. The protocol complies with the modern vehicle bus system's development tendency and will become a common diagnostic standard for vehicle industry. So research is necessary to ISO15765. II. CAN AND ISO15765 A. CAN CAN is a multi-master broadcast serial bus protocol, message-based communication and uses Non-Destructive bit wise arbitration. It provides fast, prioritized, reliable, broadcast message transmission with sophisticated error detection and error handling. ISO11898 [3] is an international standard for CAN. According to OSI (open systems interconnection) reference model, CAN protocol only defines the lower two layers, physical and data link layer. Higher layer protocol based on CAN is a high-level protocol implemented on the existing CAN protocol. Different higher layer protocol can be defined by user for special-purpose. B. Structure of ISO15765 ISO15765 is one of CAN based higher layer protocol used for vehicle fault diagnosis. It can implement communication between an off-board diagnostic tester and an on-board ECU to facilitate inspection, test, diagnostics Figure 1. Structure of ISO15765 According to the OSI reference model, ISO15765 protocol defines four layers, application layer, network layer, data link layer and physical layer. Data link layer and physical layer are CAN services, specified in ISO11898. Network layer [4] provides services to higher layer, and multi-frame transmission protocol for long message is also specified in network layer. Application layer [5] specifies the implementation of a common set of unified diagnostic services(uds) based on CAN. There are six types of diagnostic services. (1) Diagnostic and communication management function unit provide services to control diagnostic sessions; (2) Data transmission functional unit is used for real-time monitor vehicle parameters to help fault diagnosis judgment. (3) Stored data transmission functional unit provides reading and clearing diagnosis trouble code (DTC) services to diagnose faults. (4) Services of Input/output control functional unit can control input/output signal of ECU to further confirm the fault location. (5) Remote activation of routine functional unit is used to wake up diagnostic routines within ECU, the results of the routines can help fault diagnosis judgment. (6) Upload/download functional unit can transmit large quantities of data between diagnostic tester and ECU. III. DEVELOPMENT OF ISO15765 PROTOCOL STACK In accordance with ISO15765 structure, software architecture of ISO15765 protocol stack designed in this paper is shown in Fig.2. The protocol stack can be divided 978-1-4577-1701-7/11/$26.00 2011 IEEE 1952

into three parts, application layer, network layer and CAN. Each layer provides interfaces to upper layer. Figure 2. Overall design of ISO15765 protocol stack In order to real-time receive data from lower layer, receiving threads and buffers are provided for application and network layer. A. Software Realization of Application Layer Application layer provides six service primitives shown in figure 3, they are used to realize communication between application layers of diagnostic tester and ECU. Meaning and interface functions provided in this paper for these primitives are shown in Table I. including source address and destination address, A_PCI(application layer protocol control information) indicating which service type the message is and A_DATA(application layer data domain) including message data. In this paper the application layer is divided into two modules: application layer schedule and application layer process. The main function of application layer schedule is scheduling corresponding service request and service processing. The application layer schedule in diagnostic tester calls corresponding diagnostic service (described in II.B six type services) request for user application and then calls corresponding processing function to assemble corresponding A_PDU. According to the meaning of A_PCI which is the first data byte of received data from lower layer in ECU, the application layer schedule in ECU can calls corresponding processing function to response request from diagnostic tester. The main function of application layer process is to assemble data into A_PDU format to send, parse and process received data parameters in receiver. The application layer process in ECU also can send corresponding response to tester. It also provides error handles, such as invalid format of received data or invalid requested sub-function and so on, and the ECU will send negative response to diagnostic tester with the negative response codes. The software implementation of application layer is based on state machine. The state machine contains the following states, ready, receive data from network layer, application layer scheduling and application layer processing. The status state transition diagram is shown in figure4. Figure 3. Application layer service primitives TABLE I. APPLICATION LAYER SERVICE PRIMITIVES A_PDU(Application layer protocol data unit) contains three parts, A_AI (application layer address information) Figure 4. Application layer state-transition diagram Once initialization is completed, state enters into ready state. As a receiver, when network layer has data sending to the application layer, event bounding to application layer receiving thread will be enabled signaled, then state will transition to receive data from network, after finishing receiving data from network, state transitions to application layer schedule, according the received data, the application layer call the corresponding process function, then the application layer enters into the state of application layer process. When the process function has been completed, it will return into the ready state. As a sender, when user has diagnostics service request, application layer enter into the state of application layer schedule, and after scheduling, it will transition to the state of application layer process, and then send the processed 1953

request data to network layer, at last it returns into the ready state. B. Software Realization of Network Layer Network layer provides two functions, one provides services to higher layer, the other one provides internal operation. Network layer defines four communication services primitives to higher layer, Network layer software provides interfaces to implement these services, the interfaces for them is shown in table II. TABLE II. NETWORK LAYER SERVICE PRIMITIVES Services primitives Internal operation is used for multi-frame transmission, it is implemented by segmenting and reassembling message. Data link layer uses CAN protocol, and the CAN protocol data unit only contains eight bytes data, So the messages of which the data length are longer than eight bytes should be segmented. And the received data should be reassembled in the receiver. Network layer defines four frames: SF (single-frame), FF (first-frame), FC (flowcontrol frame) and (consecutive-frame). When the data length of request message is less than 8 (local diagnosis) or 7 (remote diagnosis) bytes, the message will be directly packaged into a SF and sent to data link layer. Conversely, data length of request message is more than 7 or 6 bytes, the message will be segmented. Firgure5 is single-frame communication between sender and receiver. sender. All s are numbered with SN (Sequence Number) by the sender to help the receiver re-assemble them in the same order. The flow control mechanism allows the receiver to inform the sender about the receiver s capabilities. The flow control mechanism is implemented by receiver to send FC containing BS (block-size) which is the maximum number of s the receiver allows the sender to send. N_USData.req Sender FF N_USData.con Segment Network layer FC FC Receiver Reassemble Network layer Figure 6. Multi -frame communication N_USData_FF.ind N_USData.ind N_PDU(Network layer protocol data unit) includes three parts, network layer address information (N_AI), network layer protocol control information (N_PCI) which identifies the type of N_PDU and network layer data domain (N_DATA). Figure7 shows the mapping between A_PDU and N_PDU.... Figure 7. Mapping of A_PDU onto N_PDU The software implementation of network layer is also based on state machine. The state machine contains following states, ready, Network layer preprocess, segment and reassemble. The network layer state transition diagram is shown in figure 8 and the state transition table is shown in table III. Figure 5. Single-frame communication Firgure6 is Multi-frame communication. Transmission of longer messages is performed via segmentation of the message and transmission of multiple N_PDUs. Reception of longer messages is performed via reception of multiple N_PDUs and reassembly of the received data bytes. The longer messages are segmented into FF (first N_PDU of the message) and s (all the following N_PDUs) in the Figure 8. Network layer state-transition diagram TABLE III. NETWORK LAYER STATE-TRANSITION TABLE 1954

Network layer preprocess state is used to judge where the received data come from, if data come from the application layer and then judge the data length of received data. When data come from the data link layer, the Network layer preprocess will then judge the frame type of the data, SF, FF, or FC. Segment and reassemble module have been described above. As application layer, network layer also enters into ready state after initializing. When event bounding to network layer receiving thread is signaled, the network layer receives data (R1), and then network layer enters into preprocess state. If result of Network layer preprocess is that received data are request message from application layer and the data length is less than 8 or 7 bytes, network layer will send data in SF (R4) and then return into ready state. If the data length is more than 7 or 6 bytes (R2), network layer will transition to segment state. After success of segmentprocess (R3), network layer returns into ready state, if failed (R5), network layer will send N_Data.confim with error information to application layer and then return into ready state. If result of Network layer pretreatment is that received data are from network layer and is a SF frame (R7), network layer will send data to application layer and then return into ready state. If data is a FC frame (R2), then network layer will transition to segment state. If the data is FF or (R6), network layer will enter into reassemble state. After success of reassemble-process (R8), the receiver sends N_Data.ind with data to application layer. If failed (R9), the receiver will send N_Data.ind with error information to application layer and then return into ready state. C. Software Realization of Data Link Layer Data link layer is specified in international standard ISO11898. Data link layer is implemented by the driver of CAN controller supporting ISO11898. Therefore, only the interfaces provided to network layer are introduced in the paper in table IV. The mapping of N_PDU onto CAN PDU is shown in figure9. CAN PDU contains there parts, they are arbitration field (29 bit identifier), control field (DLC valid data length) and data field. The N_AI (address information from network) mapped into the 29 bit identifier field, the N_PCI and N_DATA(data from N_PDU) are mapped into the data field in CAN PDU. TABLE IV. DATA LINK LAYER INTERFACE Figure 9. Mapping of N_PDU onto CAN PDU IV. TEST AND RESULT In order to test the effectiveness of the design, the protocol stack was assembled into PC as a diagnostic tester, and the ECU in figure10 supports ISO15765. Diagnostic tester includes two parts: user interface and ISO15765 protocol stack. Fig.10 Frame of test environment In order to test the effectiveness of the protocol stack, we have a test case set which covers the following testing requirements: 1) Test the process of sending and receiving request message of each diagnostic service defined in application layer. 2) Test the function of internal modules in network, such as segment module, reassemble module and flow control management. 3) Test error handling when segment or reassemble message failed. 4) Test the protocol message processing from application layer to data link layer and from data linker layer to application layer. The test result shows that the protocol stack meets the consistency requirement of ISO15765 and satisfies the requirements for general fault diagnosis. V. CONCLUSION ISO15765 is a well-defined protocol for vehicle fault diagnosis based on CAN protocol, it can meet requirements of OBD and EOBD, ISO15765 protocol is becoming a development tendency in vehicle fault diagnosis. The paper has analyzed and implemented the protocol stack of ISO15765. Layered and interface approaches are used to design the ISO15765 protocol stack. Lower layers provide interfaces to higher layers. Modular design is also used to realization of internal operations of each layer which ensures that the protocol 1955

stack has good transplantability and can be easy to clip. The test result shows that the protocol stack provided by the paper can satisfy the consistency requirement of ISO15765 and meet general fault diagnosis requirements. The protocol stack can be used on PC or ECU in vehicle. ACKNOWLEDGMENT This paper is supported by National Science and Technology Support Project (NO: 2009BADB5B01). At the point of finishing this paper, I d like to express my sincere thanks to all those who have lent me hands in the course of my writing this paper. REFERENCES [1] nternational Organization for Standardization. ISO15765-1 Road Vehicles-Diagnostics on Controller Area Networks(CAN) Part1: General information [S]. ISO Standard, 2004. [2] nternational Organization for Standardization. ISO14229 Road Vehicles - Unified diagnostic services(uds) specification and requirements [S]. ISO Standard, 2006. [3] nternational Organization for Standardization. ISO11898-1 Road Vehicles-Controller area network (CAN) - Part1: Data link layer and physical signaling [S]. ISO Standard, 2003. [4] International Organization for Standardization. ISO15765-2 Road Vehicles-Diagnostics on Controller Area Network (CAN) Part2: Network layer services [S]. ISO Standard, 2004. [5] International Organization for Standardization. ISO15765-3 Road Vehicles-Diagnostics on Controller Area Network (CAN) Part3: Implementation of unified diagnostic services(uds on CAN)[S]. ISO Standard, 2004.. 1956