Automated Driving

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

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

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

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

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 !