Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations


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

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

2 © 2008 RealTime-at-Work - 2 In-vehicle networking : 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%)

3 © 2008 RealTime-at-Work - 3 PART 1: Scheduling messages with offsets on CAN

4 © 2008 RealTime-at-Work - 4 Scheduling frames with offsets ?! Periods 20 ms 15 ms 10 ms , ,5 0 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

5 © 2008 RealTime-at-Work - 5 System model (1/2) ECU Frame Transmission request task Frame response time  Performance metric: worst-case response time CAN Higher prio. frames frame

6 © 2008 RealTime-at-Work - 6 System model (2/2) The offset of a message stream is the time at which the transmission request of the first frame is issued The offset of a message stream is the time at which the transmission request of the first frame is issued Complexity: best choosing the offsets is exponential in the task periods → approximate solutions Complexity: best choosing the offsets is exponential in the task periods → approximate solutions Middleware task imposes a certain granularity Middleware task imposes a certain granularity Without ECU synchronisation, offsets are local to ECUs Without ECU synchronisation, offsets are local to ECUs

7 © 2008 RealTime-at-Work - 7 But task scheduling has to be adapted… ECU Frame Transmission request task Frame response time  In addition, avoiding consecutive frame constructions on an ECU allows to reduce latency CAN Higher prio. frames frame

8 © 2008 RealTime-at-Work - 8 Time Frame 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: f 1 =(T 1 =10), f 2 =(T 2 =20), f 3 (T 3 =20) f 1,1 f 1,2 f 2,1 f 3,1

9 © 2008 RealTime-at-Work - 9 Offsets Algorithm applied on a typical body network 21 ms 65 ms

10 © 2008 RealTime-at-Work - 10 Offsets Algorithm (3/3) Low complexity and efficient as is but further improvements possible: Low complexity and efficient as is but further improvements possible: add frame(s) / ECU(s) to an existing design add frame(s) / ECU(s) to an existing design user defined criteria : optimize last 10 frames, a specific frame, user defined criteria : optimize last 10 frames, a specific frame, take into account priorities take into account priorities optimization algorithms: tabu search, hill climbing, genetic algorithms optimization algorithms: tabu search, hill climbing, genetic algorithms …

11 © 2008 RealTime-at-Work - 11 Efficiency of offsets : 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 stations

12 © 2008 RealTime-at-Work - 12 Efficiency of offsets : some insight (2/2)  A larger workload waiting for transmission implies larger response times for the low priority frames..

13 © 2008 RealTime-at-Work - 13 Computing worst-case response times with offsets

14 © 2008 RealTime-at-Work - 14 Computing frame worst-case response time with offsets CAN Controller buffer Tx CAN Bus AUTOSAR COM Frame-packing task 5ms 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

15 © 2008 RealTime-at-Work - 15 WCRT : State of the art Scientific literature: Scientific literature: Complexity is exponential Complexity is exponential No schedulability analysis with offsets in the distributed non-preemptive case No schedulability analysis with offsets in the distributed non-preemptive case Offsets in the preemptive case : not suited for > tasks Offsets in the preemptive case : not suited for > tasks WCRT without offsets: infinite number of Tx buffers and no queue at the microcontroller level WCRT without offsets: infinite number of Tx buffers and no queue at the microcontroller level RTaW software: NETCAR-Analyzer RTaW software: NETCAR-Analyzer

16 © 2008 RealTime-at-Work - 16 NETCAR-Analyzer : developed at INRIA, then RealTime-at-Work

17 © 2008 RealTime-at-Work - 17 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

18 © 2008 RealTime-at-Work - 18 Performance evaluation :  Experimental Setup  WCRT of the frames wrt random offsets and lower bound  WCRT reduction ratio for chassis and body networks  Load increase : add new ECUs / add more traffic

