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 [email protected]
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