MULTIPLE ELECTRONIC CONTROL UNITS CALIBRATION SYSTEM BASED ON EXPLICIT CALIBRATION PROTOCOL AND J1939 PROTOCOL

Transcription

1 42 CHINESE JOURNAL OF MECHANICAL ENGINEERING Vol. 21, ano. 1, a2008 YANG Shiwei ZHU Keqing XU Quankui YANG Lin ZHUO Bin Institute of Automotive Electronic Technology, Shanghai Jiaotong University, Shanghai , China MULTIPLE ELECTRONIC CONTROL UNITS CALIBRATION SYSTEM BASED ON EXPLICIT CALIBRATION PROTOCOL AND J1939 PROTOCOL Abstract: The rising number of electronic control units (ECUs) in vehicles and the decreasing time to market have led to the need for advanced methods of calibration. A multi-ecu calibration system was developed based on the explicit calibration protocol (XCP) and J1939 communication protocol to satisfy the need of calibrating multiple ECUs simultaneously. The messages in the controller area network (CAN) are defined in the J1939 protocol. Each CAN node can get its own calibration messages and information from other ECUs, and block other messages by qualifying the CAN messages with priority, source or destination address. The data field of the calibration message is designed with the XCP, with CAN acting as the transport layer. The calibration sessions are setup with the event-triggered XCP driver in the master node and the responding XCP driver in the slave nodes. Mirroring calibration variables from ROM to RAM enables the user to calibrate ECUs online. The application example shows that the multi-ecu calibration system can calibrate multiple ECUs simultaneously, and the main program can also accomplish its calculation and send commands to the actuators in time. By the multi-ecu calibration system, the calibration effort and time can be reduced and the variables in ECU can get a better match with the variables of other ECUs. Key words: Electronic control unit (ECU) Calibration Explicit calibration protocol (XCP) J1939 communication protocol Controlled area network (CAN) 0 INTRODUCTION In automotive applications it is common practice to interconnect electronic control units (ECUs) in a controller area network (CAN). The automotive industry uses CAN as the in-vehicle network (IVN) for the engine management, the body electronics like door and roof control, air conditioning, and lightning, as well as for the entertainment control. Calibration becomes more complex as automobiles become equipped with more ECUs. Up to now, most of the calibration systems based on the CAN calibration protocol (CCP) can calibrate only one ECU every time [1-6]. As a result, the ECUs in automotive have to be calibrated separately with these calibration systems. The variables in ECUs can not be optimized to match each other well so that the calibration efficiency will decrease greatly. Consequently,a multi-ecu calibration system will be an effective means as functionality is distributed among multiple ECUs. A multi-ecu calibration system was developed based on explicit calibration protocol (XCP) and J1939. The XCP is an improved and generalized version of CCP 2.1 that can be used in networks other than CAN. The J1939 of the Society of Automotive Engineers (SAE) is the open standard for networking and communication in vehicles. The calibration tool was connected to the CAN network in vehicle by USBCAN. The structure of the calibration messages were designed in the standard message architecture defined in J9139, while the data field of calibration messages is defined in XCP. In this calibration system, all CAN messages can reach their destinations orderly by the priority mechanism and the receiving mask registers in the CAN nodes. The event-triggered XCP drivers in the master and the responding XCP driver in the slave serve as the two sides of the calibration session. The application example shows that the multi-ecu calibration system can calibrate multiple ECUs at the same time without affecting the performance of the ECUs. 1 XCP CALIBRATION SYSTEM XCP is a standard automotive calibration protocol defined by Received February 11, 2007; received in revised form September 10, 2007; accepted September 30, 2007 the Association for Standardization of Automation and Measuring systems (ASAM) organization. It clearly separates the protocol layer from the transport layer being used. The main advantage of XCP is the transport layer independency. Specifications currently exist for the transport layers in Ethernet, SPI, SCI and CAN. The multi-ecu calibration system we developed is based on CAN. 1.1 Calibration system structure The XCP used for calibration is a master-slave type communication protocol. The master node is a calibration system initiating the data transfer on the CAN by sending commands to the slave nodes and the ECUs act as slave nodes. A master node is connected to one or more slave nodes with the CAN bus. All calibration messages and data to be transferred are packed into the command transfer object (CTO) or data transfer object (DTO). The CTO is used for transferring generic control commands. The DTO is used for transmitting synchronous data. The communication mechanism of the calibration system is shown in Fig. 1. CAN is used as the transport layer in this calibration system. Fig. 1 Communication mechanism calibration system As can be seen, the master node is connected to the CAN network by USBCAN, in which a Philips SJA1000 chip is used as the CAN controller and a Philips PCA82C250 chip as the CAN transceiver. The slave nodes are connected to the CAN bus by PCA82C250 and TouCAN module of the MC68376 microcontroller.