19 © 2008 RealTime-at-Work - 19 Experimental Setup  Body and chassis networks  Set of frames generated with NETCARBENCH (GPL- licensed – With / without load concentration: one ECU generates 30% of the load

20 © 2008 RealTime-at-Work - 20 Offsets in practice : large response time improvements (1/2) ms

21 © 2008 RealTime-at-Work - 21 WCRT Reduction Ratio Body Networks Chassis Networks  Results are even better with loaded stations

22 © 2008 RealTime-at-Work - 22 Offsets allow higher network loads Typically: WCRT at 60% with offsets  WCRT at 30% without offsets Typically: WCRT at 60% with offsets  WCRT at 30% without offsets

23 © 2008 RealTime-at-Work - 23 Partial offset usage ms

24 © 2008 RealTime-at-Work - 24 Conclusions 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

25 © 2008 RealTime-at-Work - 25 PART 2: Protocol basics and some configuration problems

26 © 2008 RealTime-at-Work - 26 Protocol basics MAC de type TDMAMAC 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)

27 © 2008 RealTime-at-Work - 27 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

28 © 2008 RealTime-at-Work - 28 What is needed first : identify the intended use of FlexRay Use of FlexRay at BMW – from [3]

29 © 2008 RealTime-at-Work - 29 Requirements 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, …

30 © 2008 RealTime-at-Work - 30 Tasks run either synchronously or asynchronously wrt the communication cycle

31 © 2008 RealTime-at-Work - 31 Application software : synchronous or asynchronous wrt FlexRay time? Crucial question - 3 cases: all applicative modules are synchronized with FlexRay global time all applicative modules are running asynchronously 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)

32 © 2008 RealTime-at-Work - 32 Case 1 : synchronous case (1/2) Best possible results with regard to signal latency and dependability Picture from [1]

33 © 2008 RealTime-at-Work - 33 Case 1 : synchronous case (2/2) But strong constraints: But strong constraints: require Static Cyclic Scheduling require Static Cyclic Scheduling impose to re-design existing functions / design according to the bus configuration impose to re-design existing functions / design according to the bus configuration task periods constrained by FlexRay/Autosar rules (cycle repetition, e.g. 10, 20, 40, 80ms with a cycle=5ms) task periods constrained by FlexRay/Autosar rules (cycle repetition, e.g. 10, 20, 40, 80ms with a cycle=5ms)  might require to artificially increase the frequency of some tasks → CPU load length of the communication cycle is crucial length of the communication cycle is crucial

34 © 2008 RealTime-at-Work - 34 Case 2 : asynchronous case Signals produced at variable time points in the round – depends on the scheduling of tasks Signals produced at variable time points in the round – depends on the scheduling of tasks Static segmentDynamic 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

35 © 2008 RealTime-at-Work - 35 FlexRay configuration: sub-problems (1/4) 1.Network configuration: 1. Topology 2. Redundant transmission support (bmw=no) 3. Data rate (bmw=10Mbit/s) 4. Bus-guardian : local, star coupler, none (bmw=none)  Contraints : dependability objective, traffic growth forecast, costs, interoperability with other FlexRay networks (same data rate might be a plus), etc..

36 © 2008 RealTime-at-Work - 36 FlexRay configuration: sub-problems (2/4) 2.Communication cycle: 1. Global size (e.g., bmw=5ms) 2. Length of the ST segment (e.g., bmw=3ms) 3. Length of the dynamic segment (e.g., bmw=2ms)  Constraints : task periods, minimal sampling rate (e.g., 2.5ms), efficient use of bandwidth (small cycles  unused slots), carry-over of ECUs, …

37 © 2008 RealTime-at-Work - 37 FlexRay configuration: sub-problems (3/4) 3.Configuration of the ST and DYN segments 1. Number of ST slots 2. Size of the ST slots (=size of the frame) 3. Number DYN slots  Contraints : incremental design (how many ST + DYN slots left unused?), efficient bandwidth usage (e.g., one large slot for an ECU or 2 small?), carry-over of ECUs, …

38 © 2008 RealTime-at-Work - 38 FlexRay configuration: sub-problems (4/4) 4.Frame packing for the ST and DYN Slots 5.Allocation of the slots to the ECUs 1. assign ST slots to ECUs – construct the 64 schedule 2. assign DYN slots to ECUs – consider slot-multiplexing 6.Assign a local priority to each frame for the transmission on the DYN slots own by a station 6.Assign a local priority to each frame for the transmission on the DYN slots own by a station  Algorithm support :  point 5.1 to be solved in link with task scheduling  points can be handled jointly

