Whitepaper

The next step in

E/E architectures
The automotive industry is facing one of the greatest
transformations in its histor y. New business models
promise additional revenue throughout the vehicle life
cycle. Consumers increasingly expect their cars to
blend into their digital, private, and professional lives.
For manufacturers, there are many new opportunities
to stand out from competition, however, especially for
the established ones, leveraging this is a challenge.
 2 | 20

Abstract

Current E/E architectures do not scale in technical foundation for simplified develop-
terms of updateability, customizability, and ment of functions using high-performance
connectivity. Where speed is becoming vi- central computers and zone controllers. To
tal, their design, underlying development ensure that the design remains costeffective,
methods, and tools pose a significant limi- it is essential to drive the technical transfor-
tation. This hinders the introduction of the mation pragmatically, in particular by con-
envisioned softwarecentric technology plat- sidering existing architectures. There is no
forms. To succeed in the transformation to one-size-fits-all solution, so we include in
the softwaredefined vehicle (SDV), multile- this whitepaper possible fusion, migration,
vel strategies based on a common analysis and convergence scenarios, which can also
of the different technology domains are re- be implemented in several steps.
quired.
As the world’s largest tier 1 supplier with
In this whitepaper, we analyze the SDV from many years of experience in all vehicle do-
the perspective of the E/E architecture. We mains, we provide a comprehensive view of
describe the impact of the SDV within and the disruptive topic of new vehicle architec-
between the individual functional domains tures. In doing so, we want to help our cus-
and use this to derive technology needs and tomers on their way to the next generation
reference architectures. of vehicles.
The implementation of the SDV is close-
ly linked to new vehicle-centric and zon-
al architectures, since these provide the
 3 | 20

Table of contents
1
Introduction 04

2
The software-defined vehicle is 06
changing the vehicle domains but
will not eliminate them
2.1 Connecting information, entertainment, and 07
convenience creates added value
2.2 Driving dynamics and comfort are based on 09
the actuators installed in vehicle production
2.3 Data-driven development and new business 11
opportunities shape assisted/automated driving
experience

3
The primary challenge in the 13
software architecture is
managing complexity

4
The pragmatic implementation 15
of zonal E/E architectures

5
The next centralization steps 17
come in different variants
6
Conclusion 19

Imprint 20
1 | Introduction 4 | 20

1
Introduction
The demand for new E/E architectures has This is an opportunity, in particular for es-
massively increased in the past years, and tablished automotive manufacturers, to en-
the first vehicle manufacturers are already ter new domains and tap into new sources
moving to centralized and zonal architec- of revenue.
tures. However, there is still some criticism
New E/E architectures, however, have to
of the new designs. In E/E architecture
balance the conflicting priorities of ensur-
circles, they are said to be too expen-
ing costeffectiveness in the initial produc-
sive, hard to scale, and that they lack the
tion of the vehicle and the newly expected
potential for a risk-mitigating step-by-step
support for reconfigurability and exten-
migration path from legacy systems. But at
sibility over the vehicle’s lifetime. One-
the same time, the new architectures help
time “packages” that can be configured at
create new opportunities. They offer a
purchase are increasingly being augmented
relevant competitive advantage through
by vehicle feature “subscriptions” that can
simplification, enabling holistic updates,
be added later (even temporarily). Features
and making softwarebased configurability
can then be developed well after the initial
and extensibility the central focus. Even
start of production of a vehicle line.
though there are currently some slowdowns,
the race to fundamentally advance vehicle
architectures is on.
With the new vehicle architectures, con-
sumers’ changing expectations of the driv-
ing experience can be better responded
to. In today’s market, engine performance,
exterior, and safety are no longer the only
criteria customers consider when choos-
ing a vehicle. Especially younger people
buy a vehicle because it promises them
enter tainment, convenience, and inte-
gration into the online world. They seek
products that seamlessly connect the
worlds of transport, home, and produc-
tivity. The vehicle is currently evolving into
a technological stage where a person-
alized user experience (UX) and con-
tinuous evolution are key per formers.
1 | Introduction 5 | 20

