Challenges Towards New Software Platforms for Automated ... · TOYOTA standard BSW with full...

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

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 TOYOTADeveloped 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.

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

Technical Trends : E/E Architecture Technologies 4Application

12PF 15PF 19PF 2XPF

ePF

BSW

CAN-FD

STEP1,2STEP3

STEP4

Ethernet

CS:TMC supplyCS:Tier1 Self sourced

Acceptance TestConformance Test

ADASConnected

Phase５

Phase4

SecOC

Zone（Backbone NW）

Overlay NW

TSN

AVB(gPTP)

G－Book

ETC

T-CONNECTC-ACC BAC

DBC

ARXML

VLAN

E2E

LAN・Power source

Domain

BigData

Secure Boot

ECU認証

SOAIoT

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

C C

C C

C C

C C

C C

C C

E/E Architecture Evolution 5

Layered LAN Central Gateway+ Domain LAN

ComputingPlatform

A

C C C

CC

C AA

FR

FL

RR

RL

C

C

C

C

AA

A

A

ComputingPlatform++

N

A

C

Adaptive

Classic

legends

Non-AUTOSARN

N

N

Online cloud

Online cloud

Offline cloudA

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)

Toyota E/E Architecture Evolution and AUTOSAR BSW migration 601 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

DECSTAR2CANARY

SPF R1.2(10SPF)

SPF R1.0(06SPF)

SPF R1.1(08SPF)

CS-LightSPF R1.3

OSEK

TOYOTA proprietary requirement

partially AUTOSARCompliant

STEP4[full AUTOSAR compliant]

CCSt-CORE[TOYOTA standard BSWs]

7

Proprietary Specification

Benefit of AUTOSAR Standard BSW

Tier1 BSWIncorporatingToyota Spec.

Toyota BSW

Impl

emen

tatio

n Ef

fort

Spec.Reviews

Q&A

TestResultReviews CCSD

evel

opm

ent

Effo

rt

SPF R1.0

Decstar1

Decstar2

Canary

BSW Stacks

Standard BSW

Dev

elop

men

t Ef

fort

SPF R1.0

TOYOTAProprietarySpec.

AUTOSARBased Spec.

t-CORE

Shift to

AUTOSARBSW

HW

μCBasic Software

Standard I/FApl Apl Apl Apl

Standard Specification Proprietary Software Standard Software

Common understanding of Spec.(Functions)Common usage of Implementations

Split & Share of Responsibility betweenOEM, Tier1, Tier2

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

Today’s Agenda 9


Modular approachcreates 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 with1) “large variant set” (including smaller vehicle)2) “systems’ engineering” for global optimization3) short sprint release “repeatedly”

Technical Trends : Development Process 10

Potential measure on E/E Architecture1) Open System (on demand)2) Centralization3) Frequent Update (OTA)

C C

C C

C C

C C

C C

C C



ComputingPlatform

A

C C C

CC

C AA

FR

FL

RR

RL

C

C

C

C

AA

A

A

ComputingPlatform++

N

A

C

Adaptive

Classic

legends

Non-AUTOSARN

N

N

Online cloud

Online cloud

Offline cloudA

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

12Future E/E Architecture: Central & Zone Concept

Current Architecture (Domain based) Next Gen. (Central and Zone)Physical

Impactimage on change

Power ①Dedicated, additional wire and route required ①Minimized wire under ZoneNetwork ②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 ECULogical ⑤Software changes on distributed ECUs ⑤Software change only on Central ECU

CGW

J/B

⑤

⑤

Zone ECU

I/O

Sensor Act. Sensor Act.…

HUB

MCU

Newfeature

Act.

New feature

Smart Act.④ Act. ④

① ②

③Central ECU

SWC

Ａ

SWCＢ

SWCＣ

⑤ ⑤

Central ECU

Zonal ECU

No space

Less extendibility

Few vehiclecoverage

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

SpaceMirgin

Extendable

High # vehiclecoverage

Lightweight

C C

C C

C C

C C

C C

C C



ComputingPlatform

A

C C C

CC

C AA

N

A

C

Adaptive

Classic

legends

Non-AUTOSARN

NOnline 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

AA

A

A

ComputingPlatform++

NOnline cloud

Offline cloudA

C

C

C

C?

14A 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

NOnline cloud

FR

FL

RR

RL

C

C

C

C

AA

A

A

A

A

A

A

Offline cloud

NOnline cloud

Offline cloudA

Brains + Domain Master

Localize OTA change

Introduction of New Applications may become a Driving Force

AIAutonomous

EV (Regulation in

various countries)

MaaS service

C C

C C

