See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/228599005

A New Approach to Functional and Software Structure for Engine Management

Systems - BOSCH ME7

Article · February 1998

DOI: 10.4271/980801

CITATIONS READS
52 1,685

4 authors, including:

Horst Bischof
Graz University of Technology
792 PUBLICATIONS   29,603 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

visual search in surveillance archives View project

AUTOVISTA View project

All content following this page was uploaded by Horst Bischof on 04 June 2014.

The user has requested enhancement of the downloaded file.

 98P-178 (49)

A New Approach to Functional and Software Structure

for Engine Management Systems - BOSCH ME7
J. Gerhardt, H. Hönninger, and H. Bischof
Robert Bosch GmbH

Copyright © 1998 Society of Automotive Engineers, Inc.

ABSTRACT also be equipped with a complete on-board diagnostic

and monitoring system.
This paper describes the new Engine Management The introduction of electronic throttle control (ETC) as a
System (EMS) ME7. drive-by-wire system with it’s adjustable relationship
Torque and A/F demands for modern EMS result from between the pedal position and throttle position
both, internal functions (i.e. engine start, idle speed enables the EMS to now control all torque-influencing
control, catalyst heating) and external systems (i.e. outputs over the entire operating range of the engine.
driver’s request, transmission or vehicle dynamic With stand alone ETC systems, mutual functional
control). With ME7 these demands are processed to impacts have to be considered, such as idle speed
the optimized actions of the actuators by a centrally control which must be divided into the two subsystems.
coordinated torque and A/F management. The design The fully integrated system with control of injection,
of the functions is physically based to provide optimum ignition and cylinder charge can eliminate this
portability and minimum calibration time. Examples are drawback but then a complete redesign of the entire
given for the physical manifold pressure model and the system is required.
cylinder charge control of ME7 with electronic throttle The new functional architecture of the ME7 system is
control. characterized by the following main features:
The real time operating system „ERCOS“ and a layer • Centrally coordinated torque management:
based software architecture enable the implementation The engine torque represents the central system
of these functions in a flexible family of products for variable. All torque requirements derived from EMS
current and future systems. internal functions or external systems (i.e. drive
Topics, such as warm-up strategies for catalysts in train or vehicle dynamic control) result in a variation
conventional port injection systems, gasoline direct of torque or efficiency and are defined on this
injection systems (with their switch-over strategies basis.
between stoichiometric and stratified operation), NOx • Centrally coordinated A/F management:
catalyst control, and the requirements of future Similarly, all mixture demands are coordinated in
integrated drive train management systems, all require one central manager. Based on the operating
maximum flexibility and expandability. conditions, a set of basic functions controls the A/F
The introduction of the ME7 is an important step ratio within the physical limits defined by the
towards this future. The design represents a good flammability of the mixture.
basis for development sharing with customers and is • Subsystems based on physical models with
also an important prerequisite for the vehicle physically defined interfaces:
management system CARTRONIC. The use of physically based functions improves the
transparency of the system’s architecture.
Computed values can be directly compared with
1. INTRODUCTION physically measurable values.
Using physically based functions in combination with a
The functional structure of engine management centrally coordinated torque and A/F management
systems has evolved over several years [Ref. 1]. allows for an improved handling of function variants.
Starting with a simple injection system with a separate Due to their relationship to the physical structure, single
ignition unit in the early 70’s, injection and ignition were functions as well as functionally linked groups of
integrated into one single electronic control unit during functions (subsystems) could be easily compared with
the 80’s. A modern EMS is comprised of a large customer’s requests using physically measured values.
number of subsystems, and not only controls basic Therefore a set of basic platform functions was realized
EMS-functions such as injection and ignition timing or and applied over the entire EMS family.
emission control (i.e. Lambda closed loop control or
The realization of an appropriate Software structure
catalyst heating) but also manages additional functions,
guarantees the system’s modularity which allows
such as continuous camshaft control, resonance flap
different customer’s requests to be met as well as
actuation or engine fan control. A modern EMS must
future challenges. By means of the torque based 2.1.2 Brief Functional Overview
functional structure the software implementation is
independent of demands generated by external The ME7 contains all functions to control a modern SI-
systems. The real time operating system „ERCOS“ and engine. In this section only a brief functional overview is
a layer based software architecture enable a system given. Due to the system’s modularity very different
evolution with optimum portability at a high level for system configurations can be realized. For example
future microcontrollers. Most of the functions are systems with different sensors for cylinder charge
realized in the programming language ANSI C, to determination (air mass or speed density), naturally
provide good modularity and integration of customer aspirated or turbocharged engines, engines with or
specific functions. without EGR and engines with variable camshaft
actuation are possible. The main system features are
2. A NEW FUNCTIONAL AND SOFTWARE as follows:
STRUCTURE FOR ENGINE MANAGEMENT
SYSTEMS • The engine torque management which controls all
torque influencing actuators (see also section
2.1 ME7 SYSTEM OVERVIEW ‘Functional Structure’).
• A/F ratio control with a central A/F manager, λ-pilot
2.1.1 System Configuration control, λ-closed loop control, or alternatively with a
Nernst or universal λ-sensor and trim control
Figure 1 shows an ME7 system overview with the main (details see section ‘Functional Structure’).
sensors and actuators. In addition to the components • Sequential, cylinder individual fuel injection.
of a conventional EMS, the system is comprised of the • Ignition timing, including control of dwell angle and
ETC related elements, which include the accelerator ignition angle.
pedal module to interpret the driver’s request, the • Cylinder individual knock control.
throttle actuator for cylinder charge control and the • Emission control functions for optimized emissions
cruise control lever. during cranking, start and after start which enable
the realization of different catalyst warm-up
strategies, using a lean mixture or a rich mixture