The automotive industry’s response to these Many features and goals of the SDV, how-
challenges is the software-defined vehicle, ever, can already be implemented through
which represents a shift of the technological less disr uptive changes. This allows
solution space from hardware to software. the optimizations of today’s architectures
This new focus brings the envisioned flexi- to be preserved throughout the ongoing
bility; however, it also requires changing the evolution.
overall vehicle architecture. In addition to
In this whitepaper, we assess the SDV
the need to replace many small, functionally
specifically from the perspective of the E/E
oriented control units with a few powerful
architecture. We identify the influence of
vehicle computers, the internal and external
the SDV paradigm on the different func-
connectivity in the vehicle and the “vehicle
tional domains and determine the relevant
OS,” a construct aimed at reducing variance
drivers that must be considered when
in the hardware and software development,
changing existing solutions. Tapping into our
are central topics of the next generation of
experience as a comprehensive solution
E/E architectures. In these new architec-
provider, we explore how existing archi-
tures, static functions and add-on features
tecture components such as control units,
are complemented by dynamic and distrib-
sensors, actuators, and the wiring harness
uted services, for example, those that use
need to be modernized or replaced and
cloud data to optimize the driving strat-
where new solutions need to be added.
egy. As a result, the boundaries between
classic domains are becoming more blurred.
In terms of the technical elements, we of-
ten find this to be less pronounced, but
there is a significant increase in functional
interdependencies. It is clear that legacy
architectures, markets, and a vehicle seg-
ment focus require a variety of solutions.
Share vehicle production volume
centralized
Vehicle
centralized
Domain
Distributed

2024 2025 2026 2027 2028 2029

Traditional E/E Domain Centralized Vehicle Centralized

Figure 1: OEMs are ramping up new vehicle-centralized architectures and gradually replace prior architectural patterns.
2 | The software-defined vehicle is changing the 6 | 20
vehicle domains but will not elimate them

2
The software-defined vehicle is changing the
vehicle domains but will not eliminate them
There are high expectations that the soft-
Freshness: updating or expanding
ware-defined vehicle will provide endless 01 existing functions to improve the
new opportunities. But one may wonder:
user experience
since subscriptions and servicebased func-
tionality (for example, monthly plans for
traffic data) are already available in today’s
Bug fixing: fixing errors that arise
vehicles, why does the technological back- 02 after development before they
bone of a software-defined vehicle need to affect the individual customers
be adapted at all?
The novelty is in the dynamics. In the SDV,
features grow over time and across all func- Offerings: introducing new features
tional domains, where they were previous-
03 to continue adding short-term and
ly defined only once. A vehicle becomes a long-term value to the vehicle
living platform, with the production date
only a secondary indicator of its capabilities. The demand for technically enabling new of-
There are several preliminary steps neces- ferings over the vehicle’s lifetime requires
sary to enable this. new system layouts and “softwareification.”
But the solutions are not the same for every
First, it needs capable centralized hardware
part of the vehicle. Even though all domains
that is designed with corresponding perfor-
will eventually move to more software-
mance reserves or can be replaced through-
driven development approaches, what form
out the vehicle’s lifetime. This is the most
this takes varies. Domains will continue to
obvious change. The SDV cannot be imple-
have individual constraints and optimization
mented in legacy distributed architectures.
points that must be considered. To under-
A second fundamental requirement is a stand the technical needs of the SDV, we
stable connection to a cloud platform, have collected the new driving forces and
through which features are managed, and expectations from each domain. This allows
continuous interaction with the vehicle us to examine the architectural decisions
(for telemetry, data, and services). The and variance points for each of the new E/E
cloud platform and the vehicle become a architectures. We will start with the infotain-
strongly interwoven technical ecosystem. ment and body/comfort domains, move on
Finally, the update path becomes the most to motion-related functions, and conclude
vital element. Updates will be used for this chapter with our analysis of the driver
different objectives. These are: assistance and automated driving functions.
2.1 | Connecting information, entertainment, 7 | 20
and convenience creates added value

