Trends in Embedded Communication Systems : Traffic Shaping on CAN and introduction of FlexRay Nicolas Navet ESIEE – 13/06/2008.

Trends in Embedded Communication Trends in Embedded Communication Systems : Systems :

Traffic Shaping on CAN Traffic Shaping on CAN and introduction of FlexRayand introduction of FlexRay

Nicolas NavetNicolas Navet

ESIEE – 13/06/2008ESIEE – 13/06/2008

© 2008 RealTime-at-Work - 2

In-vehicle networking : In-vehicle networking : will CAN be able to keep up the pace?will CAN be able to keep up the pace?

Typically max. bus load is set to 35% Not enough wrt to short/medium term

bandwidth needs … Solution 1: multiple CAN networks … but

gateways induce heavy overhead Solution 2: switch to FlexRay … expensive for

bandwidth alone Solution 3: optimize the scheduling of CAN

frame .. Offsets provide a solution to make CAN predictable at higher network load (≥60%)


PART 1: Scheduling messages with offsets on CAN


Scheduling frames with offsets ?!Scheduling frames with offsets ?!

000

1050

1555

0 10 20 30 40 50 60 70 80 90 100 110

Periods 20 ms 15 ms 10 ms

0 10 20 30 40 50 60 70 80 90 100

52,50

110

52,50

Periods 20 ms 15 ms 10 ms

Principle: desynchronize transmissions to avoid load peaks

Algorithms to decide offsets are based on arithmetical properties of the periods and size of the frame


System model (1/2) System model (1/2)

ECUFrame Transmission request

task

Frame response time

Performance metric: worst-case response time

CANHigher prio. frames

frame


System model (2/2) System model (2/2) The offset of a message stream is the time at which The offset of a message stream is the time at which

the transmission request of the first frame is issuedthe transmission request of the first frame is issued

Complexity: best choosing the offsets is exponential in the Complexity: best choosing the offsets is exponential in the task periods task periods → → approximate solutions approximate solutions

Middleware task imposes a certain granularity Middleware task imposes a certain granularity Without ECU synchronisation, offsets are local to ECUsWithout ECU synchronisation, offsets are local to ECUs


But task scheduling has to be But task scheduling has to be adapted… adapted…

ECUFrame Transmission request

task

Frame response time

In addition, avoiding consecutive frame constructions on an ECU allows to reduce latency

CANHigher prio. frames

frame


TimeTime 00 22 44 66 88 1010 1212 1414 1616 1818

FrameFrame

Simple offsets Algorithm (1/3)Simple offsets Algorithm (1/3) Ideas:

assign offsets in the order of the transmission frequencies release of the first frame is as far as possible from adjacent

frames identify “least loaded interval”

Ex: f1=(T1=10), f2=(T2=20), f3(T3=20)

f1,1 f1,2f2,1 f3,1


Offsets Algorithm applied on a typical Offsets Algorithm applied on a typical body networkbody network

21 ms

65 ms


Offsets Algorithm (3/3)Offsets Algorithm (3/3)

Low complexity andLow complexity and efficient as is but efficient as is but further improvements possible:further improvements possible: add frame(s) / ECU(s) to an existing designadd frame(s) / ECU(s) to an existing design user defined criteria : optimize last 10 frames, user defined criteria : optimize last 10 frames,

a specific frame, a specific frame, take into account priorities take into account priorities optimization algorithms: tabu search, hill optimization algorithms: tabu search, hill

climbing, genetic algorithmsclimbing, genetic algorithms … …


Efficiency of offsets : Efficiency of offsets : some insight (1/2)some insight (1/2)

Almost a straight line, suggests that our algorithm is near-optimal

Work = time

to transmit the CAN

frames sent

by the station

s


Efficiency of offsets : Efficiency of offsets : some insight (2/2)some insight (2/2)

A larger workload waiting for transmission implies larger response times for the low priority frames ..


Computing worst-case response times with offsets


Computing frame worst-case Computing frame worst-case response time with offsetsresponse time with offsets

CAN Controller

buffer Tx

CAN Bus

AUTOSAR COM

Frame-packing task5ms

9 6 8

1

2

Waiting queue:

-FIFO

-Highest Priority First (HPF - Autosar)

-Carmaker specific

Requirements :

- handle 100+ frames

- very fast execution times

- ≠ waiting queue policy at the microcontroller level

- limited number of transmission buffers


WCRT : State of the art WCRT : State of the art

Scientific literature:Scientific literature: Complexity is exponential Complexity is exponential No schedulability analysis with offsets in the No schedulability analysis with offsets in the