Figure 1: Engine Management System ME7

 including exhaust gas recirculation (EGR) and derived simultaneously from different subsystems,
secondary air injection (SAI) control if necessary there was no central torque coordination. This meant,
[Ref. 2], [Ref. 3]. that subsystems inside the EMS as well as external
• Canister purge control based on canister charge. systems directly required, for example, a reduction of
• Idle speed control. the throttle or an ignition retard to obtain a certain
• Diagnostic and monitoring functions: torque reduction. The priority of each demand had to
• The system is comprised of the complete OBD II be defined independently in each subsystem. This lack
functionality to meet both MY ‘98 and future EOBD of a central coordination caused interactions of different
requirements. A torque-based monitoring systems demands (due to shifts of operation points) resulting in
supervises the throttle control under all operating a strong interdependence of calibration data of the
conditions and reacts with the appropriate limp- different subsystems (i.e. calibration of ignition timing
home functionality in case of a failure. influenced idle speed pilot control).
• To communicate with external systems, such as a
transmission control system or a vehicle dynamic On the contrary the functional structure of the ME7
control system, torque demands can be received system is characterized by two coordination steps
via a torque interface, realized via CAN. Therefore (Figure 3).
the EMS is able to process external torque
demands within the torque manager. (see also • Torque demand manager:
section ‘Functional Structure’). Input values for the torque demand manager are all
• Conventional or continuous camshaft control. internal and external requirements which can be
• Resonance flap actuation. defined as a torque or efficiency value. Internal
• Engine fan control. demands are for example generated by the start
• Control of air-conditioner (A/C). function, idle speed control, engine speed
• Cruise control. limitation, as well as engine protection functions or
• The system contains the necessary interfaces to catalyst heating. External torque demands are
application tools, end of line programming tools, defined by the driver, cruise control, or vehicle
service and SCAN-tools. dynamic control. The major task of the torque
• Immobilizer. demand manager is the priority handling which is
• Additional customer defined functions as required. processed by a minimum/maximum selection.
• In the next step the resulting torque demands are
2.2 FUNCTIONAL STRUCTURE processed in driveability functions (mostly filtering
or slope limiting functions), dashpot function (to
Essential functional features of the ME7 structure are limit the minimal intake manifold pressure) and the
the central torque and A/F management and the use of anti-jerking function. The driveability functions, due
physically-based functions. to customer’s requests, allow calibrations over a
wide range of applications. The calibration can vary
2.2.1 Torque-based system structure between a comfortable and a sportive
characteristic.
2.2.1.1 Structural approach Engine start-up,
Catalyst heating,
Idle speed control
External Torque
Choosing a torque-based system architecture was Demands
Efficiency demand
initiated by the followings concerns when the previous • Driver
situation was analyzed [Ref. 4], (Figure 2) • Cruise control
Throttle angle
• Limitation of vehicle speed
• Vehicle dynamic
control
Driver Torque demand Torque
• Driveability Torque Torque Ignition timing
Calculation demands manager conversion
demand
Cruise control of desired Throttle angle Individual fuel
throttle Coordination Realization cut-off
Engine start-up
angle of torque and of desired
Idle speed control
efficiency demands torque
Cylinder individu Idle speed control Injection time

Catalyst heating fuel cut-off

Engine speed limitation Waste gate
Calculation control

Anti-jerking function of inj. time Injection time

Protection of engine

Limitation of engine speed

& vehicle speed Calculation Ignition timing
of spark
Protection of advance
engine components
Waste-gate
Figure 3:Influencing Engine Torque -
Transmission control
Boost control Situation with Torque-Based System Structure
control
Vehicle dynamic control
The output value of this management block is a
resulting torque demand, taking the required
Figure 2: Influences on Engine Torque efficiency into consideration, which is equal to 1.0
- previous situation during normal operation and which can be reduced
for example during catalyst heating.
In the case of several torque or efficiency demands, • Torque converter:
 In a second step the resulting torque demand is which does not yet consider losses caused by the gas
converted into the available controller outputs exchange. Therefore „tq_i“ differs from the value of
which are able to adjust the engine output torque. indicated torque represented by the work integral from
These controller outputs are the throttle angle, the entire 4-stroke process. Subtraction of losses
ignition timing and injection timing (including a derived from gas exchange and friction leads to the
cylinder individual fuel cut-off) supplemented by a engine output torque. The clutch torque results when
waste-gate control in the case of turbocharged taking into account the torque which is necessary to
engine. drive auxiliary components such as the alternator, the
steering pump or the A/C.
This simple structure can be extended in case of highly
dynamic torque demands resulting for example from Taking the torque losses and the gear ratio inside the
vehicle dynamic control. In this case two resulting torque converter, the gear box and the differential into
torque demands are defined: consideration, wheel torque results, which represents
the available torque for vehicle motion.
• The long-term torque demand has to be realized
via a variation of the cylinder charge. This demand Due to the complexity of the combustion process in an
results in a variation of the throttle position and the SI-engine the generation of internal torque is
waste-gate opening, which means that it’s dynamic described by an empirical approach with physical
behavior is limited for example by the regulating intermediate and interface values which take the limited
speed of the throttle actuator and the time constant computation resources of a mass production ECU into
of the intake manifold which can amount to several account.
100 ms at low engine speeds.
• A separate short-term demand is realized via the The necessity to determine the controller outputs
crank synchronous controller outputs (injection and based on the required resulting torque means, that the
ignition timing) which enable a modification of inverse calculation of the torque model must be
engine torque within the following combustion cycle. possible.
With the separate short-term component all highly
dynamic torque demands, which only last some 100
The basic structure of the model, used for calculating
ms can be realized without affecting the slow
the internal torque value „tq_i“ is shown in Figure 5.
cylinder charge path. Examples for highly dynamic
demands are the torque reduction generated in a
Structure to separate engine load, engine speed, ignition timing, Lambda and torque
transmission control for a comfortable gear shifting
or a quick and short demand when the vehicle Internal torque originating Internal torque
dynamic control is active. Cylinder charge
from combustion
(optimal ignition time,
depending on ignition
timing, Lambda and
stoichiometric mixture) individual fuel cut-off
Engine speed ∗ ∗ ∗
2.2.1.2 Internal torque model Lambda Lambda-efficiency