2.1
Connecting information, entertainment,
and convenience creates added value

New SDV features obtain their automo- For reasons such as these, we expect
tive -specific character by connecting that the physical functions and their low-
different domains of the vehicle. Such cross- level controls will continue to remain largely
domain functions already exist today. In separated from the infotainment domain
the software-defined vehicle, however, the and be accessed by the infotainment apps
connection points between the domains only through logical interfaces, known as
will no longer be feature-specific; instead, vehicle APIs or hardware abstraction layers.
they will be designed more broadly and For practical reasons such as connector
generically to support reuse in a poten- sizes, it even makes sense to keep body
tially large variety of future applications. functions at least partially on dedicated
We expect the infotainment domain and control units (possibly as added function-
body domain to be initially affected the most ality in a zone ECU) or concentrate them
by this shift, because they jointly provide the in a protected execution environment on
oftenenvisioned digital and physical interac- another central controller. This provides the
tions between passengers and the vehicle. separation that is necessary from a security
Oftentimes, the infotainment domain is also and safety perspective.
the functional endpoint of the cloud uplink,
However, we have observed that, in practice,
extending the interactions to smartphones
manufacturers plan for different allocations
and remote services.
of the control logic of sensors and actuators.
To quickly implement new, value-gener- Logic is centralized, implemented locally
ating services that can be experienced on existing control units, or even distrib-
immediately by the consumers, the new uted between zone ECUs. The allocation is
vehicle platforms provide easy access to the often decided for each function individually,
necessary sensor information, actuators, and there are few cases where it follows a
and vehicle information. Safety and securi- generic strategy. Due to stricter require-
ty objectives, however, must not be jeop- ments relating to self-diagnostics, startup
ardized in this new setup. This particularly timing, and fallback behavior, however, hard-
applies to vehicle functions that control the ware sensor/actuator-specific implementa-
lights, doors, and seats, where implementa- tions will never entirely disappear from the
tion or execution errors may create a safety deeper system levels.
hazard. Additionally, personally identifiable
information must always remain protected.
2.1 | Connecting information, entertainment, 8 | 20
and convenience creates added value

As stated above, generic application inter- This is why such APIs are combined with
faces are a cornerstone of the simplified transport protocols that allow connections
implementation of cross-domain functions. to be established dynamically and support
For further optimization, SDV platforms a guaranteed quality of service. Examples
implement functional safety objectives are SOME/IP and DDS, both of which are
through generic, high-level, software-based used on Ethernet-type buses, often in com-
protection mechanisms so that critical actu- bination with Time-Sensitive Networking.
ators, for example, can be locked while driv- Another change we see in the systems en-
ing. This significantly reduces the process- gineering for these architectures affects
ing burden for SDV applications and can be the variant and version management. Ver-
combined with simple, locally implemented sion management will be expanded to
protective mechanisms in the actuator. include not only software component version
management but also API version manage-
Vehicle APIs are a software construct that
ment. The latter provides for easier depend-
allows technical endpoints to be moved
ency management. Nevertheless, any addi-
almost completely freely within the E/E
tional regulations, such as for releasing the
architecture through corresponding abstrac-
overall functional chains, always need to be
tions. Nevertheless, the underlying commu-
taken into account in addition to managing
nication buses need to be capable of sup-
technical compatibility.
porting the emerging dynamics.

C A S E
Data telemetry Subscription More seamless New BEV platforms
becomes essential ADAS features integration of as opportunity and
part of the dev. with preinstalled cloud-operated and innovation stage for
workflow hardware for digital services into signaficant EE/A
higher-segment physical vehicle restructuring
vehicles experience beyond
infotainment