2 CHINESE JOURNAL OF MECHANICAL ENGINEERING 43 For the session between master and slave, a command packet sent by the master node must always be answered by a command response packet or an error packet by the slave node. 1.2 CAN message structure To allow electronic devices to communicate with each other, CAN message structure is defined in J1939 by providing standard message architecture. The SAE J1939 is based on CAN data link layer using the extended frame format (29-bit identifiers) [7]. It has been used for communication between the individual electronic control units and components of the drive train. In the CAN network, calibration messages use J1939 protocol data unit (PDU) standard message architecture as well as the messages exchanged between ECUs. The identifier field in CAN message is defined in J1939 protocol and the data field is defined in XCP, as shown in Fig. 2. The J1939 PDU consists of seven fields: priority (P), reserved (R), data page (DP), PDU format (PF), PDU specific (PS), source address (SA), and data fields. Some of the CAN data frame fields have been left out of the PDU definition because they are controlled entirely by the CAN specification and are invisible to all of OSI layers above the data link layer. They are SRR, IDE and RTR. Fig. 2 CAN message structure Priority mechanism There are two types of messages in the CAN network: one for calibration and one for exchanging information between ECUs. When the bus is free, any node may start to transmit a frame. If two or more nodes start to transmit frames at the same time, the bus access conflict is resolved by contention-based arbitration using the P bit in PDU. The P value determines the message s priority. The mechanism of arbitration guarantees that neither information nor time is lost. Messages between ECUs should be allowed high-priority to override all calibration messages. In this calibration system, the priority of ECU communication messages is 2 and that of calibration messages is Receiving messages There are calibration information flow and ECU information flow in the CAN network. CAN messages should be identified with different priority, SA and destination address (DA) to indicate their categories and flow directions according to their functions. The direction information is included in the identifier field of PDU. The PS field in PDU is a destination address when the value of the PF field is below 240. The DA defines the specific address to which the message is being sent. There shall only be one device in the network with a given source address. Therefore, the source address field assures that the CAN identifier will be unique, as required by CAN. There are four CAN nodes in this research. The J1939 protocol assigned each node a unique address, 39 for computer, 0 for engine control module (ECM), 81 for DC motor control module (DMCM) and 82 for battery control module (BCM). The address 81 and 82 are SAE reserved for future use. CAN controllers in each CAN node have their acceptance mask registers for received frame IDs, thus the message flow direction can be defined in the identifiers and the messages can be filtered by qualifying the received message IDs when comparing them to the receive buffer identifiers. The mask registers in master and slave nodes should be configured correctly to make sure that each node can receive their needed messages and block others. The messages on CAN bus are assigned with a specific P, SA and DA according to their functions, respectively. ECU messages have higher priority than calibration messages. The messages, received by the master node, are only used for calibration and the DA in the identifier must be the computer. The master can use the P and DA to distinguish the calibration messages sent to the master node. The SJA1000 chip in the master node has only one receiving buffer and one transmitting buffer. Therefore, the receive identifier can be set to 0x and the mask register can be set to 0xE001FE00. The CAN calibration message and the ECU communication message may be both received by slave nodes. The TouCAN module in the slave node contains 16 message buffers and three receiving mask registers, global mask register for buffer 0-13, buffer 14 mask register and buffer 15 mask registers. In this calibration system, the 0-13 buffers are used for the ECU communication messages. The buffer 14 is used to receive and 15 to transmit the calibration messages. The messages to slave nodes are filtered by the P and DA in PDU. The configuration of receive identifiers and TouCAN registers of slave nodes are shown in Table 1. Node address ECM 0 DMCM 81 BCM 82 Table 1 Configuration of receiving mask registers in hex Global receive ID Receive global mask register Buffer 14 receive ID Receive buffer 14 mask register 0x xE001FE00 0x E 0xE00001FE 0x4000A200 0xE001FE00 0x E 0xE00001FE 0x4000A400 0xE001FE00 0x E 0xE00001FE XCP message on CAN The XCP messages are packed and transported in the data field of PDU, as shown in Fig. 2. The XCP message structure is shown in Fig. 3. An XCP packet consists of an identification field, an optional timestamp field and a data field. The XCP header and XCP tail depend upon the transport layer used [8-9]. Fig. 3 XCP message structure XCP packet, defined in XCP protocol layer specification, is independent from the transportation layer used. Since with CCP, the protocol layer is tightly linked to the properties of the CAN transport layer, it is not possible to switch over to another transport medium. XCP offers this transfer, which is of crucial advantage to both the ECU and tool sides. It is thus possible to use the same protocol implementation even when the physical interface has been modified. Without much effort and with very little modification to the ECU software architecture, this same protocol could then be transferred to a transport medium available in production ECUs. According to XCP transport layer specification, there s no XCP header on CAN. The XCP tail consists of a control field containing optional contents. The maximum data length of a CAN message is 8 bytes and therefore maximum length of an XCP on CAN message is 8 bytes. If the length of an XCP packet equals 8, the control field of the XCP tail is empty. If the length is smaller than 8, there are two possibilities to set the fill bytes. The first possibility is to set the XCP tail empty and the XCP on CAN message is the same as the XCP packet. The second possibility is to set the XCP tail contains (8-length) fill bytes. The contents of the fill bytes can be ignored. 2 XCP DRIVERS The session between master and slaves is based on the

