toyota-Challenges towards New Software Platform for Automated Driving.pdf

1. 9th Vector Congress 20th-21st Nov. 2018 Challenges towards New Software Platform for Automated Driving and High Computational ECU’s 1 Kenji Nishikawa, Kenji Hontani E/E Architecture Development Div. TOYOTA MOTOR CORPORATION

2. Introduction 2 Who am I ? Project General Manager @TOYOTA (E/E Architecture Development Div.) Engaged in In‐House Development of Chassis Control Systems (ESC, 4WS) 2 Times assigned to Toyota Motor Europe (Electronics Systems for European Vehicles) Responsible for Basic Software development for All Toyota Vehicles. Engaged in AUTOSAR activities and served as a Steering Committee Member from TOYOTA Developed AUTOSAR based BSW into All Toyota Vehicles Currently on second assignment from TOYOTA to IAI Corporation. Assistant Director at IAI, developing software for industrial robots.

3. Today’s Agenda 3 • TOYOTA E/E Architecture Evolution and Software Platform(BSW) • Technical Trends and Next Generation E/E Architecture • Challenges towards New Systems(CASE) Development • Summary

4. Technical Trends : E/E Architecture Technologies 4 Application 12PF 15PF 19PF 2XPF ePF BSW CAN-FD STEP1,2 STEP3 STEP4 Ethernet CS:TMC supply CS:Tier1 Self sourced Acceptance Test Conformance Test ADAS Connected Phase５ Phase4 SecOC Zone （Backbone NW） Overlay NW TSN AVB(gPTP) G－Book ETC T-CONNECT C-ACC BAC DBC ARXML VLAN E2E LAN・Power source Domain BigData Secure Boot ECU認証 SOA IoT HD BaseT Optical Ethernet CAN SD TSS オープン化 Standard Safety and Security High Speed Communication Cloud IDS/IDPS SOME/IP CAN-FD CAN OSEK NM AUTOSAR NM DoIP New vehicle state OTA1.0 （Ethernet, CAN-FD） KVM Business model OTA2.0 OTA3.0 OTA4.0

5. C C C C C C C C C C C C E/E Architecture Evolution 5 Layered LAN Central Gateway + Domain LAN Computing Platform A C C C C C C A A FR FL RR RL C C C C A A A A Computing Platform++ N A C Adaptive Classic legends Non-AUTOSAR N N N Online cloud Online cloud Offline cloud A C C C C Simple LAN LAN P2P E/E Architecture evolved in order to meet  Complex System Requirement  Development effort reduction Connected ECUʼs utilize Common Software Platform (Basic Software)

6. Toyota E/E Architecture Evolution and AUTOSAR BSW migration 6 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21～ STEP1 [for powertrain & chassis domain] STEP3 [Step1 & 2 unified] [TOYOTA BSW Specification] [Standard compliance] [E/E Architecture] 06PF 08PF 10PF 12PF 15PF 19PF Standardize requirement STEP2 [for body domain] DECSTAR1 DECSTAR2 CANARY SPF R1.2(10SPF) SPF R1.0(06SPF) SPF R1.1(08SPF) CS-Light SPF R1.3 OSEK TOYOTA proprietary requirement partially AUTOSAR Compliant STEP4 [full AUTOSAR compliant] CCS t-CORE [TOYOTA standard BSWs]

7. 7 Proprietary Specification Benefit of AUTOSAR Standard BSW Tier1 BSW Incorporating Toyota Spec. Toyota BSW Implementation Effort Spec. Reviews Q&A Test Result Reviews CCS Development Effort SPF R1.0 Decstar1 Decstar2 Canary BSW Stacks Standard BSW Development Effort SPF R1.0 TOYOTA Proprietary Spec. AUTOSAR Based Spec. t-CORE Shift to AUTOSAR BSW HW μC Basic Software Standard I/F Apl Apl Apl Apl Standard Specification Proprietary Software Standard Software Common understanding of Spec.(Functions) Common usage of Implementations Split & Share of Responsibility between OEM, Tier1, Tier2

8. 8 ◆TOYOTA standard BSW with full AUTOSAR compliance ◆Support TNGA (TOYOTA New Global Architecture) requirement ◆More than 82 ECU, 27 Tier-1 Projects (including in-house development) ◆Business model for efficient Software development (BSW: Global BSW Vender, Application:OEM) t-CORE