Cloud data usage Shadow mode data Increasing Energy efficiency

and function and continuous customer value improved through
offloading in all system updates for focus to comfort data-centric
vehicle domains continuous functions and operating strategy
performance entertainment optimizations
improvements

Figure 2: Vehicle-centralized architectures are a response to expectation from the C.A.S.E.* paradigm. It
requires a shift of technological solutions into software, and a technology platform supporting fast iterations.

*(connected, autonomous, sharing, electrificed)

2.2 | Driving dynamics and comfort are based on the 9 | 20
actuators installed in vehicle production

2.2
Driving dynamics and comfort are based on
the actuators installed in vehicle production

While assisted and automated driving dynamic longitudinal and lateral motion
functions are on the rise, the manual driving coordination. With a further shift of steer-
experience will remain a vital part of the ing, braking, acceleration, and suspension
design, since it is still the essence of the functions to that system, the motion func-
brand for many automotive manufacturers. tions can be realized in a more uniform
Consequently, we expect that the driving development environment.
software, in particular the parts responsible
Despite this trend towards centralization,
for regular driving situations, will not follow
however, we still have not seen any major
the same continuous evolution path, but will
step towards dissolving the close connec-
already have reached a very mature state
tion between high-frequency control/reg-
with the start of vehicle production. Subse-
ulation tasks and the sensors and actua-
quent software-based updates are expected
tors of the domain. The comparatively low
to happen primarily “under the hood.” Some
benefits in terms of system costs, very strict
extensions will come to the SDV in the form
safety requirements, and individual compo-
of maintenance and performance improve-
nents that are highly optimized for perfor-
ments that use cloud data or run non-critical
mance and cost stand in the way of this.
additional functions offboard.
While end customers might not be able
to experience the new SDV architectures
in this domain right away, these architec-
tures can still bring a significant benefit
for manufacturers. They can use the in-
troduction of central control systems to
improve the performance of their vehicles in
terms of safety, comfort, and efficiency for
2.2 | Driving dynamics and comfort are based on the 10 | 20
actuators installed in vehicle production

For the subsystems mentioned above, the The same is true of functions for optimizing
SDV has the advantage that, in addition to the operating strategy, which (depending
simplified joint development, updates can on the stage of development) are imple-
be rolled out without bringing the vehi- mented in local or cloud environments that
cle to a mechanic. Improvements to driver are optimized for dynamic loads. Depend-
support features used in critical driving ing on how relevant these functions are for
situations, such as traction control and vehicle homologation, however, there may
vehicle dynamics, can also be introduced be limitations in the freedom of allocation
using this option. For reasons of safety and and updates.
stricter vehicle homologation regulations,
For vehicle manufacturers, this presents
however, the relatively high update rates and
opportunities for new, indirect monetization
variety of versions for the functions seen in
models. Data collected through standard
other domains are not expected.
interfaces can be used for value-creating
An online channel to an automotive back- services such as predictive maintenance and
end, most likely implemented in an execu- for creating battery certificates. Features
tion environment separate from the direct can also be activated at a later time.
driving coordination functions, provides an
opportunity to make the driving experience
even safer through cloud-based function-
al extensions, such as predictive warnings
in the event of poor street conditions due
to snow and ice. However, since the vehi-
cle must remain useable even without a re-
mote connection, these are primarily non-
essential additions to the core functionality.
2.3 | Data-driven development and new business opportunities shape 11 | 20
assisted/automated driving experience

2.3
Data-driven development and new business opportunities
shape assisted/automated driving experience

