Research Journal of Applied Sciences, Engineering and Technology 4(13): 1980-1991, 2012
ISSN: 2040-7467
© Maxwell Scientific Organization, 2012
Submitted: March 13, 2012
Accepted: March 22, 2012
Published: July 01, 2012
Development of Electronic Control Unit For Body Control System of Pure
Electric Vehicle
1
Li Hongqiang, 1Miao Changyun, 2Yang Haijing, 1Meng Yongqiang,
3
Chen Hong and 1Liu Fangshu
1
School of Electronics and Information Engineering, Tianjin Polytechnic University, Tianjin
300387, China
2
Library, Tianjin University of Technology, Tianjin 300384, China
3
China Automotive Technology and Research Center, Tianjin 300162, China
Abstract: This study concerns the design of Electronic Control Units (ECUs) for the Body Control System
(BCS) of Pure Electric Vehicle (PEV). The main research contents are divided into two parts: its CANopen
application layer protocol and the model based design of fault detection for anti-pinch window. Firstly, the
structure of the BCS and the function of each ECU were analyzed. Then according to the communication needs
among the ECUs, the CANopen protocol for each ECU was designed. It contained the design of Network
Management, Process Data Objects and Service Data Objects. A CANopen network simulation platform was
designed by CANoe software and its components CANoe.CANopen. According to the analysis of anti-pinch
window model system, the algorithm based on H-/H4 fault detection observer estimation is proposed. Apart
from the previous methods, the pinch torque rate is considered as a fault under the pinched condition to generate
a residual. A residual is zero in normal, but it will deviate from the constant when sensing the pinched
condition. Co-simulation model of CANopen protocol and the anti-pinch model based on CANoe-MATLAB
and the bench test are design to verify the designed ECUs. The test results show that the bus load rate is 3.49%
and the results of detection time are respectively 0.18 and 0.185s, which show the CANopen protocol and the
anti-pinch algorithm are proper to the BCS of PEV.
Key words: Anti-pinch window, CANoe-Matlab, CANopen, electronic control units, pure electric vehicle
INTRODUCTION
Due to the fast evolution of semiconductor
technology, there are more and more Electronic Control
Units (ECUs) used in automobiles. ECUs are the core
components in automobiles system. They act in some
aspects such as the engine, bodywork, chassis control and
have communication function.
By now, researchers have done a lot of complex and
detailed study about automotive ECUs and made many
valuable results. Kyung-Bae et al. (2004) introduced auto
efficiency function test equipment for the smart airbag
ECU and write the test program by LabView. Hiroyuki
et al. (2006) discusses a lightweight compact CVT unit
newly developed by Daihatsu and an Electronic Control
Unit (ECU) developed jointly between Daihatsu and
Fujitsu Ten. Takashima and Kita (2008) proposed the
development process of the hybrid vehicle and electric
vehicle’s ECU. Sun and Zhang (2011) introduced the
design of ECU for automotive acceleration slip regulation
system based on Freescale S 12 MCU.
These literatures are most about gasoline and diesel
and the studies of ECUs are also for the automotive
engine and vehicle braking, stability and direction. The
research about the design of Pure Electric Vehicle (PEV)
door windows ECU is not too much.
Compared with the traditional design of automotive
ECU, the design of application layer protocol for ECUs is
more important in PEV system. There are two main
application layer protocols: J1939 and CANopen. Now
J1939 protocol has been used in the design of the
automotive driving force control system (Wu et al., 2009).
CANopen standard has been implemented in the in onvehicle network of the hybrid electric vehicle and the
design scheme of a CANopen slave stack for power train
controller in hybrid electric vehicle (Xu and Dong, 2010).
CANopen standard is used in the distributed bus
controlling of the hybrid power vehicle, which ensured
the communication of CAN equipments from different
companies (LivinÛ et al., 2009). J1939 protocol is main
used in heavy vehicles. It is facilitating to decompose but
its scalability is poor. In contrast, CANopen is a
Corresponding Author: Li Hongqiang, School of Electronics and Information Engineering, Tianjin Polytechnic University, Tianjin
300387, China, Tel.: +86-83955390
1980
Res. J. Appl. Sci. Eng. Technol., 4(13) 1980-1991, 2012
LFD_ECU
CC_ECU
RFD_ECU
CAN BUS
RBD_ECU
L BD_E CU
Fig. 1: The topological structure of BCS
CAN
I/O
Communication
Object Dictionary
Application
NMT Objects
PDOs
SDOs
Special Function
Objects
Data Types
Communication
Objects
Application
Objects
Application
Program
Device Profile
Fig. 2: The model of CAN open device
completely open protocol and has a high degree of
flexibility. So we choose CANopen as the application
layer protocol in the PEV.
This study designed the door and window ECUs for
PEV’s Body Control System (BCS). We developed the
CANopen protocol for the body control network and
proposed the model based design of fault detection for
anti-pinch window. By CANoe software and its plug-in
CANoe-Matlab interface, we achieved co-simulation of
the CANopen protocol and the anti-pinch model. Then by
the actual bench test, we further verify the designed
ECUs.
THE STRUCTURE AND CANOPEN
PROTOCOL OF THE BCS
PEV’s BCS consists of five ECUs: central control
ECU (CC_ECU), left front door ECU (LFD_ECU), right
front door ECU (RFD_ECU), left back door ECU
(LBD_ECU) and right back door ECU (RBD_ECU). The
objects of each ECU mainly include vehicle window and
door lock, while front door ECUs also controls the review
mirror. The topological structure of BCS is shown in
Fig. 1. In the remainder of this section, the function of
each ECU is analyzed. CC_ECU is the core of the BCS,
which mainly analyzes the information from other ECUs
and manages the function of those ECUs. In the working
process of the system, LFD_ECU sends the detected
keying information to CC_ECU. Based on the messages,
CC_ECU sends the control signal to the corresponding
ECU and the function is implemented there.
LFD_ECU is the most complicated one, which
integrates almost all the control keys including door lock
control key, control keys of eight windows and review
mirror control key. Through CAN bus, it sends control
command and state information to CC_ECU and receives
the control instruction from CC_ECU. The control objects
of the RFD_ECU mainly contain window motor and lock
motor of that door and the motor of the right review
mirror. RFD_ECU receives control signal from CC_ECU
and sends the local state information. RFD_ECU can also
send lock control instructions.
Compared with front door ECUs input switching
signal of both back door ECUs is simpler, which have
only one key for window controlling. The controlled
objects include lock motor and window motor of the door.
The back door ECUs only receive instruction from
CC_ECU and send the state information.
The model of CANopen device: As it is shown in Fig. 2,
A CANopen device can be divided into three parts:
communication interface, object dictionary and
application program (Kong et al., 2007). The
communication interface defines four types of
communication objects: Network Management Object
(NMT), Service Data Object (SDO), Process Data Object
1981
Res. J. Appl. Sci. Eng. Technol., 4(13) 1980-1991, 2012
Table 1: The Node-ID of each ECU in BCS
ECU
CC
LFD
RFD
Node_ID
0x01
0x0a
0x0b
LBD
0x0c
RBD
0x0d
(PDO) and Special Function Objects including
Synchronization (SYNC), Time Stamp and Emergency. It
provides services to transmit and to receive these
communication objects over the CAN bus. The Object
Dictionary (OD) describes all data types, communication
objects and application objects used in this device. It is
the interface to the application software. The OD is an
ordered grouping of objects; each object is addressed
using a 16-bit index and 8-bit sub index. The application
program provides the internal control functionality as well
as the interface to the process hardware interfaces.
A CANopen device has to support a number of the
network management services and needs a minimum of
one SDO. Each CANopen device that produces or
consumes process data should have at least one PDO. All
other communication objects are optional. The following
will introduce the design of each ECU’s communication
objects and object dictionary in BCS of PEV based on
CANopen device model.
The design of NMT:
NMT service: The CANopen network management is
node-oriented and follows a master/slave structure. It
requires one device in the network, which fulfills the
function of the NMT Master. The other nodes are NMT
Slaves. We choose CC_ECU to act as the master node,
other nodes act as the slave node. NMT Master is defined
in the entry 1F80h-1F9Fh in OD. So we define the
corresponding content in CC_ECU’s OD. The Node-ID
arrangement is as shown in Table 1.
Node guarding: Another feature of CANopen networks
is node guarding. Node guarding enables the network
manager to determine whether a node is still alive on the
network and also to determine the nodes operating state.It
is periodically performed by the NMT Master which
transmits a CAN remote frame to a NMT Slave. The
NMT Slave then responds by sending its operating state
in a single byte back to the NMT Master. Optionally, a
NMT Slave may also guard the NMT Master by timing
the interval between successive life and guard remote
frames. If the interval is too great or a lifeguard remote
frame is not received within a certain preset time frame,
the NMT Slave knows that the NMT Master is dead. The
objects at index 100Ch and 100Dh define the guard time
and the life time factor. The value of guard time is 300 ms
and the value of life time is 500 ms in this study.
The design of PDO: PDO is used to transfer real-time
data. It is transferred from one (and only one) producer to
one or more consumers. PDO transfer is limited to 1 to 8
bytes. The data content of a PDO is defined through its
CAN identifier only and its content is assumed known to
sender as well as receivers. PDO includes TPDO and
RPDO. TPDO is used to transmit message and RPDO is
used to receive message. The message can be
transmitted/received when both RPDO ID and TPDO ID
is set to the same.
In the BCS, all nodes transmit high-speed and realtime data through PDO. According to the preceding
analyze, CC_ECU contains 4 TPDOs and 7 RPDOs. 4
TPDOs were used to send the control commands to other
four ECUs. It includes: window control commands, door
lock control commands. The left front and right front door
ECUs commands include rearview mirror control
commands. 4 RPDOs are used to receive the remaining
four ECUs status information, including: window state,
lock state, the window motor current, motor current door
locks, window controls automatic/electric, fault code, etc.
The left front and right front door ECUs also includes
rear-view mirror state; 2 RPDOs are used to receive the
door lock command and key control commands from
LFD_ECU. RPDO is used to receive the door 1 lock
commands from RFD_ECU. LFD_ECU contains 3
TPDOs and 1 RPDO. 3 TPDOs are used to send key
control commands, status information and door lock
control command. 1 RPDO is used to receive the control
Fig. 3: The PDO transmission relationship
1982
Res. J. Appl. Sci. Eng. Technol., 4(13) 1980-1991, 2012
TPDO1 Application Object
Index Sub-Index
Data
7000h
01h
WindowUp
7000h
02h
WindowDown
…
…
…
Communication Parameter 1800h
01h
COB-ID
18ah
02h
transmission type
ffh
03h
04h
05h
TPDO1
Inhibit time
reserved
Event timer
18ah
Mapping Parameter 1A00h
00h
0fh
01h
70000101h
02h
70000201h
…
…
-
WindowUp
WindowDown
…
Fig. 4: The diagram of TPDO1 of LFD_ECU
commands from CC_ECU. RFD_ECU contains 2 TPDOs
and 1 RPDO. 2 TPDOs are used to send Door lock
command and the status information. 1 RPDO is used to
receive the control commands from CC_ECU. The back
doors ECUs contain 1 TPDO to send status information,
1 RPDO to receive control commands from CC_ECU.
The transmission relationship between each ECU is
shown in Fig. 3.
Each PDO is described by 2 objects in the Object
Dictionary: PDO Communication Parameter and PDO
Mapping Parameter. We use TPDO1 of LFD_ECU as an
example to illustrate the description of PDO.
As shown in Fig. 4, communication parameter of
TPDO1 is 1800 h, in which sub-index 01 h indicates
communication object identifier (COB-ID) of TPDO1
consisting of 180 h and Node_ID, where Node_ID is the
Node_ID of front-left ECU. 02 h defines the transmission
type of PDO, whose content FFh indicates asynchronous
based on event trigger. 03 and 04 h define prohibition
time and timing time respectively, which both are set to
the default value. The mapping parameter of TPDO1 is
1A00h where its application object list is contained. The
content 70000101 h of its sub-index 01 h indicates its 1st
application object is stored at main index 7000 h and subindex 01 h, which is the raising instruction of front-left
window. The last two bytes indicate the data structure, i.e.
01 h for 1 bit structure, 08 h for 8 bit structure, 10 h for 16
bits structure and 20 h for 32 bits structure. Based on the
same principle, all the rest control instructions are mapped
to the mapping parameters of TPDO1.
The design of SDO: With SDO the access to entries of a
device object dictionary is provided. One SDO uses two
CAN Data Frames with different identifiers, because the
communication is confirmed. The owner of the accessed
object dictionary is the server of the SDO. A device may
support more than one SDO. One supported SDO is
mandatory and the default case. In this system CC_ECU
is Client and other ECUs are Servers. SDOs are described
by the communication parameter. The default ServerSDO is defined in the entry 1200h-12FFh and Client-SDO
is specified in the entry 1280h-12FFh in OD. The
communication process of CC_ECU accessing LFD_ECU
object dictionary by SDO is depicted in Fig. 5. CC_ECU
is as client and LFD_ECU is as server. Based on its
requirement, CC_ECU generates SDO request message
and sends it onto CAN bus. SDO request message
contains ID and data. ID, defined by main index 1280 h
and sub-index 01 h of its object dictionary, consists of 600
h and Node_ID, where Node_ID is the Node_ID of the
server to be accessed, namely front-left ECU. Data of
SDO request message is used to indicate the requested
task of SDO. On receiving this SDO request, LFD_ECU
analyzes the message and completes the requested task of
CC_ECU SDO, after which the implementation result of
the SDO request is packaged and sent onto the bus.
Finally, one SDO response message is returned to
CC_ECU. Similarly, SDO response message contains ID
and data, where ID is defined by main index 1200 h and
sub-index 02 h of its object dictionary. ID consists of 580
h and Node_ID, where Node_ID is the Node_ID of
server, namely front-left ECU. Data of SDO response
message is used to indicate the implementation result of
SDO request.
The design of SYNC: SYNC is used to synchronize tasks
network-wide. Time Stamp provides application devices
a common time frame reference. Emergency is triggered
by the occurrence of a device internal error. This system
use default value.
The simulation of CANopen protocol: We use CANoe
and its components CANoe.CANopen developed by
Germany Vector Informatik to design the BCS CANopen
network simulation platform. CANoe is a comprehensive
software tool for the development, testing and analysis of
1983
Res. J. Appl. Sci. Eng. Technol., 4(13) 1980-1991, 2012
Index
CC _ECU
Object Dictionary of CC_ECU
Description
Sub-Index
1280h
01h
1280h
02h
…
…
SDO Request
60ah
58ah
Data
COB-ID Client->Server 60ah
COB-ID Server- >Client 58ah
…
…
data1
data2
SDO R esponse
LFD_ECU
Object Dictionary of LFD_ECU
Index Sub -Index
Data
Description
1200h
01h COB -ID Client->Server 60ah
1200h
02h COB -ID Server->Client 58ah
xxxxh
xxh
---xxh
…
…
---…
Fig. 5: The SDO communication between CC_ECU and LFD_ECU
Analysis this control
requirements and
communication needs
of the system
Use can eds software to
create the EDS file for
each node
Run por can open software
to create the door control
system can open network
Use CAPL language to
build functional
modeling of real nodes
Run can oe
software to generate
the simulation model
Use panel Editor to
de singn display
interface
Complete the de singof
the can open network
Fig. 6: The flow chart of CAN open network design
entire ECU networks and individual ECUs. Its
components contain: ProCANopen, CANeds, Panel Editor
and CAPL Browser. ProCANopen is used to plan and
configures the CANopen networks. CANeds is used to
create and check EDS files (Electronic Data Sheet). Panel
Editor is used for designing of control panels. CAPL
Browser is used to edit the Communication Access
Programming Language (CAPL) program. The flow of
the CANopen network design is shown in Fig. 6.
Object dictionary is necessary for every ECU in the
CANopen network. The Electronic Data Sheet (EDS) is
the standard storage mode for object dictionary. CANeds
software is used to establish EDS file for each ECU. The
main contents of EDS file are: the define of PDO
communication parameter and mapping parameter, SDO
parameter and the data.
ProCANopen is used to configure each ECU’s OD.
As it is shown in Fig. 7, Firstly, body control CANopen
1984
Res. J. Appl. Sci. Eng. Technol., 4(13) 1980-1991, 2012
G roup:
EDS
CC _EC U
ID 1
G roup:
EDS
E DS
LFD_EC U
ID 10
EDS
R FD_E CU
ID 11
L BD_EC U
ID 12
E DS
R BD_EC U
ID 13
Fig. 7: The configuration of CAN open network
ECU
ECU
ECU
RBD_ECU
RFD_ECU
CC_ECU
Prog
Prog
Prog
Bus
CANopen
CAN 1
ECU
ECU
LBD_ECU
LFD_ECU
Prog
Prog
Fig. 8: The configuration of simulation nodes
network is designed. Secondly, EDS file generated by
the CANeds is imported into each node. Finally the nodes
object dictionary is configure. The main contents are: the
Configuration of NMT, Lifeguarding, PDO relationship
and SDO Properties. Then the files needed for simulation
can be generated automatically during the generation
process.
After importing the generated database to CANoe
software, a simple BCS CANopen network is achieved.
The configuration of nodes is shown in Fig. 8.
But for a real control system, each node has specific
functions. So the CAPL program is used to simulate node
functions in CANoe, such as: window lift, lock switch,
mirror control. The CAPL code is shown as follows:
Simulation nodes LFD_ECU:
on envVar evN10_7004_2
{int a; a = getValue (evN1_7101_2);
putValue (evN10_7001_2, a); // LFD_ECU detects the
control key information and then sends key control PDO
message to the CAN bus.}
Simulation nodes CC_ECU:
on message N10_TPDO0 {int a;
a = getValue (evN1_2101_2);
putValue (evN1_2001_2, a); // Receive command
information and store the command in the object
dictionary.}
Simulation nodes RBD_ECU
on message N1_TPDO0
{int a;
a = getvalue (evN11_7101_2);
SignalWindowDown (a); // window down function is
called putValue (evN13_7001_2, evN13_2101_2); //
change the current state of the RFD_ECU}
In order to make the control panel more intuitive, the
panel editor software included in CANoe is used to edit
the control panel. The designed control panel is shown in
Fig. 9. It contains the control area and the display area.
The control area contains: window, door lock and rear
view mirror control keys. The display area contains: the
display of windows and door locks.
1985
Res. J. Appl. Sci. Eng. Technol., 4(13) 1980-1991, 2012
Fig. 9: The designed control panel
THE MODELING OF ANTI-PINCH WINDOW
Using (1) and (2), we can obtain the following form:
Recently, special attention has been paid to the antipinch protection and fault diagnosis when the window
lifts (Ma et al., 2008). In this study the pinch torque rate
is seen as a fault which is considered a variable or a
feature deviates from the normal value when the window
is presented by the obstacle. The basic method of the fault
detection is to construct an optimal fault detection
observer which is used to acquire a residual. Through
comparing the residual evaluation value with a threshold,
it is easy to judge whether a fault is in the control system.
Consider the uncertain LTI dynamic system described by
state-space model:
 x  Ax  Bu  B f f  Bv v  Bnn

 y  Cx  Du  D f f  Dv v  Dnn
