Pushing the limits of Controller Area Network (CAN)


Published on

Slides of a talk given at ERTS2008 in Toulouse. Abstract: with the increasing amount of electronics, making best usage of the bandwidth becomes of primary importance in automotive networks. One
solution that is being investigated by car manufacturers is to schedule the messages with offsets, which leads to a desynchronization of the message streams. As it will be shown, this “traffic shaping” strategy is very beneficial in terms of worst-case response times. In this slides, the problem of choosing the best offsets is addressed in the case of Controller Area Network, which is a de-facto standard in the automotive world. Comprehensive experiments shown give insight into the fundamental reasons why offsets are efficient, and demonstrate that offsets actually provide a major performance boost in terms of response times. These experimental results suggest that sound offset strategies may extend the lifespan of CAN further, and may defer the introduction of FlexRay and additional CAN networks.

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Pushing the limits of Controller Area Network (CAN)

  1. 1. Pushing the limits of CAN - Scheduling frames with offsets provides a major performance boost Nicolas NAVET INRIA / RealTime-at-Work http://www.loria.fr/~nnavet http://www.realtimeatwork.com [email_address] ERTS – 30/01/2008 Joint work with Mathieu GRENIER and Lionel HAVET
  2. 2. In-vehicle networking : will CAN be able to keep up the pace? <ul><li>Typically max. bus load is set to 35% </li></ul><ul><li>Not enough wrt to short/medium term bandwidth needs … </li></ul><ul><ul><li>Solution 1: multiple CAN networks … but gateways induce heavy overhead </li></ul></ul><ul><ul><li>Solution 2: switch to FlexRay … expensive for bandwidth alone </li></ul></ul><ul><ul><li>Solution 3: optimize the scheduling of CAN frame .. Offsets provide a solution to make CAN predictable at higher network load (≥60%) </li></ul></ul>
  3. 3. Scheduling frames with offsets ?! Principle: desynchronize transmissions to avoid load peaks Algorithms to decide offsets are based on arithmetical properties of the periods and size of the frame 0 0 0 10 5 0 15 5 5 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 5 2,5 0 110 5 2,5 0 Periods 20 ms 15 ms 10 ms
  4. 4. System model (1/2) ECU Frame Transmission request task Frame response time <ul><li>Performance metric: worst-case response time </li></ul>CAN Higher prio. frames frame
  5. 5. System model (2/2) <ul><li>The offset of a message stream is the time at which the transmission request of the first frame is issued </li></ul><ul><li>Complexity: best choosing the offsets is exponential in the task periods -> approximate solutions </li></ul><ul><li>Middleware task imposes a certain granularity </li></ul><ul><li>Without ECU synchronisation, offsets are local to ECUs </li></ul>
  6. 6. But task scheduling has to be adapted… ECU <ul><li>In addition, avoiding consecutive frame constructions on an ECU allows to reduce latency </li></ul>Frame Transmission request task Frame response time CAN Higher prio. frames frame
  7. 7. Offsets Algorithm (1/3) <ul><li>Ideas: </li></ul><ul><ul><li>assign offsets in the order of the transmission frequencies </li></ul></ul><ul><ul><li>release of the first frame is as far as possible from adjacent frames </li></ul></ul><ul><ul><li>identify “least loaded interval” </li></ul></ul><ul><li>Ex: f 1 =(T 1 =10) , f 2 =(T 2 =20) , f 3 (T 3 =20) </li></ul>f 1,1 f 1,2 f 2,1 f 3,1 Frame 18 16 14 12 10 8 6 4 2 0 Time
  8. 8. Offsets Algorithm applied on a typical body network 21 ms 65 ms
  9. 9. Offsets Algorithm (3/3) <ul><li>Low complexity and efficient as is but further improvements possible: </li></ul><ul><ul><li>add frame(s) / ECU(s) to an existing design </li></ul></ul><ul><ul><li>user defined criteria : optimize last 10 frames, a specific frame, </li></ul></ul><ul><ul><li>take into account priorities </li></ul></ul><ul><ul><li>optimization algorithms: tabu search, hill climbing, genetic algorithms </li></ul></ul><ul><ul><li>… </li></ul></ul>
  10. 10. Efficiency of offsets : some insight (1/2) <ul><li>Almost a straight line, suggests that our algorithm is near-optimal </li></ul>Work = time to transmit the CAN frames sent by the stations
  11. 11. Efficiency of offsets : some insight (2/2) <ul><li>A larger workload waiting for transmission implies larger response times for the low priority frames .. </li></ul>
  12. 12. Computing worst-case response times with offsets
  13. 13. Computing frame worst-case response time with offsets CAN Controller buffer Tx CAN Bus 9 6 8 1 2 <ul><li>Waiting queue : </li></ul><ul><li>FIFO </li></ul><ul><li>Highest Priority First (HPF - Autosar) </li></ul><ul><li>Carmaker specific </li></ul><ul><li>Requirements : </li></ul><ul><li>handle 100+ frames </li></ul><ul><li>very fast execution times </li></ul><ul><li>≠ waiting queue policy at the microcontroller level </li></ul><ul><li>limited number of transmission buffers </li></ul>AUTOSAR COM Frame-packing task 5ms
  14. 14. WCRT : State of the art <ul><li>Scientific literature: </li></ul><ul><ul><li>Complexity is exponential </li></ul></ul><ul><ul><li>No schedulability analysis with offsets in the distributed non-preemptive case </li></ul></ul><ul><ul><li>Offsets in the preemptive case : not suited for > 10-20 tasks </li></ul></ul><ul><ul><li>WCRT without offsets: infinite number of Tx buffers and no queue at the microcontroller level </li></ul></ul><ul><li>Our software: NETCAR-Analyzer </li></ul>
  15. 15. NETCAR-Analyzer : developed at INRIA, then RealTime-at-Work
  16. 16. <ul><li>NETCAR-Analyzer : an overview </li></ul><ul><li>Worst-case response time on CAN with and without offsets </li></ul><ul><li>Proven near-optimal offsets assignments with user-defined performance criteria (e.g. WCRT of the 10 lowest prio. frames) </li></ul><ul><li>Exhibit the situations leading to the worst-case (results can be checked by simulations/testing) </li></ul><ul><li>Enable to dimension transmission/reception buffers (RAM) </li></ul><ul><li>Handle both FIFO and prioritized ECUs </li></ul><ul><li>Fast multi-core implementation (<1mn for 100 frames) </li></ul><ul><li>Industrial use since December 2006 </li></ul>
  17. 17. <ul><li>Experimental Setup </li></ul><ul><li>WCRT of the frames wrt random offsets and lower bound </li></ul><ul><li>WCRT reduction ratio for chassis and body networks </li></ul><ul><li>Load increase : add new ECUs / add more traffic </li></ul>Performance evaluation :
  18. 18. Experimental Setup <ul><li>Body and chassis networks </li></ul><ul><li>Set of frames generated with NETCARBENCH (GPL-licenced) </li></ul>With / without load concentration: one ECU generates 30% of the load N e t w o r k # E C U s # M e s s a g e s B a n d w i d t h F r a m e p e r i o d s B o d y 1 5 - 2 0 ¼ 7 0 1 2 5 K b i t / s 5 0 m s - 2 s C h a s s i s 5 - 1 5 ¼ 6 0 5 0 0 K b i t / s 1 0 m s - 1 s
  19. 19. Offsets in practice : large response time improvements (1/2) 21 17 32 65 ms
  20. 20. WCRT Reduction Ratio Body Networks Chassis Networks <ul><li>Results are even better with loaded stations </li></ul>
  21. 21. Offsets allow higher network loads <ul><li>Typically: WCRT at 60% with offsets  WCRT at 30% without offsets </li></ul>
  22. 22. Partial offset usage 34 17 42 65 ms
  23. 23. Conclusions <ul><li>Offsets provide an cost-effective short-term solution to postpone multiple CANs and FlexRay </li></ul><ul><li>Tradeoff between Event and Time Triggered </li></ul><ul><li>Further large improvements are possible by synchronizing the ECUs … </li></ul>ET CAN CAN with offsets TT-CAN + Complexity + Determinism
  24. 24. Questions, feedback? please contact me at [email_address]