3 44 YANG Shiwei, et al: Multiple electronic control units calibration system based on explicit YYYANG Zhiyong, et al: brake test calibration of SiCp/a356 protocol brake and disk J1939 and protocol interpretation of experimental resultsy standard communication model defined in the XCP. Each request packet from the master will be answered by a corresponding response packet or an error packet, and the master node may not send a new request until the response to the previous request has been received. 2.1 XCP driver in master The XCP driver in the master is the control center of the calibration system. Flow chart in Fig. 4 shows the mechanism of the XCP driver in the master. 2.2 XCP driver in slave For every command from the master, the XCP driver in the slave must respond with a return message. Fig. 5 is the flow chart of the XCP driver in slave. When the slave node receives a calibration message from CAN bus, the main program in ECU will be interrupted and all data in data and address registers are stored in stack. Then the program counter will be redirected to the entrance of the XCP service program. The PID in the XCP message will be read to decide which command will be executed. All of the commands will be ignored except Connect if the slave hasn t been connected to the CAN network. When being connected, the slave will answer the master with a correct message if the command was correctly implemented and the PID of the message received is between 0xC0 and 0xFF. Otherwise, it will return an error message with 0xFE in the PID. When the user sends a program command to the slave, other commands will be ignored temporally until erase and program operations of the ROM have been completed. Fig. 4 Flow chart of XCP driver in master node System state (S ): 1. Online 2. Calibration 3. Program 4. Offline 5. Idle The state of the calibration system includes online, idle, calibration, program and offline. The system is in idle state at start-up. All calibration events are triggered either by user s operations in the interface of the calibration software or by the messages from CAN bus. The system state will switch from idle to a corresponding one according to the operation s type and the master will then call a function to complete the user s operations, as shown in Fig. 4. The XCP driver in master consists of 4 main functions including Connect (), Calibration (), Program () and Disconnect (). Table 2 demonstrates the commands used in each function and their packet identifiers. The XCP driver in master has been packed into calibration software that can be installed in computer. Table 2 Main functions in master driver and their commands Function Command PID Connect 0xFF Get_Comm_Mode_Info 0xFB Get_Status 0xFD Get_ID 0xFA Connect Upload 0xF5 Select_Cal_Page 0xEB Set_Mta Build_Chksum 0xF3 Calibration Program Upload Download Program_Start Program_Clear Program 0xF5 0xF0 0xD2 0xD1 0xD0 Program_Reset 0xCF Disconnect Disconnect 0xFE Fig. 5 Flow chart of XCP driver in slave node Generally, the calibration variables are stored in the ROM of ECU. After the erase and program operation of ROM, there should be a short time delay before it becomes readable again, which prevents the ECU from being calibrated online and affects the normal running of the main program. The shortage can be avoided by calibrating variables in RAM. Therefore, as can be seen in Fig. 5, calibration variables are totally copied into RAM once the ECU powers on. The calibration data are calibrated in RAM. At the end of the calibration, the variables will be written back to the ROM. Therefore, the variables can be kept permanently after the ECU powers off. The calibration program in slave nodes accesses its main program in an interruption mode. It is assigned a 4 level interruption priority to ensure real-time capability of the main program. TouCAN module has an IARB field which can be assigned a priority from 0x0 to 0xF. 0x0 is the highest and 0xF is the lowest. 3 APPLICATIONS The multi-ecu calibration system has been put into use in the development of the integrated starter generator (ISG) hybrid vehicle. There were four slave nodes in this CAN network: computer, engine control module, DC motor control module and battery control module. As shown in Fig. 6, the calibration tool was installed in the computer and acted as the master node. Three ECUs developed for the ISG hybrid vehicle, acted as the slave nodes. The master was connected to the slave by the USBCAN and twisted-pair.