distributed non-preemptive casedistributed non-preemptive case Offsets in the preemptive case : not suited for Offsets in the preemptive case : not suited for

> 10-20 tasks > 10-20 tasks WCRT without offsets: infinite number of Tx WCRT without offsets: infinite number of Tx

buffers and no queue at the microcontroller buffers and no queue at the microcontroller levellevel

RTaW software: RTaW software: NETCAR-AnalyzerNETCAR-Analyzer


NETCAR-Analyzer : developed at INRIA, then RealTime-at-Work


NETCAR-Analyzer : an overview Worst-case response times/jitters on CAN with and without offsets for the frames

Proven near-optimal offsets assignment algorithms with user-defined performance criteria: e.g. optimize the worst-case response times for a specific subset of tasks, for instance, the 10 lowest priority frames

Exhibit the situations leading to the worst-case: results can be checked by simulations/testing

Enable dimensioning transmission/reception buffers at the ECU and communication controller level

Handle both FIFO and prioritized waiting queues at the ECU level

Fast multi-core implementation: typically, an exact response time computation requires less than 30 seconds for 100 frames on a dual-core system

Gateway support: forwarding of signals/frames from one network to another,

In use since December 2006 at PSA Peugeot Citroën


Performance evaluation : Experimental SetupExperimental Setup WCRT of the frames wrt random offsets WCRT of the frames wrt random offsets and lower boundand lower bound WCRT reduction ratio for chassis and WCRT reduction ratio for chassis and body networksbody networks Load increase : add new ECUs / add Load increase : add new ECUs / add more trafficmore traffic


Experimental SetupExperimental Setup

Body and chassis networks

Network #ECUs #M essages Bandwidth Frame periodsBody 15-20 ¼70 125Kbit/ s 50ms-2s

Chassis 5-15 ¼60 500Kbit/ s 10ms-1s

