Research on Fault Diagnostic System in CVT Based on UDS

Abstract

A communication model of diagnostic network and implementation of unified diagnostic services (UDS) based on controller area network (CAN) bus are presented in this paper, and fault diagnostic function of transmission control unit (TCU), USB- (universal serial bus-) CAN hardware and software modules, and fault diagnostic software based on personal computer (PC) are designed. Model diagnostic method is applied on ratio control, and fault diagnostic system is tested in vehicle.

1. Introduction

More and more automotive electronic control modules start to use CAN instead of traditional K (ISO14230) diagnostic mode due to its higher speed and reliable method. In order to unify different on-board network diagnostic services, ISO established a general diagnostic communication protocol, ISO14229, which is also called UDS. The protocol can satisfy the demands of Europe on-board diagnostics (E-OBD) system and conform to the development trend of modern network bus system, which will become the future vehicle industry general diagnostic criteria [1, 2]. Continuously variable transmission (CVT) electronic control unit, as an important module of automotive electronics, uses a diagnostic method to monitor the transmission system and components operation. On the one hand, if a fault happens in system, the diagnostic system freezes frame data and provides real-time warning. Also, the diagnostic equipment can provide real-time, accurate working data, and diagnostic information for after-sale diagnostic analysis, achieving the purpose of repairing and monitoring [3].

2. The Communication Mode of Diagnostic Network

Diagnostic protocol is divided into application layer, network layer, data link layer, and physical layer. Service identifier and the format of the parameters and content of specific diagnostic service which follow ISO14229 are defined on application layer. The format of the parameters and content of specific diagnostic service in service identifier in application layer conform to ISO14229. Data is transmitted in the form of a single frame or multi frame, which follow ISO15765-2 [4]. On data link layer, it is responsible for the single frame or multi frame under the network layer data sent by the physical layer, or which received CAN frame from the physical layer and submitting it to the network layer [5]. Diagnostic process is always to be launched by diagnostic equipment, after electronic control unit accepting the request of service and resolving step by step according to diagnostic protocol. Eventually, the service is passed to the application layer, as shown in Figure 1.

Figure 1:

The communication model of diagnostic network.

3. The Implementation of the UDS on CAN Bus

The unsegmented data flow and segmented data flow are defined in network layer of ISO15765 protocol. The unsegmented data flow consists of a single frame, where single frame length is no more than 7 under normal addressing mode or less than 6 under extended addressing mode. The segmented data flow consists of a message of multi frame section. The data length is more than 7 under normal addressing mode or more than 6 under extended addressing mode. The data stream contains of a first frame and multiple consecutive frames. Two types of message transmission are shown in Figure 2.

Figure 2:

Unsegmented and segmented message.

The single frame, first frame, the consecutive frame, and flow control all contain data domain of 8 bytes. The data domain consists of protocol control information and data transmission. The structure of all kinds of CAN messages is shown in Table 1 [6].

Table 1:

Data domain structure.

Frame type	Byte 1		Byte 2	Byte 3	Byte 4–8
Frame type	Bit 7-4	Bit 3-0	Byte 2	Byte 3	Byte 4–8

Single frame	0	SF_DL	SID	data 1–6
First frame	1	FF_DL		SID	data 1–5
Consecutive frame	2	SN		data 1–7
Flow control	3	FS	BS	STmin

Remarks: SF_DL denotes 4-bit single frame data length; SID denotes service identifier; FF_DL denotes 12-bit first frame data length; SN denotes sequence number; FS denotes data flow state; BS denotes block size; STmin denotes the minimum time interval.

TCU supports the following addressing modes: physical addressing mode and functional addressing mode. In the physical addressing mode, all messages are received by TCU physical address. TCU can perform services which are supported by the activation diagnostic session when the physical addressing mode request is activated. In the functional addressing mode, message is requested when request information of diagnostic equipment is not in the case of a particular module.

TCU supports normal and extended diagnostic modes. When the vehicle is ignited, TCU is initialized into the normal mode. Meanwhile, the controller functions and diagnostic services are activated, but the specification execution from the customer is not allowed under the extended mode.

4. UDS Diagnostic Services