C CA

AA

N

NOnline cloud

Car Share

Connected

Today’s Agenda 15


Application Driver for Future E/E Architecture : CASE 16

Powertrain / ChassisADASBodyInfotainment

Size / Complexity

Electrification

Source : chargedevs.com

OEM

Vehicle as a part of IoT

ConnectedLv3, Lv4, …

AutonomousSource : Morgan Stanley Research chargedevs.com

Shared

17

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

18Highway Automated Driving System

19

It seems to be working well….

20How to Validate/Verify the System … Globaly142 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 Validationis Necessary

Test Cases should cover all the Roads Globally=>Condensed/Compressed Validation Method Necessary

走行軌跡

21

e.g. Merging on highway (Ariake IC)Result from MILS evaluation

Ego

Vehic

le

Oth

er

Vehic

le

80

Speed of Other Vehicle

Dis

tan

ce

to O

ther V

eh

icle

○ ○ －－－－－－－○ ○ －－－－－－－○ ○ ○ ○ －－－－－○ ○ ○ ○ －－－－－○ ○ ○ ○ ○ ○ －－－○ ○ ○ ○ ○ ○ －－－○ ○ ○ ○ ○ ○ －－－○ ○ ○ △ ○ ○ ○ ○ －○ ○ ○ ○ △ ○ ○ ○ ○○ ○ ○ ○ ○ △ ○ ○ ○－－ ○ ○ ○ × △ ○ ○－－ ○ ○ ○ ○ × ○ ○－－－－ ○ ○ × △ ○－－－－ ○ ○ × × △－－－－－－ ○ × ×－－－－－－ ○ ○ ○－－－－－－ ○ ○ ○－－－－－－－－ ○

Successfully merged in front

Successfully merged

in behind

Utilize to develop algorithm forPlanning/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 CoverageVerifying "Planning/Control"Verifying "Recognition"

Utilizin

g c

om

pute

r gra

phic

s images

22Driving Scene in Backlight

23

e.g. Merging on highway (Ariake IC)Result from MILS evaluation

Ego

Vehic

le

Oth

er

Vehic

le

80

Speed of Other Vehicle

Dis

tan

ce

to O

ther V

eh

icle

○ ○ －－－－－－－○ ○ －－－－－－－○ ○ ○ ○ －－－－－○ ○ ○ ○ －－－－－○ ○ ○ ○ ○ ○ －－－○ ○ ○ ○ ○ ○ －－－○ ○ ○ ○ ○ ○ －－－○ ○ ○ △ ○ ○ ○ ○ －○ ○ ○ ○ △ ○ ○ ○ ○○ ○ ○ ○ ○ △ ○ ○ ○－－ ○ ○ ○ × △ ○ ○－－ ○ ○ ○ ○ × ○ ○－－－－ ○ ○ × △ ○－－－－ ○ ○ × × △－－－－－－ ○ × ×－－－－－－ ○ ○ ○－－－－－－ ○ ○ ○－－－－－－－－ ○

Successfully merged in front

Successfully merged

in behind

Utilize to develop algorithm forPlanning/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"

Utilizin

g c

om

pute

r gra

phic

s images

Utilizing Virtual Environment for Verification Coverage

24

Scaling Computational Power

Research Pre-development Development& Series Production

FunctionalityChecked

Real-Time,PerformanceChecked

Deploymentready

e.g. Deep learning servere.g. Voice recognition

Application Application Application

e.g. trunk serverCentral Unit

gettingcloser

Enabling Technologies for CASE Systems Development

backend

onboardOptimize Hardware

update

Same Functionality between different Computing Platforms

Virtual Environment

(PC base)

Mass Production ECU

Enabling Technologies for CASE Systems Development 25

APP(IVI)

APP (ADAS)

AI APP(deep learning)

Computing unit for frequently changing software

StableI/F

StableI/F

Cloud APP(edge computing)

APP (ADAS) e.g. 10ms

APP (AD) e.g. 100ms

APP(IVI)

APP(AI)

APP(Cloud)

e.g. 1000ms

SoftwareUpdate(C++)

Decision makingAIIVI

OEMTier‐1Tier‐1Tier‐2

C

C

C

C

C

C

C

C

A CN

Key software (for OEM) may be executed on adaptive PF.Scalable software (extended features) are located at central ECU

Split & Share of Responsibility betweenOEM, Tier1, Tier2

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

Thank you very much for your attention !

Challenges Towards New Software Platforms for Automated ... · TOYOTA standard BSW with full...

Documents

Transcript of Challenges Towards New Software Platforms for Automated ... · TOYOTA standard BSW with full...