1

Technical Article

February 2012

Structuring ECU Tests More Rationally

ECU tests are run on different development levels, and they range

from checking of individual components to system tests and cus-

tomer acceptance testing. To cover requirements in the best possi-

ble way, tools and test equipment are often built up in various

departments, often over a period of years. For test bench tests,

however, users need small to mid-size test solutions that can be

scaled to testing needs. Large scale Hardware-in-the-Loop systems

(HIL systems) are not only overqualified for the work bench, they

are also too expensive and simply too large. With large 19” hous-

ings, a PC, peripheral devices with extensive cable sets, they find

their rightful place in the laboratory. For road testing in the auto-

mobile, testing personnel require mobile-capable equipment,

where the focus is on compactness. As a result, at many companies

a quantity of test platforms and tools has become established; they

come from different manufacturers, each one only covers certain

portions of test requirements and they have different data formats

and operate with different user interface philosophies.

Heterogeneous test landscapes prevent synergistic effects

Such typical test layouts are associated with the problem of

overlapping, multiple implementation, and they make uniform test

management more difficult than it needs to be. For example, test

definitions and test flows need to be created individually for each

test system. Then there is the time expended in training personnel

and learning the various testing languages and operating

sequences. Given this situation, the desire for greater scalability,

reusability and more uniform handling of test systems is quite

understandable.

Generally, the central task in testing an ECU is to find an optimal

set of tests to obtain meaningful results quickly. Therefore, test

data management and test management systems that are power-

ful and comprehensive are of primary importance in achieving a

economical and modern 'test culture' in a business. Such systems

fulfill all requirements for traceability and provide an overview of

the current state of a development, answering such questions as:

Which requirements have been fulfilled, and which functions are

operationally ready? This gives developers and project managers

an instrument for monitoring success, and at any time it can be

used to verify that an ECU’s quality and maturity level are continu-

ally rising until the quality goal of a system is finally attained with

a precisely known version of the System-under-Test. Uniform test

data management on all development levels also makes it easy to

identify the points at which tests need to be adapted when

requirements suddenly change. That is because experience has

shown that development processes are seldom entirely linear in

nature.

Scalability and flexibility trump in ECU testing

The development of an ECU always involves numerous tests. Test require-ments differ significantly, depending on the stage of development, and within a company they generally fall under the auspices of different departments. If they use different platforms, this leads to high resource requirements in test creation and test management. Much more economical are solutions based on the tool CANoe for simulation and test, which is well-suited for tests on all development levels, due to its high scalability and flexibility.

2

Technical Article

February 2012

From minimal configuration to universal system

The requirements of HIL systems are multilayered, and they dif-

fer significantly from one application case to another. A scalable

platform must, on the one hand, cover all conceivable tasks, while

on the other it must permit a reasonable minimum configuration.

The tasks to be performed range from stimulation of the ECU, con-

trol of the system environment and testing of system reactions to

automated test execution and report generation (see Figure 1).

The user interface and a practical approach deserve consideration

as well. How do engineers want to create their test models and

sequences? Which approach leads to the goal quickest? The possi-

bilities range from model-based graphic methods to user-friendly

drag and drop editors for simple test sequences and finally classic

programming.

An optimally scalable test system (see Figure 2) provides interface

hardware for all relevant bus systems in the automotive field. Key

systems here include CAN, FlexRay, LIN, MOST, Ethernet and the

K-Line. Depending on the domain, various digital and analog inter-

faces to external measurement and control hardware may be need-

ed, such as GPIB or RS232 interfaces. A suitable debug interface

must also be considered for accessing the ECU’s memory via

NEXUS/JTAG, over XCP or alternatively by diagnostic access. A com-

plete environment simulation also includes exact simulation of all

sensors and actuators connected to an ECU, such as temperature

sensors, pressure sensors, switches, lamps or actuator motors.

Generally, ECUs check their inputs and outputs for the presence of

these components; this involves checking for relevant termination

impedances and other electrical properties.

Artificial worlds of sensors and actuators

Often, it does not make sense to connect original sensors and

actuators to the ECU for testing. This would make test automation

considerably more difficult, e.g. by having robots operating con-

trols. In addition, a frequent objective of tests is to subject the ECU

to specific error situations. How does the system react to short cir-

cuits, overvoltages and undervoltages or other disturbances under

test? Are error events correctly entered in fault memory? It is gen-

erally impossible to generate specific errors and manipulate sensor

and actuator behavior with original components, rather one

requires flexibly configurable test hardware with ECU stimulation

(also known as remaining bus simulation).

During the tests, which are ideally run automatically, the actual

work for developers lies in the creation of test designs, test

models, flow sequences and scripts. Therefore, the performance

capability of a test platform is essentially determined by the avail-

ability of efficient tools with various graphic or text-based meth-

ods for test creation. The preferred method depends primarily on

the specific tasks to be performed, on the qualifications and

knowledge of personnel and last be not least on personal

preferences.

From model-based test creation to classic programming

Test designs and sequences can be implemented quite well

based on UML diagrams using a graphically oriented tool. Impor-