(1)
where x is the state vector, u is the control input, y is the
measurement vector, v and n are the unknown finite
energy disturbance and the white noise, f is the fault input
vector. A, B, C, D, Bv, Bn, Dv, Dn, Bf, Df are known
matrices with appropriate dimensions.
Generally speaking, a fault detection system consists
of two parts: a residual generator and a residual evaluator.
First we design residual generator based on fault detection
filter as follows:
 x  ( A  LC ) x  ( B  LD)u  Ly

  Du
 y  Cx
 r  y  y

(2)
where are respectively the state and measurement vector,
r is the residual signal, L represents observer gain matrix.
e  ( A  LC)e  ( B f  LD f ) f  ( Bv  LDv )

 v  ( Bn  LDn )n,
r  Ce  D f  D v  D n
f
v
n

(3)
Note that the dynamics of the residual signal r
depends on not only v, n and f, but also the state e.
However, r is completely decoupled from the input u. We
can express the (3) in the form of transfer function:
r(s) = Trf(s)f(s)+Trn(s)n(s)+Trv(s)v(s)
(4)
Trv, Trn, Trf are the transfer functions from v, n, f to r
respectively. Here we can describe the fault detection by
the relationship between the input v, n, f and the output r.
The next section we will formulate the fault detection of
anti-pinch window as a mixed H-/H4 estimation problem
and provide an LMI solution to the estimation problem.
Given three scalars $>0, (1>0, (2>0. Observer (1) is
called an H-/H4 fault detection observer if the following
three established:
||Trn(s)||4< (1 Trn= C(sI – A – LC)-1(Bn – LDn)+Dn
(5)
||Trv(s)||4<(2Trv = C(sI – A – LC)-1(Bv – LDv)+Dv
(6)
||Trf(s)||->$Trf = C(SI – A – LC)-1(Bf – LDf)+Df
(7)
while, as we know, condition (5), (6) represent the worsecase criterion for the effect of disturbances on the residual
r, condition (7) stands for the worse-case criterion for the
sensitivity of r to fault. Clearly, these three criteria capture
the most significant features of fault detection observer.
According to bounded real lemma the optimization
problem consists of formula (5), (6) and (7) can be
expressed by the following LMI matrices inequality:
1986
Res. J. Appl. Sci. Eng. Technol., 4(13) 1980-1991, 2012
Table 2: The parameters of window motor
Variable
Parameter
armature resistance
Rm
Lm
armature inductance
Ke
back electromotive
force coefficient
Kt
torque coefficient
Tn
electromechanical
time constant
J
moment inertia
Vc
supply voltage
Values
0.85
0.649
0.1204
v•s/rad
s
0.1204
9.3×10G3
kg•m2
v
1.5 86×10G4
12
 A T P  PA  C T C  LC  C T LT

 PBv  LDv  C T Dv  T

PBv  LDv  C T Dv 
0
  12 I  DvT Dv 
 A T P  PA  C T C  LC  C T LT

 PBn  LDn  C T Dn  T

PBn  LDn  C T Dn 
0
  22 I  DnT Dn 
 A T P  PA  C T C  LC  C T LT

T
C T D f  LD f  PB f

C T D f  LD f  PB f 
0
 2 I  D Tf D f



 A T P  PA  C T LT  LC

T
PB f  LD f



. 
893109
0  ,
B f  

0 
Units
S
mH
v•s/rad
PB f  LD f 
0
0

 893109
. 


0 
 0 
, B 
 893109
. 


0 
B 
C = [1 0 0], D = [0], n 
,
 0 
1 
 
Bv  1 
 0
Using the LMI toolbox in MATLAB, the
performance indices are: (1min = 0.0145, (2min = 0.05, $max
= 1.4883, the observer gain is: L = [183.5130-11.29700.1825]T. Then the robust fault diagnosis system model of
anti-pinch window with the observer gain can be built as
shown in Fig. 10.
SIMULATION AND RESULTS
The parameters of the DC can be get by
experiments which given in Table 2. The matrices of the
model can be designed as follow:
  107.530  6305170
0
.


A 
0
0
1

0
0
0
Dn = [0.05], Dv = [0], Df = [1]
The co-simulation of CANopen protocol and antipinch algorithms: In the development of ECU, the
simulation evaluation of the design results is to determine
whether the development agreement meets the design
requirements. CANoe is a professional tool for ECU
development, testing and analysis, which supports the
entire system of development process from requirements
analysis to system implementation. Meanwhile,
MATLAB/Simulink often used by researchers has a
strong ability to build complex functional model,
however, it is not perfect to the bus network system
simulation. Considering the two aspects, Vector
Informatik introduces CANoe-Matlab interface in order to
achieve a co-simulation with Matlab and CANoe, (Lin
and Zhang, 2008; Duan et al., 2010; Li et al., 2009).
CANoe-MATLAB interface can be operated in two
different modes: one is offline mode, the other is
Hardware-In-the-Loop (HIL) mode. The whole system
simulation process is based on HIL mode as shown in
Fig. 11. In HIL mode, CANoe runs as
MATLAB/Simulink subsidiary mode. When the time
starts running simulink model, CANoe will automatically
open the bus monitor and display bus message value and
signal value.
Fig. 10: Simulink model of anti-pinch window
1987
Res. J. Appl. Sci. Eng. Technol., 4(13) 1980-1991, 2012
Simul ati on node
L FD_ECU
M ATL AB/Simul ink
CANo e
CANoe/
MATLAB
interface
C ANope n
net wo rk
Moto r
Con tro l
a lgo rith m
Lef t rear view mir ro r Ri ght r ear view mir ror
Door Lo ck
CANcaseXL USB2 .0
In terf ace car d
Contro l switch
CAN Bus
Fig. 11: The co-simulation of CAN open protocol and anti-pinch window
Vec tor CANoe.ISO11783.LIN.MOST .Fle xRay.J 1587.IP- car_sim.cf g*
File Vie w Star t Mode Configur ation Window He lp
LFD_ECU sends ke y
contr ol c ommand
Chn Dir
Name
Tra ce
Time
2.656544
1
Tx
303.37...
1
Tx
303.38...
1
Tx
303.51...
1
Tx
303.11...
1 seTx
RFD_ECU
nds
0.556952
Tx
sta te inf 1or mation
Bus Statistics
Busloa d
Busload [ %]
Pe akloa d [%]
Std Data [ fr/s]
Std Data [ tota l]
DLC
2
4
4
5
5
8
0 NMTZe roMsg
18A N10_TPDO0
181
N1_TPDO0
28A N10_TPDO1
18B N11_TPDO0
58A
SSDO_010
CAN 1
3.49
4.06
44
2084
Data
CC_ECU
01 00
se nds contr ol
02 00 00 00
command
02 00 00 00
00 00 00 00
02 0D 00 00
43 00 10 00 95 01 00 00
Message number
Sta tistics
Msg/s
20.0
10.0
0
100
200
300
400
Fig. 12: The observation window of CAN open network
The CANopen network simulation result: The BCS
CANopen network simulation platform is created. We can
use the simulation platform to test and verify the design
CANopen network. The contents of simulation contain:
the realization of the control button functions, PDO
message sending, bus loads and so on.
As Fig. 12 shown, by controlling the right front
window down button, we observed the response of the
corresponding control object. When the system starts, the
four ECUs sends status messages periodically, the control
keys stochastic control. The bus load rate is 3.49%, the
peak the peak load rate is 4.06%. The bus operation is
good.
The anti-pinch algorithm simulation result: With the
Simulink Real-Time Workshop, we can target CANoe
1988
Res. J. Appl. Sci. Eng. Technol., 4(13) 1980-1991, 2012
Amplitude
1.2
1.0
0.8
Residual
Evaluation
0.6
0.4
0.2
0.0
-0.2
-0.4
0.0
0.5
1.0
1.5
2.0
2.5 3.0
Time (sec)
3.5
4.0
4.5
5.0
Fig. 13: Co-simulation results
and produce a Windows DLL which can be loaded in
CANoe's simulation environment. With this approach it
is possible to test and verify a design with real hardware
in a networked environment. The simulation can be used
as a simulation of the remainder of the bus in a real-time
environment. This mode is recommended, if it is
necessary to run huge models and the remaining bus in
real time. The simulation results are as follows.
Figure 13 shows the residual and the residual
evaluation when the fault occurs, we can see the results
are similar as the MATLAB Simulation results. The
residual changes dramatically under the pinch condition
and the residual evaluation exceed the threshold as the
former results.
The results of bench test: In order to debug the functions
of the ECU, the tests for various factors in part are
required on the real vehicle test. But a large number of
financial and human recourses are consumed using the
real car test. This is why the specialized research
laboratories develop the test platforms and benches for the
test of the ECU which proposed a means of quick test for
the real car test.
Based on the former test of HIL mode, we rig the
ECU of car door and window on the real frame for the
bench test. The networked control functions of the car
door and window are verified effectively, as well as the
anti-pinch algorithm.
The test bench based on the charade model of
TIANJIN FAW XIALI AUTOMOBILE COLTD which
is the prototype of XL PEV. Figure 14 shows a general
view of the test bench.
In order to verify the effectiveness of door and
window control network, CANopen network can access
to communicate with the PC by interface devices. PC
through the interface device can send control commands
to the network and receive the real-time data transmission
status of ECUs. We use VC++ software to design the door
and window control network CANopen protocol
monitoring testing software. The main window is shown
in Fig. 15.
Computer
USB
CC_ECU
Node-ID: 0x01
USB/CAN converter
LBD_ECU
Node-ID: 0x12
LFD_ECU
Node-ID: 0x10
CAN
RBD_ECU
Node-ID: 0x13
RFD_ECU
Node-ID: 0x11
Fig. 14: Architecture of test system
Fig. 15: The monitoring testing software
1989
Res. J. Appl. Sci. Eng. Technol., 4(13) 1980-1991, 2012
CONCLUSION
1.2
1.0
Obstacle detected
This study mainly introduces the design and
simulation ECUs for PEV BCS. It contains the design of
its application layer protocol-CANopen and anti-pinch
algorithm of windows. We have built the simulation
model of CANopen network by CANoe and the model of
anti-pinch window by Matlab. By CANoe-Matlab
interface we realize the Co-simulation of the CANopen
protocol and the function of anti-pinch. The simulation
results show the observer can detect the fault after it
occurs 0.16s and the bus load rate is 3.49%. Moreover,
the bench test verifies the algorithm can detect the antipinch with the road vibration after it occurs 0.185s. The
results show that the designed ECUs are proper and have
great practical value.
Residual
0.8
0.6
0.4
Obstacle appear
0.2
0.0
-0.2
-0.4
0.0 0.5 1.0 1.5 2.0 2.5 3.0 3.5 4.0 4.5 5.0
Time (sec)
Fig. 16: Residual of pinch condition
1.2
1.0
Residual
0.8
Obstacle detected
2
1
3 4
ACKNOWLEDGMENT
0.6
0.4
This study is supported by The National High
Technology Research and Development Program of China
(No.2001AA501310) and the Specialized Research Fund
for the Doctoral Program of Higher Education of China
(No. 20101201120001).
Obstacle appear
0.2
0.0
-0.2
-0.4
0.0 0.5 1.0 1.5 2.0 2.5 3.0 3.5 4.0 4.5 5.0
Time (sec)
REFERENCES
Fig. 17: Residual of pinch condition with road vibration
Figure 16 shows the pinch condition when the
window lifts. The beeline is the threshold 0.5042 and the
residual exceeds the threshold at 2.88s when the obstacle
prevented the window rising at 2.7s. We can calculate the
detection time is 0.18s. The robust fault detection can
detect the anti-pinch accurately and quickly as the figure
shown.
Based on the actual measurement of Hall signal on
the C-class road which is dirt, gravel, continuous winding
road, 10 degree slope, below the hard ground 20 cm
wading and the two snow-covered roads in China road
grader. The test of anti-pinch window with road vibration
is verified. Figure 17 shows the residual of pinch
condition with road vibration. As the figure shown, the
residual appears some fluctuation which all below the
threshold at the point 1, 2, 3, 4 because of the road
vibration. As the former the pinch condition occurs at 2.7s
and the residual exceeds the threshold at 2.885s. The
detection time is 0.185s. We can see the fluctuation of
residual with the road vibration does not exceed the
threshold, avoiding the error detection. The robust fault
detection for anti-pinch can inhibit the disturbance of road
vibration as the results shown. But this inhibition is within
a certain range because of the threshold.
Kyung-Bae, C., K. Tae-Kook and P. Gwi-Tae, 2004.
Development function test equipment for smart
airbag Electronics Control Unit (ECU). IEEE
International Symposium on Consumer Electronics,
ISCE, United Kingdom, September, pp: 1-3.
Duan, J., H. Deng and Y. Yu, 2010. Co-Simulation of
SBW and FlexRay Bus Based on CANoe-MATLAB.
Proceedings of the 2010 IEEE International
Conference on Automation and Logistics, Hong
Kong and Macau, August, pp: 16-20.
Hiroyuki, H., I. Yutaka and K. Junichi, 2006.
Development of CVT/ECU for Daihatsu Vehicles.
Fujitsu Ten Technical Report., 24(2): 20-25.
Kong, F., H. Zhang and X. Song, 2007. A preliminary
investigation into vehicle control network based on
CANopen Protocol. Automot. Eng., 29(7): 594-596.
Lin, C. and L. Zhang, 2008. Hardware-in-the-loop
simulation and its application in electric vehicle
development. IEEE VPPC, China, September, pp:
3-5.
Li, D., J. Cao and J. Zhang, 2009. Co-simulation of
vehicle CAN bus based on CANoe-MATLAB. J.
Comput. Appl., 6: 57-61.
LivinÛ, G., V. Horga, M. R|Ûoi, M. Albu and G. Chiriac,
2009. Implementing the CANopen Protocol for the
Distributed Control of a Hybrid Electric Vehicle.
EPE Chapter ‘Electric Drives’ Joint Symposium,
France, July 1-3.
1990
Res. J. Appl. Sci. Eng. Technol., 4(13) 1980-1991, 2012
Ma, W., S. Zhang and H. Wang, 2008. The design of antipinch car window using Hall sensor. Automotive
Eng., 35(12): 1256-1260.
Sun, J. and L. Zhang, 2011. ECU design of automotive
ASR systems and Its hardware-in-the-loop simulation
using xPC target. Chinese J. Automot. Eng., 1(1): 7680.
Takashima, H. and T. Kita, 2008. Study on Architecture
of ECU for automobile. T. Jap. Soc. Mech. Eng. Part
C., 74(743): 1758-1764.
Wu, J., Y. Li, J. Li, Y. Li, H. Yu and L. Song, 2009. CAN
bus of automotive driving force control system based
on SAE protocol J1939. J. Jilin Univ. Eng. Technol.
Edn., 39(4): 855-858.
Xu, Z. and S. Dong, 2010. The Design and
Implementation of a CANopen Slave Stack for
Powertrain Controller in Hybrid Electric Vehicle.
2010 International Conference on Intelligent
Computation Technology and Automation, China,
May 11-12.
1991