The application of the diagnostic function of UDS is the diagnostic services. UDS diagnostic services can be organized into the six categories, including diagnostic and communication management service, data transmission service, data storage, input/output control service routines, remote wake-up service, and upload/download service [7]. Diagnostic and communication management service is to define the main session control service and the communication parameter setting, which guarantee the normal work during the process of diagnostic communication. Data transmission service mainly monitors the parameters of vehicle in real-time. Storing data service reads and clears up the ECU internal fault code for fault diagnosis. Input/output control function unit controls the input/output of vehicle ECU. Remote wake-up service activates ECU internal diagnostic routines. Upload/download service is primarily used in exchanging a large number of data between diagnostic equipment and the internal ECU of vehicles. UDS diagnostic services implementation of TCU is shown in Table 2.

Table 2:

UDS diagnostic services.

Service		Function addressing		Physical addressing
SID	Service name	Normal mode	Extended mode	Normal mode	Extended mode

Diagnostic and communications management
10	Diagnostic session control	○	○	○	○
11	ECU reset service	○	○
27	Security access			○	○
3E	Tester present	○	○	○	○

Data transmission
22	Read data by identifier	○	○	○	○
2E	Write data by identifier				●

Stored data
14	Clear diagnostic information	○	○	○	○
19	Read DTC information	○	○	○	○

Remarks: ○ denotes diagnostic supported under any security condition; ● denotes diagnostic only supported under unlock security condition.

5. The Design of the Fault Diagnostic System

According to ISO15765, CAN information ID from TCU to diagnostic equipment is set to 0x7E9 (standard frame). CAN physical addressing information ID from diagnostic equipment to TCU is set to 0x7E1. CAN functional addressing information ID from diagnostic equipment to TCU is set to 0x7DF. The CAN communication uses the baud rate with 500 kbps. The structure of fault diagnostic system is shown in Figure 3, including TCU fault diagnostic software, the USB-CAN hardware and software, and implementation of TCU diagnostic function.

Figure 3:

Structure diagram of TCU fault diagnostic system.

5.1. TCU Fault Diagnostic Software Design

The software is developed with the platform C++ Builder, which adopts modular design. The structure of the software system is shown in Figure 4.

Figure 4:

Structure diagram of TCU fault diagnostic software.

(1) CAN Communication Module. It receives TCU fault information and the important parameters in the process of transmission operation, which is based on the diagnostic communication specification.

(2) Fault Information Management Database. It builds up the fault table and stores the fault information and specific description of the fault codes.

(3) Fault Diagnostic Management Module. It analyzes the fault diagnostic message for fault diagnostic information. Fault code, description, and other information can be displayed in the interface of the fault diagnostic software.

(4) Monitoring Alarm Module. When the failures are detected, they are divided into general failure and severe failure, according to the severity of the fault. General failure lights trouble light, while severe failure flashes trouble light.

(5) Fault Diagnostic Interface. It is used to set the communication port number, baud rate, and diagnostic data storage paths and show fault codes. Moreover, the data flow operation is also in fault diagnostic interface, which provides real-time data flow monitoring function, and display the important parameters. The main interface of TCU fault diagnostic system is shown in Figure 5.

Figure 5:

Main interface of TCU fault diagnostic system.

5.2. The Hardware Design of USB-CAN

USB-CAN include MCU, CAN transceiver and USB serial port module. Its framework is shown in Figure 6.

Figure 6:

Framework of USB-CAN.

The controller uses the MC9S08DZ60 because of its low cost and low power consumption. CAN communication module adopts the TJA1040 of NXP. The CAN transceiver has very low electromagnetic radiation and high ability of resistance to electromagnetic, which is fully compatible with ISO11898 protocol and supports high communication rate up to 1 Mbps. The interface between the USB and serial port module adopts FTDI's FT232RL, which is applied for the USB to serial port interface conversion.

5.3. The Software Design of USB-CAN

The software function of the USB-CAN is to realize the data interaction between the message on the CAN bus and the USB of PC which serves a virtual serial port. This is because many current notebook makers canceled the serial port. Since serial port protocol is simple, the interface is easy to be developed. The virtual serial port is selected to communicate with PC. Firstly, slave computer receives some serial communication data with ID, which was sent by diagnostic software from PC. Then a message is sent to the TCU by MCU and MCU receives a reply message from TCU. After that, MCU restructures the message and sends it to the host PC.

5.4. The Development of TCU Diagnostic Function

The TCU diagnostic function diagram is shown in Figure 7.

Figure 7:

Principle block diagram of TCU.

(1) TCU Self-Diagnosis Function. The input and output signal have a certain range when CVT is operating. If a signal value is beyond this range and this phenomenon does not disappear after a period of time, TCU will make a judge based on the rule of failure [8]. TCU will store the fault in the form of a code in EEPROM, lighting trouble light at the same time.