Internal combustion engine Clutch

Cylinder Reduction-factor
individual
Torque converter

Cylinder charge Internal torque torque Wheel fuel cut-off

(originated from
box&&

torque Distance from

differential
differential

combustion) optimal ignition

Lambda
Gearbox

timing Efficiency of ignition time

Combustion
-
Gear

Ignition timing -

Losses caused by gas

exchange and friction Figure 5: Simplified Torque Model
Losses caused by auxiliary comp.
In principal, the comprehensive dependency of internal
torque on cylinder charge, engine speed, Lambda,
Torque losses and transmission (automatic transmission)
ignition timing and cylinder individual fuel cut-off could
Gear losses and transmission
be described in a five dimension map. The decisive
step to simplify this dependency is the introduction of
two central reference values:
Figure 4: Torque definitions concerning
the drive train • the optimal spark advance „sa_opt“ and
• the corresponding optimal internal torque „tqi_opt“,
Figure 4 illustrates different torque values related to a which reaches it’s maximum value at optimal spark
drive train. Influenced by the major input variables advance.

• relative cylinder charge (fresh air mass per stroke), In some operating points the optimal spark advance is
• Lambda (A/F ratio related to a stoichiometric ratio) a theoretical value, because of the engine knock limit.
and Both reference values refer to Lambda equal to 1.0 (Å
• ignition timing „sa_opt_l1“ and „tqi_opt_l1“) and are defined by 2-
dimensional look-up tables:
the combustion generates an internal torque „tq_i“,
 sa_opt_l1 = fn. (rc, n_eng) (1) In Figure 6 a characteristic line is also shown, as a
result of a least-square-optimization [Ref. 5]. The
tqi_opt_l1 = fn. (rc, n_eng) (2) possibility to reduce the dependency of spark advance
efficiency on „d_sa“ to one single characteristic line is
Relative cylinder air charge „rc“ refers to a 100% value confirmed by applications of this structure on several
defined by the displacement per cylinder and the engines with a wide range of cylinder numbers, engine
standard air density. The second influencing variable is displacements and combustion chamber designs. This
the engine speed „n_eng“. characteristic is related therefore to the engine design
only and not to an operating point.
The actual torque value „tqi“ is the result of a
multiplication with Lambda- and spark advance Identifying the parameters of the model for a certain
efficiencies engine only means measuring „tqi_opt_l1“ and the
dependency of „tqi“ on spark advance and Lambda.
eff_lam = fn. (lam) (3) The numeric optimization combined with a suitable
control of an engine dyno allows for an automatic
eff_sa = fn. (d_sa) (4) identification of the model parameters, which are
shown in Figure 5.
and the reduction factor „eff_red“ caused by a cylinder
individual fuel cut-off: 2.2.1.4 Calculation of the desired values
tqi =
As previously mentioned, the torque model is not only
tqi_opt_l1 * eff_lam * eff_red * eff_sa (5) used to determine the actual value of the internal
torque. The basic equation (equation 5) can also
In equations 3 through 5 „lam“ represents Lambda. For deliver the desired values of the controller outputs:
simplification of the basic equation (equation 5), spark
advance efficiency is defined depending on the tqi_tar = tqi_opt_l1 (rc_tar, n_eng)
difference between actual spark advance „sa“ and the * eff_lam_tar
optimal spark advance: * eff_red_tar
* eff_sa_tar (6)
d_sa = sa_opt - sa (6) Figure 7: Determination of Torque Influencing
Target Values

2.2.1.3 Identification of model parameters Conversion

Desired
charge throttle
Desired torque throttle angle angle
Equation (5) describes the decoupling of the five- (to be realized Desired
cylinder
by means of Conversion
dimensional relationship between the internal torque Priority
scheduler,
charge) charge
Driver torque desired manifold
and it’s influencing variables by introduction of the cyl. charge
path
load pressure

optimal internal torque and the optimal spark advance. Conversion Desired
waste-gate
opening
Actual charge
Deviation of measured efficiency from the idealized characteristic (used in the model) External wast-gate
cylinder
and Calculation of
Basis: 1000 different operating points of a 4-cyl. engine charge
internal efficiencies and
1.2 torque base torque Efficiency, Lambda
demands data ignition advance

1.0 Cyl.-indiv.
cut-off
Conversion
Ignition advance efficiency

Priority torque Inj.time

0.8 scheduler, Desired internal torque
synchronous synchronous
path crankshaft
variables Ign.timing
0.6

0.4

