1

Technical Article

April 2009

Testing Multiple ECUs Right at the Developer’s Workbench

The complexity of systems in today’s automobiles, both in the elec-

tronics and software, makes comprehensive tests necessary in all

development phases, because it is easier and cheaper to correct

errors detected early than those detected later. This is why each

ECU undergoes in-depth testing, followed by integration tests on a

breadboard setup and classic tests that are run on fully equipped

test stands.

Verifying ECU functions for normal operation is an important

requirement. However, the numerous cases when faults occur

deserve special attention. How ECUs malfunction in infrequent

situations or in situations that are impossible under normal operat-

ing conditions can cause significant problems for manufacturers

when they occur in the field later. Such faults are difficult to find

and analyze. Therefore, it is important to systematically test ECUs

early during development to verify their correct behavior when

faults occur.

Functional Testing of ECUs

Testing ECU functionality includes stimulating it via hardware and

software interfaces and evaluating its responses. It is important

for the ECU to be in an environment that most closely resembles

that of the real vehicle, and most importantly that the ECU not be

able to detect any difference between the simulated environment

of the test bench and the actual environment in the vehicle.

In many cases, ECUs automatically check their sensors and

actuators, so it is essential to have them connected during the test.

If external components are missing, the ECU may generate errors or

deactivate certain functions. Therefore, the sensors and actuators

are necessary for all tests.

The prototype actuators and sensors are often connected

directly to the ECU for testing. During testing the test bench is only

usable for the specific ECU for those actuators and sensors. Also

problematic here is the way to automate test sequences, since the

A Modular Test System for Efficient Functional Tests with Fault Simulation

Functional testing of automotive ECUs, besides testing for basic functionality, must also test the most significant faults at the ECU’s communication interfaces and the I/O interfaces. By using the VT System, a modular test system by Vector that is tailored to automotive industry requirements, you can efficiently execute functional tests during early development phases.

2

Technical Article

April 2009

original components might need to be operated by actuating robot-

ics, which are difficult to program.

A better alternative is to simulate the connected loads and

sensors. Since ECUs are often just equipped with simple test switches

a complex simulation of the electrical and physical properties of

the components is not required. Simple simulations are com-

pletely adequate and can be implemented with cost-effective,

compact and yet flexible test systems. Another advantage of sensor

and actuator simulation lies in its potential for automating test

sequences, and a Hardware-In-the-Loop (HIL) test.

ECU Testing in Fault Situations

However additional equipment is needed to cover fault situations

during ECU testing. Such equipment – such as the VT System from

Vector – is connected in the circuit between the ECU and its sensors

and actuators (Figure 1). These test components can be used to

test the following fault situations:

Electrical wiring is damaged, such as due to line breaks or short >

circuits.

Sensors or actuators are damaged: Sensors do not output any >

values, they supply incorrect values, or electrical characteristics,

such as internal impedance or current consumption which

deviate from the specification.

Incorrect input values, especially incorrect sensor data: The >

sensor might seem to be working properly from the ECU’s point

of view, but even though values are within allowable limits, they

are implausible or contradict other sensor values.

In these cases, the ECU response must be defined by the user, e.g.

to generate appropriate fault memory entries. In turn, these

entries must be checked by the test system – in this case via the

diagnostic interface.

Flexible Test Solution with CANoe and the VT System

These considerations place strict requirements on robust, high-

capacity test systems in terms of interfaces and test hardware, test

automation, operation of software interfaces and the capabilities

of rest-of-bus simulations, just to name a few.

CANoe from Vector is a widely used tool that is available on the

market for analysis, simulation and test automation of ECUs

(Figure 1). Vector hardware interfaces ensure a reliable bus inter-

face to CAN, LIN, FlexRay or MOST. Measurement and test hardware

is connected via GPIB or the serial port, and standard I/O cards

from various manufacturers may also be used.

The VT System is a modular I/O system that drives ECU inputs

and outputs for functional testing with CANoe. It lets users set up

compact test benches of various complexities. The ECU’s I/O lines

and any necessary sensors and actuators are connected to the

VT System modules. The PC with CANoe is connected to the real-

time capable EtherCAT via the computer’s Ethernet port. This lets

users set up flexible test systems with little integration or wiring

effort. Due to its modular construction, the VT System is ideal for

small test setups at developer workbenches as well as for compre-

hensive test benches in the testing laboratory.

All of the components needed to interconnect an I/O channel

are integrated into a VT System module. This significantly simpli-

fies the setup of test stands. Examples of I/O channels: an ECU

output for driving a windshield wiper motor or an input for

connecting a temperature sensor. The modules and all measure-

ment and stimulation devices are designed for voltage ranges of up

Figure 1: The VT System is placed between the ECU and actuators/sensors for testing.

3

Technical Article

April 2009

to 32 Volts, ranges that are typical in the automotive environment.

For example, they can handle the higher currents that may arise

when driving lamps and motors.

The following test devices are already built into the modules:

Relays for connecting ECU lines to real or simulated sensors and >

actuators

Relays for simulating line faults, such as short circuits, to supply >

voltage lines

Electronic load for simulating actuators >

Measuring ECU output voltages, including calculating the ave >

rage, effective values and PWM parameters

Resistor decades for stimulating sensor inputs >

Outputting voltages to simulate sensors. >

The ECU’s I/O channels do not need to share these test devices,

since the VT modules provide separate devices for each channel.

This simplifies test automation and programming, and lets users

represent and produce multiple faults and more complex operating

sequences without any problems.

The VT System from Vector gives the test engineer a compact

and powerful solution for setting up flexible test systems for auto-

motive applications. Test automation can be efficiently implemen-

ted in CANoe by seamlessly integrating the VT System.

Translation of a German publication in Automobil Elektronik, 2/2009

Links:Homepage Vector: www.vector.comProduct Information VT System: www.vector.com/vt-systemProduct Information CANoe: www.vector.com/canoe

>> Your Contact:

Germany and all countries, not named belowVector Informatik GmbH, Stuttgart, Germany, www.vector.com

France, Belgium, Luxembourg Vector France, Paris/Malakoff, France, www.vector-france.com

Sweden, Denmark, Norway, Finland, IcelandVecScan AB, Göteborg, Sweden, www.vector-scandinavia.com

Great BritainVector GB Ltd., Birmingham, United Kingdom, www.vector-gb.co.uk

USA, Canada, MexicoVector CANtech, Inc., Detroit/Novi, USA, www.vector-cantech.com

JapanVector Japan Co., Ltd., Tokyo, Japan, www.vector-japan.co.jp

KoreaVector Korea IT Inc., Seoul, Republic of Korea, www.vector.kr

E-Mail Contactinfo@vector-worldwide.com

Stefan Krauß Studied Computer Science at the University of Stuttgart from 1990 to 1995. After gradu-ation he worked as a research assistant at the Institute for Computer Science in the university’s Software Engineering Depart-ment until 2001. Since 2002 he has been working with Vector Informatik GmbH in Stuttgart, where he is currently Product Manager for the VT System.