By
Marcus Boumans, Ingo Hein, and Christian Viehmann,
Robert Bosch GmbH
29
L A B C A R F O R C A L I B R AT I O N
variants, the ProjectBuild was devel-
oped.
It is based on a configuration man-
agement system, in this case the
TortoiseSVN source control software.
It stores all available model segments
in a model library, together with the
projects assembled and their histo-
ries. In this way, any modifications
made to model segments or projects
can be tracked and used for easy
comparison.
One of the central project files is the
wiring harness specification. It con-
tains the major part of the configura-
tion, which also includes the connec-
tivity between model and PT-LABCAR
hardware (where PT stands for Power-
train), and the connections with the
respective ECU by means of an adapt-
er. The ProjectBuild generates all of
these connections automatically and
integrates them in the executable
LABCAR project. It is also possible –
when deploying an ES4440 Failure
Simulation Module and preparing for
an I/O function test – to also consider
these additional connections and
automatically generate the required
configuration.
The detailed adaptation of a project
to a given vehicle or vehicle variant
occurs during parameterization. In a
manner reminiscent of the calibration
of ECU software, this includes the
tweaking of parameter values and
program maps. The goal is to achieve
the best possible match between
system and reality. This “model cali-
bration” and its history are stored in
the configuration management.
The environment is augmented by
a continuous integration solution.
This means that each project is auto-
matically and cyclically checked for
changes. If any occur, a ProjectBuild
process is triggered, which ensures
that a LABCAR project, that is both
current and ready to run, is always
available. To round out the system’s
capabilities, the integration of auto-
mated validation and verification is
used as well.
Deploying LABCAR systems for cali-
bration
On the basis of the abovementioned
models, a LABCAR model that was
functionally enhanced through the
addition of more detailed models
(raw-emissions model, catalytic con-
verter model) was created, param-
eterized, and verified for a reference
passenger car. This “virtual test ve-
hicle“ was then used to investigate
and confirm the benefits generated
by the system for a number of cali-
bration work packages. It goes with-
out saying that these functionally
enhanced LABCAR models are also
available to software developers for
simulation and software validation
purposes.
Due to the large number of cross-
connections (i.e., of basic engine
parameterization, comfort and con-
venience functions, etc.), the calibra-
tion work packages emission optimi-
zation and diagnostics calibration are
predestined for the HiL simulation en-
vironment. Thanks to the integration
of the above named model exten-
sions, emission-specific target vari-
ables became part of the simulation
Over recent years, driven by in-
creasingly restrictive exhaust emission
legislations and diagnostics regula-
tions as well as rising levels of cus-
tomer demands, the complexity of
engine controls – and thus the effort
required for calibration and testing –
has been on a steady climb. To ensure
a manufacturer’s competitiveness,
the increased complexity and high
diversity of variants must be mastered
along with competitive pricing and
high quality. It therefore stands to
reason that at DGS-EC the worldwide
deployment of ETAS LABCAR systems
for software testing is an established
component of the development pro-
cess. It has been shown that the
deployment of extended simulation
models facilitates the use of HiL sys-
tems as standard development tools
for calibration work as well. As a re-
sult of this, the so-called HiL House
was established at DGS-EC. It is the
juncture where both software devel-
opment and calibration merge their
specific expertise in terms of HiL with
the objective to achieve the extended
deployment of LABCAR systems at a
reasonable cost.
Build system aids efficient generation
of LABCAR projects
DGS-EC uses LABCAR at its world-
wide locations for running software
and post-delivery tests. This requires
the provision and maintenance of
simulation models for each individual
vehicle and its variants (i.e., body,
powertrain, and transmission). At the
time of this writing, the model count
exceeds 100. To ensure efficient and
attractive pricing in the face of the
rising number of projects and their
HiL House@Bosch
Efficient LABCAR deployment uses extended simulation models
To aid ECU development, the Electronic Controls Division of Bosch Diesel Gasoline Systems (DGS-EC)
relies on the extended deployment of the ETAS LABCAR Hardware-in-the-Loop (HiL) testing system
for calibration tasks and other applications. The corresponding LABCAR powertrain projects are being
developed on the basis of cutting-edge software engineering methods.
28
L A B C A R F O R C A L I B R AT I O N
Figure 2:
Comparison of
measured vs. simu-
lated emissions
in the European
Driving Cycle.
Figure 1:
ProjectBuild with
components from
model library.
Vehicle
HiL simulation
HC
NOx
HC
NOx
Cumulative raw engine emissions
Cumulative tailpipe emissions
Grams
Grams
Vehicle
HiL simulation
for the first time. Figure 2 shows that
the simulated emissions are indeed
very close to those of the reference
vehicle. The result is a considerable
increase in the number deployment
options for the HiL simulator in cali-
bration work.
As a typical feature of the work
packages related to diagnostics cali-
bration, a large number of cyclical
exhaust gas measurements are re-
quired. The priority here is the defi-
nition of start-up conditions, the prio-
ritization of functions, and the quan-
tification of exhaust gas noxiousness
resulting from system faults and/
or active diagnostic interventions. By
shifting a segment of the required
measurements to the HiL simulator,
it can be used to perform an initial
calibration, while functional cross
connections and worst-case scenarios
are determined early along the time-
line. As a result, actual measurements
taken on the test vehicle can be either
dispensed with or used more effec-
tively. Figure 3 shows the findings of
a study investigating the compara-
bility of the actual vs. simulated
behavior of diagnostic functions in
the European Driving Cycle. The com-
parison looks at the point in time
at which the cycle flag is set, i.e., at
which a diagnostic result is available.
It was found that the results of the
virtual vehicle were well within the
range of the scatter of the real-world
vehicle. For the lambda probe offset
diagnostics, no scatter data was avail-
able for the real vehicle. The relatively
large time difference was the reason
30
L A B C A R F O R C A L I B R AT I O N
T H E C H A L L E N G E
To ensure competitiveness, the increased complexity and high diversity of variants must be mastered
along with competitive pricing and high quality.
T H E S O L U T I O N
It was demonstrated that the deployment of extended simulation models enables HiL systems to
be used as a standard development tool also for calibration purposes. To this end, a virtual vehicle
for LABCAR was developed.
T H E B E N E F I T
The results obtained with the virtual vehicle are within the scatter range of its physical counterpart.
The result is a significant increase of the deployment options for the HiL simulator in calibration
work. As a result, actual measurements taken on the test vehicle can be either dispensed with or
used more effectively.
Figure 3: Comparison of diagnostic function sequences in the physical vs. virtual vehicle.
for taking a closer look at the way the
driver influences the results. It was
found that a variation of the vehicle’s
road speed (within the legally per-
mitted tolerance of ± 2 km/h) may
cause a shift in the result of well over
100 seconds. In contrast to the phys-
ical test vehicle, valuable robust-
ness investigations of this kind can be
run on the HiL simulator quite easily
and cost-efficiently. And that is just
another enthusiastic vote for HiL
deployment.
Outlook
In order to expand the benefits
resulting from the deployment of
simulators in ECU software develop-
ment, it will be necessary to extend
the existing model library and to
continue the development of the
requisite parameterization methods.
To increase user acceptance of the
model-based approach and win
additional efficiency benefits, the
configuration effort for application-
specific models must be further
reduced. In the future, the model-
based approach can be more firmly
anchored in the entire software de-
velopment process, and be deployed
much earlier along the development
timeline. This includes also the shared
utilization of models and simulation
environments in function develop-
ment and calibration.
Automated Testing
of Diagnostic Interfaces
ETAS Engineering Services for VCI and ECU interfaces
For OEMs and service providers, statutory requirements and the objective of achieving the exchangeability of
standard components for diagnostic purposes burden OEMs and service providers with massive integration
expenditures. This means that OEMs need to apply sufficient testing depth to verify hardware and software
components as well as the data contents of various suppliers. At the same time, they are called upon to ensure
the flexibility and extensibility of applicable diagnostic systems. This article introduces two examples of automation
solutions provided by ETAS, both of which aid the testing of diagnostic components on customers’ premises.
By Thomas Wambera, ETAS
Figure 1: Automated interface testing using the test automation solution from ETAS.
Application
■
Application behavior testing
■
Database integrity testing
■
Application interface(s) testing
■
GUI/Blackbox testing
Communication
■
ECU simulation on VCI
■
Vehicle/system testing
■
HiL simulation with LABCAR
■
ECU testing
VCI API (J2534, ISO 22900-2,
RP1210)
■
Automated VCI API testing
■
Automated VCI API bench-
marking
■
Manual VCI API testing
VCI API (J2534 / ISO 22900-2 / RP1210)
User Interface
Application
Data Abstraction Layer
Classical
Silk Test
ETAS Test
Automation
DB
31
T E S T A U T O M AT I O N
Physical
vehicle
Std. dev.
1.2 s
65.8 s
-
Std. dev.
0.6 s
27.1 s
0.3 s
Difference
2.4 s / 0.3 %
-44.2 s / 16.2 %
71.2 s / 8.0 %
Catalyst
diagnostics
Lambda probe
offset diagnostics
Lambda probe
dynamics diagnostics
860.5 s
272.3 s
895.1 s
862.8 s
316.5 s
966.2 s
Virtual
vehicle