10th AUTOSAR Open Conference

AUTOSAR Nov-2017

TMC Software Platform for Automated Driving System

Kazuhiro KajioToyota Motor Corporation

Yutaka MatsubaraNagoya University

2

Automated Driving(TMC Objective)Realize a society where all people can move safely, smoothly and freely

Safety

EnvironmentFree TransportationA human and a car will build a fellow

relationship with a same purpose in which they occasionally watch over, help and

reach out to each other.

Automated Driving (Highway)A demonstration test for automated driving on a limited highway

(Tokyo Metropolitan Expressway) was conducted in October, 2015.

3

Automated Driving (Urban Road)More diverse environments, objects and scenes are on urban road,

More precise perception and decision are required.

4

Highway Urban RoadDriving environment has not been improved: various driving roads and traffic

rules are present.

Clear driving lanes Complicated rules

Exclusive for automobiles:

same traveling direction Various mobile bodies

Various mobile bodies are present with various traveling directions.

Crossing traffic lines

Waiting for parking?

No lanes

Comprehensive judgment for various scenes is required.

Hand signals

Separating and mergingL/C, construction, etc.

Opposing/crossing roads Pedestrians

Road surface condition Signals

Giving way/ Being aggressive?

CommunicationWhat is a direction?

Automated Driving (Sensor Configuration)Periphery recognition and own vehicle position estimation are performed

using sensors (Radar, LiDAR, Camera, GNSS, Dynamic Map).

Stereo Camera

Back LIDAR

Front-SideLIDAR

Side-Rear LIDAR

GNSS Antenna

FrontRadar

FrontLIDAR

SR Radar

Back Radar

5

Automated Driving (Architecture)Automated Driving Functions are mapped on ECUs and Sensors over

Ethernet network.

6

ADAS ECU#1

DLC

SensorSensorSensor Sensor

E/SW #1

E/SW #2

HMI

: 100BASE-T1 (OABR): 100BASE-TX (Fast Ethernet)

System Architecture

Network Architecture(Ethernet)

MAPCGW

TCU

(1) Perception(2) Planning

(3) Control

HMI

Vehicle control

Decision

Trajectory PlanTarget speed

MergingPassing

Route planning

surrounding vehiclesRelative speed

Map informationShape of roads

Periphery recognition

Vehicle position withprecise and dynamic map

ADAS ECU#2

Software Platform Tech for Automated Driving

7

① Large-scale Software Execution on SOC(many-cores)Parallelization and real time execution of software...[RTOS]

② Agile Software Development CycleStandard API for SWC portability from prototype to production...[POSIX]

③ Large Data CommunicationSafe, Secure and Qualified large-data communication...[Ethernet]

④ Time-sensitive Control and FOT SimulationTime-synchronized communication and simulation...[AVB(gPTP)]

⑤ Software Update(SOTA)Service oriented and dynamic communication…[SOME/IP-SD]

⑥ Efficient Software Development with Standards Standardization of software platform...[AUTOSAR Adaptive]

①RTOSParallelization and Real-time Execution of Software

RTOS:Real-Time Operating System

8

A57

L1 Cache MMU

NEON

FPU

Core3

A57

L1 Cache MMU

NEON

FPU

Core2

A57

L1 Cache MMU

NEON

FPU

Core1

Many-cores and Parallelization

SOC(R-Car H3 SiP)Heterogeneous 8 Cores(ARM A57x4, A53x4)

ARM A57ｘ４(1.6GHz) ARM A53ｘ４(1.2GHz)

DDR4 DDR4

DDR4

DDR4

R-Car H3

Hyper Flash

9

SCU(L1 Cache coherent) L2 Cache(2M)

SCU(L1 Cache coherent) L2 Cache(2M)

Main Memory Domain AXI

DBSC4 Cache 0 Cache 1

DDR4ch0

DDR4ch1

DDR4ch2

DDR4ch3

ARMA57

L1 Cache32K(D)48K(I)

MMU

NEONFPU

Core0

CCI-500(L12Cache coherent)

A53

L1 Cache MMU

NEON

FPU

Core7

A53

L1 Cache MMU

NEON

FPU

Core6

A53

L1 Cache MMU

NEON

FPU

Core5

ARMA53

L1 Cache32K(D)48K(I)

MMU

NEONFPU

Core4

Automated Driving Software is so large and time-critical that parallelization and real-time execution are essential.

R-Car H3

RTOS (Multi-threading)Parallelization and speed-up are done with multi-threading.

