Development of Controller Diagnostic System Based on ODX

Abstract

OBD is an important technology for insurance of automotive safety and emission. The requirement for automotive safety and emission is getting higher, so more attention has been paid on OBD technology. The paper presents an instruction to the development of controller diagnostic system based on ODX (Open Diagnostic Data Exchange). According to the property of ECU I/O signals, using this method to build a diagnostic model of BCM (Body Control Module) in a certain automotive. The test results show the diagnostic model based on ODX is easy to embed, and will help OEM or after-sales tool supplier to explore their diagnostic tools.

F2012-D02-036

1 Foreword

OBD is On Board Diagnostic System, at first legislated from CARB in 1985, then carry out from 1988. SAE draw up the standard of OBD-I in 1988 [1]. From 1980s the United States, Japan, Europe, and other major auto makers start to use OBD system in their production of automotive.

The reason for more attention on OBD is the high requirement for emission. The OBD systems monitor the devices in automotive that related to the emission, and through the connector (SAE J1962) to exchange data from diagnostic tool. ECU in every phase of automotive design-manufacture-aftersale, it may exchange data with different tools through OBD connector [2]. The data formats in different tools are obviously very important. This paper presents an instruction to the development of controller diagnostic system based on ODX (Open Diagnostic Data Exchange), and build BCM database for a certain automotive in ODX, through the validation to prove the consistency.

2 Open Diagnostic Data Exchange

ODX (Open diagnostic data exchange) at first raised by ASAM (Association for Standardization of Automation and Measuring Systems), and released by ISO (International Standards Organization) in March 4th, 2009 as standard ISO22901-1:2008, according to ODX 2.2.0 as the standard of diagnostic data exchange. ODX data format release process as the Fig. 1. ODX standard consists of all the diagnostic data model from automotive and ECU, for example, DTC (diagnostic trouble code), data parameters, identification data, input–output parameters, ECU coding; ECU diagnostic communication protocol; Data-link layer communication parameters; ECU flash data format; related connector description etc. Using the database of ODX standard can make sure the database from every major auto makers independent on the diagnostic tool that from any tool supplier. Ensure the consistency of the database in the line of automotive design-manufacture-aftersale. Currently there are many automotive makers, as BMW, GM; there are many ECU suppliers, as Bosch, Siemens-VDO; and many diagnostic tool suppliers, as Vector, Softing, ESG, ETAS etc. support the ODX.

Fig. 1

Development process of ODX

3 Design and Application of OBD System

3.1 Legislated On-Board Diagnostics

The OBD system that related to emission is monitoring the signals and devices that belong to engine in automotive. This function is implemented by ECU (Electronic Control Unit). Any components or subsystems’ fault that may course the emission exceed the legislation limit, the ECU will exactly diagnostic the failed components or subsystems, and then do the failure reminder. In the standard of OBD-II, the main diagnostic systems that related to emission are monitoring subsystems as three-way catalytic converter, lambda sensor, engine knock and fuel oil system [3].

3.2 Vehicle Manufacturer Enhanced Diagnostics

Besides the legislated On-Board Diagnostic, the electronic monitoring system defined as enhanced diagnostic. Normally use the ECU in body to achieve the function. The body ECU monitors the surrounding components and devices, include input outputs, then analysis the signals based on the diagnostic software, in order to identify whether the surrounding components have fault. Then to judgment the reason of the fault, record the corresponding diagnostic trouble code (DTC).

ECU surrounding components can be divided into input component, such as switch, sensor; output component, such as engine, actuator etc. Different surrounding components considering use different monitoring strategies. Figure 2 is the example of the surrounding components.

Fig. 2

ECU surrounding components

3.3 Input Component Monitoring

When the input monitoring component is switch, the fault monitoring flow is showed in Fig. 3.

Fig. 3

The monitoring flow of switch

The switch divided into self-locking and non self-locking, the status of self-locking switch cannot judgment the fault condition, so generally do not do the fault detection. The non self-locking switch after the execution of a signal, will recovery the signal. If the signal can’t recovery to the initial status after the conversion, then consider the switch has fault.

When the input component is sensor, the MCU collect the voltage and current of the sensor. In initial ECU have defined the valid range of each sensor, when ECU monitor the signal exceed the specified valid range, can be judged one of the following faults: sensor cable is loose or damaged, the wiring is short to ground or short battery, the sensor is failure.

3.3.1 Output Component Monitoring

The output component means the actuator connected to the ECU. ECU monitor the signal of the actuator, read back to the MCU, then judgment whether the actuator or the actuator loop have the fault. Because the majority of the electrical actuators are electromagnetic coil, such as motor, so detect the actuator can measuring the resistance of the coil. The abnormal resistance will cause the voltage read back to the MCU in abnormal status.

4 Diagnostic Application Design in Body ECU

The OBD function of body ECU is focus on the enhance diagnostic, each vehicle manufacturer always design the system based on the feature of the vehicle electrical system. This session, will engage in the diagnostic system design for the body controller of a vehicle platform. At first, according to the feature of the BCM (Body Controller Module) surrounding component, distinguish the types of signals. Confirm the signal resources that need to detect. Figure 4 list some signal resources of the BCM.

Fig. 4

Some signal resources of the BCM

• 1. Hazard Switch, it is a non self-locking switch, when detect the signal always in the high voltage, and then can consider the switch is in the fault. The door contact switch is self-locking switch, so cannot judge the fault condition.