10. Modular approach creates Many Variants System / Software become too Large (Cross Domain Functionality) Tier‐1 Development Process need to be Agile (streamlined product line strategy) OEM has to cope with 1) “large variant set” (including smaller vehicle) 2) “systems’ engineering” for global optimization 3) short sprint release “repeatedly” Technical Trends : Development Process 10 Potential measure on E/E Architecture 1) Open System (on demand) 2) Centralization 3) Frequent Update (OTA)

11. C C C C C C C C C C C C E/E Architecture Evolution 11 Layered LAN Central Gateway + Domain LAN Computing Platform A C C C C C C A A FR FL RR RL C C C C A A A A Computing Platform++ N A C Adaptive Classic legends Non-AUTOSAR N N N Online cloud Online cloud Offline cloud A C C C C Simple LAN LAN P2P E/E Architecture may need  Central ECU  Brain ECU Functions could be distributed to Zone ECU Added value Commodity

12. 12 Future E/E Architecture: Central & Zone Concept Current Architecture (Domain based) Next Gen. (Central and Zone) Physical Impact image on change Power ①Dedicated, additional wire and route required ①Minimized wire under Zone Network ②Dedicated, additional wire and route required ③Negotiation effort on network design ②Minimized wire under Zone ③Localized change (i.e. comm. matrix) Mounting ④Redesign on additional ECU ④Spared space for additional ECU Logical ⑤Software changes on distributed ECUs ⑤Software change only on Central ECU CGW J/B ⑤ ⑤ Zone ECU I/O Sensor Act. Sensor Act. … HUB MCU New feature Act. New feature Smart Act. ④ Act. ④ ① ② ③ Central ECU SWC Ａ SWC Ｂ SWC Ｃ ⑤ ⑤ Central ECU Zonal ECU No space Less extendibility Few vehicle coverage Heavy weight ⑤ Central & Zone Concept is recognized as ultimate goal of Physical E/E Architecture ① ② ② ② ③ ③ ③ ④ ④ Goal: Cost down by ECU integration Goal: Easy software plugin Goal: Localize physical changes Space Mirgin Extendable High # vehicle coverage Light weight

13. C C C C C C C C C C C C E/E Architecture Evolution 13 Layered LAN Central Gateway + Domain LAN Computing Platform A C C C C C C A A N A C Adaptive Classic legends Non-AUTOSAR N N Online cloud Simple LAN LAN P2P Open question : • how to migrate toward Central & Zone Architecture • Timelines for Introduction FR FL RR RL C C C C A A A A Computing Platform++ N Online cloud Offline cloud A C C C C ?

14. 14 A Possible Migration Scenario Cost Speed (Time to market) Flexibility Development Deployment Hardware consolidation C C C C C C C C C C C C Central Gateway + Domain Brains overlay A C A N N Online cloud FR FL RR RL C C C C A A A A A A A A Offline cloud N Online cloud Offline cloud A Brains + Domain Master Localize OTA change Introduction of New Applications may become a Driving Force AI Autonomous EV (Regulation in various countries) MaaS service C C C C C C A A A N N Online cloud Car Share Connected

16. Application Driver for Future E/E Architecture : CASE 16 Powertrain / Chassis ADAS Body Infotainment Size / Complexity Electrification Source : chargedevs.com OEM Vehicle as a part of IoT Connected Lv3, Lv4, … Autonomous Source : Morgan Stanley Research chargedevs.com Shared

17. 17 Let’s have a brief look at the actual development status

18. 18 Highway Automated Driving System

19. 19 It seems to be working well….

20. 20 How to Validate/Verify the System … Globaly 142 Billion Km(on road test) Necessary for Full AutoDriving May take 2700years (Avr Spd 60Km/h) Total Road Extension (Global) ≒36 Million km （Calculated from 2013 World Factbook） Comprehensive Validation is Necessary Test Cases should cover all the Roads Globally =>Condensed/Compressed Validation Method Necessary 走行軌跡

