CAN in Automotive Applications: a Look Forward

3,763 views
3,743 views

Published on

There is today more than 20 years of experience in automotive CAN applications, and CAN has certainly proven very successful as a robust, cost effective and all-around network technology. But the use of CAN in vehicles is evolving, in particular because of more complex and heterogeneous architectures with FlexRay or Ethernet networks, and because of recent needs like hybrid, electric propulsion or driver assistance that involves more stringent real-time constraints. Besides, there are other new requirements on CAN: more fine-grained ECU mode management for energy savings, multi-ECU splitted functions and huge software downloads. In parallel, safety issues request more and more mechanisms to protect against potential failures and provide end-to-end integrity. The development process is also evolving with the advent of multi-domain cooperation, Autosar, ISO2626-2 and the always shorter time-to-market requirements. In this landscape, CAN has now to be used at much higher bus load level than in the past, and there is less margin for error. What does it imply in terms of verification and validation? What are the characteristics of the communication stacks that should be paid attention to? This article is intended to shed some light and share our views on these issues.

Published in: Automotive, Technology, Business
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
3,763
On SlideShare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
81
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

CAN in Automotive Applications: a Look Forward

  1. 1. CAN in Automotive Applications:a Look ForwardNicolas NAVET (INRIA/RTaW), Hervé PERRAULT (PSA)13th International CAN ConferenceHambach Castle, March 5-6 2012. March, 5 2012
  2. 2. Automotive CAN: the early days (1/2)Priority Sender node DLC Period (ms) 1 Engine Controller 8 10 2 Wheel angle sensor 3 14 3 Engine Controller 3 20 4 AGB 2 15 5 ABS 5 20 6 stations, 12 frames, 6 ABS 5 40 21% load 7 ABS 4 15 8 Body gateway 5 50 9 undisclosed 4 20 10 Engine Controller 7 100 11 AGB 5 50 12 ABS 1 100 Early CAN project at PSA (1996, see [1]) 250kbit/s 05/03/2012 - 2
  3. 3. Automotive CAN: the early days (2/2) Worst-case latencies (=response times) are less than 5.5 ms NETCAR-Analyzer screenshot 05/03/2012 - 3
  4. 4. Proliferation of ECUs and buses 45 40 35 30 CAN LAS info-div LIN 25 CAN CAR CAN CONF 20 CAN I/S 15 Up to 5 CAN 10 interconnected 5 by gateways 0 X4-2000 X4-2003 D2 2004 D2 TG D25 X3 X6-2005 X7-2007 W2 PF3 # ECUs and buses in some PSA projects between 2000 and 2010 [2]
  5. 5. Today’s set of messages• Size : Up to 20 nodes and 100 frames “easy” integration• Bus-rate : 250 or 500kbits for the OEM till 35-40% - precise• Load : > 50%, sometimes 60% or more … performance evaluation• Max latencies : 5ms or less needed beyond• Gateways : CAN/CAN or CAN/FLEXRAY induce delays and bursty traffic.• Aperiodic traffic (eg, Autosar mixed transmission mode) NETCARBENCH is a GPL licensed software to generate “realistic” and non confidential CAN message sets according to a set of user-defined parameters. Available at www.netcarbench.org 05/03/2012 - 5
  6. 6. RTaW : help designers build truly safe and optimized systems – Services and Software for : architecture design, ECU and network configuration, formal and temporal verification (simulation, analysis, trace-inspection) – Communications systems : CAN, FlexRay, AFDX, industrial Ethernet, TTP, etc … – CAN customers: PSA and Renault− Most software tools are downloadableat www.realtimeatwork.com / we provideR&D, support and custom extensions− No black box software: we publish allalgorithms that are implemented(ongoing) RTaW-Sim CAN simulator 05/03/2012 - 6
  7. 7. 2Optimizing CAN networksWhat levers do we have and what it implies ? 05/03/2012 - 7
  8. 8. Automotive CAN communication stack : a simplified view ECU Middleware 1 Waiting queue: 5ms Frame-packing task 1 - FIFO - Highest Priority First 1 - OEM specific 2000 CAN Controller 9 6 8 buffer Tx CAN Bus
  9. 9. Optimizing CAN : meeting performance and robustnessconstraints at higher load An industrial requirement • Reduce architecture complexity, HW costs & weight, consumption and emission • Avoid industrial risks and costs of new technologies • Incremental design / better performances How ? 1. Keep amount of data transmitted minimum! → better identification and traceability of timing constraints 2. Synchronize producing tasks with communication tasks 3. Desynchronize frames by using offsets [3,4] 4. Assign priorities according to deadlines 5. Re-consider frame packing [12] 6. Optimize communication stacks so as to remove all “distortions” to the ideal CAN behavior -9
  10. 10. Scheduling frames with offsets ?!Principle: desynchronize transmissions to avoid load peaks 0 10 15 Periods 0 5 5 20 ms 0 0 5 15 ms 10 ms 0 10 20 30 40 50 60 70 80 90 100 110 5 5 2,5 2,5 Periods 0 0 20 ms 15 ms 10 ms 0 10 20 30 40 50 60 70 80 90 100 110
  11. 11. Offsets algorithm applied on a typical bodynetwork least-loaded algorithm [3] 65 ms 32 21 17 Worst-case latencies on a 125 kbit/s body network
  12. 12. Let’s assume frame waiting queue is FIFO on ECU1, the OEM doesnot know it or software cannot handle it … Many high-priority frames are delayed here because a single ECU (out of 15) has a FIFO queue … could propagate through gateways Up to recently [5,6], no response analysis on CAN was published …
  13. 13. Our work : bridging the gap between (analytic)models and reality Higher load → less margin → more accurate models 1 Hardware models 2 Error bursts Software models (producer, sender, receiver, device drivers, etc) 3 Error models (reboot,errors) Interarrival times Individual errors 4 Aperiodic traces Traffic models incl. aperiodic - 13
  14. 14. 3Departure from the ideal CANbehaviorSome reasons 05/03/2012 - 14
  15. 15. Departure from ideal CAN (1/2)ECU Middleware 1 5ms Frame-packing task 1 1 20001 Non-HPF waiting queues [5,6] CAN Controller2 Frame queuing not done in priority order by 9 6 8 communication task buffer Tx CAN B
  16. 16. Analyzing communication traces : priorityinversion Priority inversion here (probably) because frames are not queued in the order of priority RTaW-TraceInspector : check comm. stack implementation, periods, offsets, aperiodic traffic, clock drifts, etc .. 05/03/2012 - 16
  17. 17. Departure from ideal CAN (2/2)ECU Middleware 5ms Frame-packing task 23 Non abortable transmission requests [9] 14 Not enough transmission buffers [8,10] CAN Controller5 Delays in refilling the buffers [11] 9 6 8… buffer Tx CAN Bu
  18. 18. Higher load level calls for 1. More constraining specifications / or conservative assumptions → a single node can jeopardize the system 2. Thorough use of Validation & Verification techniques: − simulation, analysis and trace inspection − none of them alone is sufficient ! Know-how, embedded software, verification techniques, and tool support have progressed to a point where highly loaded CAN networks - yet safe are possible 05/03/2012 - 18
  19. 19. References 05/03/2012 - 19
  20. 20. [1] N. Navet, Y-Q. Song, F. Simonot, “Worst-Case Deadline Failure Probability in Real-Time Applications Distributed over CAN (Controller Area Network)“, Journal of Systems Architecture, Elsevier Science, vol. 46, n°7, 2000. Available at www.realtimeatwork.com [2] N. Navet, B. Delord (PSA), M. Baumeister (Freescale), “Virtualization in Automotive Embedded Systems : an Outlook”, talk at RTS Embedded Systems 2010, Paris, France, March, 2010. Available atReferences www.realtimeatwork.com [3] 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, 2008. Available at www.realtimeatwork.com [4] P. Meumeu-Yomsi, D. Bertrand, N. Navet, R. Davis, "Controller Area Network (CAN): Response Time Analysis with Offsets", to appear in Proc. of the 9th IEEE International Workshop on Factory Communication System (WFCS 2012), May 21-24, 2012, Lemgo/Detmold, Germany. [5] R.I. Davis, S. Kollmann, V. Pollex, F. Slomka, "Controller Area Network (CAN) Schedulability Analysis with FIFO queues”. In proceedings 23rd Euromicro Conference on Real-Time Systems (ECRTS), pages 45-56, July 2011. [6] R. Davis, N. Navet, "Controller Area Network (CAN) Schedulability Analysis for Messages with Arbitrary Deadlines in FIFO and Work-Conserving Queues", to appear in Proc. of the 9th IEEE International Workshop on Factory Communication System (WFCS 2012), May 21-24, 2012, Lemgo/Detmold, Germany. [7] R. Davis, A. Burn, R. Bril, and J. Lukkien, “Controller Area Network (CAN) schedulability analysis: Refuted, revisited and revised”, Real-Time Systems, vol. 35, pp. 239–272, 2007. [8] M. D. Natale, “Evaluating message transmission times in Controller Area Networks without buffer preemption”, in 8th Brazilian Workshop on Real-Time Systems, 2006. [9] D. Khan, R. Davis, N. Navet, “Schedulability analysis of CAN with non-abortable transmission requests“, 16th IEEE International Conference on Emerging Technologies and Factory Automation (ETFA 2011), Toulouse, France, September 2011. Available at www.realtimeatwork.com [10] U. Keskin, R. Bril, and J. Lukkien, “Evaluating message transmission times in Controller Area Network (CAN) without buffer preemption revisited”, to appear in Proc. of the 9th IEEE International Workshop on Factory Communication System (WFCS 2012), May 21-24, 2012, Lemgo/Detmold, Germany. [11] D. Khan, R. Bril, N. Navet, “Integrating Hardware Limitations in CAN Schedulability Analysis”, WiP at the 8th IEEE International Workshop on Factory Communication Systems (WFCS 2010), Nancy, France, May 2010. Available at www.realtimeatwork.com [12] R. Saket, N. Navet, “Frame Packing Algorithms for Automotive Applications“, Journal of Embedded Computing, vol. 2, n° 1, pp93-102, 2006. Available at www.realtimeatwork.com [13] N. Navet, H. Perrault, “CAN in Automotive Applications: a look forward”, 13th International CAN Conference, Hambach Castle, March 5-6, 2012. Available at www.realtimeatwork.com 05/03/2012 - 20
  21. 21. Software used in this study  NETCARBENCH, automotive benchmark generator, freely available at http://www.netcarbench.org  RTaW-Sim, Fine-grained simulation of CAN based communication systems with fault injection capabilities”, downloadable at http://www.realtimeatwork.com/software/rtaw-sim/  NETCAR-Analyzer, Timing analysis and resource usage optimization for CAN based communication systems, downloadable at http://www.realtimeatwork.com/software/netcar-analyzer/  RTaW-TraceInspector, Analyze communication traces and check communication stack implementation and specification compliance, see http://www.realtimeatwork.com/software/rtaw-traceinspector/ 05/03/2012 - 21

×