0.2
The target torque value „tqi_tar“ is calculated by
multiplication of the optimal torque at lamba = 1.0 and
0.0
0 10 20 30 40 50 optimal spark advance by the efficiencies. Solving
Deviation of the ignition advance from the optimal ignition advance in deg. crank
equation (6) for „rc_tar“, „eff_lam_tar“, „eff_red_tar“ or
curve obtained after applying the method of least mean square deviation
Measurement „eff_sa_tar“ delivers the target values for the controller
outputs which influence torque (Figure 7).
Figure 6: Resulting Error of Spark Advance
• Priority handling
Efficiency When determining target values, a priority handling
must be considered. Under normal operating
Figure 6 shows the dependency of the spark advance conditions, torque demands must be realized by
efficiency „eff_sa“ on the difference „d_sa“ between cylinder charge control to guarantee that spark
optimal and actual spark advance measured at 1000 advance and Lambda do not differ from the values
operating points of a 4-cylinder engine, representing determined in the basic calibration.
the total operating range (in engine speed and load).
• Influence of basic calibration data: functions. As a result of modifying the engine
To compute the desired value of the cylinder design only the characteristic lines and look-up
charge „rc_tar“, the target value for „tqi_opt_l1“ has tables have to be actualized.
to be calculated first, taking into account the pilot Due to the fact that external systems have no direct
control values of the mixture and the spark impact on the throttle angle or the ignition timing,
advance chosen in the basic calibration, which may for example torque demands of a traction control or
differ from Lambda 1.0 and the optimal spark drive train control system are independent on the
advance. Then the desired cylinder charge „rc_tar“ current status of ME7 data calibration.
can be computed by using an inverse torque look- Further simplification is a result of the consistent
up table data-base for all controller outputs. If for example
the engine efficiency should be reduced at a given
rc_tar = fn. (tqi_opt_l1, n_eng) (7) driver’s demand, the desired torque value to be
realized via the cylinder charge path can be
• Determination of desired throttle position increased, leading automatically to a decrease of
The resulting value „rc_tar“ represents the target spark advance. Therefore it is not necessary to
cylinder charge which is necessary to realize the calibrate the two paths separately.
demanded torque under consideration of the The system can be expanded easily for future
boundary values (i.e. Lambda and spark advance) system requirements such as a drive train
of the specific calibration. In the next step „rc_tar“ management for conventional gear box or a CVT
is converted into a target throttle opening, using [4], gasoline direct injection, variable valve timing,
state parameters from the intake manifold model and so on.
described in section ‘Functional Structure’. Finally
the throttle is positioned by a closed loop controller. 2.2.2 A/F management
• Crank synchronous controller outputs:
The set of target values for the crank synchronous In addition to the torque management the ME7 system
controller outputs are determined in a similar is also provided with A/F management (Figure 8).
manner. For example the most important target
spark advance is derived from „eff_sa_tar“: The A/F management consists of 3 essential
components:
eff_sa_tar =
• The basic calibration:
tqi_tar / (tqi_bas*eff_lam_act*eff_red_act) Here all mixture variations caused by systematic,
(8) reproducible system tolerances are eliminated. The
target of the basic calibration is a Lambda equal to
• Influence of actual cylinder charge: 1.0 under all operating conditions.
In equation 8 „tqi_tar“ represents the target value
for the internal torque. The value „tqi_bas(rc_act, Basic Calibration (Lambda=1.0)
n_eng)“ is an output value of the torque look-up + Lambda-Variation (Pilot Control)
+ Lambda-Limitation
table with respect to engine speed and the actual
value of the cylinder charge, measured for example
by an air mass flow meter or computed based on a Rich Pilot control
Rich
measured intake manifold pressure. Lambda limit
Taking the real cylinder charge into consideration,
Lambda

the two torque conversion paths (cylinder charge

1.0 Temperature
path and crank synchronous path in Figure 7) are
linked, so that no other coordination of the two
Lean
paths is necessary.
Lean Lambda limit

2.2.1.5 Valuation of torque-based structure

The system architecture based on the internal torque Figure 8: Characteristic Lines of Lambda Limits
provides the following advantages: and Lambda Pilot Values

• Improved accuracy when processing system • Lambda pilot control:

internal or external torque demands. This In addition to the basic calibration the desired
improvement is reached by means of a central Lambda value can be chosen depending on the
conversion of coordinated torque demands which operating condition. Therefore an enrichment
avoid interactions between the control variables during start or warm-up could be carried out for
(cylinder charge, Lambda, ignition timing and example. Furthermore an enleanment could be
cylinder individual fuel cut-off). realized in the case of lean-burn concepts.
• Simplified calibration:
The characteristic lines and look-up tables of the • Lambda limits:
torque control are only dependent on engine data, To coordinate the A/F ratio without cross-coupling
so there are less interactions with other control of the calibration data, (i.e. for warm-up and
 catalyst heating) the range of Lambda variation is relationship to the intake manifold pressure the relative
limited. The limit values are defined by the cylinder charge can be determined. [Ref.6],[Ref.7]. In
mixture’s flammability dependent on the engine a speed-density system the modeled intake manifold
operating point. pressure is replaced by the measured value.

2.2.3 Physically based functions

Many platform functions in the ME7 are realized, based m s h fm

on a physical model of the controlled system. The step ( r lr o h )
p s , V s , T s

m s
from heuristic functions to physically based functions m s h fm M a s s a ir flo w ( H F M ) ( r l) B a la n c e o f m a s s a ir flo w s fo r in ta k e m a n ifo ld :
m s M a s s a ir flo w in to
requires a sufficient mathematical model of the c o m b u s tio n c h a m b e r
(d p s /d t)* V s = (d m s /d t) * R * T s
r lr o h P r im a r y c y l. c h a rg e
controlled system. A major advantage of this concept is rl
p s
c y lin d e r c h a r g e
In ta k e m a n ifo ld p re s s u re
= (m s h fm -m s ) * R * T s