4 CHINESE JOURNAL OF MECHANICAL ENGINEERING 45 Some experiments have been done to evaluate the impact on the real-time capability of the ECUs when the calibration system was running. All these signals were sampled with the XCP calibration system. The test results are shown in Fig. 8 and Fig. 9. Fig. 6 XCP calibration system The absolute address information of the calibration data is available in the address description file (*.map), which is generated during the process of compiling the main program project. The physical layout of the flash device is well-known to the calibration tool with this *.map file. The calibration software can read the value of a variable through its start address stored in *.map file. Every ECU has its own *.map file. Fig. 7 is the interface of the calibration software. When the ECUs are powered on, they copy calibration data from ROM to RAM and are ready to be calibrated. The user starts the calibration tool, as shown in Fig. 7a, and the master send out a connect command to the slave synchronously. After a successful connection, the master reads the calibration data to the computer automatically. The user opens the calibration map and modifies the data in it, as shown in Figs. 7b and 7c. To respond to the user s operation, the master will then sent calibration commands to change the data in RAM. At last, the user sends a program command to store these calibrated variables in ROM (Fig. 7d). Fig. 8 Crank to idle Fig. 9 Free acceleration (a) (b) (c) The engine was driving only by the DC motor in cranking phase, shown in Fig. 8. The DC motor was shut down when the speed reached 690 r/min and then the engine began to inject fuel. The speed climbed to 800 r/min and fell to and fluctuated around the idle target speed (700 r/min). The engine speed is calculated six times for one engine cycle and it will be refreshed every 0.5 s at 100 r/min. Thus, there is a step on the engine speed curve. Fig. 9 shows the entire process when the engine state switched from idle to acceleration and back to idle. The injection fuel quantity followed the pedal value tightly when the pedal was pressed instantaneously from 0% to 130%. Then the pedal was released suddenly, and the engine cut off fuel supply according to the pedal control strategy, and the speed fell subsequently. The engine switched to idling state again and fuel supply was recovered. In this research, the cycle length of the main program in the ECM was measured with the time counter in TPURAM. The ECM spent 2.17 ms to finish the calculation cycle when the calibration system was off, and 2.53 ms when the calibration system was on. They are both less than 3.33 ms, the maximum cycle time permitted when the engine is at r/min. From these experiments one can conclude that the ECUs of the ISG hybrid system can communicate and work harmoniously with each other when they are calibrated simultaneously, and the control schemes are well implemented. Fig. 7 (d) Interface of the XCP calibration tool 4 CONCLUSIONS (1) A multi-ecu calibration system has been developed based on J1939 and XCP. It can work properly in the CAN network, in which PCA82C250/251 acts as CAN transceiver and TouCAN and SJA1000 as CAN controller. (2) With the identifiers defined in J1939 and the configuration of receiving mask registers, the ECU messages and calibration messages can be sent orderly and reach their destinations without being received by other CAN nodes.

