Multicore scheduling in automotive ECUs


Published on

As the demand for computing power is quickly
increasing in the automotive domain, car manufactur-ers and tier-one suppliers are gradually introducing mul-ticore ECUs in their electronic architectures. Additionally, these multicore ECUs offer new features such as higher levels of parallelism which eases the respect of
the safety requirements introduced by the ISO 26262 and can be taken advantage of in various other automotive use-cases. These new features involve also more complexity in the design, development and verification of the software applications. Hence, OEMs and suppliers will require new tools and methodologies for deployment and
validation. In this paper, we present the main use cases
for multicore ECUs and then focus on one of them. Pre-
cisely, we address the problem of scheduling numerous
elementary software components (called runnables) on
a limited set of identical cores. In the context of an au-
tomotive design, we assume the use of the static task
partitioning scheme which provides simplicity and bet-
ter predictability for the ECU designers by comparison
with a global scheduling approach. We show how the
global scheduling problem can be addressed as two sub-
problems: partitioning the set of runnables and building
the schedule on each core. At that point, we prove that
each of the sub-problems cannot be solved optimally due
to their algorithmic complexity. We then present low com-
plexity heuristics to partition and build a schedule of the
runnable set on each core before discussing schedula-
bility verification methods. Finally, we assess the perfor-
mance of our approach on realistic case-studies.

  • Be the first to comment

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

No notes for slide

Multicore scheduling in automotive ECUs

  1. 1. Multicore scheduling in automotive ECUs Aurélien Monot - PSA Peugeot Citroën, LORIA Nicolas Navet - INRIA, RealTime-at-Work Françoise Simonot - LORIA Bernard Bavoux - PSA Peugeot Citroën Talk at ERTS2 2010 Toulouse, May 21st 2010
  2. 2. 2 Outlook Context: New tools and methodologies are needed as multicore ECUs are being introduced in the automotive EE architecture. Problem: How to address the scheduling of numerous runnables on a multicore ECUs in the context of the automotive domain? Method: Deployment of load balancing algorithms in ECU configuration tools.
  3. 3. 3 The case of a generic car manufacturer Typical number of ECUs in a car in 2000 : 20 Typical number of ECUs in a car in 2010 : over 40 The number of ECUs has more than doubled in 10 years Other examples Between 60 and 80 ECUs in the Audi A8 Over 100 ECUs in some Lexus !
  4. 4. 4 Moving towards multicore architecture Decreasing the complexity of in-vehicle architecture: reduces EE design and verification efforts decreases number of network interfaces decreases traffic on CAN network reduces costs ECU 1 ECU 2 Tas Tas Tas k k k Tas Tas Tas k k k
  5. 5. 5 Moving towards multicore architecture Other use cases for the automotive domain Dealing with resource demanding applications ‣ engine control, image processing... Improving the safety ‣ segragation of multi-source software, ISO26262... Dedicated use of core ‣ monitoring, event-triggered tasks General benefits of multi-core reduced power consumption reduced heat reduced EMC
  6. 6. 6 AutoSAR requirements • Static partitioning • Static cyclic scheduling using schedule tables • BSW are all allocated on the same core
  7. 7. 7 Problem Goal: schedule numerous runnables on a multicore ECU Two sub-problems Partitioning ‣ 600 runnables on 2 cores : 2600 possible allocations Build schedule table ‣ 300 runnables in 200 slots (expiry points) : 200300 schedules Sub-objectives and criteria Avoid load peaks ‣ Max Balance load over time ‣ Standard Deviation
  8. 8. 8 Model Runnables P1=10 R P2=10 R1 C1=2 C2=1 2 •Period O1=0 O2=5 •WCET •Initial Offset P3=20 P4=20 R3 C3=3 R4 C4=2 •Core allocation constraint O3=5 O4=15 •Colocation constraint Sequencer task R R R R R1 R3 R1 R4 R1 R3 R1 R4 2 2 2 2 0 5 10 15 20 25 30 35 40 Ttic Slots Tcycle
  9. 9. 9 Solution Partitioning is dealt with as a bin packing problem Worst fit decreasing algorithm with fixed number of bins Load Balancing is done with the Least Loaded algorithm (LL) inspired from CAN domain [Grenier and Navet ERTSS2008] Extended to handle non harmonic runnable sets (G-LL) Improved so as to reduce further load peaks (G-LLσ) Implemented in a tool Freely available soon at
  10. 10. 10 Experiments with RTaW-ECU
  11. 11. 11 Harmonic task sets LL Max: 4.79 Min: 4.52 StdDvt: 0.038 G-LLσ Max: 4.75 Min: 4.65 StdDvt: 0.018 Generated load: 94%, Ttic=5ms, Tcycle = 1s
  12. 12. 12 Non harmonic task sets Cmax Schedulability bound in the harmonic case 1− Ttic Generated 95% 97% 95% 97% Max WCET (μs) 150 300 900 CPU load Schedulability 94% 82% Schedulability 97% 94% 82% bound in the Max WCET = Max WCET = 900μs bound in the harmonic case 300μs harmonic case Success % of 64% 18% 12% 1% Success % of LL 96% 96% 92% LL Success % of 94% 94% 30% 5% Success % of G-LL 100% 100% 100% G-LL Success % of 100% 100% 97% 76% G-LL1σ Statistics collected over 1000 generated runnable sets
  13. 13. 13 Multiple synchronized sequencer tasks per core Incremental scheduling of three synchronized sequencer tasks with respective load of 45%, 35% and 15% resulting in 95% of the core capacity. Tcycle=1000ms and Ttic=5ms
  14. 14. 14 Multiple non synchronized sequencer tasks per core Case arises for sequencer tasks using different tic counters Engine control applications (standard time vs RPM) Any offset between the sequencer tasks and all clock rates are possible during runtime each sequencer task needs to be balanced independantly Verification is possible considering maximum clock rates Multi-frame scheduling results can be used
  15. 15. 15 Conclusion Adoption of multicore ECU raises new challenges Evolution of software architecture design Scheduling of software components We propose runnable scheduling heuristics for ECUs Fast and performant Easily adaptable for more advanced applications Compatible with AutoSAR R4.0 and its multicore extensions Future work Precedence constraints Lockstep synchronization Distributed timing chains
  16. 16. 16 Thank you for your attention