the physical interpretation of internal and interface T s

V s T o ta l v o lu m e o f
A ir te m p e r a tu r e
in ta k e m a n ifo ld
in in ta k e m a n ifo ld
C o n v e r te d in to c y l. c h a r g e :
V h T o ta l d is p la c e m e n t
values for improved comprehensibility and n m o t E n g in e s p e e d
P 0 = 1 0 1 3 h P a d p s /d t ( r lr o h - r l) * n m o t * p 0 * ( T s /T 0 ) * ( V h /V s )
transparency. T 0 = 2 7 3 K

rl
d p s
Because of the link to physical reality it is easier to r lr o h d t
* * * p s
define platform functions and to reuse them in different
P 0 * (V h /V s ) T s /T 0 n m o t
system configurations or future EMS generations.
Using a set of platform functions also allows to transfer
a calibration data set from one project to another. Figure 10: Basic Equation of Intake Manifold

As an example for the physically based functions used The integration of an intake manifold model allows for
in the ME7 the following determination and control of more the determination of a correct cylinder charge
the cylinder charge is described on the basis of an under steady state and dynamic operating conditions.
intake manifold model. Further motivation to apply this model to the ME7
system is the necessity of a cylinder charge control.
In this model the intake manifold pressure as a central The throttle position has to be calculated according to
state variable is calculated to determine the cylinder the required engine torque (Figure 11).
charge during dynamic and steady state operation.
The model considers the influences of all operating Pedal
position
conditions which modify the manifold pressure, such as
Calcul. Convers.
purge control, external and internal EGR and Driver’s of torque
Desired
charge
Request desired into
resonance flap control. torque charge

Adaptation results (offset/ factor) Actual

charge
Figure 9 shows the system configuration: Desired
torque Charge Cyl. charge
control determination
C a n is te r
Engine
Engine Air mass
P u r g e V a lv e
flow
P u r g e C a n is te r Position
Throttle
m s te
control
E G R -V a lv e
Id le s p e e d Boost Waste
Waste
A c tu a to r gate Pressure
control gate
m s a g r determination
m s lls Pressure
p ld Convers. upstream
p u T u rb o p s p a g C a ta ly s t p u
H F M V ld tld V s throttle
tu C h a rg e r ts torque Ignition
T h r o ttle m s s a u g -> ignition
B o d y
m s h fm
m s d k

m s h fm : M a s s a ir flo w H F M
m s d k :
m s s a u g :
M a
M a
s s
s s
a ir flo w
a ir flo w
th r o ttle b o d
in ta k e m a n
y
ifo ld
Figure 11: Cylinder Charge Control
m s te :
m s a g r: M a
M a s s
s s
a ir flo w
a ir flo w
c a n is te r p u
E G R v a lv e
r g e v a lv e
Structure in ME7
p u ,p ld ,p s ,p a g : B a ro m e tr ic p re s s u re , p re s s u r e o f tu r b o c h a r g e r , in ta k e m a n ifo ld , e x h a u s t g a s
tu ,tld ,ts : T e m p e ra tu re a m b ie n t, tu r b o , in ta k e m a n ifo ld
V ld , V s : T o ta l v o lu m e o f tu rb o c h a r g e r , in ta k e m a n ifo ld
Main input values of this controller are the modeled
intake manifold pressure and two adaptive values
Figure 9: Intake Manifold of an SI-Engine which eliminate the influences of air leakage and
tolerances between the cylinder charge signal and the
The model balances all mass flows into the intake expected throttle position at a given air mass flow and
manifold and all mass flows into the combustion engine speed .
chamber. Important input variables of the model are the
air mass flow into the intake manifold metered for 2.3 SOFTWARE STRUCTURE
example via an air mass flow meter and the modeled
combustion chamber temperature. As shown in Figure 2.3.1 Changes Made
10 the basic equation of the intake manifold model is
generated by differentiation of the gas equation. Requirement analysis or constructing a requirement
model is not a simple sequential step, which is finished
In the first step the intake manifold pressure is before the architecture, design, implementation and
calculated based on the air mass flow measured by the test development activities have started. There is
air mass flow meter. With the assumption of a linear extensive overlap between the phases. The process is
iterative, both within each phase and over multiple integrated. The mechanical design of the ECU is also
phases. This is especially true for a platform new, supporting surface mounting of all electronic
development, supporting a complete product family devices. Furthermore variants in microhybrid
with a broad variance in system and customer specific technology are available, which offer new options in
configurations. mechanical system integration. Yet the partitioning
between hardware and software was not under
Systems evolve in time. Building a new system from consideration in the project. Being aware of the many
scratch is not the typical approach, due to restrictions in changes in the development process, functional
development time and effort. The ME7 was built from structure and software was a conscious decision for
an existing system in an incremental and evolutionary risk management.
manner, thus being able to deliver a running system for
test and calibration purposes right from the beginning. There are various possible system configurations with
more than a hundred input and output flows, however
The maintenance or reengineering phase therefore all have in principle the same topology and a lot of
does not begin with the delivery and it does not end commonalties. Measuring engine speed and load are
with delivery and mass production. The maintenance examples for commonalties on an abstract level
phase is in fact the most important phase to prove between all system variants.
expansion capability, reuse and variants engineering.
Most important for a given system variant a static
Hard facts are the ever increasing complexity, environment can be assumed, therefore a deterministic
changing functional requirements and continuously system approach was chosen.
tightened nonfunctional requirements related to quality,
cost and time to market. 2.3.3 Architecture