5 46 YANG Shiwei, et al: Multiple electronic control units calibration system based on explicit YYYANG Zhiyong, et al: brake test calibration of SiCp/a356 protocol brake and disk J1939 and protocol interpretation of experimental resultsy (3) The application example shows that the multi-ecu calibration system can calibrate several ECUs simultaneously by means of interrupting the main program, and the ECUs still can meet real-time characteristic well. More effective calibration and shorter product development cycle can be reached with the XCP multi-ecu calibration system. (4) In addition, the number of the CAN nodes can reach almost one hundred. It enables the calibration system to fulfill the calibration of the rising number of ECUs. XCP clearly separates the protocol layer from the transport layer being used. By separating the protocol and transport layers, the XCP protocol layer can be implemented generically and reused. References [1] FENG Jing, WANG Juxi, ZHUO Bin. Research of CAN communication module based on CCP for calibration system of electronically controlled engine[j]. Chinese Internal Combustion Engine Engineering, 2003, 24(5): (in Chinese) [2] LI Yabo, ZHANG Junzhi, GAN Haiyun. Development of hybrid electric vehicle ECU calibration system based on CCP[J]. Automotive Engineering, 2004, 26(4): (in Chinese) [3] SUN Wei, ZHANG Yunlong, YUAN Dahong. Development of the CAN-based electronic control engine calibration system[j]. Automotive Technology, 2004, 11(4): (in Chinese) [4] REN Liang, LI Jin, YANG Fuyuan. Design of online calibration system for electronic controlled diesel engines[j]. Chinese Internal Combustion Engine Engineering, 2005, 26(2): 5-8. (in Chinese) [5] WANG Junxi, YANG Lin, FENG Jing. Development of a new calibration system for electronic control units based on CCP[J]. Transaction of CSICE, 2005, 23(2): [6] WANG Junxi, FENG Jing, MAO Xiaojian, et al. Development of a new calibration and monitoring system for in-vehicle electronic control units based on controller area network calibration protocol[j]. Proceedings of the Institution of Mechanical Engineers, Part D: Journal of Automobile Engineering, 2005, 219 (12): [7] Surface vehicle recommended practice data link layer[r]. Society of Automotive Engineers, [8] ROEL S, RAINER Z, FRANK H, et al. XCP - Part 2-protocol layer specification -1.0[OL]. ( ) [ ] asam.net/ doc_int/getfile/getfile.php?id=238&memberlogin=. [9] ROEL S, RAINER Z, FRANK H, et al. XCP - Part 3- Transport Layer Specification XCP on CAN -1.0[OL]. ( ) [ ] Biographical notes YANG Shiwei is a PhD candidate in Shanghai Jiaotong University, China. He received his MS degree from School of Energy and Power Engineering, Jiangsu University, China, in His research interests include electronic unit pump control strategy, development of calibration system, etc. Tel: ; ysw.521@163.com