![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](https://image.slidesharecdn.com/identifyingtherightpathforwardforfuturevehicleeearchitecture-trainingpresentation-230127123339-8e126db5/85/Identifying-the-Right-Path-Forward-for-Future-Vehicle-EE-Architecture-Training-Presentation-pdf-6-320.jpg)
Identifying the Right Path Forward for Future Vehicle EE Architecture - Training Presentation.pdf
- 1. PUBLIC NXP, THE NXP LOGO AND NXP SECURE CONNECTIONS FOR A SMARTER WORLD ARE TRADEMARKS OF NXP B.V. ALL OTHER PRODUCT OR SERVICE NAMES ARE THE PROPERTY OF THEIR RESPECTIVE OWNERS. © 2021 NXP B.V. J U N E 2 0 2 1 Francesco Sindaco Director of Strategy and Business Development, Product Line In-Vehicle Networking IDENTIFYING THE RIGHT PATH FORWARD FOR FUTURE VEHICLE EE ARCHITECTURE
- 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
- 13. 1 2 PUBLIC VEHICLE TRANSFORMATION ARCHITECTURAL PATHS TRANSFORMATION STEPS
- 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)
- 28. 2 7 PUBLIC VEHICLE TRANSFORMATION ARCHITECTURAL PATHS TRANSFORMATION STEPS FINAL MESSAGES
- 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
- 34. 3 3 PUBLIC NXP, THE NXP LOGO AND NXP SECURE CONNECTIONS FOR A SMARTER WORLD ARE TRADEMARKS OF NXP B.V. ALL OTHER PRODUCT OR SERVICE NAMES ARE THE PROPERTY OF THEIR RESPECTIVE OWNERS. © 2021 NXP B.V. SHOWROOM.NXP.COM