Downloaded from SAE International by Univ of California Berkeley, Saturday, July 28, 2018

Domain Control Units - the Solution for Future E/E 2010-01-0686

Published
Architectures? 04/12/2010

Wolfgang Stolz, Robert Kornhaas and Ralph Krause

Robert Bosch GmbH

Tino Sommer
Bosch Engineering GmbH

Copyright © 2010 SAE International

The availability of new sensors for the vehicle surrounding

ABSTRACT (e.g. camera systems, radar sensors, ultrasonic sensors) offers
In order to master the increasing complexity of electrical/ the opportunity to develop new functions for driver
electronic (E/E) systems in vehicles, E/E architecture design information and driver assistance by combining the available
has become an established discipline. The task of the E/E sensor data. Using these additional data increases the
architecture design is to come up with solutions to interconnectedness between existing functions in the vehicle
challenging and often contradictory requirements such as and it also increases the processing power requirements.
reduced cost and increased flexibility / scalability. One way
to optimize the E/E architecture in terms of cost (electronics Another trend that influences the E/E architecture is the
& wiring harness) is to integrate functions. This can be done development of new propulsion systems: mild and full
by either combining functions from multiple ECUs into a hybrid, range extender and electrical engines. This increases
single ECU or by introducing Domain Control Units. Domain the demand for addressing system variance in the E/E
Control Units provide the main software functionality for a architecture.
vehicle domain, while relegating the basic functions of
actuator control to connected intelligent actuators. Depending This leads to an increasing challenge for the layout of the E/E
on the different market segments (low price, volume and architecture in vehicles. In order to master the complexity in
premium) and the different vehicle domains, the actual usage designing E/E systems, the E/E architecture design has
of Domain Control Units can be quite different and introduced a hierarchical approach for the allocation and
sometimes questionable. realization of functions in the system. The main strength of
the E/E architecture design approach is the differentiation
In this paper, the potential use of Domain Control Units is between the logical level and the implementation level. The
evaluated for the different vehicle domains with respect to the logical level defines the functional chains which are
main drivers, including technical as well as functional trends. necessary to realize the features that must be implemented
This evaluation is based on generic architecture patterns for (e.g. active front steering). The implementation level defines
integration. In addition, the future introduction of Domain the technical realization of functions and their allocation to
Control Units in the three different market segments is components in the vehicle.
evaluated.
One approach to handle the increasing interconnectedness as
well as the increasing variance is the introduction of “central
INTRODUCTION managers” (e.g. safety manager or motion manager) via
Driven by innovations in the areas of driver information, Domain Control Units.
driver assistance, passenger safety and propulsion the number
of electrical and electronic components is continuously This paper investigates whether Domain Control Units are the
increasing in modern cars. answer to these challenges in E/E architecture design. To this
 Downloaded from SAE International by Univ of California Berkeley, Saturday, July 28, 2018

purpose, the relevant aspects in defining domains, the use of VEHICLE DOMAINS
implementation design patterns and the requirements in the
different market segments are evaluated. As a conclusion, the Whereas in the mid seventies in some cars the only electrical
probability of the introduction of DCUs in the different components were the fan of the heating system and the car
domains is stated. radio, today's vehicles comprise up to 70 electrical /
electronic control units (ECU). These ECUs together with
their associated sensors and electro-mechanical actuators will
E/E ARCHITECTURE DESIGN be referred to as components in this paper. The components
fulfill tasks related to the control of the combustion engine,
the braking and steering as well as driver comfort, driver
information and driver assistance. In many cases, the
development of functions requires an interaction between
different components to realize the targeted functionality.
Therefore it is reasonable to define domains in which the
different functions can be grouped and worked on as a quasi
independent sub system. The benefit in working in these
domains arises in the synergies (e.g. development effort,
integration effort) which can be gained by establishing a
homogeneous field of work, i.e. appropriate grouping of sub
systems.
Figure 1. Models of E/E architecture