10

pthread_create() pthread_join()

Processing A

threadB

thread_A

threadC

threadD

After parallelization

Before parallelizationt

Parallelization with multi-threading (Example)

t

Core 0

Core 0

Core 1

Core 2

Core 3

Signal communication(Ethernet (OABR))

ADAS ECU

POSIX OSASIL-D

SOC (R-Car H3）

Process 1C++

AUTOSARSWCProxy

Middleware RTE

Process nＣ

A57x41.6 GHz

A53x41.2 GHz

PSE51 PSE51

Control Application (ASIL)

POSIX IPC POSIX IPC

RTOS (SMP x Core Affinity)Real-time execution is secured by core-affinity on SMP Architecture.

thread Core Binding with RTOS（example）SOC(R-Car H3）

POSIX OSASIL-D

ProcessVirtualAddress Space

A57core0

A57core1

A57core2

A57core3

A53core4

A53core5

A53core6

A53core7

ProcessVirtualAddress Spacethread@100ms

ProcessVirtualAddress Space

ProcessVirtualAddress Space

ProcessVirtualAddress Space

thread @100ms

thread@100ms

thread@100ms

thread@100ms

thread@100ms

thread@100ms

thread@1000ms

ARM A53(1.2GHz) ARM A57(1.6GHz)

POSIX Process

ProcessVirtualAddress Space

thread@100ms

thread @100ms

Rte Task@100msBSWTask@1ms

Rx ISR2

Tx ISR2AUTOSARProcessIPC

@100ms

thread_binding()*

*OS Specific API

11

RTOS (Boot Time)Due to long boot time (example below:3.08s) ,

Network and Software architecture(ex:Diag) shall be optimally designed.

App Running

App and Com Running

Boot time

3.08s

tPower ON

R-Car H3 ARM A57, A53, R712

Program is loaded from Hyper Flash(512MByte) to DDR4(4GByte)

R7

A57

A53

IPL(R7)

IPL(A57) Kernel Boot

Kernel Boot

POSIX Boot

POSIX Boot AUTOSAR SWC Active

POSIX SWC Active

R7 Active

AUTOSAR Init

0.141s 1.616s 0.310s 1.013s

②POSIXStandard API for SWC Portability from Prototype to Production

POSIX:IEEE Std 1003.1(Portable operating system interface)C++14:ISO/IEC14882:2014(E) – Programming Language C++

13

Prototype and Verification EnvironmentPrototype and verification are executed on PC environment.

SWC portability from prototype(PC) to production(ECU) is needed.

Prototype and VerificationGitHub, CI server

Software ConfigurationManagement

14

Curves

Roads all over the world

Slopes

Lanes Road side objects

Traffic environment

External world model

×Combination

Sensor model

Passenger cars Pedestrians

Trucks Motorcycles

Laser

Millimeter wave

Ultrasonic wave

ACCPCSLTC

Automated driving

Control model

Engine control

Brake control

Power steering control

High-precisionvehicle model

Engine

Brake

Power steering

Chassis

Meter

Meter control

PerceptionPerception Control Actuator

Simplified vehicle model

FeedbackExternal External world

シーンシーンScene

Camera

POSIX OS

Processor(ex:intel Xeon)

Process １C++

Middleware

Process nC

Core１ Core n

POSIX(Standard API)

POSIX OSASIL-D

SOC(ex:ARMv8 , intel Atom)

Process １C++

Process nC

Prototype Production

Selected PSE51 61 Standard API (s) can be called by Application.

ADAS ECUPC

Core１ Core n

libc++ libc libc++ libc

PSE51 PSE51

・・・ ・・・ Profile API StdAPI

Target

PSE51 287 61(28)

・Single Process・IPC(Shm)

PSE52 626 ↑ ・Single Process・IPC(MQ)

PSE53 754 ↑ ・Multiple Process・IPC(Socket)

PSE54 912 ↑ ・Multiple Users・File System

POSIX Profile and Standard API( )C++14 API

Identical Source code

15

POSIX IPC POSIX IPC

C++14:ISO/IEC14882:2014(E) – Programming Language C++

MiddlewarePSE51 PSE51

POSIX(IPC)

Shared Memory

Shared Memory is 5 times faster(example below) than Socket.Standard API(s) are selected taking account of their performance.

MeasuredPeriod

Socket

Process ASender

Process BReceiver

R-Car H3 ARM A57, A53

semaphore shared_memory

sem_wait()

Get(read_pointer)

Get(data[read_pointer])

Set(read_pointer++)

Set(count--)

sem_post()

Process ASender

Process BReceiver

socket socketrecv()

send()

Shared MemoryPSE51

SocketPSE53

16

MeasuredPeriod

③EthernetLarge Data Communication

17

AUTOSAR Classic on POSIXEthernet Communication is done over AUTOSAR Classic on POSIX

19PF BSW Reference Implementation(R4.2.1/R4.3.0+TMC Extended Feature)

POSIX OS

AUTOSAR SWC(Proxy)

18

Signal communication(Ethernet (OABR))

ADAS ECU

POSIX OSASIL-D

SOC (R-Car H3）

Process 1C++

AUTOSARSWCProxy

Middleware RTE

Process nＣ

A57x41.6 GHz

A53x41.2 GHz

PSE51 PSE51

Control Application (ASIL)

POSIX IPC POSIX IPC

Ethernet (E2E and SecOC)Large Data(s) are sent over SOMEIPXF(Serialization).

Safety(E2E) and Security(FV/MAC) mechanism are implemented.

I-PDU( 1/ N )

1400 byte(byte Stream)

SecurityFV

7byteMAC4byte

I-PDU( */N )

I-PDU(N/N)

APL Header(X) byte

SomeIP8byte

E2E 12byte

APL Header(X) byte

SomeIP8byte

E2E 12byte

APL Header(X) byte

SomeIP8byte

E2E 12byte

Security

EthernetHeader + VLAN

14+4byte

IP HeaderIPv4

20byte

UDPHeader8byte

PDUHeader8byte

FCS4byteL-SDU ( 1/ N ) APL Header

(X) byteSomeIP

8byteE2E

12byte

Security

EthernetHeader + VLAN

14+4byte

IP HeaderIPv4

20byte

UDPHeader8byte

PDUHeader8byte

L-SDU ( */N )FCS4byteAPL Header

(X) byteSomeIP

8byteE2E

12byte

Security

Security

EthernetHeader + VLAN

14+4byte

IP HeaderIPv4

20byte

UDPHeader8byte

PDUHeader8byte

L-SDU(N/N)APL Header

(X) byteSomeIP

8byteE2E

12byte

FCS4byte

Security

[Ethernet Frame]

[PDU]

[Message]

APP

BSW/RTE

Ethernet

FV7byte

RTE_Read

LiDAR(Detection List)

MAC4byte

FV7byte

MAC4byte

FV7byte

MAC4byte

FV7byte

MAC4byte

FV7byte

MAC4byte

Zero Padding

Zero Padding

1400 byte(byte Stream)

1400 byte(byte Stream)

APLHeader(X) byte

APLHeader(X) byte

APLHeader(X) byte

Zero Padding

RTE_Read RTE_Read

Message (Large Data)

Safety Mechanism Security Mechanism

19

Large Data Communication (LiDAR Detection List)

Ethernet(CPU Load)

0

5

10

15

20

25

30

35

40

45

CPULo

ad[%

]

Time[s]

CPU load on R-Car H3 A53(Core5)

RteTask(tA)BSW Task(tB)EventHandlerTask

Ethernet Rx time(1400byte/Frame)CRY(SW)

Off-loading with HSM(Hardware Security Module) andload balancing by optimized function mapping to cores are important.

CPU Load(Tx:7Messages, Rx:9Messages)

BSW Task RTE Task

AES-CMAC

Max:42.7%

AUTOSAR Classic on POSIX OS@R-Car H3 ARM A53 (Core5)20

Ave:21.4%3% 81% 16%

Ethernet(QoS Verification)

ExampleLiDAR Detection List120,046byte＠100ms(Ｎ=86 Frames)QoS Metric

1) Max Latency:86.1ms2) Jitter(Ave):85.3ms3) Frame Loss: No Loss