Development systems have to handle these real world In the architectural development the question how to
aspects to immediately improve the situation. In the design has to be answered. The functional
ME7 development therefore a selected set of changes requirements at one level must be rigorously allocated
was planned and introduced step by step. This process to a physical structure with nonfunctional requirements
is still ongoing. added.

There are bottom up forced changes. The use of high 2.3.4 Software architecture
level programming languages, ANSI C instead of
Assembler in the ME7, is one example. There is no Following strategies for real time system specification
sensible way to handle Assembler programs of such as described, for example, by Hatley and Pirbhai [Ref.
complexity. The systematic introduction of specification 11] or Goldsmith [Ref. 12] and using the principles of
simulation and code inspection methods are further abstraction and decomposition, the technology
examples for this class of changes, which were independent requirements model has to be
absolutely necessary. transformed in a technology-nonspecific physical
model. Therefore buffers are inserted between the
Changes with "top down character" in the project were essential requirements model core and the
the development of a new functional structure and of a environment. The resulting architecture template
software architecture to support their implementation in embeds the requirements model core into input
a product line. processing and output processing architecture blocks.
Also blocks for interface-processing and self-test are
2.3.2 Context added as shown in Figure 12.

What is the system we are talking about? Traditionally Interface,...processing

we find a dedicated electronic control unit (ECU) for
Requirements Core
engine management, connected to a lot of sensors,
Transformation
actuators and other control units or monitoring devices Input processing Output processing
in the car. The system consists of the ECU itself and Control
all the devices it is connected to. Proceeding in an
Information
incremental and evolutionary way the context diagram
is drawn by replacing the ECU with the single Self-Test,... processing
transformation "control & monitor engine" and the
devices connected to it are the terminators. In the ME7
project this partitioning was a given fact. (The context Figure 12: Architecture Template
diagram partitions the information and processes that
are within the scope of the system and those that are The essential requirements model describes what the
outside the scope) logical outputs should be, depending on the logical
inputs. It assumes ideal technology, though all the input
The ECU has one or two standard microcontrollers and flows are in parallel and instantly transformed into the
peripheral electronics functionally comparable to former corresponding output flows. The input and output
systems. The peripheral electronics are more highly processing blocks have to convert the physical flows
into the logical flows described by the requirements
core model. This model has to be enhanced by the User Program
timing requirements. For all the logical flows response
times or actualization rates, the resolution, accuracy
and value ranges must be specified.
Hardware
Encapsulation
The further decomposition into architecture modules,
architecture flows and so on, ending in code
organization charts is a sophisticated process. User Library
Important guidelines for partitioning are the general
principles of cohesion and coupling, as known from
structural analysis and design methods. This is also
valid for object based or other methods and languages
for real time system description and construction.
ERCOS
Real Time Operating System
Independent from the methods used, this is an
example of the already mentioned inherent iterative
and recursive character of complex systems
development. Hardware

The intention here was to minimize the influence of the

µC and the various configurations, using different Figure 13: Layer Structure Model
sensors and actuators on the design and
implementation of the requirements core block. The The hardware encapsulation contents serves to read
requirements model represents the knowledge about ADC-Channels, reading digital inputs, setting digital
the application work and should be reused even on the outputs, CAN-Handling, or generating PWM-Signals.
implementation level for the whole product family and Also most parts of the input and output processing are
also for further generations of engine management contentented in this layer. This is also true for the
systems. A set of rules for architecture, design and interface processing and self-test architecture blocks.
implementation is necessary to encapsulate the µC and The hardware encapsulation therefore has an inner
system configuration dependencies. structure, which has to be very carefully designed and
shown as a mission critical point for success.
Together the operating system, the user library and the
2.3.4.1 Layer structure model hardware encapsulation can be thought of as a
hardware abstraction layer.
The top level of the set of rules used in this project is Looking at Figure 12 and remembering the concept to
shown graphical in Figure 13. make the design and implementation for the
requirements core model as independent from the
One idea of a layer based architecture is, that lower hardware as possible, it should be reside in the user
layers offer all the services needed by higher layers. program layer.
The supporting character of offering services is
visualized here by the triangles. It is important to Maybe this sounds theoretical, but in the project we
recognize that their semantic is not equal to flow. The experienced positive examples to show that it works.
user program gets it’s inputs by using services and it Different electronic throttle bodies are supported with
provides the outputs for example by using services of no influence on the software in the user program layer
the hardware encapsulation layer. and different load measurement sensors can be used
by simply exchanging a few parts in the software.
The run-time part of ERCOS (Embedded Real-time
Control Operating System), [Ref. 13] follows the
2.3.4.2 Object Model
concepts of virtual machines, or simply it offers
services for scheduling, inter-process communication
ERCOS offers a complete framework and is a object
and so on, to construct and support applications with
based language for real time system construction.
hard real-time requirements.
The basic object classes that are supported are
The user library consists of arithmetic, filtering, processes, functions, messages and resources (Figure
integration and interpolation routines. They are 15). Out of the basic classes only processes are active.
application dependent and most of them are A function is a passive object which can be called.
implemented in Assembler, using all the features of the Messages are basic objects for communication
µC for best efficiency. between processes and provide the methods send and
receive. To model resources which can only be
accessed exclusively, resource objects are provided
with the methods get and release.
 scheduling strategies use fixed priority assignments.