The E/E architecture design process is a systematic approach

for the layout of vehicle communication and power supply
networks. It covers the functional and non-functional
requirements for the implementation. Figure 1 shows all
layers needed in an E/E architecture design [1]. The main
parts in this layer model are system development and E/E
architecture development. The models for system
development comprise the requirements definition and the
required building blocks to describe the functional and
technological model. These building blocks describe the
functional chains which are necessary to realize the required
features. The models of E/E architecture reflect the results of
different integration stages of electronic systems in the Figure 2. Classification criteria for definition of vehicle
vehicle. domains

The main benefit of applying the E/E architecture design

As shown in Figure 2, classifying the domains only in terms
process is the separation of the functional architecture
of physics (vehicle dynamics) and other functions (comfort
(logical level) from the actual implementation in the vehicle
and driver assistance) would lead to only two very large
components. With this separation it is possible to set up a
inhomogeneous domains in terms of required technology and
functional architecture for complex functions in the design
competence. Therefore according functional as well as non-
phase without the restraints of implementation.
functional criteria should be applied in order to define
domains which are as large as possible without loosing
As in many cases new vehicle platforms are derived from
possible synergies.
existing architectures, two approaches for architecture design
are in use. The bottom-up approach is based on an existing E/
Most important functional criteria are:
E architecture whereas the top-down approach follows all the
model steps starting with the complete set of functional and • Functional dependency: clustering of all networked
non-functional requirements. In the bottom-up approach the functions to limit the number of interfaces / dependencies
E/E architecture is derived by making use of existing models between domains
and extending them by adding the new functional and
network aspects. In the top-down approach the functional • Innovation speed: the change rate / speed of functionality
complexity is in the main focus and is typically chosen in might lead to a temporary separation of a sub domain in order
developing an E/E architecture for new vehicle platforms. to handle these functions as an independent sub system
 Downloaded from SAE International by Univ of California Berkeley, Saturday, July 28, 2018

• Technology: clustering of functions which require specific • Level 1: Isolated electronic control units
technology in the implementation
• Level 2: Connected electronic control units - bus systems
Most important non-functional requirements are: connect the ECUs for data exchange

• Competence: clustering of the required technical • Level 3: Master/Slave networks - one ECU acts as master
engineering competence and synchronizes the so called slaves in executing their
dedicated tasks
• Organization: organization of the company
• Level 4: Domain Control Units (DCU) - a load free DCU
Due to the fact that companies are often organized based on absorbs the software functionality
the defined domains, non-functional requirements such as the Due to the fact that E/E architecture design is heavily cost
existing, historically grown organization (OEM and / or driven, the introduction of DCU as defined in Figure 3 is
supplier) strongly influence the possibility to adapt actual often questioned regarding its benefit in terms of system
domain definitions. However, the domains on the logical costs. In existing E/E architectures the term DCU is
level can be looked at as independent of the organizational sometimes used for different integrated ECU solutions. To
setup. The following main domains find wide application in distinguish between a purely cost driven integration of ECUs
the E/E architecture: and a DCU concept it is important to reflect the different
• Body & Cabin (driver comfort and lighting) design patterns with respect to the logical level in the E/E
architecture design. Figure 4 shows the basic building blocks
• Infotainment (displays, driver entertainment and necessary to realize a function in a vehicle. The functional
information systems) software calculates the set point command (e.g. torque
• Vehicle Motion & Safety (chassis, active / passive safety demand). The control software generates the according
and driver assistance functions) control values (e.g. current per second).
• Powertrain (propulsion and exhaust gas treatment)

IMPLEMENTATION DESIGN
PATTERNS
In the defined domains different design patterns for the
implementation of functions can be found. In the E/E-
architecture design process the functional building blocks are
assigned to components in the node model after deciding
about the technology in the technological model. The
combination of ECU and communication model defines the
basic implementation design patterns in the E/E architecture.
Figure 3 shows the existing design pattern representing
different integration levels:
Figure 4. Basic building blocks in the E/E architecture
design