21. 21 e.g. Merging on highway (Ariake IC) Result from MILS evaluation Ego Vehicle Other Vehicle 80 Speed of Other Vehicle Distance to Other Vehicle ○ ○ －－－－－－－ ○ ○ －－－－－－－ ○ ○ ○ ○ －－－－－ ○ ○ ○ ○ －－－－－ ○ ○ ○ ○ ○ ○ －－－ ○ ○ ○ ○ ○ ○ －－－ ○ ○ ○ ○ ○ ○ －－－ ○ ○ ○ △ ○ ○ ○ ○ － ○ ○ ○ ○ △ ○ ○ ○ ○ ○ ○ ○ ○ ○ △ ○ ○ ○ －－ ○ ○ ○ × △ ○ ○ －－ ○ ○ ○ ○ × ○ ○ －－－－ ○ ○ × △ ○ －－－－ ○ ○ × × △ －－－－－－ ○ × × －－－－－－ ○ ○ ○ －－－－－－ ○ ○ ○ －－－－－－－－ ○ Successfully merged in front Successfully merged in behind Utilize to develop algorithm for Planning/Control performance Simulation is effective for matrix-style verification (Automatic, Re-usable, Rare scene) Behind Front Conflict Accumulated Data and Simulation is the key for Verification coverage Backlight Road-surface reflection Utilizing Virtual Environment for Verification Coverage Verifying "Planning/Control" Verifying "Recognition" Utilizing computer graphics images

22. 22 Driving Scene in Backlight

23. 23 e.g. Merging on highway (Ariake IC) Result from MILS evaluation Ego Vehicle Other Vehicle 80 Speed of Other Vehicle Distance to Other Vehicle ○ ○ －－－－－－－ ○ ○ －－－－－－－ ○ ○ ○ ○ －－－－－ ○ ○ ○ ○ －－－－－ ○ ○ ○ ○ ○ ○ －－－ ○ ○ ○ ○ ○ ○ －－－ ○ ○ ○ ○ ○ ○ －－－ ○ ○ ○ △ ○ ○ ○ ○ － ○ ○ ○ ○ △ ○ ○ ○ ○ ○ ○ ○ ○ ○ △ ○ ○ ○ －－ ○ ○ ○ × △ ○ ○ －－ ○ ○ ○ ○ × ○ ○ －－－－ ○ ○ × △ ○ －－－－ ○ ○ × × △ －－－－－－ ○ × × －－－－－－ ○ ○ ○ －－－－－－ ○ ○ ○ －－－－－－－－ ○ Successfully merged in front Successfully merged in behind Utilize to develop algorithm for Planning/Control performance Simulation is effective for matrix-style verification (Automatic, Re-usable, Rare scene) Behind Front Conflict Accumulated Data and Simulation is the key for Verification coverage Backlight Road-surface reflection Verifying "Planning/Control" Verifying "Recognition" Utilizing computer graphics images Utilizing Virtual Environment for Verification Coverage

24. 24 Scaling Computational Power Research Pre-development Development & Series Production Functionality Checked Real-Time, Performance Checked Deployment ready e.g. Deep learning server e.g. Voice recognition Application Application Application e.g. trunk server Central Unit getting closer Enabling Technologies for CASE Systems Development backend onboard Optimize Hardware update Same Functionality between different Computing Platforms Virtual Environment (PC base) Mass Production ECU

25. Enabling Technologies for CASE Systems Development 25 APP (IVI) APP (ADAS) AI APP (deep learning) Computing unit for frequently changing software Stable I/F Stable I/F Cloud APP (edge computing) APP (ADAS) e.g. 10ms APP (AD) e.g. 100ms APP (IVI) APP (AI) APP (Cloud) e.g. 1000ms Software Update (C++) Decision making AI IVI OEM Tier‐1 Tier‐1 Tier‐2 C C C C C C C C A C N Key software (for OEM) may be executed on adaptive PF. Scalable software (extended features) are located at central ECU Split & Share of Responsibility between OEM, Tier1, Tier2

26. Summary 26 • E/E Architecture May Evolve to Central & Zone Conept • Migration from Domanin LAN Architecture my be enabled by Adapting CASE Systems into the Architecture • Verification & Validation of CASE System only possible with utilization of Vertual Technology • Software Platform (Adaptive AUTOSAR) must support same functionality between Virtual Environment to Mass Production ECU’s • Work Split & Share between OEM, Tier1, Tier2 essential for the success of Future Software Platform and E/E Architecture

27. 27 Thank you very much for your attention !

toyota-Challenges towards New Software Platform for Automated Driving.pdf

Du liest eine Vorschau.

Hier ansehen

toyota-Challenges towards New Software Platform for Automated Driving.pdf

Weitere Verwandte Inhalte

Ähnlich wie toyota-Challenges towards New Software Platform for Automated Driving.pdf (20)

Weitere von xmumiao (8)

Aktuellste (20)