Set of frames generated with NETCARBENCH (GPL-licensed – http://www.netcarbench.org)

With / without load concentration: one ECU generates 30% of the load


Offsets in practice : large response Offsets in practice : large response time improvements (1/2)time improvements (1/2)

21

17

32

65 ms


WCRT Reduction RatioWCRT Reduction Ratio

Body Networks Chassis Networks

Results are even better with loaded stations


Offsets allow higher network loadsOffsets allow higher network loads

Typically: WCRT at 60% with offsets Typically: WCRT at 60% with offsets WCRT at 30% without offsets WCRT at 30% without offsets


Partial offset usagePartial offset usage

34

17

42

65 ms


Conclusions on offsetsConclusions on offsets

Offsets provide an cost-effective short-term solution to postpone multiple CANs and FlexRay

Tradeoff between Event and Time Triggered

Further large improvements are possible by synchronizing the ECUs …

ET CAN CAN with offsets TT-CAN

+ Complexity+ Determinism


PART 2: Protocol basics and some configuration problems


Protocol basicsProtocol basics

MAC de type TDMA MAC F-TDMA Typically ST segment: 3 ms and DYN: 2ms Frames: up to 254 bytes, size is fixed in the static segment (BMW:16bytes) Data rate: between 500kbit/s and 10Mbit/s 64 ≠ communication schedules max. (but a slot always belongs to the same station)


FlexRay configuration FlexRay configuration Extremely complex problem:

Mixed of TT and ET scheduling Tightly linked with task scheduling Large number of parameters (>70) AUTOSAR constraints (OS, COM, etc) …

Design objectives should be first clearly identified: Minimum bandwidth to use cheap components (2.5

Mbit/s, 5MBit/s ?) Enable incremental design ? Carry-over of ECUs ?

No chance to solve the pb optimally – too many free variables, sub-problems alone are NP-hard


What is needed first : identify the What is needed first : identify the intended use of FlexRayintended use of FlexRay

Use of FlexRay at BMW – from [3]


Requirements on FlexRayRequirements on FlexRay Performance requirements: both run-time

(response times, jitters, etc.) and End-of-Line/Garage flash update

Incrementality requirements: additional functions or ECUs

Dependability requirements: fail-silence, babbling idiot, deadline failure probability under EMI, …

Platform requirements: platform wide frames (e.g., NM), carry-over of ECUs, able to deal with com. controller + CPU + Autosar stack performances, …


Tasks run either Tasks run either synchronously or asynchronouslysynchronously or asynchronously wrt wrt

the communication cyclethe communication cycle


Application software : synchronous or asynchronous wrt FlexRay time?

Crucial question - 3 cases:1. all applicative modules are synchronized with FlexRay

global time2. all applicative modules are running asynchronously3. combination of synchronized and asynchronous modules

Case 3 is likely since there are modules that cannot be synchronized (engine controller?) that might be reused from previous designs Case 3 requires both Static Cyclic Scheduling (SCS) and

Fixed Priority Scheduling (FPS)


Case 1 : synchronous case (1/2) Case 1 : synchronous case (1/2)

Best possible results with regard to signal latency and dependability

Picture from [1]


Case 1 : synchronous case (2/2) Case 1 : synchronous case (2/2)

But strong constraints:But strong constraints: require require Static Cyclic SchedulingStatic Cyclic Scheduling impose to re-design existing functions / design impose to re-design existing functions / design

according to the bus configurationaccording to the bus configuration task periods constrained by FlexRay/Autosar rules task periods constrained by FlexRay/Autosar rules

(cycle repetition, e.g. 10, 20, 40, 80ms with a (cycle repetition, e.g. 10, 20, 40, 80ms with a cycle=5ms)cycle=5ms)

might require to artificially might require to artificially increase the increase the frequency of some tasksfrequency of some tasks → CPU load→ CPU load

length of the communication cycle is cruciallength of the communication cycle is crucial


Case 2 : asynchronous caseCase 2 : asynchronous case

Signals produced at variable time points in Signals produced at variable time points in the roundthe round – depends on the scheduling of – depends on the scheduling of taskstasks

Static segment Dynamic segment

Signal Release interval

Signal freshness constraint imposes a range of slots for transmission and a min. frequency (every x cycles)

Typical case with legacy software


FlexRay configuration: FlexRay configuration: sub-problems (1/4)sub-problems (1/4)

1.1. Network configuration:Network configuration:1.1. TopologyTopology2.2. Redundant transmission support (bmw=no)Redundant transmission support (bmw=no)3.3. Data rate (bmw=10Mbit/s)Data rate (bmw=10Mbit/s)4.4. Bus-guardian : local, star coupler, none Bus-guardian : local, star coupler, none

(bmw=none)(bmw=none)

Contraints :Contraints : dependability objective, traffic dependability objective, traffic growth forecast, growth forecast, costscosts, interoperability with , interoperability with other FlexRay networks (same data rate other FlexRay networks (same data rate might be a plus), etc .. might be a plus), etc ..



2.2. Communication cycle:Communication cycle:1.1. Global size (e.g., bmw=5ms)Global size (e.g., bmw=5ms)

2.2. Length of the ST segment (e.g., bmw=3ms)Length of the ST segment (e.g., bmw=3ms)

3.3. Length of the dynamic segment (e.g., Length of the dynamic segment (e.g., bmw=2ms)bmw=2ms)

Constraints :Constraints : task periods, minimal task periods, minimal sampling rate (e.g., 2.5ms), efficient use of sampling rate (e.g., 2.5ms), efficient use of bandwidth (small cycles bandwidth (small cycles unused slots), unused slots), carry-over of ECUs, …carry-over of ECUs, …



3.3. Configuration of the ST and DYN Configuration of the ST and DYN segmentssegments

1.1. Number of ST slots Number of ST slots 2.2. Size of the ST slots (=size of the frame)Size of the ST slots (=size of the frame)3.3. Number DYN slotsNumber DYN slots

Contraints :Contraints : incremental design (how many incremental design (how many ST + DYN slots left unused?), efficient ST + DYN slots left unused?), efficient bandwidth usage (e.g., one large slot for an bandwidth usage (e.g., one large slot for an ECU or 2 small?), carry-over of ECUs, …ECU or 2 small?), carry-over of ECUs, …



4.4. Frame packingFrame packing for the ST and DYN Slots for the ST and DYN Slots

5.5. Allocation of the slots to the ECUsAllocation of the slots to the ECUs1.1. assign ST slots to ECUs – construct the 64 scheduleassign ST slots to ECUs – construct the 64 schedule2.2. assign DYN slots to ECUs – consider slot-multiplexingassign DYN slots to ECUs – consider slot-multiplexing

6.6. Assign a local priority to each frame for the Assign a local priority to each frame for the transmission on the DYN slotstransmission on the DYN slots own by a station own by a station

Algorithm support :Algorithm support : point 5.1 to be solved in link with task schedulingpoint 5.1 to be solved in link with task scheduling points 5.2 + 6. can be handled jointlypoints 5.2 + 6. can be handled jointly


Configuring FlexRayConfiguring FlexRay

The good news :The good news : many design choices are imposed by strategic decision many design choices are imposed by strategic decision

Most configuration sub-problems have been addressed Most configuration sub-problems have been addressed

independently (see references)independently (see references)

The bad news :The bad news : some non-trivial adaptations/improvements needed to some non-trivial adaptations/improvements needed to

existing workexisting work problem gets more complex if resource optimization is a problem gets more complex if resource optimization is a

constraint (≠current BMW network)constraint (≠current BMW network) optimal solution is out of reach anywayoptimal solution is out of reach anyway


Questions, feedback? Questions, feedback? please contact me atplease contact me at

[email protected]@loria.fr


References References


References – Offsets on CANReferences – Offsets on CAN[1] M. Grenier, L. Havet, N. Navet, "Pushing the limits of CAN - Scheduling frames [1] M. Grenier, L. Havet, N. Navet, "Pushing the limits of CAN - Scheduling frames

with offsets provides a major performance boost", Proc. of the 4th European with offsets provides a major performance boost", Proc. of the 4th European Congress Embedded Real Time Software (ERTS 2008), Toulouse, France, Congress Embedded Real Time Software (ERTS 2008), Toulouse, France, January 29 - February 1, 2008.January 29 - February 1, 2008.

[2] C. Braun, L. Havet, N. Navet, "NETCARBENCH: a benchmark for techniques and [2] C. Braun, L. Havet, N. Navet, "NETCARBENCH: a benchmark for techniques and tools used in the design of automotive communication systems", Proc of the tools used in the design of automotive communication systems", Proc of the 7th IFAC International Conference on Fieldbuses & Networks in Industrial & 7th IFAC International Conference on Fieldbuses & Networks in Industrial & Embedded Systems (FeT 2007), Toulouse, France, November 7-9, 2007.Embedded Systems (FeT 2007), Toulouse, France, November 7-9, 2007.

[3] M. Grenier, J. Goossens, and N. Navet, “Near-optimal fixed priority preemptive [3] M. Grenier, J. Goossens, and N. Navet, “Near-optimal fixed priority preemptive scheduling of offset free systems”. In Proc. of the 14th International scheduling of offset free systems”. In Proc. of the 14th International Conference on Network and Systems (RTNS’2006), Poitiers, France, May 30-Conference on Network and Systems (RTNS’2006), Poitiers, France, May 30-31, 2006.31, 2006.

[4] R.I. Davis, A. Burns, R.J. Bril, and J.J. Lukkien, “Controller Area Network (CAN) [4] R.I. Davis, A. Burns, R.J. Bril, and J.J. Lukkien, “Controller Area Network (CAN) schedulability analysis: Refuted, revisited and revised”, Real-Time Systems, schedulability analysis: Refuted, revisited and revised”, Real-Time Systems, 35(3):239–272, April 2007.35(3):239–272, April 2007.

[5] J. Goossens, “Scheduling of offset free systems”, Real-Time Systems, 24(2):239–[5] J. Goossens, “Scheduling of offset free systems”, Real-Time Systems, 24(2):239–258, March 2003.258, March 2003.

[6] K. Tindell and A. Burns, “Guaranteed message latencies for distributed safety-[6] K. Tindell and A. Burns, “Guaranteed message latencies for distributed safety-critical hard real-time control networks”, in 1st International CAN Conference critical hard real-time control networks”, in 1st International CAN Conference Proceedings, Germany, September 1994, 1994.Proceedings, Germany, September 1994, 1994.


References – FlexRay (1/2) References – FlexRay (1/2) FLEXRAYFLEXRAY – protocol and usage by carmarkers– protocol and usage by carmarkers

[1] B. Schätz, C. Kühnel, M. Gonschorek, “The FlexRay Protocol”, to appear in the [1] B. Schätz, C. Kühnel, M. Gonschorek, “The FlexRay Protocol”, to appear in the Automotive embedded Handbook, N. Navet, F. Simonot-Lion editors, CRC Automotive embedded Handbook, N. Navet, F. Simonot-Lion editors, CRC Press/Taylor and Francis, 2008. Press/Taylor and Francis, 2008.

[2] Vector Informatik GmbH, interview of Mr. Peteratzinger (BMW), Mr. Steiner [2] Vector Informatik GmbH, interview of Mr. Peteratzinger (BMW), Mr. Steiner (BMW), “Use of XCP on FlexRay at BMW”, published in “Collection of (BMW), “Use of XCP on FlexRay at BMW”, published in “Collection of professional articles”, 09/2006. Available at professional articles”, 09/2006. Available at www.vector-worldwide.com/articleswww.vector-worldwide.com/articles

[3] A. Schedl, “Goals and Architecture of FlexRay at BMW”, slides presented at the [3] A. Schedl, “Goals and Architecture of FlexRay at BMW”, slides presented at the Vector FlexRay Symposium, March 6 2007. Vector FlexRay Symposium, March 6 2007.

[4] J. Broy (Porsche A.G.), K.D. Müller-Glaser, “The impact of time-triggered [4] J. Broy (Porsche A.G.), K.D. Müller-Glaser, “The impact of time-triggered communication in automotive embedded systems”, IEEE SIES’2007, July 2007.communication in automotive embedded systems”, IEEE SIES’2007, July 2007.

FRAME PACKINGFRAME PACKING

[5] R. Saket, N. Navet, "Frame Packing Algorithms for Automotive Applications", [5] R. Saket, N. Navet, "Frame Packing Algorithms for Automotive Applications", Journal of Embedded Computing, vol. 2, n° 1, pp93-102, 2006.Journal of Embedded Computing, vol. 2, n° 1, pp93-102, 2006.

DEPENDABILITYDEPENDABILITY

[6] B. Gaujal, N. Navet, "Maximizing the Robustness of TDMA Networks with [6] B. Gaujal, N. Navet, "Maximizing the Robustness of TDMA Networks with Applications to TTP/C", Real-Time Systems, Kluwer Academic Publishers, vol Applications to TTP/C", Real-Time Systems, Kluwer Academic Publishers, vol 31, n°1-3, pp5-31, December 2005.31, n°1-3, pp5-31, December 2005.


References – FlexRay (2/2) References – FlexRay (2/2)

CONFIGURATION OF THE STATIC SEGMENTCONFIGURATION OF THE STATIC SEGMENT

[6] S. Ding, N. Murakami, H. Tomiyama, H. Takada, “A GA-based scheduling method for [6] S. Ding, N. Murakami, H. Tomiyama, H. Takada, “A GA-based scheduling method for FlexRay systems”, EMSOFT, 2005. FlexRay systems”, EMSOFT, 2005.

[7] A. Hamann, R. Ernst, “TDMA Time Slot and Turn Optimization with Evolutionary [7] A. Hamann, R. Ernst, “TDMA Time Slot and Turn Optimization with Evolutionary Search Techniques”, Proceedings of the Design, Automation and Test in Europe Search Techniques”, Proceedings of the Design, Automation and Test in Europe Conference, Volume 1, p312–317, 2005.Conference, Volume 1, p312–317, 2005.

[8] E. Wandeler, L. Thiele, “Optimal TDMA time slot and cycle length allocation for hard [8] E. Wandeler, L. Thiele, “Optimal TDMA time slot and cycle length allocation for hard real-time systems”, Proceedings of the 2006 conference on Asia South Pacific real-time systems”, Proceedings of the 2006 conference on Asia South Pacific design automation.design automation.

[9] M. Grenier, L. Havet, N. Navet, “[9] M. Grenier, L. Havet, N. Navet, “Configuring the communication on FlexRay: the Configuring the communication on FlexRay: the case of the static segment”, Proceedings of ERTS’2008.case of the static segment”, Proceedings of ERTS’2008.

CONFIGURATION OF THE DYNAMIC SEGMENTCONFIGURATION OF THE DYNAMIC SEGMENT

[10] T. Pop, P. Pop, P. Eles, Z. Peng, A. Andrei, “Timing Analysis of the FlexRay [10] T. Pop, P. Pop, P. Eles, Z. Peng, A. Andrei, “Timing Analysis of the FlexRay Communication Protocol”, ECRTS 2006.Communication Protocol”, ECRTS 2006.

[11] [11] T. Pop, P. Pop, P. Eles, Z. Peng,T. Pop, P. Pop, P. Eles, Z. Peng, “Bus Access Optimisation for FlexRay-based “Bus Access Optimisation for FlexRay-based Distributed Embedded Systems”, DATE 2007.Distributed Embedded Systems”, DATE 2007.

INTERFERENCE OF SCS TASKS ON FPS TASKSINTERFERENCE OF SCS TASKS ON FPS TASKS

[12] [12] T. Pop, P. Pop, P. Eles, Z. Peng,T. Pop, P. Pop, P. Eles, Z. Peng, “Optimization of Hierarchically Scheduled “Optimization of Hierarchically Scheduled Heterogeneous Embedded Systems”, RTCSA’2005.Heterogeneous Embedded Systems”, RTCSA’2005.

Trends in Embedded Communication Systems : Traffic Shaping on CAN and introduction of FlexRay Nicolas Navet ESIEE – 13/06/2008.

Documents

frames frame slide

ms slide

specific frame

ecus slide

efficiency of offsets

frames ecus

scheduling frames

task scheduling