(2) TCU Failure Protection Function. When TCU detects some malfunctioning in the sensors or actuators, TCU will provide alternative signals or setting goals to take the place of the fault signal, which is to maintain the control system to ensure the transmission operating.

The flow chart of diagnostic services is shown in Figure 8. The diagnostic services adopt the judgment step by step. In Table 3, the subfunction, the request parameters, positive response identifier, positive response parameters, and the negative response code in diagnostic services are listed. Taking diagnostic model control as an example, if diagnostic equipment request message is 02 10 03 00 00 00 00 00, TCU response message will be 02 05 03 00 00 00 00 00. Negative response message of unmatched session is 03 7F 10 22 00 00 00 00.

Table 3:

UDS diagnostic service definition.

SID	Request subfunction	Request parameter	Positive response identifier	Positive response parameter	Negative response code¹

10	01—Normal mode	—	50	01	12, 13, 22
10	03—Extended mode	—	50	03	12, 13, 22

11	01—Hardware reset	—	51	01	12, 13, 22, 33
11	03—Software reset	—	51	03	12, 13, 22, 33

27	01—Request seed	—	67	xxxxxxxx	12, 13, 22, 24, 31, 35,
27	02—Transmit key	xxxxxxxx	67	—	36, 37

3E	00—Need response	—	7E	0	12, 13

22	—	DID²	62	DID + content	12, 22, 31, 33

2E	—	DID + content	6E	DID	12, 22, 31, 33, 72

14	—	FF FF 00	54	—	12, 22, 31

19	01—Read DTC³ number by identifier	FF	59	DTCNo	12, 13, 31
19	0A—Read all DTC	—	59	DTC	12, 13, 31

Remarks: ¹negative response code: definition as shown in Table 4

DID: data identifier

DTC: diagnostic trouble code.

Table 4:

Negative response code.

NRC	Meaning

12 h	Subfunction not supported
13 h	Incorrect message length or invalid format
22 h	Conditions not correct
24 h	Request sequence error
31 h	Request out of range
33 h	Security access denied
35 h	Invalid key
36 h	Exceed number of attempts
37 h	Required time delay not expired
71 h	Transfer data suspended
72 h	General programming failure
7F h	Service not supported in active session

Figure 8:

The process of TCU responding diagnostic service.

5.5. Studying the Method of CVT Fault Diagnosis

The schematic diagram of CVT hydraulic system is shown in Figure 9. In CVT, the clamping force of the primary pulley and the secondary pulley is controlled by a hydraulic valve. The secondary cylinder pressure is controlled by the proportional relief valve, preventing large metal belt slip between the pulley and the metal belt and also maintaining an effective torque transmission of the engine [9, 10]. In the meanwhile, the primary cylinder pressure is controlled by the proportional reducing valve to achieve ratio control.

Figure 9:

CVT hydraulic principle diagram.

Given the metal belt constraints, there is a nonlinear relationship between the speed ratio and the displacement between the primary pulley and secondary pulley. The real ratio is calculated by measuring the speed of the primary and the secondary pulley according to the ratio control. Considering the installation of a shift sensor, cost, and other factors, the ratio control is achieved by wheel speed detection of the primary pulley and secondary pulley through the speed sensor [11].

A ratio control model is designed as shown in Figure 10. The target ratio is obtained by a look-up table of the throttle position degree θ and the vehicle speed V, and then the target ratio is revised according to the rate of the throttle changing [12, 13]. Based on the difference between current ratio and the target ratio, the fuzzy controller calculates PWM (pulse width modulate) output, controlling the proportional valve in order to regulate the hydraulic cylinder to achieve the ratio control [14, 15].

Figure 10:

Ratio control model.

Without the addition of CVT sensors, the online fault diagnostic ways of model-based ratio control system is explored [16, 17]. Firstly, the global and local output prediction models are developed based on the collection of data. Based on the discrepancy between the predicted output of the model and the actual output, diagnostic services are performed. Then the failure is isolated and positioned, according to measuring signal, output results of the global and local element's diagnostic model, and the preestablished diagnostic logic table [18].

6. Diagnostic Function Tests

In the early development stage of UDS function and TCU fault diagnostic software, the diagnostic function of Vector's CAN bus analysis tool CANalyzer is used. The TCU and laptop are connected by a USB-CAN module for testing and verifying completeness of whole diagnostic system. As can be seen in red oval of Figure 11, in the real vehicle test, the real ratio cannot follow the target ratio well. So the diagnostic function is activated. Test results of reading the fault code and data flow in TCU fault diagnostic software are shown in Figure 12.