Process
Function
Activate
Init
calls Å Å
Call

Å
calls
sends
Message Function

Send Call gets Å Ressource

Task
Receive releases Å Get schedule-sequence
receives Å calls Å
Release
process 1
Process Message

Activate sends Å Send

process 2
Init Receive
process 3

Figure 14: Basic Objects and their Relations process n

Complex objects, the previously mentioned

„subsystems“ with well defined interfaces can be Figure 16: Tasks
constructed out of basic objects. Each subsystem
defines which objects constitute the interface and which It is possible to assign an interrupt source to a
are hidden inside. Figure 15 shows an example of a preemptive priority level. There is no distinction
subsystem which provides a function and a message necessary between tasks that are activated by
as an interface. Additionally, to implement the required hardware (interrupts) or by software. Thus a unified
functionality there are two processes, two functions and concept for hardware and software activated tasks is
one resource which are hidden inside the subsystem. provided.

Additionally multiple operating modes are supported, to

Message
Function allow completely different configurations (i.e. factory
Send
Receive Call testing, flash programming and driving mode).
Subsystem

Process Process Function

Activate Activate Resource Call preemptive scheduler

Function Init
Init
Call Get preemptive priority = 0 = 1 = 2 ...
Release

cooperative scheduler proc proc proc

Figure 15: A Complex Object (Subsystem)
coop. prio = 0 = 1 = 2 ... proc proc
The object model is supported by a set of tools
proc
(ERCOS-Off Line Tools) which have been developed to proc proc proc proc
allow easy construction of object-based software while proc
proc proc proc
providing interface checks for consistency and
optimization techniques for the runtime management of proc
proc
objects. The subsystem concept of ERCOS is one
major step towards software sharing and open
systems. Figure 17: Scheduler

2.3.4.3 Scheduling 2.4 SYSTEM FAMILY

A combination of static and dynamic scheduling The system architecture characterized by a torque-
together with a mixed preemptive/cooperative based system structure, an A/F management and the
scheduling strategy is supported. Due to hard efficiency use of physical based functions allows the generation
constraints in the project as a result of hardware cost, of a system family containing
mostly static scheduling is used. Tasks are
• the EMS with integrated throttle control (ME7)
implemented as schedule-sequences that contain a
• the conventional (M7) system with a bypass idle
sequence of processes to be executed in the specified
speed actuator
order and at a given priority level upon occurrence of a
certain activation event (Figure 16). • the system for gasoline direct injection (MED7)
• and the system for a complete drive train
Only a small amount of the application has short management (MEG7).
latency requirements which requires preemptive
scheduling while the large remainder can be scheduled The design of a consecutive system generation, based
cooperatively. This is realized by a hierarchical on the same system architecture but using a different
scheduler concept where the cooperative scheduler is CPU architecture is also possible (Figure 18).
subordinated under the preemptive scheduler. The
cooperative scheduler is treated as a single task at the • M7: System without ETC
lowest priority level of the preemptive scheduler. Both To create this conventional or basic system without
 ETC the cylinder charge control has to be limited to electronic throttle control and integrated
the operating range of the idle speed actuator. Due transmission control MEG7, and MED7 for gasoline
to the fact, that there is a fixed mechanical link direct injection engines are all members of this
between the pedal and the throttle position, the family.
throttle position represents the driver’s request. • ERCOS is now the standard operating system for
With the help of these major supplements the M7 BOSCH automotive products. As an open market
system was derived very easily and in a very short product it is available from the company ETAS for
development time. different microcontroller platforms . In the EMS
product line the run time part is reused bit for bit in
all products.
• The encapsulation of sensors/actuators for
ME... x different system configurations and the µC in a
MEG 7 Next generation
Motronic of hardware abstraction layer are the foundation for
with integrated ETC Motronic systems
and reuse and flexibility. Benefits of the new functional
transmission
MED 7 control structure are the improved physical transparency of
ME 7 Motronic the system, and the separation of engine and
Motronic for GDI
with function related calibration data. The introduction of
integrated M7
ETC Motronic the new functional and software structure as a core
with
idle speed
of the product family enables future challenges to
control be met, such as an extended system, for example
today time CARTRONIC.

Figure 18: Roadmap of System Family

• MED7: System for gasoline direct injection

The main functions provided in addition to the ME7
system are: [Ref.14],[Ref.15]
♦ Control of torque and emissions under
stratified and homogeneous operation and
the transition between these two states.
♦ Control of an EGR system with high flow
rates.
♦ Control of the entire fuel system including
the high pressure control and the operation
of high pressure injectors.
♦ Canister purge control for homogeneous
and stratified operating conditions.
♦ Control of a NOx storage catalyst
♦ Suitable monitoring concept
• MEG7: Drive train management
The step from the management of engine related
torques to a drive train management includes not CONTACT
only the EMS but also the control of the
transmission and the torque converter. Therefore Jürgen Gerhardt
an integrated drive train control means Robert Bosch GmbH - K3/ESY
coordinating all torque demands on the level of P.O. Box 30 02 40
drive train output torque. An optimized control D 70 442 Stuttgart/ Germany
strategy of all drive train components allows a E-mail: Juergen.Gerhardt@pcm.bosch.de
further reduction of emissions/ fuel consumption
[Ref. 15], [Ref. 3]. Harald Hönninger
• CARTRONIC Robert Bosch GmbH - K3/EAP
A further step is the management of all torque- P.O. Box 30 02 40
related demands on the basis of wheel torque, D 70 442 Stuttgart/ Germany
which allows the integration of all vehicle related E-mail: Harald.Hoenninger@pcm.bosch.de
torque demands including not only current vehicle
dynamic control systems but also an active braking Dr. Hubert Bischof
system for example. [Ref. 4]. Robert Bosch GmbH - K3/ESY
P.O. Box 30 02 40
3. CONCLUSION D 70 442 Stuttgart/ Germany
E-mail: Hubert.Bischof@pcm.bosch.de
• There is a broad range of system configurations
supported by the EMS product family based on the REFERENCES
ME7. Standard MOTRONIC M7, MOTRONIC with
electronic throttle control ME7, MOTRONIC with 1. Glöckler,O.; Benninger,N.F.:
 „Beitrag der Motorsteuerung für Ottomotoren zur ABBREVIATIONS