The development of assisted and automat- Furthermore, reducing the number of differ-
ed driving functions is a great beneficiary ent variants lowers costs. This is done de-
of the constant connectivity envisioned for spite the fact that not all of this functionality
the SDV. With a constant influx of scene may be needed in individual cases.
and telemetry data,the automated/assisted
The SDV cloud connection is used for
driving system (ADAS) can be continuously
feature release management and billing. It
improved. Through iterative updates, these
is clear that this only represents a profita-
improvements are rolled out to all custom-
ble business model when the business case
ers. Consequently, the expected update
covering vehicle production costs, addition-
rates will likely be higher.
al revenue over lifetime, and the possible
The mentioned elements of SDV techno- reduction in the number of variants comes
logy are generally necessary to sustain- out positive.
ably improve the quality of the product,
According to current observations, auto-
but they can already be implemented today
motive manufacturers with a focus on the
in existing domain-centric architectures.
upper-midrange and premium vehicle seg-
So in terms of the user experience, at a
ment in particular have used this approach
first glance it seems that there is no need
so far. The transition from assisted (<=L2+)
for action. Does this mean that ADAS is a
to automated (>=L3) driving functions
“non-SDV” domain? No.
significantly increases the need for sensors,
There is a change in end customer business performance, and redundant system struc-
models for ADAS that affects the under- tures. In order for the additional feature
lying E/E architecture. Previous architec- purchasing model to work outside of the
tures are built to optimize costs by allowing premium segment, making a distinction
optimal selection of sensor sets, Compute between vehicles allowing or not allowing
performance, and storage per vehicle and the later integration of >=L3 driving func-
purchased feature set. While cost-effective, tions represents a valid criterion for creating
this rules out any post-production feature variants in production. In new vehicle archi-
upgrades. tectures, this can be done through purely
additive expansion designs with additional
Architectures that aim to enable general SDV
centralized controllers, redundant power
capabilities in ADAS take a completely differ-
supplies, and additional sensors that do not
ent approach. Possible increases in the costs
disrupt the original <=L2+ architecture.
of vehicle production (due to overprovision-
ing of sensors and Compute performance)
are counteracted by revenue from sub-
scription models and pay-per-use options.
2.3 | Data-driven development and new business opportunities shape 12 | 20
assisted/automated driving experience

Through closer integration with the cloud, multigigabit Ethernet, as per the current state
additional data sources can be included of the art. Shifting within the ADAS domain
in the SDV that continue to improve the towards a zonal architecture in the currently
functional performance of the assistance envisioned architectures appears to be
features (for example, through predictive advantageous for interfaces with lower
planning using online maps with detected bandwidth requirements. For ultrasonic
road conditions such as black ice). Until sensors, a zonal coupling can also prove to
more robust wireless communication tech- be advantageous when it comes to overall
nologies become available, these more geometries.
volatile SDV features will not replace the
robust, universally available core of the
ADAS functional platform. Instead, they will
complement it.
From the perspective of the overall architec-
ture, centralization of the ADAS functions
will continue to be a focus when it comes
to implementing the SDV. This is required
in particular to enable wider software-
based scaling in homogeneous hardware
platforms. We expect that ADAS-specific
sensor systems that require a lot of band-
width (cameras, lidar systems, and raw
data radar systems) will initially remain
connected with a star topology through
broadband interfaces specific to the tech-
nology domain (e.g., LVDS for cameras) or
3 | The primary challenge in the software architecture is managing complexity 13 | 20

