Automotive Ethernet Real-Time Predictability - RTAS...

Automotive Ethernet Real-Time

Predictability

Jan R. Seyler, Thilo Streichert, Helmut Leier

16.04.2014

Overview

1. Motivation

2. Modelling of Ethernet networks

3. Safeguarding of Ethernet-Networks

4. Case Study and Results

5. Discussion and Outlook

Automotive Ethernet Real-Time Predictability | Jan R. Seyler | RTAS'14 | 16.04.2014 2

Motivation

Metrics for network design and load assessment have to be reconsidered


Criteria for designing a feasible

communication matrix: Busload

Criteria for designing a feasible

communication matrix: ?

release of

first C-matrix

start of

production

next model

Bus

Lo

ad

[%

]

Today Ethernet

Link load?

Buffer utilisation?

End-to-end timing?


1. Motivation





ECU ECU

Application Layer

Application Layer


µC

DSP Switch

Service-oriented Communication

• Modelling of receiver behavior instead of sender behavior as in CAN/FlexRay networks

Protocol

Stack

Application Layer Client1 Client2 Server1 … …

Protocol

Stack

µC

Timing Behavior of Frame Generation


ECU

µC

DSP Switch

Socket Adapter

• Sockets collect PDUs for an Ethernet frame

• Definition of trigger conditions for the sockets (timer, buffer, always)

Protocol

Stack

Socket Adaptor

Socket 1 Socket 2 Socket n

…

7 7|8|9|7|9 3

8

8

3 7 8 9 7 9 7 1

1

Timer-Trigger PDU-Trigger Buffer full Timer-Trigger PDU-Trigger

Time

Eth-

Frame

Timer

Socket

Buffer

PDU

Communication Design for Ethernet


ECU

µC

DSP Switch

Network communication

specified by the OEM

Inter-processor communication

specified by the supplier

Ethernet topology and traffic across the switches:

• OEM specifies topology and network communication

• In case of inter-processor communication via a switch, the supplier will specify the traffic

• Traffic by supplier and OEM interferes in the switch

• Communication description needs to be exchanged between supplier and OEM to achieve a

feasible communication matrix


1. Motivation





What is Real-Time Predictability?

• A system is considered real-time predictable if the transmission time of every

(timing-critical) message is bounded.

• Predictable by technology

FlexRay

TTEthernet

• Predictable by design

Worst-case timing analysis


The technology uses methods like time slots to ensure real-time predictability

Overhead will be part of the technology

Design-overhead will be a result of the analysis method and the network

itself.

Different Approaches to Evaluate Ethernet Traffic

Automotive Ethernet Real-Time Predictability | Jan R. Seyler | RTAS'14 | 16.04.2014

Simulation/Experiment

Best case

calculated

Best case

real

Average case Worst case

real

Worst case

calculated

Latency

[ms]

Pro

ba

bil

ity

Analysis

Load scenarios and topology

Simulation Analysis Experiment

10

Combination of these three approaches to benefit from the specific advantages.

+ Simple modeling of different

scenarios

+ Traceability (Gantt-Charts,

statistical distributions, etc.)

- Computationally intensive

- Abstraction of real world

- Result depends on stimuli

+ Simple modeling of different

scenarios

+ Corner cases can be evaluated

(clear upper and lower bounds)

- Over approximation of

worst case

- Abstraction of real world

+ Good approximation of the real

world behavior

+ Representative statistical results

- Special hardware and software

required

- Complexity for setting up the test

cases

- Result depends on stimuli

Tool Chain

Automotive Ethernet Real-Time Predictability | Jan R. Seyler | RTAS'14 | 16.04.2014

AUTOSAR-XML converter for specific input

formats of evaluation tools

Simulation Analysis Experiment

11

Merging of results

Timing of the software stack


1. Motivation





Scenario


Load scenario:

• 56x Messages with two different priorities

• Payload sizes: 1–1400Byte

• Periods: 0.1 – 1000 ms

• Uni-/Multi-/Broadcast-Messages

Topology:

• 8x ECUs

• 2x Switches

• 7x 100MBit/s and 2x 1Gbit/s links

• No Shaping

Step 1: Will it work?


Analysis of the Switch Buffers


Sw

itch

#1

S

wit

ch

#2

Switch#1 Switch#2

Buff

er

fill

leve

l [b

yte]

25000

Three cases can be distinguished:

1. If the available hardware buffer is higher

than the analyzed worst-case, no data will

ever be lost.

2. If the available hardware buffer is

between the worst-case and the

maximum from simulation and

experiment, it is unlikely that data will be

lost.

3. If the available hardware buffer is lower

than the maximum from simulation and

experiment, a part of the transmitted data

will be lost.


Discussion of the Results

Switch#1 Switch#2

Buff

er

fill

leve

l [b

yte]

25000

Case 3: Detailed Analysis


0,00%

5,00%

10,00%

15,00%

20,00%

25,00%

30,00%

575 1150 1725 2300 2875 3450 4025 4600 5175 5750 6325 6900 7475 8050 8625

Pro

ba

bil

ity

Buffer fill level [byte]

Switch#1

0,00%

5,00%

10,00%

15,00%

20,00%

25,00%

30,00%

35,00%

40,00%

169 338 507 676 845 1014 1183 1352 1521 1690 1859 2028 2197 2366 2535

Pro

ba

bil

ity

Buffer fill level [byte]

Switch#2

Step 2: Is it predictable?


Latency


late

ncy

[ms]

Ethernet Messages

0.7

Discussion of Results

Four cases can be distinguished:

1. If required latency of a message is larger than analyzed

worst case, the system will definitely work

2. If required latency of a message is between worst case of

analysis and simulation/experiment, the system might work

(more detailed testing or redesign might be a consequence)

3. If required latency of a message is lower than worst case in

analysis, simulation and experiment, the system will not

hold its deadlines in any case

4. If required latency of a message is lower than the best case,

the system will never hold its deadlines


Conclusion:

• Worst case analysis either guides a designer to find critical

messages or approves the fulfilling of latency requirements

Histogram of a Single Message

• Latency histogram for the evaluation of non-real-time traffic

• Histogram data together with expert knowledge can be used to assess the functional behavior


[µs]


1. Motivation





Conclusion

• Ethernet requires and allows the introduction of new metrics for system

evaluation (end-to-end latency, buffer usage)

• Tool-chain allows a detailed evaluation of Ethernet systems including:

Upper and lower bounds for latency and required buffer

Experimental and simulation results for specific traffic scenarios

• Room for improvements:

Analysis tools and methods are based on periodic event models. A more dynamic and application

based communication pattern should be added

Further reduction of over approximation in worst case analysis

Refined modeling of switch behavior like adding buffer allocation


Questions?

Automotive Ethernet Real-Time Predictability - RTAS...

Documents

Transcript of Automotive Ethernet Real-Time Predictability - RTAS...