Post on 03-Oct-2020
WORKING DRAFT
Last Modified 12.06.2018 14:50 W. Europe Standard Time
Printed 12.06.2018 14:52 W. Europe Standard Time
McKinsey and Global Semiconductor Alliance | Munich, June 4 2018
Automotive Electronics Architecture
of the Future – Implications for semiconductor
companies
WORKSHOP DOCUMENT
CONFIDENTIAL AND PROPRIETARYAny use of this material without specific permission of McKinsey & Company is strictly prohibited
Last M
odifie
d 1
2.0
6.2
018 1
4:5
0 W
. Euro
pe S
tandard
Tim
eP
rinte
d 1
2.0
6.2
018 1
4:5
2 W
. Euro
pe S
tandard
Tim
e
2McKinsey & Company
Background and purpose of our workshops
Background: GSA-McKinsey cooperation
▪ Intensive research collaboration focusing on the
most relevant topics for the semiconductor industry
– The Internet of Things – opportunities and
challenges for semiconductor companies (2015)
– Security in the Internet of Things (2016)
▪ Project steering by GSA EMEA Executive Forum,
with knowledge input through interviews and
surveys by many industry players / GSA members
▪ Publications and wide industry dissemination
Current hot topic: automotive electronic and software trends – what does it mean for semiconductor companies?
▪ Recent developments and trends in automotive electronics
are on top of mind for many industry leaders and GSA
members
▪ Key challenges is that this is a deeply technical topic that
has significant strategic implications for many players
across the value chain
▪ In 2 workshops in November 2017, we discussed and
aligned on 10 hypotheses on the future technology
evolution of automotive electronics & software
▪ Goal of this workshop is to recap those trends and then
discuss the implications and learnings for incumbent
semiconductor companies
Last M
odifie
d 1
2.0
6.2
018 1
4:5
0 W
. Euro
pe S
tandard
Tim
eP
rinte
d 1
2.0
6.2
018 1
4:5
2 W
. Euro
pe S
tandard
Tim
e
3McKinsey & Company
Software is the core enabler for key automotive innovations in connectivity, autonomous driving,
electrification and diverse mobility and thus increasingly becomes a differentiating factor
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
Last M
odifie
d 1
2.0
6.2
018 1
4:5
0 W
. Euro
pe S
tandard
Tim
eP
rinte
d 1
2.0
6.2
018 1
4:5
2 W
. Euro
pe S
tandard
Tim
e
4McKinsey & Company
Increasing complexity in software is a key challenge for the automotive industry – modern
vehicle architecture has to be adjusted in order to manage complexity and quality
SOURCE: McKinsey & Company Analysis, IEEE "This Car Runs on Code"; HAWK; Automotive Electronics Initiative
Software lines of code (SLOC), millions
A modern car is a computer on wheels,
differentiated by the software features it offers
Already in the last years, software applications in vehicles have seen a dramatic increase in size and complexity…
…leading to significant quality issues caused by faulty software implementations
EXEMPLARY
▪ Recall of 1.9M hybrid cars
▪ Recall of 143,000 cars in the US
▪ Recall of 65,000 cars
▪ Recall of ~1.4M cars
▪ SW security flaw made cars vulnerable to hackers
▪ SW flaw may cause the hybrid system to shut down while driving
▪ Flaw in the continuously vari-able automatic transmission software may subject the drive pulley shaft to high stress
▪ SW flaw may cause vehicle doors to be unlatched
▪ Flaw in engine control unit SW may cause engine to stop while stopping at a traffic light
▪ Recall of ~3,000 cars
To ensure safety in increasing degrees of autonomy, software quality and complexity are a key challenge for the automotive industry, requiring a rethink today’s vehicle software and E/E architecture
~ 10
~150
20162015
~ 100
2010
x 1,5
x 10
Last M
odifie
d 1
2.0
6.2
018 1
4:5
0 W
. Euro
pe S
tandard
Tim
eP
rinte
d 1
2.0
6.2
018 1
4:5
2 W
. Euro
pe S
tandard
Tim
e
5McKinsey & 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 OEM
Auto soft-ware/SW environment supplier
Car electronics system supplier
Semi-conductor supplier
Integrationarchitects
FeaturesSW giants / Tech players
Hardware
Does not reflect non-embedded applications / software (e.g., cloud-based) that interacts with vehicle
Computing and connectivity players
Last M
odifie
d 1
2.0
6.2
018 1
4:5
0 W
. Euro
pe S
tandard
Tim
eP
rinte
d 1
2.0
6.2
018 1
4:5
2 W
. Euro
pe S
tandard
Tim
e
6McKinsey & Company
The vehicle architecture will become more 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 stack
Vehicle
Middleware layer/OS
E/E hardware2
UI/UX/HMI
Connectivity (back-haul)
Artificial intelligence / Advanced analytics
Sensors ActuatorsPower
components
Cloud platform
Applications1
FROM: Partially vertically
integrated architecture TO: Layered in-vehicle and backend architecture
Combine in-vehicle data with environmental data
Significant increase in number of applications, moving into a service-oriented architecture with interdependent services
Abstract applications from hardware
Analyze data for real-time decisions and autonomous driving
Modified layersNew layers
< >
Closely controlled add-on apps and modulesdue to safety reasons
Last M
odifie
d 1
2.0
6.2
018 1
4:5
0 W
. Euro
pe S
tandard
Tim
eP
rinte
d 1
2.0
6.2
018 1
4:5
2 W
. Euro
pe S
tandard
Tim
e
7McKinsey & Company
The E/E architecture has evolved from independent function – specific ECUs towards a
centralized architecture
Generation High-level architecture
Vehicle centralized E/E architecture
Domain centralizedE/E architecture
Distributed E/E architecture
Main features
2nd generation
▪ Collaboration of ECUs within one domain
▪ Domains: body/comfort, chassis, powertrain,and infotainment
▪ 3-4 independent networks
▪ Limited communication between domainsInfotainment
Body/comfort Chassis
Power-train
4th generation
▪ Central domain controller
▪ Ability to handle more complex functions, e.g. L3 HAD
▪ Consolidation of functions (cost optimization)
Domain controller
1st generation
▪ Independent ECUs
▪ Isolated functions
▪ Each function has its ECU (1:1 connection)
Today
3rd generation
▪ Stronger collaboration via central gateway
▪ Cross-functional connection
▪ Ability to handle complex functions, e.g. ACC
Central GW
5th generation
▪ Virtual domain
▪ Limited dedicated hardware
▪ Ethernet backbone
▪ High complex, high compute functions
▪ Suitable for L4-L5 HADSensor Actuator
Gateway
Infotain-ment
Focus of the document
Outlook
Last M
odifie
d 1
2.0
6.2
018 1
4:5
0 W
. Euro
pe S
tandard
Tim
eP
rinte
d 1
2.0
6.2
018 1
4:5
2 W
. Euro
pe S
tandard
Tim
e
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
5 Sensors will become more intelligent: Intelligence will likely move from ECUs into sensors. Future sensors can pre-process data for simple calculations, trigger actuators directly, and inform ECUs retrospectively about the actions – HAD will require central computing to connect sensors
1 ECUs are getting consolidated: Instead of a multitude of specific ECUs for specific functionalities, the industry will move to a consolidated vehicle architecture driven by costs, new market entrants, and demand from HAD – on the long-term, further virtualization will lead to more SW agnostic HW
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
Last M
odifie
d 1
2.0
6.2
018 1
4:5
0 W
. Euro
pe S
tandard
Tim
eP
rinte
d 1
2.0
6.2
018 1
4:5
2 W
. Euro
pe S
tandard
Tim
e
9McKinsey & Company
Potential disruptive developments – „what ifs“ and their implication for semiconductor companies
What if…
…OEMs significantly invest into capabilities around the right electronics hardware to specify chips in a way that they move to become their “own fabless” semicon supplier?
…Tier-1 suppliers make a decisive push to provide integrated ADAS/HAD systems fully commoditizing the underlying hardware?
…intelligence in a vehicle is truly centralized resulting in demand on semiconductors primarily for a central supercomputer while decentralized chipsets are almost fully substituted/reduced to very basic functionality?
…industry standardization of the hardware stack incl. virtualization leads to a commoditization of chips similar to PCs?
For discussion:
▪ How realistic would you see those
disruptive scenarios?
▪ How could semiconductor companies
setup themselfs to prepare for such
developments?