3
The primary challenge in the software
architecture is managing complexity
In the previous chapter, we outlined the With the evolution of the SDV, tech-
different needs of the functional domains nical separation mechanisms such as
and how they benefit from an SDV-en- hypervisors and containers play a key role.
abled E/E architecture. Centralization and For microprocessor platforms, technical
consolidation were key aspects here. In the solutions from other industries, such as from
following, we will conduct a small excursion data centers, have already been transferred
into the software domain to look at tech- and enhanced for use in an automotive
nical separation needs, because this is an context. This allows functions from different
overarching driver that impacts the extent to domains to be merged, even onto a
which consolidation in the E/E architectures single system-on-chip (SoC). The operating
is possible and sensible. systems available in the automotive domain
provide many features that allow concerns
In the SDV, software becomes the fulcrum
to be separated as desired, so they can be
of the technological development of the
managed, verified, and validated by small
vehicle. In order to keep the growing amount
teams, as autonomously as possible and
of software manageable, complexity must
without regression. This also applies to
be reduced and controlled. This means that
safety-related freedom from interference
both the software platforms of the SDV and
requirements. The evolution of automotive
the tooling used must be suitable, but also
microprocessor platforms, however, is not
the hardware designs need to be assessed
yet complete and continues to be driven by
for their capability to act as “software carri-
consortia such as SOAFEE. Nevertheless, a
ers.” Here, the support for good separation
high maturity level has been reached already,
mechanisms, rooted in hardware, is vital.
enabling domain and functional consolida-
Where previously complexity was reduced
tion onto single microprocessor platforms.
by placing functions into different control
units, now the controller platform’s inter-
nals are becoming the primary contributor
to the separation.
3 | The primary challenge in the software architecture is managing complexity 14 | 20

On the other hand, microcontroller plat- This is necessary, for example, to meet
forms are still in the early stages of the requirements of UN ECE R156 regard-
supporting modular deployment of func- ing the release of software updates. In
tions. This partially stems from limitations this context, the decoupling of homolo-
in the hardware itself, but also applies gation-related functions is far more rel-
to many microcontroller software frame- evant than the ability to install or update
works that target singlepoint integrations software components individually. This
and monolithic deployments. Their granu- leads to beneficial partitions in the E/E
larity is therefore, at most, at the level of architecture that strictly separate, for exam-
separated virtualization-based partitions, ple, homologation-related functions from
but with shortcomings in their indepen- other functions.
dence and hardware agnosticism. This impos-
es a hindrance with regard to finely granular
deployability, which currently leads to the
perception that dynamic SDV functions are
only developed on microprocessor plat-
forms.
Especially for the driving and assisted/
automated driving domains with their
great importance for safety and tight
functional coupling, the fact remains
that, despite decoupled development, the
software as a functional implementa-
tion must still be managed as a whole.
4 | The Pragmatic implementation of zonal E/E architectures 15 | 20

4
The Pragmatic implementation
of zonal E/E architectures
As is now obvious, centralization is essen- Zone ECUs can leverage fur ther cost
tial in SDV E/E architectures, but may be benefits if they simultaneously contribute
constrained by the technical capabilities of to a noticeable reduction in the overall
the Compute hardware or software frame- number of ECUs. This is particularly evident
works used. To complete our picture of for body-related vehicle applications, where
these architectures, we will now move on many small ECUs may be combined.
to the underlying layers of the E/E archi-
As already noted in the title of this section,
tecture, here in particular the use of zone
however, the task of the zones is decided
controllers for decoupling functions in the
pragmatically – from the “extended arm”
SDV.
of the central control units to the largely
One often-mentioned primary driver for independent geometrically oriented extend-
zonalization is that geometric vehicle ed body domain controller. Service-orient-
partitioning using zone ECUs allows the ed architectures allow for a greater degree
wiring harness to be simplified through of freedom in allocation and use the zone
segmentation and de-/multiplexing. From the controllers as an infrastructure element for
perspective of the communication network, the implementation of abstracting vehicle
these zone controllers bundle lower-speed APIs.
communication channels and connect them
The scaling of zone ECUs is limited by pin
to a larger central backbone. The power
count and heat dissipation limits (espe-
network in a zonal E/E architecture bene-
cially for power electronics), which means
fits from a finely granular safety and control
that the use of sensitive components such
architecture using, for example, electron-
as high-performance SoCs or large memo-
ic fuses. This simplifies the overall power
ries is subjected to strict limitations. High-
subdistribution, which is advantageously
er-performance zone ECUs are possible with
implemented in combination with central
a more comprehensive and costly cooling
power management that takes care of the
solution, but centralization in the direction
main distribution. Zonalization can provide
of actively cooled central vehicle computers
benefits both for production costs and
generally appears more favorable.
for automating wire harness production
and installation, but the advantages vary
depending on the amount of equipment in
the vehicle. Especially in the cost-optimized
budget vehicle segment with significantly
smaller feature sets, additional ECUs for
simplifying the wire harness may ultimately
not pay off.
4 | The Pragmatic implementation of zonal E/E architectures 16 | 20

