By Marcus Boumans, Ingo Hein, and Christian Viehmann, Robert Bosch GmbH

---

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