The dependencies between the vehicle functions which have

to be implemented determine the choice of the appropriate
implementation design pattern. As Figure 5 indicates, Level 1
is preferable for isolated functions. Level 2 is used if the
different ECUs exchange information (e.g. sensor signals) or
if the software functions interact to close control loops in the
functional software. With increasing functional dependency,
i.e. the need to exchange data to close control loops, the
application of Level 2 is limited by the complexity in the data
handling between the functional software parts allocated to
different ECUs. Therefore, with increasing data exchange and
Figure 3. Basic design patterns in E/E architecture number of involved functions, an integration of functionality
on Level 3 or 4 is reasonable in terms of performance and
 Downloaded from SAE International by Univ of California Berkeley, Saturday, July 28, 2018

Figure 6. Domain Control Unit as integration platform for Level 2 ECUs

development effort (e.g. synchronization of development, freedom in developing advanced networked functions. In this
system integration and validation). case the DCU is the focal point of changes. If the functional
range of a component can be covered by the functional
software w/o changes in the hardware, the variance can be
handled completely in the DCU. In these cases the intelligent
drivers remain invariant and can be used independent of the
changes in the functional software, i.e. DCU. This leads to a
cost benefit by re-using the same components for different
vehicle types with different functional range. Furthermore the
integration of the functional software in a DCU reduces the
effort in developing advanced networked functions (e.g.
synchronization of development, system integration and
validation effort).

In order to decide about the introduction of a DCU and its

software scope, the following guiding questions related to the
decision box depicted in Figure 7 can be used:

• Functional Dependency: Are networked functions for e.g.

vehicle motion management allocated to different ECUs?
Figure 5. Application of design patterns • Functional Range: Depends the functional range for
different market segments or functional options only on
The main difference between Level 3 and 4 is the clear software, or is different hardware required?
separation between the functional software, the control
software and the hardware drivers. In the master/slave • Innovation Driver: Is the functional innovation driven by
concept, only the ECU independent software functions are software (e.g. driver assistance functions)?
integrated in the master ECU, leaving part of the functional • Equipment Rate: Will the functionality be implemented as
software allocated to the slave ECUs. In the Domain Control standard or optional equipment?
Unit the main functional software is integrated, while
relegating the basic functions of actuator control to the • Coupling SW - HW: Is the functional software strongly
connected intelligent drivers as shown in Figure 6. coupled to the control software / hardware? Does the system
response time prohibit a separation of functional and control
<figure 6 here> software (e.g. due to latency times)?

The benefit of introducing DCUs shows in the variant • Restraints: Are there other functional or non-functional
management of components used in different market restraints to separate the functional and control software?
segments (low price, volume and premium) and additional
 Downloaded from SAE International by Univ of California Berkeley, Saturday, July 28, 2018

DESIGN PATTERNS IN ACTUAL

VEHICLES
• Body and Cabin: Level 3 design pattern is applied in most
vehicles. A central body computer module is used in almost
all vehicles driven by the high number of comfort and support
functions.

• Infotainment: Level 2 for basic vehicles with low functional

range; Level 3 is widely used in vehicles for the medium
segment; Level 4 was introduced in some vehicles via the so
called Head Unit.

• Vehicle Motion and Safety: Level 2 for basic vehicles with

Figure 7. Decision box for introduction of DCUs
low functional range; Level 3 for vehicles with high
functional range.
Depending on the respective domain, the decision about
• Powertrain: Level 3 in most cases, connecting the engine
implementing a DCU based on these guiding questions can
control unit with e.g. the electronic control unit for exhaust
be different.
gas treatment in the master/slave principle.
On the implementation level the introduction of DCUs is FUNCTIONAL TRENDS IN THE
enabled by actual trends in hardware and software
technology: DOMAINS
• Software architecture: standardization of software / • Body and Cabin: Except the innovation of LED technique
interfaces in AUTOSAR supports the decoupling of software for lighting the functionality is very stable. Therefore there is
and hardware no trend to change from Level 3 to Level 4.