Communication Matrix（CAN, ETH/AVB, GW(RM))

QoS Simulator(OMNet++)

Ethernet Switch Model(ex:Broadcom(BCM89501),

NXP(SJA1105))

TopologySimulation Result

Communication Matrix

QoS Simulator and Evaluation bench are pre-developed.Several QoS metrics can be measured and verified.

Ethernet Switch Model

Simulation Setting(ex:Sim Time, SW Latency at End

Node)

ARXML

LiDAR(Detection List)

ShaperSH2cos5

cos4

cos3

cos2

ShaperSH1

cos1

cos0

ShaperSH0

SP/WRR SCH2

SP/WRR SH1

Example(BCM89501)

21

④AVB(gPTP)Time-synchronized Communication

AVB:IEEE 802.1AVB(Audio VideoBridging) gPTP:IEEE 802.1AS(generalized Precision Time Protocol)

22

Time-sensitive Control and FOT SimulationTime-synchronized communication is needed for precise control and

efficient prototype and verification(FOT simulation)

ADAS ECU#1

MAPDLC

SensorSensorSensor Sensor

E/SW #1

E/SW #2

HMI

: 100BASE-T1 (OABR): 100BASE-TX (Fast Ethernet)

ADAS ECU#2 SLAVESLAVE

SLAVESLAVESLAVESLAVE