A further shift of functions into zone ECUs, Finally, zone ECUs specialized for distrib-
especially sensor preprocessing for the uting communication have the potential
ADAS domain, does not provide clear advan- to perform in-vehicle diagnostic gateway
tages. Either increased centralization with functions. However, in terms of the SDV,
simpler sensors or preprocessing within the this must be reconciled with the general
sensor make more sense in terms of domain need for a central data telemetry and update
independence and technology specificity. master function, which can be advanta-
For example, the processing algorithms geously implemented at the central Com-
of radar systems are very sensor-specific. pute layer.
Moving this to a zone ECU requires common
component development and puts addition-
al burden on the zone ECU design. Function-
ally, the benefit of zone-based preprocess-
ing is limited, as quickly becomes evident in
the example of a 360-degree camera view
with overlapping image areas that need to
be merged. Note that this does not mean
that the camera belt will never be zonalized,
because technology standards and silicon
availability are constantly improving. The
zones would, however, act only as a multi-
plexer in this case.
5 | The next centralization steps come in different variants 17 | 20

5
The next centralization steps
come in different variants
Considering SDV architectures from a One integration step that has already been
domain perspective, as presented in the implemented by some vehicle manufactur-
previous sections, shows a clear trend ers today is that of a “shared housing,” in
towards centralization, with consolidated which separate Compute units are accom-
ECUs for ADAS, infotainment, and driving modated in a common mechanical frame.
and body functions. Between the “new” The ADAS and infotainment domains in
domains and the underlying zone ECUs, more particular, both of which rely on high-per-
standardized interfaces will allow cross- formance SoCs and heat-sensitive memory
domain implementation of functions. The components, benefit from a common cool-
next integration steps will take place at ing system and possibly additional shared
the granularity level of this now-completed infrastructure. The shared housing concept
domain consolidation, resulting in differ- can be designed as a fixed multi-PCB solu-
ent technological variants. Single-domain tion or, with more flexibility in mind, using
controllers will therefore successively adapted module concepts. This makes them
disappear from the E/E architecture. Within cheaper to maintain and allows them to be
the ECUs, however, they will remain – for potentially replaced by better hardware
reasons such as different requirements for versions over the lifetime of the vehicle.
approval and management processes but
also due to varying technical constraints.

AIP = ADAS Integration Platform

CAM = Camera Head
CIP AIP CCU = Connectivity Control Unit
CIP = Cockpit Integration Platform
ECU = Electronic Control Unit
ESP = Electronic Stability Program ECU
EPS = Electric Power Steering ECU
INV = Inverter ECU
MIP = Motion Integration Platform
VIP = Vehicle Integration Platform
Z = Zone Controller ECU

Figure 3: First vehicle-centralized architectures will introduce centralized vehicle computers and zone ECUs. As visible
in this example, the degree of cross-integration and shift to a purely zonal communication/power network will differ
between domains.
5 | The next centralization steps come in different variants 18 | 20

Multi-SoC solutions on a single PCB rep- In addition to the primarily microproces-