• µC performance: increasing µC performance at reduced cost • Infotainment: For vehicles with extended functional range
results in decreasing importance of resource optimized Level 4 already is introduced using an integrated Head Unit.
software Innovations in the area of Human Machine Interface (HMI)
as well as enhanced functionality like internet or
• Bus systems: increasing bandwidth of e.g. TTCAN, incorporation of portable consumer electronics support the
FlexRay and Ethernet enables the decoupling of sensors / spreading of Level 4 applications.
actuators from location of function
• Vehicle Motion & Safety: The advanced driver assistance
The development of a DCU does not automatically lead to an functions are a broad and rapid growing field of innovation.
additional, separate control unit. The DCU functionality can Especially the possibility of sensor data fusion, i.e.
also be implemented in an already existing ECU. An combination of available data in the vehicle (e.g. gear rate),
additional non-functional requirement for the implementation the vehicle surrounding (e.g. radar, cameras) and external
of DCUs might arise from ISO 26262: the definition of the data (navigation, C2X), allows the development of additional
ASIL for the different vehicle functions can lead to ASIL or functions and simplification of existing functions. The
multi-ASIL requirements. The decoupling of the functional development of behavior models for the vehicle enables the
software in a DCU from the (embedded) control software and introduction of a so called safety manager (advanced driver
the possibility to use multi core-µC supports the realization of assistance) or a motion manager (longitudinal, lateral and
these requirements. vertical dynamics). These managers improve the vehicle
system response to the actual driving situation. With these
DOMAINS - APPLICATION OF new functions the introduction of Level 4 is reasonable.
IMPLEMENTATION DESIGN • Powertrain: The development of alternative propulsion
PATTERNS systems as hybrid, range extender and full electrical vehicle
lead to an increasing variance in vehicle configurations. The
Due to the different technological development, requirements introduction of a DCU to integrate the common functions
and technological maturity in the vehicle domains a variety of would be a consequent step to support the variant
design patterns can be found even in the same vehicle management and to reduce the complexity. If the
domain. developments in the domain Vehicle Motion & Safety result
in the introduction of a motion manager for the vehicle, the
 Downloaded from SAE International by Univ of California Berkeley, Saturday, July 28, 2018

integration of the Powertrain DCU into this manager is segment vehicles. Therefore, typically modular boxes are
favorable. used for optional equipment.

MARKET SEGMENTS - INFLUENCE The different requirements in the low price market segment
ON E/E ARCHITECTURE compared to the volume and premium market segment led to
the development of different E/E architectures accordingly.
The equipment rate and the available options in vehicles
designed for the three different market segments (low price,
volume and premium) vary significantly. The optimization of SUMMARY/CONCLUSIONS
the E/E architecture in terms of cost therefore leads to The innovation in the different vehicle domains has led to an
different solutions in the three market segments. Figure 8 increase of functional software and networked functions. Due
shows an architecture decision box addressing the 4 main to this development, the application of the E/E architecture
topics which have to be decided in setting up the E/E design process gains more and more importance. By
architecture. differentiating between the logical and the implementation
level it is possible to set up a functional architecture in the
design phase without the restraints of implementation.

The introduction of Domain Control Units (i.e. the integration

of the functional software) is a clear trend in the domains and
also the market segments (excluding the low price segment).
Based on the lead questions (Figure 7), the equipment rate of
vehicles and the trends in functional development the
following probability for introducing DCUs in the three
different market segments [2] can be deduced.

Figure 8. Architecture decision box

• Vehicle Layer Functions: Decision to integrate the