Figure 11:

Ratio comparing.

Figure 12:

The test case of TCU fault diagnostic software.

7. Conclusion

A TCU fault diagnostic system is developed based on UDS in this paper. An accurate, fast, stable, and reliable data communication between the TCU and diagnostic platform can be seen in this system. The diagnostic software is simple and intelligent. The entire system can run smoothly and diagnose accurately. Application result shows that the scheme of the design is reasonable and the system has the advantages of stable operation, low hardware cost, and a simple operation. Moreover, it has practical application promotion.

Conflict of Interests

The authors declare that there is no conflict of interests regarding the publication of this paper.

Footnotes

Acknowledgment

The work described in this paper was supported by the National High Technology Research and Development Program of China (863) (no. 2012AA111710).

References

Johansson

K. H.

Törngren

, and Nielsen

, “Vehicle applications of controller area network,” in Handbook of Networked and Embedded Control Systems Control Engineering, pp. 741–765, 2005.

Di Natale

Zeng

Giusto

, and Ghosal

, Understanding and Using the Controller Area Network Communication Protocol, Theory an d Practice, Springer, New York, NY, USA, 2012.

Isermann

, “Diagnosis methods for electronic controlled vehicles,” Vehicle System Dynamics, vol. 36, no. 2–3, pp. 77–117, 2001.

ISO15765-2:2004, Road Vehicles—Diagnostics on Controller Area Networks (CAN)—Part 2: Network Layer services, 2004.

Rings

and Phillips

, “Adding unified diagnostic services over CAN to an HIL test system,” SAE Technical Paper 2011–01–0454, 2011.

ISO15765-3-2004, Road Vehicles—Diagnostics on Controller Area Networks (CAN)-Part 3: Implementation of Unified Diagnostic Services (UDS on CAN), 2004.

ISO , “Road vehicles—unified diagnostic services (UDS)—part 1: specification and requirements,” ISO 14229–1:2013, 2013.

Discenzo

F. M.

Unsworth

P. J.

Loparo

K. A.

, and Marcy

H. O.

, “Intelligent motor provides enhanced diagnostics and control for next generation manufacturing systems,” Computing and Control Engineering Journal, vol. 11, no. 5, pp. 228–233, 2000.

Patel

Ely

, and Overson

, “CVT drive research study,” SAE Technical Paper 2005–01–1459, 2005.

10.

Pesgens

Vroemen

Stouten

Veldpaus

, and Steinbuch

, “Control of a hydraulically actuated continuously variable transmission,” Vehicle System Dynamics, vol. 44, no. 5, pp. 387–406, 2006.

11.

Ryu

and Kim

, “CVT ratio control with consideration of CVT system loss,” International Journal of Automotive Technology, vol. 9, no. 4, pp. 459–465, 2008.

12.

Yeo

Song

C. H.

Kim

C. S.

, and Kim

H. S.

, “Hardware in the loop simulation of hybrid vehicle for optimal engine operation by cvt ratio control,” International Journal of Automotive Technology, vol. 5, no. 3, pp. 201–208, 2004.

13.

Bae

Y.-H.

Lee

S.-H.

Kim

H.-C.

Lee

B.-R.

Jang

, and Lee

, “A real-time intelligent multiple fault diagnostic system,” International Journal of Advanced Manufacturing Technology, vol. 29, no. 5, pp. 590–597, 2006.

14.

Jin

and Ge

, “On the intelligent slope shift strategy,” Proceedings of the Institution of Mechanical Engineers Part D: Journal of Automobile Engineering, vol. 221, no. 8, pp. 991–999, 2007.

15.

Riascos

L. A. M.

Simoes

M. G.

, and Miyagi

P. E.

, “On-line fault diagnostic system for proton exchange membrane fuel cells,” Journal of Power Sources, vol. 175, no. 1, pp. 419–429, 2008.

16.

Wilamowski

B. M.

, “Neural networks and fuzzy systems,” in Mechatronics Handbook, Bishop

R. R.

, Ed., pp. 1–50, CRC Press, 2002.

17.

Ryu

Nam

Lee

, and Kim

, “Model based control for a pressure control type CVT,” International Journal of Vehicle Design, vol. 39, no. 3, pp. 175–188, 2005.

18.

Scacchioli

Rizzoni

Salman

M. A.

Onori

, and Zhang

, “Model-based diagnosis of an automotive electric power generation and storage system,” IEEE Transactions on Systems, Man and Cybernetics, vol. 44, no. 1, pp. 72–85, 2013.