resent a more rigid level of integration sor-centric integration platform for ADAS
while also increasing synergies and cost and infotainment, a comparable microcon-
benefits. They can also be combined with a troller-centric integration step can also be
modular design concept for scaled variants. considered for motion, gateway, and body
functions. These platforms are dominated
Especially in the cost-sensitive segment,
by much stronger separation mechanisms,
solutions based on fusion SoCs represent a
which are primarily designed in hardware.
valid integration solution. In this case, sepa-
This is the only way to handle the higher
ration is implemented at the software level,
determinism requirements and accom-
for example, with hypervisors and contain-
panying topics such as the decoupling of
er frameworks, always paired with strong
homologation-related functions. This is asso-
hardware-supported separation and qual-
ciated with more static software frameworks,
ity-of-service mechanisms. This degree of
which are, however, based on established
integration is also the most complex in terms
standards such as AUTOSAR Classic. These
of functional freedom from interference.
platforms offer lower idle current consump-
The question of which co -integration tion, fast startup, and easier implementation
option is best suited cannot be answered of functions up to maximum safety levels.
from a technical perspective alone. How-
ever, using elements from existing archi-
tectures in particular makes a step-by-
step approach from the shared housing
concept to the fusion SoC appear advan-
tageous as a method of minimizing risk.
6 | Conclusion 19 | 20

6
Conclusion

The next generation of vehicle architectures The new software-centric approach, howev-
puts user experience and software at the er, cannot scale sufficiently in the existing
forefront. Driven by changing consumer pref- ecosystem. New initiatives such as SOAFEE,
erences, it allows automotive manufactur- COVESA, and Eclipse.SDV provide access to
ers to tap into new business models that software resources and developers on an
build upon data-centric interconnection of unprecedented scale. However, fulfilling
the vehicle with cloud-based services and the quality requirements of the automotive
that lead to a further dissolution of func- world will take many more collaborative
tional domain boundaries in user-centric efforts, including with regard to hardware
areas. Abstraction at both the hardware and standards. New partnerships need to be
vehicle level combined with greater freedom established to generate joint synergies. In
and decoupling in software development doing so, the specifics of the highly regulat-
are necessary for coping with the increas- ed and safety-focused automotive industry,
ing complexity of the vehicle system. This which operates under high cost pressure,
is helped by adapting the E/E architectures have to be taken into account. The lack of
in such a way that they significantly simplify joint processes, methods, and tools required
the development of the vehicle functions. In for collaborative project and product devel-
both geometric and vehicle-wide centraliza- opment presents an important challenge to
tion, the convergence of control units has to be overcome.
be considered. Despite a recent decelera-
The creation of a software-defined vehi-
tion, the trend towards new vehicle architec-
cle will succeed if the requirements for
tures, which manifests itself in high-perfor-
updating, integrating cloud-based services,
mance computers and zone ECUs, continues
and managing variants and configurations
unabated.
are clearly mapped to preferred technical
In order to meet the cost, time, and quali- solutions and functional views. As a cross-
ty targets for this transformation, a holistic domain system provider with expertise in
and targeted approach is required that the classic automotive sector as well as in
aligns the specific technical, commercial, the field of the SDV, Bosch is hard at work
and functional considerations of the affect- addressing these issues. As a global player,
ed vehicle domains and provides for mean- we bring our extensive expertise to projects
ingful deviations from the often rather dog- and studies to enable content-centric, via-
matically conceived vehicle-centric archi- ble architecture advancements, such as the
tectures. This is particularly relevant to ones outlined in this whitepaper.
enable E/E architectures to be continued
to be developed step by step from lega-
cy architectures and with the aim of also
covering the entry-level market segments.
 20 | 20

Imprint

Why Bosch?

Bosch is your full-stack technology pro-

vider for innovative hardware, software,
and systems products. With our extensive
experience in systems design, our network
of experts supports our customers to real-
ize cost-efficient, scalable, and safe solu-
tions across all automotive domains.

Authors:

Dr. Thorsten Huck

Dr. Andreas Achtzehn
Andreas Deberling
Erik Goerres
Dr. Karsten Wehefritz

Cross-Domain Computing Solutions

Engineering System Architecture

Contact us now
Get in touch with our expert team. We
[email protected]
are looking forward to support you with
our expertise to design your next steps +49 173 3175436
in E/E architecture.