Open access peer-reviewed chapter

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

By XiaoJian Mao, Jun hua Song, Junxi Wang, Hang bo Tang and Zhuo bin

Submitted: November 16th 2010Published: September 12th 2011

DOI: 10.5772/intechopen.84040

Downloaded: 6020

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.

CANbufferUseCommuniaca-tion period
buffer0HCUDMCM20ms
buffer1HCUBPCM1000ms
buffer3HCUADM20ms
buffer4DMCM1HCU20ms
buffer6DMCM2HCU50ms
buffer7HCUCalibrationinterrupt trigger
buffer8BPCM1HCU1000ms
buffer9BPCM2HCU1000ms
buffer10ADMHCU20ms
buffer11CalibrationHCUInterrupt trigger
buffer12HCUDCN1/
LFEHCU
20ms
/100ms
buffer13HCUDCN2/
ETHCU
20ms
/100ms
buffer14HCUDCN320ms
buffer15EEC3HCU50ms

Table 1.

Information of CAN frames

Byte positionData definition
1DM_State_Flg bit1-4
DM_Dig_Flg bit5-8
2High byte of DM_Trq_Actual
3low byte of DM_Trq_Actual
4high byte of DM_Spd_Actual
5low byte of DM_Spd_Actual
6high byte of DM_I_Actual
7low byte of DM_I_Actual
8Set 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 HCUDCN1 and LFEHCU 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.

Parameterresponse time
Pedal signal10ms
Brake signal10ms
Speed of engine20ms
Speed of vehicle1000ms
State of charge(SOC)1s
Torque of driver motor20ms
Torque of engine20ms

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:

Ut=j=1m(Sj×τ)/TjE1

In which, Utis road rate of whole bus, Tis TR period of each communication flame, τis bit time of CAN data transmitting, Smis maximum number of TR data bit, mis the number of all communication flames. According to CAN2.0B and J1939, the data can be calculated by Table4.

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

54+8i5E2

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

s=54+8i5+67+8iE3

In which, iis 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.

Extend CAN
(number of bits)
Bit stuffing?
Start of Frame1yes
Arbitration Field11+1+1+18+1=32yes
Control field6yes
Data field8*iyes
CRC15yes
CRC delimiter1no
ACK field2no
EOF7no

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.

© 2011 The Author(s). Licensee IntechOpen. This chapter is distributed under the terms of the Creative Commons Attribution-NonCommercial-ShareAlike-3.0 License, which permits use, distribution and reproduction for non-commercial purposes, provided the original is properly cited and derivative works building on this content are distributed under the same license.

How to cite and reference

Link to this chapter Copy to clipboard

Cite this chapter Copy to clipboard

XiaoJian Mao, Jun hua Song, Junxi Wang, Hang bo Tang and Zhuo bin (September 12th 2011). Design and Analysis of Multi-Node CAN Bus for Diesel Hybrid Electric Vehicle, Electric Vehicles - Modelling and Simulations, Seref Soylu, IntechOpen, DOI: 10.5772/intechopen.84040. Available from:

chapter statistics

6020total chapter downloads

More statistics for editors and authors

Login to your personal dashboard for more detailed statistics on your publications.

Access personal reporting

Related Content

This Book

Next chapter

Sugeno Inference Perturbation Analysis for Electric Aerial Vehicles

By John T. Economou and Kevin Knowles

Related Book

First chapter

A Survey on Electric and Hybrid Electric Vehicle Technology

By Samuel E. de Lucena

We are IntechOpen, the world's leading publisher of Open Access books. Built by scientists, for scientists. Our readership spans scientists, professors, researchers, librarians, and students, as well as business professionals. We share our knowledge and peer-reveiwed research papers with libraries, scientific and engineering societies, and also work with corporate R&D departments and government entities.

More About Us