Senkung des Kraftstoffverbrauchs“
Stuttgarter Symposium 1995
2. Glöckler, O.; Bischof, H.: A/C AirConditioner
„Motorsteuerungssysteme der Zukunft“ ADC Analog Digital Converter
16. Internationales Wiener Motorensymposium, ANSI C American National Standard
Wien 1995 Institution - C-Programming Language
3. Streib,H.M.; Bischof,H. CAN Controller Area Network
„ETC: A cost Effective System for Improved
Emissions, Fuel Economy and Driveability“ CARTRONIC Structure and order of all functions,
SAE Technical Paper Series 960338 controlled by elecTRONIC control
4. Gerhardt,J., Benninger,N., Heß,W. modules in a CAR.
„Drehmomentorientierte Funktionsstruktur der EMS CPU Central Processing Unit
als neue Basis für Triebstrangsysteme“ CVT Continuously Variable Transmission
6. Aachener Kolloquium; Fahrzeug und Motorentechnik
1997
ECU Electronic Control Unit
5. Gill, P.E.; Murray, W.: EGAS Electronic GASpedal
„Quasi-Newton Methods for Unconstrained EGR Exhaust Gas Recirculation
Optimization.“ EMS Engine Management System
Journal of the Institute of Mathematics and it’s EOBD European On-Board Diagnosis
Applications
ERCOSEmbedded Real Time Operating
6. Hendricks, E. , Chevalier, A. ; Jensen, M.;
Sorensen, S.C.: System
„Modelling of the Intake Manifold Filling Dynamics“ ETC Electronic Throttle Control
SAE Technical Paper Series 96 0037, 1996 M7 MOTRONIC system without ETC
7. Streib, H.M.; Wild, E.: ME7 MOTRONIC system with integrated
„Modellbasierte Füllungserfassung und -steuerung ETC
zur Verbindung von hoher dynamischer Aktualität“
Symposium Steuerungssysteme f.d. Antriebsstrang von MED7 MOTRONIC system with ETC
Kfz., Berlin 1996 for gasoline Direct injection
8. A.S. Tanenbaum.: MEG7 Powertrain management system
„Modern Operating Systems“ MOTRONIC BOSCH engine management system
Prentice-Hall. 1992. MY Model Year
9. B. Meyer.:
„Object-Oriented Software Construction“. µC Micro Controller
Prentice Hall Book Co., Inc. 1988. OBD II On-Board Diagnosis - stage II
10. NN: OSEK Open Systems and the Corresponding
„OSEK (Open Systems and the Corresponding interfaces for automotive Electronics
Interfaces for Automotive Electronics)“ PWM Pulse Width Modulation
Operating System. 1995.
11. D. J. Hatley and I. A. Pirbhai,: SI-engine Spark Ignition Engine
„Strategies for Real-Time System Specification“
Dorset House Publishing, 1987
12. Sylvia Goldsmith: d_sa = sa_opt - sa
„A Practical Guide to Real-Time Systems“ eff_lam Lambda efficiency
Development, Prentice Hall 93
13. Poledna, Mocken, Schiemann, Beck: eff_lam_act Actual Lambda efficiency
„ERCOS: An Operating System for Automotive eff_red Reduction factor
Applications“. eff_red_act Actual reduction factor
SAE International Congress, Michigan, 1996 eff_sa Spark advance efficiency
14. Stutzenberger, H; Preussner, C.; Gerhardt, J.: eff_..._tar Target efficiency values
„Benzin-Direkteinspritzung für Ottomotoren -
Entwicklungsstand und Ausblick“ fn. Function of, depending on
18. Internationales Wiener Motorensymposium, 1997 lam Lambda
15. Moser,W.; Mentgen, D.; Rembold, H.: lam_bas Lambda of basic calibration
„Benzin-Direkteinspritzung - eine neue n_eng Engine speed
Herausforderung für zukünftige rc Relative cylinder charge
Motorsteuerungssysteme“
Motortechnische Zeitschrift 58 (1997)/Nr.9 & Nr.10
rc_act Actual relative cylinder charge
16. Streib, H.M.; Blank, H.; Wimmer, W.: rc_tar Target value rc
„Eine optimierte Antriebstrangsteuerung mit der sa Ignition angle reffering to TDC
Funktion Mastershift“ sa_bas Spark advance of basic calibration
BDI-Berichte Nr. 1099, S111-124, Düsseldorf 1993 sa_opt Optimal spark advance
sa_opt_l1 Optimal sa at lamda 1.0
tq_i Internal torque, generated by
combustion
tqi_bas tqi at sa_bas and lam_bas
tqi_opt, Optimal internal torque
tqi_opt_l1 Optimal tq_i at Lambda 1.0
tqi_tar Target value t_qi
tqi_opt_l1 Optimal tq_i at Lambda 1.0

View publication stats