Information of CAN frames
Automobile industry will face great evolution in the 21st century. Developing Energy saving and low emission products become the two directions of automobile industry. People have begun to focus on HEV since 1970s. HEV integrates power devices such as engine, motor，battery, which allow its both strong points of pure electric and traditional automobile. CAN is a serial communication protocol initially developed by BOSCH . CAN supports distributed real-time control applications with dependability requirements. CAN is used widely in automotive electronics, with bit rates up to 1 Mbit/s [2-4]. CAN is a multi-master, broadcast protocol with collision detect and a resolution mechanism based on message priorities. Each message on the CAN bus has a unique priority and is only transmitted from a single node on the bus. J1939 is a protocol developed by SAE. The J1939 protocol is a vehicle application layer built on the CAN protocol. The central entity is the Protocol Data Unit (PDU), which carries all the important information needed for determination of a message’s priority and size.
In this paper, a multi-node CAN bus of diesel hybrid electric vehicle is designed, based on CAN2.0 protocol and J1939. The design methods of hardware and software for CAN bus are presented.
2. System overview
In general, according to powertrain configuration, HEV can be classified into three types, namely serial hybrid, parallel hybrid and serial parallel hybrid electric vehicle. In this study, parallel hybrid electric vehicle is adopted, as shown in Fig.1. The motor here is Integrated Starter Generator（ISG）. This design has many advantages such as better inherited of former buses in structure, facility in application and wider applied range. And this method is applied widely in China.
3. Multi-node CAN bus for HEV
3.1. Analysis of CAN topology
According to requirement of HEV, CAN communication regular among ECU is worked out. CAN bus topology structure is designed. Hierarchical control method is used in the HEV controlled system, and the kernel controller of this powertrain is Hybrid Control Unit (HCU). The controllers of lower lever include Engine Management System (EMS), which is a diesel controller in this system, Battery Packets Control Module (BPCM), Automation Disconnect Module (ADM), Drive Motor Control Module (DMCM). And the main communication between controllers is CAN communication. Main CAN nodes of HEV powertrain are shown Fig. 2. HCU receives information form other lower ECU in order to know the whole vehicle state, at the same time HCU sends control massage to them.
3.2. Design of CAN bus for hybrid electric vehicle
HCU is designed based on the microprocessor MC68376, and multi-node CAN is developed based on 29bits extended frame. This MCU integrates one TouCAN module which meets CAN2.0B protocol, and this module has 16 buffers. Specific address is assigned for each CAN node, so it is not necessary for declare and modification of each ECU. The address is defined when HCU under power on reset. The information of CAN frame is shown in the table 1. There are two trigger methods for CAN frame, one is period trigger mode, the other is interrupt trigger mode. The period of every node is designed based on the requirement of sampling velocity for vehicle control. Each node has different transmitting and receiving (TR) period. This method can full the control requirement and reduce the road rate of CAN bus, so improve the response time of the system.
|Byte position||Data definition|
|2||High byte of DM_Trq_Actual|
|3||low byte of DM_Trq_Actual|
|4||high byte of DM_Spd_Actual|
|5||low byte of DM_Spd_Actual|
|6||high byte of DM_I_Actual|
|7||low byte of DM_I_Actual|
Data combination and data split are applied, when data’s addresses were defined. For example, the detail data definition is shown in Table2. Some variables which have two or three bits are combined in one same byte, while some variables which occupy two bytes were split high byte and low byte which in two bytes. These methods can improve the ability of CAN transmitting, which can save the space of transmitting. In addition, the load rate of CAN bus could be reduced.
4. Hardware and software design of CAN communication
4.1. Design of hardware circuit of CAN communication
TouCAN module integrated MC68376 and CAN transceiver 82C250 are adopted in the hardware design of CAN circuit. In order to improve the reliability of communication, power isolation and optoelectronic isolation are applied in the hardware design of CAN communication circuit. DC/DC isolation circuit module is used for power isolation. 6N137 is applied for optoelectronic isolation. The block diagram of CAN circuit is shown in Fig.3. Anti-jamming design should be considered in hardware design. Shield wire, impendence match of bus and electromagnetic filtering are applied in hardware design to improve the communication quality.
4.2. Design of CAN communication software algorithmic
4.2.1. Buffer time-sharing
TouCAN module that meets CAN2.0B protocol, has sixteen buffers. There are eighteen data frames in our control system. In this study, a method of buffer sharing is designed, which two frames use the same buffer, named buffer time sharing. For example, the frames of HCU
4.2.2. Time-sharing receiving and transmitting
The infra program of CAN is designed according to HCU. The method of time-sharing receiving and transmitting (TSRT) is applied to ensure quality of communication. The communication period is determined according to requirement of control system. TSRT is an effective way to improve the efficiency of communication. On one hand, TSTR could shorten the running time of CAN subroutines because of all timer subroutine don’t achieve at same time. On the other hand, amount of data transmitted on CAN bus is changed, according to time. So the road rate of CAN bus is changed at different time. When there is one timer subroutine operated, the road rate is lower. This is the most ordinary condition.
4.2.3. Optimization design of CAN drivers
CAN communication module is one of the most important subroutine of infra program. As an interrup subroutine, CAN driver subroutine may lead to longer time of interrupt relay and affect the ability of interrupt performance of system. A Real Time Operating System (RTOS) is needed in optimization of the control system software. Multi-task is applied in the CAN subroutine design.
The setting of response time of parameters should consider these two conditions.
Interrupt trigger is used in the events that need handle immediately. For example, control instruction between HCU and EMS, and calibration instructions between HCU and calibration tools.
Considering the response time of control parameters are different, as shown in Table.3. CAN messages are divided into four degrees, 20ms, 50ms, 100ms, 1000ms. At the same time, the priorities of these tasks raise when communication period become short.
|Speed of engine||20ms|
|Speed of vehicle||1000ms|
|State of charge(SOC)||1s|
|Torque of driver motor||20ms|
|Torque of engine||20ms|
The new structure of CAN communication is shown in Fig.6. Priority assignment is applied in this new structure. Each task is triggered by event interrupt. If there are two or more tasked triggered at the same time, the task of higher priority is responded firstly. Multi-task method can optimizes the resource of HCU, and supplies an effective means to extend CAN communication program.
4.3. CAN bus road rate analysis
The average road rate of CAN bus is defined as the sum total of each communication flame transmitting occupy in bus. It is conducted one equation as following:
In which, is road rate of whole bus, is TR period of each communication flame, is bit time of CAN data transmitting, is maximum number of TR data bit, is the number of all communication flames. According to CAN2.0B and J1939, the data can be calculated by Table4.
If there are bytes data in one CAN frame, form the definition and specification of CAN 2.0B, the maximum number of stuff bits of one frame can be calculated by equation as follow:
The maximum bits of each flame TR can be calculated by following equation :
In which, is the bytes data of each flame TR. The bit time is 4us, when baud rate is 250Kb/s. From equation (1) and equation (2), the maximum road rate can be calculated is about 28.05%, which is enough for bus communication.
(number of bits)
|Start of Frame||1||yes|
4.4. CAN Calibration Protocol (CCP)
One of important parts for multi-node CAN bus design is CCP driver. CCP is a CAN based application protocol for calibration and measurement data acquisition of ECUs. It is accepted by many corporations such as VECTOR, DSPACE, ETAS, and become standardization.
CCP driver is needed for ECU which parameters can be calibrated. A CCP driver software is integrated in the infra program of HCU. A basic implementation of CCP driver needs only a few control unit resources such as RAM, ROM, and CPU time. The CCP driver occupies two CAN buffers, which should be assigned low bus priority to avoid influencing other bus communication . The trigger mode of CCP driver is interrupt mode. CCP driver is the foundation of calibration platform. The calibration platform structure is shown as Fig.7. CCP driver achieves data upload, download and calibration of controlled parameters. This calibration system provided reliable, accurate and quickly CAN communication between calibration platform and ECU. It has been used successfully in HEV controlled system.
The verify tests of CAN bus include three parts: Single module verify, hardware in loop (HIL) simulation test, and bench test.
5.1. Single module verify
The structure of single module verification is shown as Fig.8.CAN transmitting and receiving (TR) program of single module is carried out in personal computer (PC). The communication between USB/CAN card and single ECU, can verify the CAN hardware function and transmitting and receiving subroutine of the ECU. Single module verification can find the error of hardware or infra TR program as early as possible, which makes well preparation for subsequent tests.
5.2. Hardware in the loop test
Hardware in the loop test is one of important steps in controller design . The structure of HIL simulation is shown in Fig.9. In HIL system are divided into two important parts: Simulation ECU and upper program of PC. The models of HEV (include engine model, motor model, battery model, ADM model and vehicle model）and monitoring interface are handled in the PC. Communication between HCU and simulation ECU is CAN communication, which uses USB/CAN converter card. The interface of monitoring is developed by Labview. This method of HIL has many advantages. It avoids double RAM communication. The ability of PC could be achieved as vehicle models that are computed in the PC. Multi-thread technology is used in the program design to reduce the response time of communication.
Hardware function can be tested by HIL test. CAN data can display clearly in the monitoring interface. So data communicated can be checked easily. And debug schedule can be quickly. HIL test shows that HCU operates normally, and sampling of sensor’s signals are real time, output signals are accurate, and the CAN communication is reliable.
5.3. Bench test
The multi-node test of CAN bus is applied in the bench test of HEV. HCU, EMS, ADM, DMCM and BPCM are concluded. Each ECU simulates the HEV running state, the CAN communication is tested in HEV bench. Figure 10 shows one curve of bench test, which include stages of motor starts engine and motor helps engine.
A reliable CAN bus could be verified from the engine running and monitoring data. The results of bench test shows that CAN hardware circuit has reliability and ability of anti-jamming. At the condition of 2600 rpm engine speed, four CAN nodes work normally. The real time communication between HCU and EMS or BPCM or other node can be achieved. What’s more, the calibration instruction and monitoring instruction can be realized regularly. The CAN communication is reliable and real time.
A multi-node CAN bus is designed based on CAN 2.0B and J1939. The structure of HEV control system is introduced. According to the requirement of control system, a CAN topology is developed. The methods of hardware and software design of CAN bus are discussed. Based on the 32-bit MC68376, power isolation and optoelectronic isolation are applied in the hardware design of CAN communication circuit. The design methods of software algorithmic are emphasized. Buffer sharing and time sharing are applied in the program design of CAN bus. The idea of multi-task is introduced. Task assignment and scheduler could optimize the real time of CAN communication, by event interrupt. Road rate of multi-node CAN bus is analyzed. In order to calibrate the ECU, the CCP driver is designed, which can achieve the data upload and download for calibration.
There are many tests to verify the multi-node CAN bus, single module test, HIL test and bench test. The multi-node CAN bus design can be accomplished quickly through these tests. All tests showed that the hardware and software design of multi-node CAN bus could meet the requirements of HEV system. The quality of CAN communication is reliable and real time.
The authors could like to acknowledge Xu Jian for his assistance in the project.
Robert B. G. C. A. N. Specification Version. 1991
Massimo C. Paolo C.. 2005CAN_LabView based development platform for fine-tuning hybrid vehicle management systems.IEEE, 433 438
Application of Electronic technology, Dai X. H. Zhu J. X. Peng Y. G. et al. 2004 Development of. E. V. control system. communication based. on C. A. N. bus[ J]. 37 39
Yao Z. Liu F. M. Li Y. X. 2005Design of Node in CAN Bus for Hybrid Electric Vehicle. Computer and Communications, 121 123
Society of Automotive Engineering INC.Data Link Layer ( 1994
Motorola INC.MC68336/376 User’sManual.
Roger Johansson, Jan Torin.On calculating guaranteed message response times on the SAE J1939 bus. Chalmers Lindholmen University College. Report 10Feb. 2002
Development of a new calibration and monitoring system for invehicle electric control units based on controller area network calibration protocol. Proc. IMechE -X J. Wang J. Feng-J X. Mao L. Yang B. Zhuo 219PartD: J. Automobile engineering: 1381 1389
The hardware design of Hardware-in-Loop Simulation System of Diesel Engine High Pressure Common-Rail ECU Based on CAN Bus. Vehicle Engine. Tang H. B. Gong Y. M. Tan W. C. Zhuo B. 1 24 28