functional software in a DCU vs. allocation to separate ECUs
• Signal Routing: Decision to directly connect the ECUs for Figure 9. Probability of introduction of DCUs in the
data exchange (backbone) vs. usage of a central gateway to three market segments
connect the domains
• Scalability: Decision about usage of higher level integration The introduction of DCUs in the volume segment for the
vs. usage of isolated ECUs (Level 1) domains Vehicle Motion & Safety and Powertrain depends
on the equipment rate of driver assistance functions and the
• ECU partitioning: Decision about functional oriented spread of alternative propulsion systems.
integration in ECUs vs. zone orientated integration (e.g. front
module and rear module) The trend for introducing DCUs is supported by:
The architecture decisions regarding scalability and vehicle • The standardization of software architecture (AUTOSAR):
layer functions are strongly influenced by the functional separation of the software and electronic hardware is enabled
range which has to be covered and the equipment rate of the by standardizing the basis software and the software
functions and the related components in the vehicles. The interfaces.
functional range for different components can vary • Microcontroller performance: sufficient performance at
significantly for the three market segments. E.g. the basic reasonable cost will be available with the new
Airbag functionality only requires one sensor, whereas high microcontroller generations in development.
end Airbag applications require up to 5 sensors and the
according software functionality. The equipment rate of the • SW based innovation: enhanced networked functions e.g.
vehicles in the three market segments also depends on the driver information and driver assistance are mainly based on
OEM strategy regarding standard and optional equipment. software rather than on hardware. These new freely allocable
E.g. an antilock braking system is provided as standard functions require an integration platform.
equipment in many low price vehicles, whereas electronic • The trend towards standardized vehicle components:
stability control is offered as option or only for higher market standardization of the basic functionality and the related
 Downloaded from SAE International by Univ of California Berkeley, Saturday, July 28, 2018

components in the vehicles leads to the need for an DCU

integration platform for additional functionality. Domain Control Unit
• The trend towards central vehicle management: central
management of vehicle functions (e.g. safety manager and E/E
motion manager) leads to complexity reduction in the E/E Electric/Electronic
architecture and development.
ECU
The main cost benefit of introducing DCUs in vehicles shows
Electronic Control Unit
in the variant management for different market segments (i.e.
re-use of intelligent drivers as defined in Figure 6) and
reduced development effort. Integrating the functional HW
software into the DCU furthermore enables an easier Hardware
development of advanced networked functions. The DCU can
either be implemented as a separate control unit or be
OEM
integrated in an appropriate existing ECU.
Original Equipment Manufacturer
The introduction of DCUs therefore is one key enabler to
master the increasing complexity in electrical / electronic SW
systems in vehicles at reasonable cost in the future. Software

REFERENCES
1. Powolny, S., Friedrich, T. Mischo, St., Kornhaas R. et al.,
“Model Based Top Down Process for Automotive E/E-
Architecture Development,” SAE Technical Paper
2008-01-0284, 2008.
2. SAE Presentation: K. Williams: Vehicle Networks at the
Crossroads - How to Cope with Worldwide Requirements?;
April 2009

CONTACT INFORMATION
Wolfgang Stolz
Robert Bosch GmbH
wolfgang.stolz@de.bosch.com
Phone: +49 (0) 7062 - 911 - 6057

DEFINITIONS/ABBREVIATIONS
ASIL
Automotive Safety Integrity Level

The Engineering Meetings Board has approved this paper for publication. It has Positions and opinions advanced in this paper are those of the author(s) and not
successfully completed SAE's peer review process under the supervision of the session necessarily those of SAE. The author is solely responsible for the content of the paper.
organizer. This process requires a minimum of three (3) reviews by industry experts. SAE Customer Service:
Tel: 877-606-7323 (inside USA and Canada)
All rights reserved. No part of this publication may be reproduced, stored in a
Tel: 724-776-4970 (outside USA)
retrieval system, or transmitted, in any form or by any means, electronic, mechanical, Fax: 724-776-0790
photocopying, recording, or otherwise, without the prior written permission of SAE. Email: CustomerService@sae.org
ISSN 0148-7191 SAE Web Address: http://www.sae.org
Printed in USA
doi:10.4271/2010-01-0686