Design and Analysis of Multi-Node CAN Bus for Diesel Hybrid Electric Vehicle

1. Introduction

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 [1]. 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[5]. 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.

Figure 1.

Structure of Diesel Hybrid Electric Vehicle

Figure 2.

Hierarchical control diagram of hybrid vehicle powertrain system

3.2. Design of CAN bus for hybrid electric vehicle

HCU is designed based on the microprocessor MC68376[6], 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.

CANbuffer	Use	Communiaca-tion period
buffer0	HCUDMCM	20ms
buffer1	HCUBPCM	1000ms
buffer3	HCUADM	20ms
buffer4	DMCM1HCU	20ms
buffer6	DMCM2HCU	50ms
buffer7	HCUCalibration	interrupt trigger
buffer8	BPCM1HCU	1000ms
buffer9	BPCM2HCU	1000ms
buffer10	ADMHCU	20ms
buffer11	CalibrationHCU	Interrupt trigger
buffer12	HCUDCN1/; LFEHCU	20ms; /100ms
buffer13	HCUDCN2/; ETHCU	20ms; /100ms
buffer14	HCUDCN3	20ms
buffer15	EEC3HCU	50ms

Table 1.

Information of CAN frames

Byte position	Data definition
1	DM_State_Flg bit1-4; DM_Dig_Flg bit5-8
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
8	Set FF

Table 2.

Detail data format of DMCM to HCU

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.

Figure 3.

Block chart of CAN circuit

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DCN1 and LFEHCU use the same buffer twelve. The flowchart of this the soft structure is shown in the figure5. Buffer time-sharing applies the mechanism of arbitration of CAN bus to avoid data conflict. What’s more, buffer time-sharing can approve the hardware usage of HCU.

Figure 4.

Flowchart of buffer time-sharing program

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.

Figure 5.

Flowchart of time-sharing program

The setting of response time of parameters should consider these two conditions.

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

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

Parameter	response time
Pedal signal	10ms
Brake signal	10ms
Speed of engine	20ms
Speed of vehicle	1000ms
State of charge(SOC)	1s
Torque of driver motor	20ms
Torque of engine	20ms

Table 3.

Response time of control parameters

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.

Figure 6.

Structure of CAN communication in the RTOS

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:

$$U_t={\displaystyle \sum _{j=1}^m(S_j}\times \tau )/T_j$$E1

In which, $$U_t$$is road rate of whole bus, $$T$$is TR period of each communication flame, $$\tau$$is bit time of CAN data transmitting, $$S_m$$is maximum number of TR data bit, $$m$$is the number of all communication flames. According to CAN2.0B and J1939, the data can be calculated by Table4.

If there are $$i$$ 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:

$$\frac{54+8i}{5}$$E2

The maximum bits of each flame TR can be calculated by following equation [7]:

$$s=\frac{54+8i}{5}+67+8i$$E3

In which, $$i$$is the bytes data of each flame TR. The bit time $$\tau$$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.

	Extend CAN; (number of bits)	Bit stuffing?
Start of Frame	1	yes
Arbitration Field	11+1+1+18+1=32	yes
Control field	6	yes
Data field	8*i	yes
CRC	15	yes
CRC delimiter	1	no
ACK field	2	no
EOF	7	no

Table 4.

Data frame of CAN message

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

Figure 7.

Structure of CCP Calibration platform

5. Verify

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.

Figure 8.

Structure of single control module

5.2. Hardware in the loop test

Hardware in the loop test is one of important steps in controller design [9]. 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.

Figure 9.

Block diagram of hardware in the loop

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.

6. Conclusion

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.

Figure 10.

Curve of bench test

Acknowledgments

The authors could like to acknowledge Xu Jian for his assistance in the project.