• 2. Wiper Intermit Switch, it is analog input signal, when MCU monitor the signal exceed the specified valid range, can be judged in fault. The input signal of the wiper intermit switch is the resistance value, through the internal pull-up resistor voltage divider, the resistance value invert to voltage value. The valid signal of the wiper intermit switch have two ranges $0\;\sim10\:{\rm{K}}\Omega$ and $20\sim 50\;{\text{K}}\Upomega$(its just for example, normally the ranges are more than two), the valid value that read by MCU also have two ranges, assume as 0.1~1 and 2~4.9 V, when exceed the different range, judged as different fault, the detailed type of the fault listed in Table 1.

  Table 1 List of BCM DTC

• 3. The output component of the BCM is controlled by the LSD and HSD that have the function of read back function. The chip of LSD or HSD according to the read back value of IS1 IS2, feedback to the A/D of MCU, MCU judge whether the actuator have fault.

Based on the above design program, the BCM may have the following failures.

5 Verification and Validation

Based on the ODX model, build up the ODX database of the BCM diagnostic function model. Then do the verification and validation.

5.1 Definition of the Communication Parameters

The tester and ECU need define the same communication speed (baud rate), address ID and message format. Then the message can be received successfully in K line and have been analyzed. These communication parameters are defined as basis parameter. It has been set up in the COMPARAM-SPEC model of the ODX data structure. The baud rate of K line normally set up as 10.4 Kbps. According to the protocol of ISO 14230, the format of K line is defined as the Table 2.

Table 2 The format of K line

The first four bytes of the message can use different formats, according to different manufacturers’ definition. This BCM define the message length in bit5-bit0 of Fmt.

The address and other signal is defined as follow:

• 1. Address separate to target address and source address, ODX database is mainly used in diagnostic tool, so for the tool, the target address is ECU, defined as 35H(hex), the source address is diagnostic tool, defined as F1H(hex).

• 2. The header of the message has three bytes, and only support physical addressing(point to point), define the Fmt as 80+ data length(include SID) in the database.

• 3. Data byte area is composed of SID and its corresponding data, not exceed 255 bytes.

• 4. Checksum and byte satisfy the following formula: $< CS >_{i} = \left\{ { < CS >_{(i - 1)} + < BYTEi > } \right\}\bmod 256,\quad i \ge 1$. Among, $< CS >_{0} = < BYTE0 >$.

Before the diagnostic SID request, the ECU has been fast initialized by the tester. Using the 25 ms high and low voltage signal as the wake signal, inform the target node the tester want to communication. Through the start communication request SID 81, build the consistency between the tester and tool with tester address, ECU address and message header etc. After the initialization, the communication will maintain, until exceed the certain time, and the tester have not send any request, the communication will stop. If the tester want to communication again, it need to send wake signal again.

5.2 Definition of Service Request ID

According to the definition, clarify the services that supported by ECU. Build these parameters in DIAG-LAYER model in ODX, then inherit the COMPARAM-SPEC, make communication parameters consistency with the vehicle parameters.

Each diagnostic service ID includes request service and response service, and the response service includes positive response and negative response. Response service and request service have certain regularity. Such as, $\text{Re} spSID = \text{Re} qSID + xxH$, $\text{Re} qSID$ is request service, $\text{Re} spSID$ is response service, $xxH$ is a fixed Hex value. In protocol KWP2000 $xxH$ is$40H$.

• Request message: $\text{Re} qSID$+request information

• Positive response message: $\text{Re} spSID$+positive response information

• Negative response message: $7F + \text{Re} qSID + NRC$, $NRC$ is negative response code.

Different service contain different meaning and length, each service also have different NRC. After build the relationship between the request message with the positive response and with the negative response message, add all these definition to the ECU’s diagnostic parameters. Then the finished diagnostic database can be exported as an ODX format, the format of ODX has the following eight types:

• 1. odx-c (COMPARAM-SPEC)

• 2. odx-d (DIAG-LAYER-CONTAINER)

• 3. odx-f (FLASH)

• 4. odx-m (MULTIPLE-ECU-JOB)

• 5. odx-v (VEHICLE-INFO-SPEC)

• 6. odx-e (ECU-CONFIG)

• 7. odx-fd (FUNCTION-DICTIONARY)

• 8. odx-p (Contains One, or Multiple ODX Files and Other Files/Data).

According to the definition of the database, it can be export the corresponding ODX file.

5.3 Verification and Validation

Using of Company Softing’s tool DTS Monaco, import the ODX database. Carry out the diagnostic testing for a real ECU. In tester have defined the K-Line communication manner, after the faster initialization between the tester and the ECU, the communication has set up, and then can do the verification. Figure 5 is the picture of the test.

Fig. 5

Interface of the diagnostic test

Choose the request service, click transmit, the interface show the request message and the response message from ECU. It has showed the request message and response message of the TesterPresent service after the communication set up. And show the request and response of readDTCByStatus.

• Req 3E

• Resp 7E

• Req 18 00 FF 00

• Resp 58 06 90 62 24 90 71 64 90 90 48 90 93 48 90 94 48 90 95 48.

Translate it is DTC B1062 B1071 B1090 B1093 B1094 B1095.

On the basis of this database, in development phase it can realize test of application diagnostic service, the test of communication time parameters in data link layer, the test of ECU DTC and the test of DTC status etc. The database exchange to the supplier of the manufactory tester, it can realize the function of EOL test, ECU coding etc. The database exchange to the dealer of the manufactory, it can realize function of repair auxiliary, read the DTC code and change ECU etc. Also the supplier of ECU can use this database in diagnostic software integration; it can save the cost of the development. And it is benefit for the software developer, they can deal with the ODX database directly, do not need master more ODX professional knowledge.