ecu communication architecture for autonomous driving · automotive ethernet –ecu communication...

Automotive Ethernet

ECU Communication Architecture for Autonomous Driving

Dr. Michael Ziehensack

June 5th, 2015

© Elektrobit (EB) 2015

Agenda

2

Levels of Autonomous Driving (AD)

Global Time Sync

Quality of Service

Fault Tolerance

Safe and Secure Communications

Summary


Automotive Ethernet – ECU Communication Architecture for Autonomous Driving


3Source: SAE, NHTSA, VDA

Degree of automation

Driver Auto-

mation


• Increased number of sensors and high bandwidth sensors

(short/long range radar, LiDAR, cameras,…) � High bandwidth

• Sensor fusion (temporal correlation of diverse sensors) � Global time sync

• From “alert & assist” to features that take more control (i.e. partial automation

and higher) � Quality of Service, Fault Tolerance, Safe and Secure Comm.


ECU communication requirements for AD

4

Short-Range

Sensors

Short-Range

Sensors

Long-

Range

Sensor

Short-

Range

Sensors

Short-

Range

Sensors

Long-

Range

Sensor

Rear/Forward

Vision Systems


Implementation

• HW: Special physical layer for automotive environment

− Now: 100 Mbit/s full duplex via single UTP cable (OABR PHY)

− Soon: 1000 Mbit/s full duplex via single UTP cable (IEEE P802.3bp)

• HW: Switched-Ethernet Network

− No shared media, always point-to-point connections: ECU – switch – ECU


High Bandwidth (main reason for Automotive Eth)

5

10x (20x)

CanFD

Fr

MOST 150x

6x

Eth 200x – 2000x

Can 1x

Lin 0,02x

Full duplex, bandwidth available at each link

Ring topology, bandwidth shared by all nodes, POF cables

Two channel operation (separate cables for each channel)

1 Mbit/s arbitration phase, 8 Mbit/s data phase, 64Byte Frame length

Reference value for comparison (1 Mbit/s)


Agenda

6


Global Time Sync

Quality of Service

Fault Tolerance


Summary



Global Time Sync

Feature breakdown:

‒ F001: global time sync (common notion of time by all network nodes), i.e. all

nodes sync to a global time (802.1AS-2011) provided by the master node

‒ F002: synchronous task execution, i.e. tasks executed sync to global time

‒ F003: Application level timestamps, i.e. timestamp acquired by SWC at data

creation to enable a time aware interpretation of data at the sensor fusion

device.

7



Solution for Global Time Sync

‒ AVB Spec IEEE 802.1AS (generalized precision time

protocol, gPTP)

• MASTER node cyclically transmits a Sync and Follow_Up

message to SLAVE nodes for synchronization to the master

clock

• Automotive gPTP profile: Master node pre-configured

• For calculation of the required time correction term a

timestamp at transmission and reception of Sync message is

required.

• HW support in Ethernet Controller for timestamp strongly

recommended to achieve high accuracy

‒ AUTOSAR Global Time Sync modules

• Synchronized Time Base Manager (StbM) provides Global

Time to applications

• Ethernet Time Synchronization Module (EthTSyn) implements

IEEE 802.1AS

8

Slaves clock offset =

t2-t1-link_delay

link_delay measured

separately

t1

received

capture t1

capture

t2

send t1



ACG7 solution for Global Time Sync

9

OS

F003

F002

SecOC

F001

Feature Groups

(1) Global Time Sync

F001, F002, F003

ACG7 Time Sync (Base) ACG7

Time Sync (Eth)

ACM7 ETH Time Sync


Agenda

10


Global Time Sync

Quality of Service

Fault Tolerance


Summary



Quality of Service

• Timing guarantees for data exchange between time critical

control applications

‒ End-to-End timing, from sender via the network to the receiver

‒ Beside the network delay, the processing time and delays at the

sender and receiver must be considered

• Time critical data and best effort data transmission on the

same network

11

t

ttransmit

treceive

Guaranteed

max.

transmission

latency

e.g. 3 ms

Feature breakdown:

‒ F004: time sensitive data transmission via Rte Sender/Receiver communication

and UDP/IP

‒ F005: Priority based traffic class queues (802.1Q-2011, ch 34)

‒ F006: Traffic shaping (per class/AVB/control stream) (802.1Q-2011, ch 34)

‒ F007: Sharing of an AVB stream


‒ AVB Spec IEEE 802.1Q (Forwarding and queuing for time-sensitive streams)

• priority based traffic transmission (SP): time critical data are prioritized over best effort data (priority field in frame)

• traffic shaping (CBS): burst of time critical data are avoided by evenly distribution of packets in time

• HW support in Ethernet Controller strongly recommended

‒ EB Quality of Service Extension for AUTOSAR

• Prioritized transmit and receive processing to achieve timing guarantees

• Multi-Level Stream Multiplexing at the sender: one class A stream can be shared by multiple AVB streams, one AVB stream can be shared by multiple control streams

• Traffic shaping for all stream levels


Solution for Quality of Service

12

Highest

Prio

Lowest

Prio

Multi-Level Stream Multiplexing



Software interaction model for AUTOSAR IP/Ethernet

µs Source

100 (1) Tx call tree*

750 (2) Tx dispatch time

850 Talker delay (1)(2)