SLAVE

SLAVE

SLAVE

TC TC

CGW

TCUFOT Log(ASAM MDF)

MASTER

23

FOT(Field Operational Test)

Replay(ASAM MDF) SimulationPrototype and Verification ECU

EthernetHeader + VLAN

14+4byte

IP HeaderIPv4

20byte

UDPHeader8byte

PDUHeader8byte

FCS4byteL-SDU

E2E [unit : byte]Leng

th[2]

Counter[2]

DataID[4]

CRC

[4]

SecurityFV

7byteMAC4byte

SomeIpHeader8byte

APLHeaderX byte

Time Stamp11byte

[Ethernet Frame with Time Stamp]

MASTER SLAVE

AVB(gPTP) (Initial Clock-sync Time)Precise time-synch is done with gPTP(precision order:us).

Initial clock-sync time(example below:～997ms) is key metric.

Pdelay＋Residence time

E/SWEnd Node End Node

Pdelay Measurement(2-steps)End Node:AUTOSAR Classic@RH850(ETNB), E/SW:BCM89531

Pdelay_Req

Pdelay_Resp

Pdelay_Resp_Follow_Up

Pdelay_Req

Pdelay_Resp

Pdelay_Resp_Follow_UpSync

SyncFollow_Up

Follow_Up

Sync(EthTSyn)

Initial Sync time

～997ms

LinkUp

E/SWResidence time

Ingress Egress

Egress timestampIngress timestamp+

+-

++

Follow_Up Message at Ingress Follow_Up Message at Egress

CorrectionField(8byte)

Pdelay time on Ingress port

t1

t4

t2

t3

(t4-t1)-(t3-t2)2 MASTER

End NodeSLAVEEnd Node

Pdelay=

24

Origin Time Stamp(10byte)

CorrectionField(8byte)

Origin Time Stamp(10byte)

Sync

SyncFollow_Up

Follow_Up

Configuration Value:EthTSynGlobalTimeTxPeriod:125msEthTSynGlobalTimeTxPdelayReqPeriod:1000ms

⑤SOME/IP-SDService-oriented and Dynamic communication

SOME/IP:Scalable Service-Oriented Middleware on Ethernet/IP SD:Service Discovery

25

Software Update(SOTA)Software Update(SOTA) offers the latest functions to customers.

Service oriented and dynamic communication is expected.

Gen1Gen1SW Update

