Research Article Research on Fault Diagnostic ...

Hindawi Publishing Corporation Advances in Mechanical Engineering Article ID 128432

Research Article Research on Fault Diagnostic System in CVT Based on UDS Jiande Wang, Yunshan Zhou, and Quan Li Engineering Research Centre of Automotive Electronics and Control Technology, Ministry of Education, Hunan University, Changsha 410082, China Correspondence should be addressed to Jiande Wang; [email protected] Received 9 July 2014; Revised 6 September 2014; Accepted 15 September 2014 Academic Editor: Hongwei Guo Copyright © Jiande Wang et al. This is an open access article distributed under the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited. 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 (EOBD) 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 ISO157652 [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.

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

Downloaded from ade.sagepub.com by guest on September 8, 2015

2

Advances in Mechanical Engineering

Tester

CAN node

Diagnostic service

Diagnostic service

Network layer

Message package/unpackage

Message package/unpackage

Data link layer

Message transmit/receive

Message transmit/receive

Physical layer

CAN driver

CAN driver

Application layer

Response

CAN_H CAN_L

Request

Figure 1: The communication model of diagnostic network.

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. 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]. 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.

Table 1: Data domain structure. Byte 1 Byte 2 Byte 3 Byte 4–8 Bit 7-4 Bit 3-0 Single frame 0 SF DL SID data 1–6 SID data 1–5 First frame 1 FF DL Consecutive frame 2 SN data 1–7 Flow control 3 FS BS STmin Frame type

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.

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 wakeup 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



3 Sender

Sender

Receiver

Receiver

Sender

Receiver

First frame

Single frame

Flow control frame

Flow control frame

Consecutive frame

Consecutive frame

Consecutive frame

Consecutive frame

Consecutive frame

Consecutive frame

(a) Unsegmented message

(b) Segmented message

Figure 2: Unsegmented and segmented message. Table 2: UDS diagnostic services.

SID

Service Service name

Function addressing Normal mode Extended mode Diagnostic and communications management I I I I

10 11 27 3E

Diagnostic session control ECU reset service Security access Tester present

22 2E

Read data by identifier Write data by identifier

I

14 19

Clear diagnostic information Read DTC information

I I

I

Physical addressing Normal mode Extended mode I

I

I

I I

I I

I

I

I e

I I

I I

I I

Data transmission

Stored data