1,000 Network delay (3)(4)(5)**

500 (6) Rx activation time

100 (7) Rx call tree*

600 Listener delay (6)(7)

2,450 Total (< 3,000 µs)

* 50µs budget for preemptions** static topology typical < 1ms

13

SWC

B

Com Stack

EthCtrl

(HW)

Switch

1

3

4

5

4

7

(1) Tx ComStack transfer time

(2) Tx dispatch time

(3) Delay caused by queued or

interfering frames

(4) Transmission time on PHY

(5) Switch transfer time

(6) Rx activation time

(7) Rx ComStack transfer time

Com Stack

EthCtrl

(HW)

6

SWC

A

SWC

D

SWC

C

3

2

Worst case delay calculation

(example)

2 independent SWC sharing an AVB Stream

SWC A (2 frames, 32 Byte, 10ms)

SWC B (1 frame, 32 Byte, 5ms)



ACG7 solution for Quality of Service

14

F005, F006, F007

F004SecOC

Feature Groups

(2) Quality of Service

F004, F005, F006, F007

ACG7 IP + ACG7 IP QoS

ACM7 ETH

ACM7 ETH QoS


Agenda

15


Global Time Sync

Quality of Service

Fault Tolerance


Summary



Fault Tolerance

• Fail-Operational requirements

(fail-safe not sufficient for autonomous driving)

‒ Fail Safe: systems which can tolerate faults by

switching to a ‘safe state’ (switching to the safe state

must not require energizing any safety-related

actuators)

‒ Fail-Operational: systems which remain operational

after any arbitrary fault of at least one part of the

system for handover time (semi-autonomous driving)

or “limp home” mode (fully autonomous driving)

16

Feature breakdown:

‒ F008: Redundancy Management (ring-topology, data sent it both directions)

‒ F009: Ingress Policing (blocking talker with stream that exceeds reserved bw.)



Solution for Fault Tolerance

• Redundancy Management

‒ Sender: adds redundancy managementinfo to Ethernet frame directly after VLAN tag

‒ Switch (ring topology, one switch per ECU): duplicates frames and transmit it on the left and right link

‒ Receiver: removes redundancy management info and checks if both frames are received within a certain timeout (reports an error in case not)

‒ Today: Ethernet Stack, Future: Switches (802.1CB)

• Fault isolation via Ingress Policing

‒ Babbling Idiot: Faulty node or faulty switch sends more data than it should.

‒ Ingress Policing Filters in Switches can monitor AVB streams and block streams that consume more bandwidth than reserved (e.g. red stream blocked as 35 > 20 Mbit/s)

17

Source: Markus Jochim (GM)

ADAS

Controller

Frame sent twice,

no switchover time

Front

Camera

Radar

ECU

Lidar

ECU

F’’ F’

ADAS

Controller

Fault Tolerance



ACG7 solution for Fault Tolerance

18

F008

SecOC

F009

Feature Groups

(3) Fault Tolerance

F008, F009

Safety RedM, ACM7 EthSwt


Agenda

19


Global Time Sync

Quality of Service

Fault Tolerance


Summary



Safe and secure communication

• Safe communication for sensitive data between ECUs

‒ protection of safety-related data exchange against the effects of faults on the communication

link between SWCs

• Secure communication for sensitive data between ECUs

‒ protection against unauthorized manipulation and replay attacks

Feature breakdown:

‒ F010: E2E protected communication

‒ F011: Secure OnBoard communication

20



Solution for Safe and secure communication

• E2E Protection – AUTOSAR E2E

− sender ECU adds protection information (E2E

header) to the data

− receiver ECU evaluates the received protection

information together with the received data and

indicates the result to the SWC

− AUTOSAR E2E Profiles P04 (CRC, counter, data ID)

specified for Ethernet

− AUTOSAR Modules: E2E Library, E2E Transformer

(Fast Data Path) or E2E Protection Wrapper

• Security – AUTOSAR SecOC

− Secure Onboard Communication (SecOC)

− Authentication and integrity of critical frames

based on Message Authentication Code (MAC)

and Freshness value (counter or timestamp)

− AUTOSAR Module SecOC

21

Source: AUTOSAR 4.2 SecOC SWS



ACG7 solution for Safe and Secure Comm.

22

SecOC

F010

F011

Feature Groups

(4) Safe and Secure Comm.

F010, F011

Safety E2E, ACG7 SECOC


Agenda

23


Global Time Sync

Quality of Service

Fault Tolerance


Summary



Summary: ACG7 ComStack for Autonomous Driving

24

OS

F008

F005, F006, F007

F003

F004

F002

SecOC

F009

Feature Groups

(1) Global Time Sync

F001, F002, F003

ACG7 Time Sync (Base) ACG7

Time Sync (Eth)

ACM7 ETH Time Sync

(2) Quality of Service

F004, F005, F006, F007

ACG7 IP + ACG7 IP QoS

ACM7 ETH

ACM7 ETH QoS

(3) Fault Tolerance

F008, F009

Safety RedM, ACM7 EthSwt

F001

F010

F011

(4) Safe and Secure Comm.

F010, F011

Safety E2E, ACG7 SECOC

Thank youautomotive.elektrobit.com

[email protected]

ecu communication architecture for autonomous driving · automotive ethernet –ecu communication...

Documents