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
SOURCE: McKinsey & Company
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
SOURCE: McKinsey & Company
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
SOURCE: McKinsey & Company
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
SOURCE: McKinsey & Company
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
11McKinsey & Company
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
12McKinsey & Company
Functional safety of autonomous vehicles can only be ensured through sensor fusion based on
redundant sensors; the number of sensors will thus significantly increase
SOURCE: McKinsey & Company
▪ 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
13McKinsey & Company
“Four terabytes is the estimated amount of data that an autonomous car will generate in about an hour and a half of driving.” 1
SOURCE: McKinsey & Company
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
14McKinsey & Company
Power and data networks will undergo significant changes in topology to ensure the
redundancy level demanded by Highly Automated Driving and safety features
SOURCE: McKinsey & Company
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
15McKinsey & Company
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
16McKinsey & Company
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
18McKinsey & Company
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
19McKinsey & Company
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
SOURCE: McKinsey & Company
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)