(Same Hardware）

time

Gen2Gen2SW Update

(Same Hardware）

OTA(4G/5G）

SWC/VINDatabasehttps Server

TCUhttps Client

ECUhttp Client

CurrentImage

NewImage

Ethernet(OABR/GbE)

Function

Software Update(SOTA)

Compressed Delta Image

Delta/Compress Image

Decode/Load Image

CurrentImage

NewImage

26

Software ConfigurationManagement

SOME/IP-SD(Use Case)

ADAS ECU(Client)

LiDAR(Server)Event ID 0x01:Object List

Event ID 0x02:Detection List

ADAS ECU(Client)

Subscribe(0x01)

Event(0x01)

LiDAR(Server)Event ID 0x01:Object List

Event ID 0x02:Detection List

Same Hardware

Same HardwareSame Software

Dynamic communication binding is enabled by SOME/IP-SD.(example below:No update at Server even when Client SWC is updated)

ADAS ECU(Client)

MAP(Server)Method ID 0x01:MapGen

Method ID 0x02:Localization

request(0x01)

response(trajectory map)

Pub/Sub(Events) RPC(Methods)

Subscribe(0x01 & 0x02)

Event(0x01)

Offer(0x01 & 0x02)

Offer(0x01 & 0x02)

Map

Offer(0X01 & 0X02)

Event(0x02)

DetectionList

Mid Grade High Grade

Object

List

No Update

SWCUpdate

SWCUpdate

No Update

27

Object List

0

20

40

60

80

100

120

140

160

180

200

0 1000 2000 3000 4000 5000 6000 7000 8000 9000SD

Tim

e[m

s]

Boot time gap[ms]

SOME/IP-SD(SD Time)Quick SD(Service Discovery) is possible(example below:～87.4ms)

However, Safety, Security and QoS are open issue.

Pub/Sub(Events)SD Time

(Case:Server boots faster than Client )AUTOSAR Adaptive R17-03@Intel(R) Core(TM)2Duo P9400 2.4GHz Ubuntu14.04 LTS 64bit

28

ADAS ECU(Client)

LiDAR(Server)

OfferFind

Subscribe

Subscribe_Ack

SD Time

Initial Wait Phase

Repetition Phase

Main Phase

Initial Delay Max

Repetition PhaseOffer

Main Phase

Configuration Value:Initial Delay Max:100msRepetition Base Delay:200msRepetitions Max:3 timesCyclic Offer delay:2000ms

EventDetection

List

Event

ObjectList

Boot time gap

⑥AUTOSARStandardization of Software Platform

29

AUTOSAR AdaptiveTMC and Nagoya Univ. joint team participates into FT(s)

to standardize software platform with partners.

AUTOSAR Adaptive OrganizationTMC and Nagoya Univ. Participation

AUTOSAR AdaptiveDemonstrator Target

QEMU,ARM(R-Car H3), Intel(Atom)

AUTOSAR Core Partners

Supported by R17-3

30

Next Network Architecture for Automated Driving

More adaptive and dynamic architecture will be demanded.AUTOSAR Adaptive will be deployed on App Server and DCU.

Central GW DCU DCU DCU DCU

CANFD2Mbps

Multimedia

CANFD2Mbps

Powertrain

CANFD2MbpsChassis

Ethernet (OABR)100MbpsADAS

CAN500KbpsBody

CAN500KbpsPowertrain

CANFD2MbpsChassis

Ethernet AVB(GbE)1GbpsADAS

Ethernet AVB(GbE)1Gbps

Application Server(5G:10Gbps)

TCU(4G:100Mbps)

CAN500KbpsMultimedia

DCU

CANFD2MbpsBody

Ethernet(OABR)100Mbps

1st Gen：Central GW Architecture Next Gen：Application Server/DCU Architecture

Statik Link& Signal COM Dynanuc Link & Service COM

CloudCloud

31

SOCCore１ Core m Core n

SOC

Process １C++

Process nC++Proxy

Core１ Core m Core n

Next Software Platform for Automated DrivingAUTOSAR Classic on POSIX will be replaced by

AUTOSAR Adaptive in the next Generation.

①SWC Description②System Description

①SWC Description②Service Interface Description③Manifest(Machine,App Service)

[AUTOSAR Adaptive Methodology]RTE/BSW Generation

(.c, h)ARA Generation

(.cpp, .hpp)

[AUTOSAR Classic Methodology]

1st Gen：AUTOSAR Classic on POSIX Next Gen：AUTOSAR Adaptive

Service+SignalCommunication

ARA API

POSIX OSASIL

Control Application(ASIL)

32

Process mＣ・・・

POSIX OSASIL-D

Process 1C++

AUTOSARSWCProxy

Middleware RTE

Process nＣ

PSE51 PSE51

Control Application (ASIL)

POSIX IPC POSIX IPC

Signal Communication

Summary

33

① Large-scale Software on SOC(many-cores)Parallelization with thread and real time execution with SMP x Core Affinity

② Agile Software Development CycleSWC portability from prototype to production with POSIX and C++14 API

③ Large Data CommunicationSafe, Secure and Qualified Ethernet with E2E, SecOC and QoS Verification

④ Time-sensitve Control and FOT SimulationTime-synchronized communication and simulation with AVB(gPTP)

⑤ Software Update(SOTA)Service discovery and dynamic communication with SOME/IP-SD

⑥ Efficient Software Development with StandardsMigration from AUTOSAR Classic on POSIX to AUTOSAR Adaptive

10th AUTOSAR Open Conference

Thank you for your attention!

Nov-2017- AUTOSAR - page 34

Yutaka MatsubaraGraduate School of Informatics, Nagoya Universityyutaka@ertl.jp

Kazuhiro KajioE/E Architecture Development. Div., Toyota Motor Corporationkazuhiro_kajio@mail.toyota.co.jp