Remarks: I denotes diagnostic supported under any security condition; e denotes diagnostic only supported under unlock security condition.

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.

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 USBCAN hardware and software, and implementation of TCU diagnostic function.

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. (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.


4


TCU fault diagnostic

USB

CAN USB-CAN

software

TCU

(PC)

Figure 3: Structure diagram of TCU fault diagnostic system.

Fault diagnostic interface Software setting Fault information management database

DTC operation

Data flow operation

Fault diagnostic management module

Monitoring alarm module

CAN communication module

Figure 4: Structure diagram of TCU fault diagnostic software.

Figure 5: Main interface of TCU fault diagnostic system.

(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.

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. 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



5

USB-CAN

CAN CAN OBD CAN interface tranreceiver

MCU

SCI

USB converter

USB

PC diagnostic software

Figure 6: Framework of USB-CAN.

TCU Secondary pressure Oil temperature

Key lock Analog input

High side on-

Shift lock

off output Reverse light P R N

Primary valve control

D Secondary valve control

S Manual plus

Digital input

Manual minus

PWM output

Clutch valve control Lock valve control

Snow mode Brake Ignition

CANH Calibration CAN

Primary speed Secondary speed Turbo speed

Frequency input

CANL

CANH Communication CAN

CANL

12 V

GND

Power input

Sensor power output

5V

Figure 7: Principle block diagram of TCU.

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.


6


Start of service

Negative response $11

Request SID supported?

No

Service not supported

Yes Session supported?

No

Negative response $7F Service not supported in current session

Yes

Length supported?

No

Negative response $13 Invalid message length

Yes Sub-function supported?

No

Negative response $12 Sub-function not supported

Yes

Positive response ready?

No

Extended response time window?

Yes

Yes

Positive response

Negative response

No Negative response $78 Request received Response pending

No

$XX Other negative response End of service

Figure 8: The process of TCU responding diagnostic service.

(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. 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



7 ẋ y

Primary pulley

V-belt Pump

PP

Ps

Ratio control

Clamping control

Secondary pulley

Figure 9: CVT hydraulic principle diagram.

Table 3: UDS diagnostic service definition. SID

Request subfunction

Request parameter

Positive response identifier

Positive response parameter

Negative response code1

10

01—Normal mode 03—Extended mode

—

50

01 03

12, 13, 22

11

01—Hardware reset 03—Software reset

—

51

01 03

12, 13, 22, 33

27

01—Request seed 02—Transmit key

— xxxxxxxx

67

xxxxxxxx —

12, 13, 22, 24, 31, 35, 36, 37

3E

00—Need response

—

7E

0

12, 13

22

—

DID2

62

DID + content

12, 22, 31, 33

2E

—

DID + content

6E

DID

12, 22, 31, 33, 72

14

— 01—Read DTC3 number by identifier 0A—Read all DTC

FF FF 00

54

—

12, 22, 31

59

DTCNo

12, 13, 31

19

FF —

DTC

Remarks: 1 negative response code: definition as shown in Table 4; 2 DID: data identifier; 3 DTC: diagnostic trouble code.

Table 4: Negative response code. NRC 12 h 13 h 22 h 24 h 31 h 33 h 35 h 36 h 37 h 71 h 72 h 7F h

Meaning Subfunction not supported Incorrect message length or invalid format Conditions not correct Request sequence error Request out of range Security access denied Invalid key Exceed number of attempts Required time delay not expired Transfer data suspended General programming failure Service not supported in active session

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. 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


8

Advances in Mechanical Engineering Fuzzy control rule de/dt

Fuzzy decision

Fuzzy

Ambiguity

Kp Ki Kd

𝜃

d𝜃/dt Target ratio

+

Ratio revise

PID

Ratio control vavle

PWM

CVT variator

𝜔P 𝜔s

−

V

Real ratio i = 𝜔P /𝜔s

Figure 10: Ratio control model. 2.6 2.4 2.2 Ratio (—)

2 1.8 1.6 1.4 1.2 1 0.8 80

100

120

140 160 Time (s)

180

200

220

Target ratio Real ratio

Figure 11: Ratio comparing.

position degree 𝜃 and the vehicle speed 𝑉, 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]. 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.

7. Conclusion A TCU fault diagnostic system is developed based on UDS in this paper. An accurate, fast, stable, and reliable data



9

(a) DTC operation

(b) Data flow operation

Figure 12: The test case of TCU fault diagnostic software.

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.

[9] [10]

[11]

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

[12]

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

[13]

[14]

References [1] K. H. Johansson, M. T¨orngren, and L. Nielsen, “Vehicle applications of controller area network,” in Handbook of Networked and Embedded Control Systems Control Engineering, pp. 741– 765, 2005. [2] M. Di Natale, H. Zeng, P. Giusto, and A. Ghosal, Understanding and Using the Controller Area Network Communication Protocol, Theory an d Practice, Springer, New York, NY, USA, 2012. [3] R. Isermann, “Diagnosis methods for electronic controlled vehicles,” Vehicle System Dynamics, vol. 36, no. 2-3, pp. 77–117, 2001. [4] ISO15765-2:2004, Road Vehicles—Diagnostics on Controller Area Networks (CAN)—Part 2: Network Layer services, 2004. [5] M. Rings and P. Phillips, “Adding unified diagnostic services over CAN to an HIL test system,” SAE Technical Paper 201101-0454, 2011. [6] ISO15765-3-2004, Road Vehicles—Diagnostics on Controller Area Networks (CAN)−Part 3: Implementation of Unified Diagnostic Services (UDS on CAN), 2004. [7] ISO, “Road vehicles—unified diagnostic services (UDS)—part 1: specification and requirements,” ISO 14229-1:2013, 2013. [8] F. M. Discenzo, P. J. Unsworth, K. A. Loparo, and H. O. Marcy, “Intelligent motor provides enhanced diagnostics and control

[15]

[16]

[17]

[18]

for next generation manufacturing systems,” Computing and Control Engineering Journal, vol. 11, no. 5, pp. 228–233, 2000. D. Patel, J. Ely, and M. Overson, “CVT drive research study,” SAE Technical Paper 2005-01-1459, 2005. M. Pesgens, B. Vroemen, B. Stouten, F. Veldpaus, and M. Steinbuch, “Control of a hydraulically actuated continuously variable transmission,” Vehicle System Dynamics, vol. 44, no. 5, pp. 387–406, 2006. W. Ryu and H. Kim, “CVT ratio control with consideration of CVT system loss,” International Journal of Automotive Technology, vol. 9, no. 4, pp. 459–465, 2008. H. Yeo, C. H. Song, C. S. Kim, and H. S. Kim, “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. Y.-H. Bae, S.-H. Lee, H.-C. Kim, B.-R. Lee, J. Jang, and J. Lee, “A real-time intelligent multiple fault diagnostic system,” International Journal of Advanced Manufacturing Technology, vol. 29, no. 5, pp. 590–597, 2006. H. Jin and A. 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. L. A. M. Riascos, M. G. Simoes, and P. E. Miyagi, “On-line fault diagnostic system for proton exchange membrane fuel cells,” Journal of Power Sources, vol. 175, no. 1, pp. 419–429, 2008. B. M. Wilamowski, “Neural networks and fuzzy systems,” in Mechatronics Handbook, R. R. Bishop, Ed., pp. 1–50, CRC Press, 2002. W. Ryu, J. Nam, Y. Lee, and H. Kim, “Model based control for a pressure control type CVT,” International Journal of Vehicle Design, vol. 39, no. 3, pp. 175–188, 2005. A. Scacchioli, G. Rizzoni, M. A. Salman, W. Li, S. Onori, and X. 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.