39 © 2008 RealTime-at-Work - 39 Configuring 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 independently (see references) Most configuration sub-problems have been addressed independently (see references) The bad news : The bad news : some non-trivial adaptations/improvements needed to existing work some non-trivial adaptations/improvements needed to existing work problem gets more complex if resource optimization is a constraint (≠current BMW network) problem gets more complex if resource optimization is a constraint (≠current BMW network) optimal solution is out of reach anyway optimal solution is out of reach anyway

40 © 2008 RealTime-at-Work - 40 Questions, feedback? please contact me at

41 © 2008 RealTime-at-Work - 41 References

42 © 2008 RealTime-at-Work - 42 References – Offsets on CAN [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 Congress Embedded Real Time Software (ERTS 2008), Toulouse, France, January 29 - February 1, [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 7th IFAC International Conference on Fieldbuses & Networks in Industrial & Embedded Systems (FeT 2007), Toulouse, France, November 7-9, [3] M. Grenier, J. Goossens, and N. Navet, “Near-optimal fixed priority preemptive scheduling of offset free systems”. In Proc. of the 14th International Conference on Network and Systems (RTNS’2006), Poitiers, France, May , [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, 35(3):239–272, April [5] J. Goossens, “Scheduling of offset free systems”, Real-Time Systems, 24(2):239–258, March [6] K. Tindell and A. Burns, “Guaranteed message latencies for distributed safety- critical hard real-time control networks”, in 1st International CAN Conference Proceedings, Germany, September 1994, 1994.

43 © 2008 RealTime-at-Work - 43 References – FlexRay (1/2) FLEXRAY – protocol and usage by carmarkers [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 Press/Taylor and Francis, [2] Vector Informatik GmbH, interview of Mr. Peteratzinger (BMW), Mr. Steiner (BMW), “Use of XCP on FlexRay at BMW”, published in “Collection of professional articles”, 09/2006. Available at worldwide.com/articles [3] A. Schedl, “Goals and Architecture of FlexRay at BMW”, slides presented at the Vector FlexRay Symposium, March [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 FRAME PACKING [5] R. Saket, N. Navet, "Frame Packing Algorithms for Automotive Applications", Journal of Embedded Computing, vol. 2, n° 1, pp93-102, DEPENDABILITY [6] B. Gaujal, N. Navet, "Maximizing the Robustness of TDMA Networks with Applications to TTP/C", Real-Time Systems, Kluwer Academic Publishers, vol 31, n°1-3, pp5-31, December 2005.

44 © 2008 RealTime-at-Work - 44 References – FlexRay (2/2) CONFIGURATION OF THE STATIC SEGMENT [6] S. Ding, N. Murakami, H. Tomiyama, H. Takada, “A GA-based scheduling method for FlexRay systems”, EMSOFT, [7] A. Hamann, R. Ernst, “TDMA Time Slot and Turn Optimization with Evolutionary Search Techniques”, Proceedings of the Design, Automation and Test in Europe Conference, Volume 1, p312–317, [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 design automation. [9] M. Grenier, L. Havet, N. Navet, “Configuring the communication on FlexRay: the case of the static segment”, Proceedings of ERTS’2008. CONFIGURATION OF THE DYNAMIC SEGMENT [10] T. Pop, P. Pop, P. Eles, Z. Peng, A. Andrei, “Timing Analysis of the FlexRay Communication Protocol”, ECRTS [11] T. Pop, P. Pop, P. Eles, Z. Peng, “Bus Access Optimisation for FlexRay-based Distributed Embedded Systems”, DATE INTERFERENCE OF SCS TASKS ON FPS TASKS [12] T. Pop, P. Pop, P. Eles, Z. Peng, “Optimization of Hierarchically Scheduled Heterogeneous Embedded Systems”, RTCSA’2005.


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

Similar presentations


Ads by Google