4. 3
PUBLIC
ONE CAR, DIFFERENT MISSIONS & TECHNOLOGY EVOLUTIONS
T H E E L E C T R I C
V E H I C L E
T H E S E R V I C E
O R I E N T E D C A R
T H E A U T O M A T E D
D R I V I N G C A R
Update, customize, reconfigure
Hardware virtualization
Safe hyper-connectivity
Be conscious, decide, learn
Mega sensing + processing
New infrastructures
Transport at top efficiency
New infrastructures
Battery technology
5. 4
PUBLIC
THREE STEPS: OPTIMIZE COSTS, NEW E/E, MANAGE CONSTRAINTS
IN ORDER TO MAKE ELECTRIC, AUTOMATED AND SERVICE ORIENTED CARS POSSIBLE,
OEMS HAVE TO:
O P T I M I Z E C O S T S I N
I N E F F I C I E N T A R E A S ,
R E L E A S I N G V A L U E
R E - I N V E S T I N
E L E C T R I C / E L E C T R O N I C S
A R C H I T E C T U R E S F I T T I N G
N E W M I S S I O N S
A L L T H A T , D E A L I N G W I T H
R E A L - W O R L D
C O N S T R A I N T S
Optimize
costs
Fit E/E architectures
to new missions
Reduce SW/HW diversity,
decrease number of modules
Simplify and lighten wiring harness
Lighten, speed up innovation cycle
for new features
EV re-think power and torque
distribution
AD enable fully redundant and
secured car systems
SO provide car functions as
shared services
Manage real-world
constraints
Cost, risk & expertise to migrate
legacy systems
Scalability required to address fleet
of vehicles
Organizational boundaries
6. 5
PUBLIC
HOW DO CAR ARCHITECTS PROCEED?
Start by re-distributing functions
• Hierarchize: layer duties (strategy, real time, I/O process)
• Cluster: merge functions, blend SW platforms and OS
• Virtualize: from specialized HW to cloud-connected servers
[The LOGICAL path]
Body Drivetrain ADAS IVI
Body
strategy
Drivetrain
strategy
ADAS
strategy
Real
Time
I/Os
IVI strategy
[The PHYSICAL path]
…then, connect them better
• Zonalize: optimize harness + connectors
• Engineer: introduce TSN for overlapped data traffic
• Toughen: E2E security and safety for distributed apps
Domain Wiring Zonal Wiring
8. 7
PUBLIC
STEP-1: INTRODUCING DOMAINS
INEFFICIENT IN SW&HW
UNFIT TO FUTURE MISSIONS
Reduced module count and
SW diversity lower cost to
build & maintain vehicle
platforms
Fast, lighter innovation cycle
FuSa, Cybersec, FOTA
Safer, more secure EE
facilitating path to AD L3+
Super-complex central
modules
Longer, heavier wiring
harness
Challenges
TODAY | FLAT
ADAS & HIGHLY
AUTOMATED DRIVING
POWERTRAIN &
VEHICLE DYNAMICS
BODY & COMFORT
INFOTAINMENT &
IN-VEHICLE
EXPERIENCE
CONNECTIVITY
SERVICE
ORIENTED
GATEWAY
DOMAIN
CONTROLLER
DOMAIN
CONTROLLER
DOMAIN
CONTROLLER
DOMAIN
CONTROLLER
DOMAIN
CONTROLLER
PURPOSE OPTIMIZING SOFTWARE
MISSIONS FACILITATING AD
LOGICAL RESTRUCTURE | DOMAINS
202025
GW
Benefits
9. 8
PUBLIC
POWERTRAIN &
VEHICLE DYNAMICS
BODY & COMFORT
INFOTAINMENT &
IN-VEHICLE
EXPERIENCE
CONNECTIVITY
SERVICE
ORIENTED
GATEWAY
DOMAIN
CONTROLLER
DOMAIN
CONTROLLER
DOMAIN
CONTROLLER
DOMAIN
CONTROLLER
DOMAIN
CONTROLLER
PURPOSE OPTIMIZING SOFTWARE
MISSIONS FACILITATING AD
LOGICAL RESTRUCTURE | DOMAINS
STEP-2: INTRODUCING ZONES
Challenges
Benefits
202535
Strongly improved wire cost,
weight and manufacturing
Efficient power distribution
enabled
Functions stepwise virtualized
simplified center ECUs
clustered end modules
Facilitate path to SO
Safety + security defined at
vehicle level tougher
ADAS crashing backbone
cost and complexity
PURPOSE OPTIMIZING WIRING
MISSIONS FACILITATING SO
ADAS & HIGHLY
AUTOMATED DRIVING
PHYSICAL RESTRUCTURE | ZONES
10. 9
PUBLIC
THE INTERMEDIATE STEP: HYBRID ARCHITECTURE
Body, then
Drivetrain
mature, less critical systems
are zonalized first
ADAS kept
separate
due to bandwidth, evolution
and safety concerns
IVI + Connectivity
kept separate
due to bandwidth, diversity
and security concerns
ONLY WHEN tech maturity,
risks and costs allow, all
domains will be zonalized
ZONAL
MODULE
ZONAL
MODULE
ZONAL
MODULE
ZONAL
MODULE
ADAS
IVI
Vehicle
Computer
(basic car
functions)
11. 1 0
PUBLIC
Flat Domain Clustered Domain Full Centralized
Flat Zonalized Hybrid Zonal Full Zonal Distributed Zonal
CARMAKER-F
CARMAKERS-A, B, C, D
Logical Path
Physical
Path
CARMAKER-E
12. 1 1
PUBLIC
THE MAIN EVOLUTION TREND: TWO WAVES, ON LOGICAL AND PHYSICAL PAT HS
Zonalized core
networks
ADAS+IVI blended
into zones
Multi-domain edge
aggregators
Multi-domain
vehicle computer
Distributing virtual
tasks
IP-based service
orientation
Body sub-
aggregators
Logical Path
Physical Path
MY22 - Domain EE
Logical: domain
Physical: dedicated
networks
MY26 - Hybrid Zonal EE
Logical: multi-domain
Physical: zonal + dedicated
networks
MY30 - Zonal EE
Logical: virtualized domain
Physical: zonal networks
14. 1 3
PUBLIC
FOUR STEPS TO RE-STRUCTURE A CAR
DISTRIBUTE THE FUNCTIONS
DEFINE THE BACKBONE
DEFINE ZONAL MODULES
DEFINE END-NODE CONNECTIVITY
1
2
3
4
CENTRAL
BRAIN(S)
ZONAL
MODULE
ZONAL
MODULE
ZONAL
MODULE
ZONAL
MODULE
15. 1 4
PUBLIC
FOUR STEPS TO RE-STRUCTURE A CAR
DISTRIBUTE THE FUNCTIONS
DEFINE THE BACKBONE
DEFINE ZONAL MODULES
DEFINE END-NODE CONNECTIVITY
1
2
3
4
CENTRAL
BRAIN(S)
ZONAL
MODULE
ZONAL
MODULE
ZONAL
MODULE
ZONAL
MODULE
16. 1 5
PUBLIC
FUNCTIONAL DISTRIBUTION: STRATEGY VS. I/O CONTROL
TRADITIONAL
DOMAIN
CONTROLLER
FULLY
DISTRIBUTED SYSTEM
PARTIALLY DISTRIBUTED
SYSTEM
F
F
F
F
e.g. Propulsion DC
(Energy planning)
e.g. Braking /
Engine Control
F
F
F
F
F
F F
F
F
e.g. Body Strategy
(“Lighting scheme”)
Multi-app
I/O controller
(e.g. drive
LEDs,PWMs)
F F
G
F F F e.g. Body Strategy
(“Lighting scheme”)
F F F
G
F F F
G Multi-app
I/O controller
(e.g. drive
LEDs,PWMs)
F F F
Traditional view:
• Flat collection of function
specific ECUs
• Combination of strategy
(service) & I/O control (signal)
Domain view:
• Domain controller provides functional
co-ordination
• Strategy partitioned on different levels
- Top level - more strategy (service)
- 2nd level - more I/O control (signal)
Full Distributed view:
• All strategy moves to top level
(service)
• 2nd level becomes generic signal
oriented services (smart IO controller)
• Top level functions evolve at quicker
pace than rest of system
Partially Distributed view:
• Distribute as much as possible,
strategy to top level, generic signal
oriented ECUs to the edge
• Complex signal functions may require
function specific ECUs.
• E.g. Engine vs Lighting control
F
Function
Specific G Generic
I/O control
strategy
17. 1 6
PUBLIC
FUNCTIONAL DISTRIBUTION AND ZONALIZATION
tunnel
CAN
sense
think
act
sense
think
act
distribute
sense
act
think
CAN
sense
think
act
Option-2: zonalize wires, distribute/centralize functions
• Logical path: split functions between strategy and I/O control,
move strategic part from edge to center
• Physical path: introduce backbone, convert CAN to IP services
• Benefit: setup a flexible, distributed system
• Challenges: re-code applications, re-structure communication
PROGRESSIVELY, ALL APPS WILL MIGRATE TO
OPTION-2, BUT TRANSITION WILL BE LONG
Option-1: zonalize wires, keep traditional functions
• Logical path: no change
• Physical path: introduce backbone, tunnel CAN-into-Ethernet
• Benefit: car re-wire preserving legacy ECUs (no HW/SW change)
• Challenges: preserve apps across tunneling
18. 1 7
PUBLIC
ZONAL COMMUNICATION EVOLUTION: FROM SIGNAL TO SERVICE
LIN
LIN
CAN
FD
CAN
FD
CAN
FD
CAN
FD
PDU
1
Zone-1 Zone-2
TUNNEL
TUNNEL
TUNNEL
LIN
LIN
CAN
FD
CAN
XL
10B
T1S
CAN
FD
2
Zone-1 Zone-2
3
LIN
LIN
10B
T1S
10B
T1S
10B
T1S
CAN
XL
Zone-1 Zone-2
SERVICE
TUNNEL
SWITCH
ABSTRACT
TUNNEL
TUNNEL
SWITCH
ABSTRACT
Pure tunneling
- Save cable
- Create infrastructure
Add service abstraction
- Enable services
- Preserve legacy apps
IP server IP server
Full HW virtualization
- All functions as services
- Almost full E2E IP
Zone-A Zone-B
PDU
SERVICE
SERVICE
SERVICE
SERVICE
Center ECU Center ECU
Zone-A Zone-B Zone-A Zone-B
19. 1 8
PUBLIC
FOUR STEPS TO RE-STRUCTURE A CAR
DISTRIBUTE THE FUNCTIONS
DEFINE THE BACKBONE
DEFINE ZONAL MODULES
DEFINE END-NODE CONNECTIVITY
1
2
3
4
CENTRAL
BRAIN(S)
ZONAL
MODULE
ZONAL
MODULE
ZONAL
MODULE
ZONAL
MODULE
20. 1 9
PUBLIC
HOW TO DEFINE THE ETHERNET BACKBONE
ring/double ring
star
tree
mesh
STEP-1: define topology, bandwidth
• Topology: redundancy vs. cost (cables, # of zones)
• Bandwidth: depends on choice of zonalized domains
• 100Mb (only body) 10Gb+ (all domains)
• Challenge: accommodating ADAS L3+
• ADAS would explode Speed, ASIL & Sec costs and risks
• first OEM choice: no ADAS on backbone
IEEE802.1Qci
Stream policing
IEEE802.1CB
Redundant path
IEEE802.1Qbv
Traffic scheduling
IEEE802.1AE (cg)
(E2E) MACsec
IEEE802.1AS2020
Redundant timing
Relay
Relay
Relay Relay
Relay
Relay
STEP-2: traffic engineering + safety + security
• Mix of critical/non-critical traffic needing determinism and
bounded latency, with no packet loss
• Network engineered + synchronized by TSN switches
• Security defined by cost and system trade-offs between
distributed (authentication-based) or centralized
(firewall-based)
21. 2 0
PUBLIC
FOUR STEPS TO RE-STRUCTURE A CAR
DISTRIBUTE THE FUNCTIONS
DEFINE THE BACKBONE
DEFINE ZONAL MODULES
DEFINE END-NODE CONNECTIVITY
1
2
3
4
CENTRAL
BRAIN(S)
ZONAL
MODULE
ZONAL
MODULE
ZONAL
MODULE
ZONAL
MODULE
22. 2 1
PUBLIC
KEY FUNCTIONS OF ZONAL MODULES – A WIDE SPAN OF CHOICES
Advanced Network
Management
Traffic
Processing
Data analysis/ processing,
Sec service/Complicated OTA
Traffic
Controlling
(+CAN Broadcasting,
Basic OTA)
Edge node
bridging
(CAN/LIN/100M ethernet
data aggregation)
Full
Domain Control
ADAS or IVI
processing
ADAS or IVI
pre-processing
Body or Chassis
processing
Body I/O control
(Edge node RT ctrl of Door
/lighting /Audio etc )
Multi Domain
I/O control
(Body + Chassis
RT control)
Basic I/O control
I/O control and
power mgmt
(Body + Chassis RT ctrl +
eFuses)
High speed
1Gb Backbone
Mid speed
CAN, LIN 10BT1S
100Mb backbone
Ultra High speed
10Gb Backbone
Hybrid High speed
1Gb Backbone
SerDes Hub
Connectivity Network Control Real Time Control App + Service Mgmt
23. 2 2
PUBLIC
ZONAL MODULES: MAIN CLUSTERS AS OF TODAY
ZONAL PROCESSOR
ZONAL CONTROLLER
ZONAL AGGREGATOR
TSN Switch
Adv GW functions
TSN Switch
Base GW functions
Traffic Management + Real Time Processing
Advanced Network Processing
App Process + Services
TSN Switch
GW functions
OnRamp-Multi Gb
OnRamp-Gb
OnRamp-100Mb
OnRamp-100Mb
Body I/O Control Body I/O Control Body I/O Control
OnRamp-Gb
Multi-dom I/O Control
TSN Switch
App processing
24. 2 3
PUBLIC
ZONAL ARCHITECTURES – FEW EXAMPLES
Front
Cabin
Rear
RL
RR
FR
FL
VC
FR RR
RL
RR
FR
FL
VC
ADAS
FL RR
FR
Roof
Door
Door
Door
Door
BCM/
BDU
FL
Trunk
BCM/
BDU
Front +
Motion
Rear
+ IVI
RL
RR
FR
FL
Cabin
+ BCM
ADAS
Roof
Zonal Processors
Zonal Controllers
Zonal Aggregators
Body Domain
Zonalization
Geographic
Aggregation
Zonalization +
ADAS Streaming
Zonalization +
Domain Processing
BCM = body controller module
BDU = body domain unit
VC = Vehicle computer
25. 2 4
PUBLIC
FOUR STEPS TO RE-STRUCTURE A CAR
DISTRIBUTE THE FUNCTIONS
DEFINE THE BACKBONE
DEFINE ZONAL MODULES
DEFINE END-NODE CONNECTIVITY
1
2
3
4
CENTRAL
BRAIN(S)
ZONAL
MODULE
ZONAL
MODULE
ZONAL
MODULE
ZONAL
MODULE
26. 2 5
PUBLIC
END-NODE CONNECTIVITY: VISION VS. REALITY
Choice of zonal bus
Prioritizing HW
virtualization
Mixing ASIL levels in zones
properly
Choice of proper end-node
MCU
Managing zonal ECU
generations
Bringing security to end-
nodes
Some Real Life Challenges
Starting situation:
a variety of legacy
standards inside
the zone
The ideal end-point:
E2E IP, less ECUs, no
more gateways, easy
service abstraction
THE VISION
CENTER
END-NODES CLUSTERED END NODES
AUDIO
AUDIO
AUDIO
CAN
100BT1
CAN
CAN
LIN
10BT1S
100BT1
CAN
CAN
XL
LIN
Zonal ECU
OnRamp / SOA
Zonal ECU
OnRamp / SOA
10BT1S
100BT1
LIN
10BT1S
CAN
XL
Zonal ECU
OnRamp
100BT1
10BT1S
CAN
XL
10BT1S
?
27. 2 6
PUBLIC
END-NODE CONNECTIVITY: TWO POSSIBLE OPTIONS FOR E2E IP
App-A
App-D
App-L
ADAS
pre-
process
100/1000BT1
Backbone
Zonal Module
(switch+apps)
App-C
App-A
App-B
App-D
Zonal I/O
controllers
10BASE-T1S
(100Mb scalable)
PWM
switch
sensor
LED
RADAR
Camera
LIDAR
App-L
App-G
App-G
App-H
sensor
switch
PWM
sensor
ADAS Sensors
Multi-Gb 10BASE-T1S
App-A
App-D
App-L
ADAS
pre-
process
Zonal Module
(switch+apps)
XL OnRamp
RADAR
Camera
LIDAR
ADAS Sensors
Multi-Gb
App-A
App-D
App-B
App-C
Sensor
switch
PWM
sensor
IP-over-CAN XL
• Standardized edge nodes
• No multi-drop hassles
• Smooth HW/SW evolution
• Cable-optimized
Identical at Higher Layers
• E2E IP applications
• Fully distributed systems
• Service generated at edge
Physically, very different
App-G
App-G
App-H
App-L
PWM
switch
sensor
LED
Legacy bus New bus
optional optional
10Mb CAN (wake-up) 100/1000BT1
Backbone
10Mb CAN (wake-up)
29. 2 8
PUBLIC
CENTRAL
BRAIN(S)
ZONAL
MODULE
ZONAL
MODULE
ZONAL
MODULE
ZONAL
MODULE
Maintain isolation while
functions get distributed and
traffic is mixed
Fast startup, low power and
strong failsafe distribution
Managing the evolution of
legacy SW into a SOA-based,
virtualized-HW EE
Re-structure communication
across the network, mixing
local broadcast CAN with
backbone unicast Ethernet
Preserve bounded latency
while re-wiring traffic over
multi-hop networks
Do all that with a mid-term
positive cost-benefit balance:
scalable, upgradable
Configuring a multi-bridge,
synchronized network, with
strong redundancy
Communication
Latency vs. busload
Time awareness
Isolation
Timing + Power Mgmt
SW migration
Sustainability
Provide an evolutionary path
inside zone, from signal-
based legacy to SOA
SOA and E2E IP
RE-STRUCTURING CARS: MAIN OEM CHALLENGES
30. 2 9
PUBLIC
NXP MISSION: PROVIDE SOLUTIONS FOR ALL ZONAL HOT SPOTS
On Zonal Modules:
provide full spectrum of solutions
On Ethernet Backbone:
provide zonal-optimized switches
In the Zones:
future-proof portfolio
On Full Architecture:
provide unrivaled, full range competence
Focus
Products
S32G/K
SJA1110
Secure
CAN
SJA1124
PMICs
eSwitch
Focus
Products
S32K
SIC CAN
10BT1S
CAN XL
FSBCs
Focus
Products
SJA1110
family
Full
TSN
ASIL B
Strong
TCAM
+ + SoC
synergy
+
CAN XL
10BTS bus
systems
Ethernet
Traffic Eng
System
Safety
+ +
System
Security
+
Mature ref.
designs
e.g. RDB
+
Zonal
ECU
End
node
10Mb-fit
Safe, Secure
Signal-improved
IP-compliant
31. 3 0
PUBLIC
OUR STORY IN A NUTSHELL
1
2
3
4
5
6 NXP will enable OEM migration with a holistic view and portfolio, providing solutions for each migration sub-step.
Key areas: zonal ECUs, CAN + Ethernet, safety and security, traffic engineering, distributed systems
Vehicle architectural transformation is radical, and involves both the nature of functions, how they’re assigned,
distributed, and finally connected together
Ultimate OEM goal is to release value presently used inefficiently, re-investing on new architectures which fit to
future car missions Electric Vehicle, Auto Drive, Service Oriented
Car architects work on two parallel paths, to logically re-partition functions and physically re-wire them, to
sustainably migrate from HW-specific, signal-based to HW-agnostic, service-based architectures
Ideally best fitting E/E is a zonally-wired architecture, with an external shell of standard I/Os connected via zonal
controllers and Ethernet backbone to central, multi-domain ECU(s) running virtual machines
Several intermediate steps will appear, to gradually blend ADAS and IVI into the new architecture
32. 3 1
PUBLIC
We recommend you
follow these classes:
• Electronics Innovation Enabling Vehicle
Evolution
• Zonal Communication Network Solutions
• The Next Automotive Networks: ASA
SerDes Links, 10BASE-T1S and CAN XL
• Trends for Audio and Radio Processing in
Zonal Vehicle Architectures
33. 3 2
PUBLIC
40+ VIRTUAL DEMOS
Focus on system solutions
Set up along NXP verticals
JOURNEYS BY DESIRED ENGAGEMENT
Self-guided tour
Live-streaming at set times
Guided tours
JOURNEYS BY DESIRED FOCUS
Edge & AI/ML
Safety & Security
Connectivity
Analog
SHOWROOM.NXP.COM