Automotive software and electrical/electronic (E/E ...€¦ · Automotive software and electrical/electronic (E/E) architecture of the future INTRODUCTION TO THE GSA MEMBERS Discussion

CONFIDENTIAL AND PROPRIETARY

Any use of this material without specific permission of McKinsey & Company is strictly prohibited

Automotive software and electrical/electronic

(E/E) architecture of the future

INTRODUCTION TO THE GSA MEMBERS

Discussion document | September 27, 2017

WORKING DRAFT

Printed 7/3/2017 7:53 PM India Standard Time

2McKinsey & Company

Software & electronics is the core enabler for key automotive innovations

SOURCE: McKinsey & Company Analysis, IEEE "This Car Runs on Code"; HAWK; Automotive Electronics Initiative

Connectivity

▪ Integration of 3rd party services

▪ Updates over-the-air to deploy

new features faster

▪ Operation of future cars partly in

the cloud

Autonomous driving

▪ Rise of built-in sensors and

actuators

▪ Higher demand for computing

power and communication

▪ Unlimited need for reliability

Diverse mobility

▪ Shared mobility services and

robo-taxis via app

▪ Customized driver experience

Electrification

▪ Introduction of new electronics

▪ Reduction of energy

consumption through advanced

software algorithms

Innovation

through

software &

electronics

3McKinsey & Company

A multitude of player are trying to capture their share of the value

SOURCE: McKinsey & Company

Auto soft-

ware/SW

environment

supplier

SW giants /

Tech players

Integration

architects

Computing and

connectivity players

Semi-conductor

supplier

Car electronics

system supplier

Premium car

OEM

Volume/low-

cost car OEM

Tier-1Automotive players

4McKinsey & Company

Not surprisingly, many players active in the automotive electronics arena today are

expanding their focus area along the stack

EXAMPLES


Emerging activitiesExisting playersNew players

Hardware

abstraction

Firmware

Applica-

tions

Operating

system

Signal

processing

Tier-2/-3 OEMTier-1

Premium car

OEM

Volume/low-cost

car OEMAuto soft-

ware/SW

environment

supplier

Car electronics

system supplier

Semi-conductor

supplier

Integration

architects

FeaturesSW giants /

Tech players

Hardware

Does not reflect non-embedded

applications / software (e.g., cloud-

based) that interacts with vehicle

Computing and

connectivity players

5McKinsey & Company

And there are potentially more disruptions to come

Liability

regulation

for

autonomous

driving

becomes

effective

New

regulation

that

requires

OEMs to

provide third

party

interface

2030+

Regulatory

changes

facilitate

use of OTA

updates

Lyft manu-

factures and

provides

own

vehicles

OEMs enter

partnership

to

standardize

vehicle

architecture

Amazon

provides in-

vehicle

cloud

platform

Uber

announces

own open

source

vehicle

stack

Safety-critical

functions

must be

implemented

redundantly in

vehicles

Mobile

networks

are widely

available

across the

world

Autonomous

cars

(Level 5) are

introduced to

the market

National

Highway Traffic

Safety

Administration

defines LiDAR

as standardToday

ILLUSTRATIVE

6McKinsey & Company

Game changers will determine the development of the future vehicle SW and E/E architecture

Data explosion

Both amount and size generated, processed, and transmitted in vehicles will

rise dramatically due to new sensors and applications

Over the air updates

Driven by increasing SW complexity and function-on-demand business models,

all components in a vehicle will be updateable

App'ification

App'ification in infotainment and ADAS/HAD functions will increase with

fragmented developers providing content into the vehicle

Integrated security

Security as a key challenge will move from a pure access control towards an

integrated security concept to avoid cyber attacks

Convergence of functionality

Function in the vehicle will not work isolated but will require a high degree of

integration to enable HAD

Game changers

will gradually

impact the

vehicle SW and

E/E

architecture

over the next

two to three

vehicle

generations

7McKinsey & Company

The vehicle architecture will become more integrated and layered – new layers for connectivity,

applications, artificial intelligence and operating system will be added


1 Strong rise in number of applications - application layer exists already today 2 Incl. OS in status quo

Today's differentiation

through:

▪ Vehicle hardware

▪ UI/UX

Software is partially

vertically integrated in the

current architecture, i.e.,

some software in ECUs

...will shift to future factors

for brand differentiation in:

▪ Infotainment features

requiring Plug & Play

capabilities

▪ Autonomous capabili-

ties including sensor

fusion algorithms as

complement to hardware

▪ Safety features based on

fail-operational behavior

▪ Software will move further

down to hardware

(smart sensors)

▪ Stacks become

horizontally integrated

▪ New layers will be added

to the stackVehicle

Middleware layer/OS

E/E hardware2

UI/UX/HMI

Connectivity

Artificial intelligence / Advanced analytics

Sensors ActuatorsPower

components

Cloud platform

Applications1

FROM: Partially vertically

integrated architecture TO: Horizontally and vertically integrated, layered architecture

Combine in-vehicle data

with environmental data

Significant increase in

number of applications

Abstract applications

from hardware

Analyze data for real-

time decisions and

autonomous driving

Modified layersNew layers

< >

8McKinsey & Company

10 working hypotheses for the automotive software and E/E architecture of the future

2

Expanded middleware layer will abstract applications from the hardware: On top of ECU hardware in the car, the middleware layer will allow for

abstraction and virtualization, a service-based architecture, and distributed computing

4

Full redundancy of power and data networks: (Safety-) critical applications will require fully redundant circles for data transmission and power supply

that are intelligently controlled to support steer-by-wire and other HAD functions

3

Limited number of architecture stacks with integrated hardware and software: The number of stacks will decline, but stacks per se will remain and

will be connected with each other. Stacks will be optimized within themselves – hardware and software will become more integrated

5 Sensors will become more intelligent: Intelligence will move from ECUs into sensors. Future sensors can pre-process data, trigger actuators directly,

and inform ECUs retrospectively about the actions

1 ECUs are getting consolidated and standardized: Instead of a multitude of specific ECUs for specific functionalities, the industry will move to a

consolidated vehicle architecture with few domain controllers doing all the calculations

6

Significant mid-term spike in the number of in-vehicle sensors: Sensors with similar functionalities will be installed in the next 2-3 vehicle

generations to ensure functional safety – in the long-term, OEMs will opt for specific sensor solutions to reduce the number of sensors/costs

8

Increasing use of cloud to combine in-vehicle data with environmental data: Data that is neither safety-critical nor personal will be increasingly

processed in the cloud to derive additional insights

9

Rise of automotive Ethernet: Due to increased data rates and redundancy requirements for HAD, automotive Ethernet will emerge as a key enabler,

especially for the central data bus

7

Data connectivity for functional safety and ADAS will always be channeled via the OEM; more open interfaces in infotainment: Central

connectivity gateways transmitting/receiving safety critical data will always connect solely to an OEM backend which 3rd parties can connect to for data

access. In infotainment, more open interfaces will allow for deployment of content according to standards set by the OEM

10 Components will be updateable and communicate bi-directionally: Test systems in the vehicle allow for function and integration tests of updates,

which form the basis of lifecycle management and post-purchase feature enhancement/unlocking. All ECUs will be able to send and receive data

to/from sensors/actuators. Data sets can be retrieved to support innovative use cases (e.g., route calculation based on vehicle parameters).

SOURCE: McKinsey

9McKinsey & Company

The one-function-one-ECU design philosophy will change: ECUs will be consolidated either in

domain-specific controllers or into a supercomputer or will disappear entirely


TODAY

▪ One ECU per functionality

▪ 30 - 150 ECUs

▪ Isolated operations

▪ Enormous complexity and high cost

savings potential

One-function-one-ECU design philosophy

Airbag

Deployment

Adaptive Front

Lighting

Adaptive Cruise

Control

Automatic

Braking

Electric

Power Steering

Idle

Stop/Start

Electronic Throttle

Control

Electronic

Valve

Timing Cylinder

De-activation

OBDII

Blindspot

Detection

Lane

Departure

Warning

Electronic

Stability

Control

Anti-lock

Braking

Active

Vibration

Control

Remote

Keyless

Entry

Transmission

Control

Seat Position

ControlTire

Pressure

Monitoring

Regenerative

Braking

Hill-Hold

Control

Active Suspension

Active Exhaust

Noise Suppression

Security System

Navigation System

Digital Turn Signals

Electronic

Toll Collection

Lane

Correction

Battery Management

Entertainment

System

DSRC

Cabin

Environment

Controls

Active

Cabin Noise

Suppression

Voice/Data

Communications

Interior

Lighting

Auto-

dimming

Mirror

Event Data

RecorderDriver

Alertness

Monitoring

Accident

Recorder

Instrument

Cluster

Head-up

Display

Night Vision

Engine

Control Parental

Controls

Windshield

Wiper Control

Active

Yaw

Control

Parking

System

▪ 5 domain-specific controllers for infotainment,

AI/sensing, safety, interior/comfort and powertrain

▪ Consolidated operating system, coordinated operations

and elimination of redundant components

Scenario 1: Consolidation of ECUs into 5 domain-specific controllers

Interior/

comfort

controller

Infotainment

controller

AI/sensing

controller

Safety

controller

Powertrain

controller

FUTURE

▪ 1 redundant supercomputer that functions as the

“brain” of the vehicle

▪ Consolidated operating system, coordinated operations

and elimination of redundant components

Supercomputer

(Central vehicle control unit)

Scenario 2: Consolidation of ECUs into one supercomputer

Scenario 3: Smart-node computing network without ECUs

▪ Distributed computing platform that comprises smart

sensors with dedicated computing power in micro-chip

▪ Virtualization of processing power via Hadoop cluster

▪ Removal of ECUs in car

1Dominant path

10McKinsey & Company

The different stacks that evolve will be connected to each other


Stacks

Require-

ments

▪ Connectivity

▪ Usability

▪ Third party integration

▪ Cost-efficiency ▪ Integration of

components

▪ Low latency

▪ Close link between actuators and

sensors

▪ Autonomous systems

▪ Redundancy

Interior/comfortInfotainment/Visualization PowertrainSafety

▪ Entertainment (e.g., radio)

▪ Backup camera system

▪ Telematics module

▪ Navigation system

▪ Wi-Fi hotspot

▪ Phone connection / mobile

office

▪ Apps

▪ Vehicle HMI

▪ Supporting systems

(e.g., for climate

control, electric

locking system)

▪ Central, door and

seat control units

▪ Personalized key

▪ Smartphone

terminal

▪ Electric windows

and mirrors

▪ Acceleration

▪ Engine braking

▪ Battery

management

▪ Airbag control

▪ Emergency brake control via external

braking mechanism

▪ E-call

▪ Pedestrian protection

▪ Rollover sensing

▪ Secondary collision mitigation

▪ Pre-crash occupant safety control

▪ Environmental modeling /

sensor fusion

▪ Perception

▪ Image recognition

▪ Modeling of decisions

▪ Adaptive cruise control

▪ Lane departure warning

systems

AI/Sensing

Functions

Hardware

Compo-

nents

Chip

WiFi Hot-

spot

Phone/

Mobile

Office

Apps

Connectivity (WiFi, LTE, …)

CPU / GPU

Middleware / OS

Middleware / OS incl. security services

ECU ECU…

Ruggedized ECUsRuggedized ECUs

Sensors Actuators Sensors ActuatorsSensors Actuators…

ActuatorsSensorsSensors

LiDAR RaDAR Camera …

GPU

Pre-processing

…Simple applications

Powertrain mgmt.

& algorithmsApplications ApplicationsAI

Connectivity

Hardware Software2


Vehicles are evolving to a mobile computing platform – the future middleware has to meet

demands for reconfigurable cars as well as the installation and upgrade of vehicle software

Future

Middleware across domain control units with ability to access

functions of DCUs

Middleware

DCU

Interior/

Comfort

AI/

Sensing

DCU

Safety

DCU

Power-

train

DCU

Infotain-

ment

DCU

Middleware layer of the future supports:

▪ Functional safety through mechanisms for fault recognition and

tolerance

▪ Plug&Play through standardized interfaces allows adding functions

not available when vehicle is launched

▪ Resource awareness and optimal allocation

Today

Middleware within each ECU responsible for intra-ECU

communication

Current limitations:

▪ Software for each function statically built into the applications of

the ECU

▪ Rebuild of entire software stack is necessary for upgrade or new

installation

▪ No methodologies to reduce complexity

Infotain-

ment

Power-

trainSafety

Interior/

Comfort

AI/

Sensing

3


Functional safety of autonomous vehicles can only be ensured through sensor fusion based on

redundant sensors; the number of sensors will thus significantly increase


▪ The vehicles’ ability to “see” and “hear” differs significantly, e.g.,

depending on weather conditions and daytime

▪ For functional safety, redundant sensors are required – redundancy

is also ensured by smart algorithms for safety-critical functions

Sensor fusion will be necessary to provide redundancy for autonomous

functions

4

Various types of sensors comprise the core of ADAS and

autonomous driving systems

1 Global Navigation Satellite System, e.g. using GPS 2 Comparison with other technologies not yet possible due to low maturity of technology

Long-range radar

LIDAR Camera

Short-/Medium range radar

Ultrasound GNSS1Infrared

Radar and camera most likely combination in next 5-8 years, although solid-

state LiDAR and camera2 will be dominant in the long-term when proven and

integrated into mass-production designs

Ultra-

sonic

LiDAR+

Camera

Radar+

LiDAR

Radar+

Camera

Cam-

era Radar LiDAR

Object detection

Distance estimation

Object edge precision

Lane tracking

Range of visibility

Functionality in bad

weather

Functionality in poor

lighting

Cost

Object classification

Production readiness

Good Fair Poor


“Four terabytes is the estimated amount of data that an autonomous car will generate in about an hour and a half of driving.” 1


5 Future system architectures will include intelligent and integrated sensors to manage the huge

amount of information required for Highly Automated Driving

1 Kathy Winter, Vice president and general manager of the Automated Driving Solutions Division at Intel Corporation

TODAY

Raw data sensors communicating unidirectional to multiple ECUs

Partially, but still limited pre-processing of data

Most likely scenario

▪ Unidirectional data flow from sensor to the system's main ECU

▪ Sensors send raw data into vehicle domain

▪ Architecture not capable of processing high amounts of data

ECU

ECU

Signal pre-

conditioning

Information

processing

A/D

converter

Signal pre-

conditioning

Information

processing

A/D

converter

Analog +

Digital signals

Sensor

Sensing

element

Sensor

Sensing

element

Data

transmission

FUTURE

Scenario 1

Smart sensors connected to several domain controllers

Scenario 2

Centralized control unit performing raw data fusion

▪ Raw data sensor sending all data to central control unit

▪ Real-time sensor data fusion enables real-time performance

▪ Cost reduction of the overall system

Sensor

Signal

pre-con-

ditioning

Informa-

tion pro-

cessing

Sensing

element

A/D con-

verter

Domain

Controller

Bus interface

Sensor fusion

Additional signal

conditioning

Digital signal

Bus

interface

Sensor

Signal

pre-con-

ditioning

Informa-

tion pro-

cessing

Sensing

element

A/D con-

verter

Bus

interface

Sensor

Central

Controller

Bus interface

Sensor fusion

Signal

conditioningDigital signal

Sensor

Sensing

elementA/D converter Bus interface

Sensing

elementA/D converter Bus interface Information

processing

Data

transmission

Data

transmission

▪ Highly integrated sensor component (sensing, processing, etc.)

▪ Only critical information is sent to centralized controller

▪ Pre-processing within sensor enables handling more data

▪ Reduced complexity of the overall architecture


Power and data networks will undergo significant changes in topology to ensure the

redundancy level demanded by Highly Automated Driving and safety features


6

Current architectures are insufficient for

future developments…

… and thus OEMs will deploy redundant, flexible, and smartly managed

power & data networks

▪ Future power networks to enable the introduction of x-by-wire functions

or HAD through fail-safe power supply functionality without additional

storage units

▪ Ring topology will likely become the default choice as it provides more

energy paths to safety-critical loads and requires less wiring circuits

than other alternative designs

▪ Modular power distribution units are positioned along the circuit and

provide load driving and monitoring; they also allow for fast detection

and system response

Redundant power networks

▪ Future networks to rely on switched Ethernet to ensure reliable inter-

domain communication

▪ Ring topology offers additional redundancy by duplicating links between

switching elements

▪ Real-time requirements to be satisfied through the addition of Ethernet

AVB and TSN to the default switched Ethernet network

Redundant data networks

The increase of power demand

due to electric powertrains, central

computers, and infotainment

solutions requires a rethinking of

power management networks

Stringent safety requirements

for HAD – support of fail

operational behavior in all

conditions – require redundant

power supply and communication

networks

Diagnostics and self-protection

mechanisms against random

failures and catastrophic events

are necessary


The future car will become a network on wheels – Ethernet is required to support the high data

rates and flexibility of new applications7FUTURE

Security challenges due to

different connection points

still need to be addressed

▪ Connectivity:

switches allow

connections to any

number of devices

▪ Flexibility in the

architectural design of

the future car

▪ Interoperability: can

be connected with

external network

▪ High bandwidth: vast

amount of data can be

communicated via

Ethernet

▪ Reduced cost: less

cabling required and

thus reduced weight

Ethernet as backbone in

addition to existing bus

systems, allowing for:

Cars will become

interconnected

Volume of

electronic

components

increases

In-car networks

connect multiple

domain systems

e.g., infotainment,

driver assist and

safety

Diagnostics and

services through

external interfaces

are required

Quality and

amount of sensor

signals grows and

thus higher data

rates to a

centralized

computer

The typical vehicle has a mixture of different bus types linked to central gateway:

TODAY

▪ Relatively low bandwidth and performance

▪ Limited scalability: adding sensors requires additional cabling and thus weight is added

… which currently do not fully support the requirements of HAD

Low-level

communicati

on systems,

e.g. mirror,

electric seats

Soft real-time

systems, e.g.

ABS,

powertrain

Hard real-

time systems,

e.g. steering,

safety

systems

Multimedia

interface,

Infotainment

Partially used

in infotainment,

radar

Typical

application

Electrical

(single wire)

Electrical

(twisted pair)

Optical,

electrical

Mainly optical Electrical (one

or more

twisted pair)

Physical

interconnect

20 kBit/s 1 MBit/s 10 Mbit/s 25 Mbit/s –

150 Mbit/s

100 Mbit/s – 1

Gbit/s

Ethernet

Bandwidth

!SOURCE: McKinsey


There are four general access points for car data and different data access strategies – we

believe the largest data sets will be accessible through the OEM backend by 2022

Accessibility for 3rd parties

Low High

TodayDescription 2022+Interfaces to access car data

▪ Data collection from licensed fleets in the

future

Fleet operator backend

▪ Integrated communication unit

developed for large fleet customers

▪ Data relevant for fleet operator

▪ Data access in collaboration project with

OEM or in return for revenue participation

▪ Data purchase in open marketplace

▪ Data availability through regulatory

decisions

OEM backend

▪ Full control by OEMs

▪ Largest functionality (e.g., incl.

return channel into car)

▪ Main access point for 3rd party solutions

today (e.g., through VOYO telematics

system)

▪ Use of OBD II dongles may be restricted in

the future due to security risks

OBD-II

▪ OBD-II port used for transmitting

data via aftermarket dongles

▪ No data access for 3rd partiesCar 2 X

▪ Car 2 X communication with

infrastructure

8

17McKinsey & CompanySOURCE: McKinsey & Company

Data sharing by multiple players is needed to pave the way for autonomous driving and further

innovative use cases that rely on data from different data sources Uplink Downlink9

…to be used for

HAD and further

services

Autonomous

driving

Pay per use

(e.g., on-

board

features)

Personalized

offers

…

Stream

videos

Pay how you

drive

Data outputs

… and processing will be done both locally and in the

cloud, with data flowing in both directions continuously

OEM Cloud processing

Sensor data used for further training HAD

models and other AI-based functions

Aggregate usage data for traffic optimization

Integrations with 3rd party personalized

services

Transmission

Sensor data transmitted in aggregated form

Sensitive vehicle and personal data

anonymized and transmitted via secure link

Vehicle API to standardize vehicle-to-OEM-

cloud data exchanges

Local processing

Sensor and camera data analyzed quickly for

HAD and time-critical safety functions

Vehicle usage and personal data used for

driving and infotainment optimization

(using local AI)

Various players upload data sets to the cloud…

Structured/unstructured data inputs

Data

Lake/Cloud

Satisfaction data

Transaction data

Vehicle dataComments on

FB page/website

App

contents

Insurance data

Social media

postings

Weather data

Traffic reports

Demographic

data

Traffic

light

control

Bank account

OEMs

App

providers

Governmental

agency

Meteorological

service

Customer

interaction

notes

Tier-1/2

suppliers

Service logsCar service/

Repair shop

Sales logsDealers

Concierge

services

providers

Financial

companies

Insurance

Social media

Automobile club

(ADAC)

Payment record


OTA updates are a prerequisite for HAD and require a significant change in the vehicle

architecture

SOURCE: McKinsey & Company, NXP

1 Store encrypted firmware updates until required along with rollback images

OTA capabilities are

partly in place for non-

critical functions

Further OTA updates

should expand on safety-

critical functions…

▪ Limited number of

vehicles can receive

updates over the air

▪ Established

manufacturers have only

used OTAs for non-

critical systems, i.e.,

infotainment and

telematics systems

▪ Fault in firmware for

critical functions requires

vehicles to be returned

to dealership

▪ OTA updates are

required to

– Unlock new features

– Ensure cybersecurity

– Fix bugs in software

quicker

– Provide a high level of

security

▪ Current vehicle

architecture does not

allow updates for ECUs

… and require significant adjustments

to vehicle architecture

New layer/functionality

10Uplink Downlink

Connectivity gateway

Central gateway

OEM OTA Cloud servers

ECU ECU ECU ECU

NAND

storage1

OTA manager

Cloud

Bi-directional communication

Control of

updates across

all ECUs, incl.

authentication of

incoming

updates,

scheduling and

communication

with backend as

well as instant

testing


Semiconductor companies stand to benefit from the architectural trends of the future car if they can

make the strategic shift to a software-centric industry dynamic


Implications for semiconductor companies Key strategic questions

▪ Wat is the required product portfolio of the future

going to look like?

▪ Which companies along the value chain do I need

to partner with? (e.g. connectivity players to

develop integrated solutions)

▪ What skills do I need to offer solutions with

embedded software?

▪ Which features are needed to allow for

differentiation from competitors (esp. in the area

of software and pre-processing of data)?

▪ Is standardization beneficial for me (open

standard vs. proprietary IP)? If yes, how can

existing solutions be standardized?

▪ Do I have the capabilities to extend the existing

portfolio towards higher stack levels?

Promote standardization of solutions across platforms

and systems on chips

Semiconductor industry is increasingly important for

the future automotive architecture, e.g. demand for

processing power rises

Speed is crucial and partnerships along the value

chain help to get access and to gain a deeper

understanding of the automotive industry

Hardware becomes commoditized - shift to software-

centric solutions necessary to achieve product

differentiation

Transition to DCUs offers differentiation potential

towards higher stack levels (e.g. applications and

middleware)

Documents

Automotive software and electrical/electronic (E/E ...€¦ · Automotive software and electrical/electronic (E/E) architecture of the future INTRODUCTION TO THE GSA MEMBERS Discussion