tant here are the different views of the tests, beginning with

graphic modeling of tests by domain and test experts up to pro-

gramming of the HIL system in a modern programming language.

Integration in a current development environment is advantageous

here.

Figure 2: CANoe is a scalable test system offering access to the System und Test over many interfaces and protocols

Figure 1: Test system with access to System und Test (SUT) and test equipment used

3

Technical Article

February 2012

Combining test sequences by drag & drop from prepared test func-

tions and cases of domain-specific user libraries with a suitable

tool is an attractive way to rapidly attain goals without program-

ming knowledge. A prerequisite is the access to application-

specif ic parameters, such as bus or hardware signals. Ideally, the

pool of test functions can be extended as much as desired and has

interfaces to other test and requirement management systems

such as DOORS.

Many programming experts continue to swear by the value of classic

programming methods. Suitable here are specialized script lan-

guages or .NET languages such as C#. The developer can use an

up-to-date IDE (Integrated Development Environment) and benefit

from automatic word completion features and symbol recommen-

dations matching the context. For some tasks, direct programming

is the quickest path to a solution.

Scalable and future proof

If the user wants to avoid later occurring limitations and the

need to procure expensive secondary systems, certain key aspects

should be considered in the selection or configuration of a test

system right from the outset. All bus systems, protocols and digital/

analog input/output options commonly used in the automotive

field should be supported or be easy to retrofit, even if they do not

play a role (yet) in the current project. Since the real time require-

ments of a test system rise significantly with an increasing number

of bus branches and input/output channels, the availability of

“intelligent” interface solutions continues to grow in importance.

Equipped with a dedicated processor, they are capable of autono-

mous (pre-) processing of subtasks.

Vector is one of the companies that offer test systems of various

sizes and configurations for ECU development. Common to all solu-

tions is that they are based on the CANoe simulation and test tool.

This makes the systems scalable, and they follow a uniform user

control philosophy. Once test applications have been created, they

can easily be exchanged between different configurations, avoid-

ing unnecessary repeated implementations. A special aspect of

Vector test systems is their analysis of ECU behavior, especially

when errors are detected. This analysis is performed with the help

of Trace, Data and Graphic windows.

Software and hardware components for scalable ECU test systems based on the example of the CANoe analysis, simulation and test system

CANoe (CAN open environment): Central software for communi-

cating with automotive bus systems via all relevant protocols,

stimulation and measurement of electrical outputs and inputs,

rest-of-bus simulation, test flow control with detailed reporting

and detailed comprehensible analysis of processes. The soft-

ware is very scalable – from laptops to desktop workstations

and the use of active interface hardware that handles time-

critical processes. Many interfaces such as ASAM HIL API or FDX

(Fast data eXchange) are available for interfacing to other

systems.

Vector OpenTest: Graphic tool for creating test designs and test

sequences with both shared and variant-specific sub-sequences,

especially by domain and test experts. HIL programmers can

also use this tool due to the integration in MS Visual Studio.

Besides CANoe, it also supports other HIL systems.

Test Automation Editor: This editor is used for drag & drop

creation of test sequences without requiring programming

knowledge; it utilizes all of CANoe’s testing capabilities and

network symbols. Its language scope can be extended by CAPL

and .NET programs. It can be linked to DOORS, and an interface

to other test management systems is public.

Classic programming: .NET languages such as C# for implemen-

tation in the Microsoft Visual Studio development environment

or the CAPL script language incorporated in CANoe are available

here.

XL interface line-up: Standard interface solutions for CAN and

LIN with USB interface, PCI bus or PCMCIA. Many different phys-

ical layers are supported by plug-in bus transceivers.

VN89xx/VT60xx: Active interface hardware with internal CPU

for FlexRay, CAN and LIN. Enables system reactions and bus

accesses that are two to eight times faster than passive

interfaces.

VT System: Measures and stimulates sensors and actuators,

generates error situations such as short circuits, overvoltages

and undervoltages.

Translation of a German publication in 'Hanser automotive', issue 2/2012

4

Technical Article

February 2012

>> Your Contact:

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

France, Belgium, Luxembourg Vector France S.A.S., Paris, 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, 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

IndiaVector Informatik India Pvt. Ltd., Pune, India, www.vector.in

ChinaVector Automotive Technology (Shanghai) Co. Ltd., China,

www.vector-china.com

E-Mail Contactinfo@vector.com

Siegfried Beeh studied Electrical Engineering at the Univer-sity of Stuttgart (Germany); after graduating he worked primarily in the development of embedded systems, with and without safety requirements. In 2002, he joined Vector where he is group leader for 'Test Tools & Diagnostic Features' and product manager for products that include standard test fea-tures in CANoe and the Test Automation Editor.

Figures:Vector Group

Links:Home page Vector: www.vector.comProduct informations:CANoe: www.vector.com/canoeVector OpenTest: www.vector.com/oteTest Automation Editor: www.vector.com/tae_enXL interfaces: www.vector.com/N89xx: www.vector.com/vn8900VT System: www.vector.com/vt