1. Requirements and Solutions for Timing Analysis of Automotive Systems Saoussen Anssi 1, Sébastien Gérard 2, Arnaud Albinet 1, François Terrier 2 1 Continental Automotive France SAS, PowerTrain E IPP {saoussen.ansi, arnaud.albinet}@continental-corporation.com 2 CEA LIST, Laboratory of model driven engineering for embedded systems, {françois.terrier, sebastien.gerard}@cea.fr

2. 2 SAM’2010, October Requirements and Solutions for Timing Analysis of Automotive Systems 2 Timing Analysis in Automotive Software Design Increasing Complexity Limited Resources Timing Constraints Safety Requirements Automotive Applications Timing Verification in automotive software design Performed Late after the implementation Addressed by means of measuring & testing No formal / systematic analysis No methodological support Design mistakes detected late High design cost Long time-to-market Necessity to integrate timing verification in the automotive development process

3. 3 SAM’2010, October Requirements and Solutions for Timing Analysis of Automotive Systems Work Context  P Part of a study to define a model based scheduling analysis process for automotive systems  Q Q.1 : how well scheduling analysis can be used for automotive applications?  Evaluate the usability of scheduling theory valuate the capability of scheduling analysis tools  Q Q.2: how to integrate scheduling analysis in the development process ? (when/how?, confidence level, refinement,...)  C Current work (Q.1): Evaluate the capability of two scheduling analysis tools  M MAST  C Cheddar

4. 4 SAM’2010, October Requirements and Solutions for Timing Analysis of Automotive Systems Scheduling Analysis Needs for Automotive Applications Automotive Applications Limited hardware resources CPU Load, RAM/ROM consumption Necessity to evaluate processor load & Needed memory size Timing constraints Deadlines, Max activation/output jitters, data synchronization constraints, end-to-end constraints Necessity to verify if those constraints are met or not Various triggering paradigms Time triggered/event triggered, periodic/sporadic/singular tasks, timing recurrence/angular recurrence Necessity to account for this triggering diversity when analyzing the system Distributed Architecture Multiple ECUs, Multiple communication protocols, CAN, LIN, Flexray, etc. Necessity to consider the distributed aspect when analyzing the system, consider the hardware platform impact Task dependency and concurrency Dependent tasks, data exchange, shared resources, preemptive/non- preemptive/cooperative tasks, same priority level Property protection Systems with black box components Necessity to consider the black box aspect when analyzing the system Necessity to support this tasks models & consider task dependency

5. 5 SAM’2010, October Requirements and Solutions for Timing Analysis of Automotive Systems Scheduling Analysis Tools Requirements (1/2) Automotive FeaturesTools Requirements Limited Hardware resources REQ1: Analysis tools should have techniques to determine the processor utilization and perform memory analysis Timing Constraints REQ2: Analysis tools should allow specifying task or function deadlines REQ3: Analysis tools should allow specifying bounds on the output jitters of functions or tasks REQ4: Analysis tools should Allow specifying jitters (either in percentage or absolute value) related to the functions or tasks activation instants REQ5: Analysis tools should Allow specifying data synchronization constraints between the inputs or the outputs of functions REQ6: Analysis tools should allow specifying end-to-end timing constraints REQ7: Analysis tools should have techniques to verify if a deadline is respected REQ8: Analysis tools should have techniques to verify if bounds imposed on output jitters are respected REQ9: Analysis tools should have techniques to verify if data synchronization constraints between the inputs or the outputs of functions are respected REQ10: Analysis tools should have techniques to verify if end-to-end timing constraints are respected. Various Triggering Patterns REQ11: Analysis tools should allow specifying periodic, sporadic and singular events REQ12: Analysis tools should allow specifying angular events

6. 6 SAM’2010, October Requirements and Solutions for Timing Analysis of Automotive Systems Automotive Features Tools Requirements Distributed Architecture REQ13: Analysis tools should allow easy description of distributed systems with multiple ECUs and communication buses. REQ14: Analysis tools should have techniques to analyze multiprocessor systems REQ15: Analysis tools should have analysis techniques at least for CAN,LIN and FlexRay REQ16: Analysis tools should allow taking into account processors overheads (basically context switch overhead) and network overheads (network driver overheads) Task concurrency & dependency REQ17: Analysis tools should allow describing task dependency resulting from shared resource use, data exchange between functions or task precedence constraints REQ18: Analysis tools should have techniques to analyse systems with shared resources REQ19: When describing task dependency due to data exchange between functions, analysis tools should allow specifying flows with joins and forks REQ20: Analysis tools should have dedicated techniques to analyse a system with tasks having the same priority level REQ21: Analysis tools should allow specifying preemptive, non preemptive, cooperative tasks and interrupts Property Protection REQ22: Analysis tools should have techniques to enable scheduling analysis for systems with black box components Scheduling Analysis Tools Requirements (2/2)

7. 7 SAM’2010, October Requirements and Solutions for Timing Analysis of Automotive Systems Scheduling Analysis Tools Capabilities (1/2) Limited hardware resources Timing Constraints  MAST : REQ1: Calculation of Processor utilization & processor slack  Cheddar : REQ1: Calculation of processor utilization factor only for periodic tasks  MAST : REQ2 & 3: Timing requirement: operation deadlines & max output jitter REQ4: External event: max activation jitter (only for periodic) REQ5 & 9 : No data synchronization constraints specification/verification REQ6: End-to-end- constraints on transaction output event REQ7 & 8: Response times for operation and transactions  Cheddar : REQ2 & 3: Deadlines on tasks REQ4: No activation jitter specification REQ5 & 9: No data synchronization constraints specification/verification REQ6: No end-to-end constraints specification REQ7 & 8: Response times calculated for tasks Triggering patterns  MAST : REQ11: External events may be periodic, sporadic, unbounded, bursty REQ12: No angular event specification  Cheddar : REQ11: No triggering event concept but rather task kind (periodic, sporadic & aperiodic) REQ12: No angular event specification

8. 8 SAM’2010, October Requirements and Solutions for Timing Analysis of Automotive Systems Scheduling Analysis Tools Capabilities (2/2) Distributed Architecture Task concurrency and dependency  MAST : REQ13 & 14: Possibility to describe and analyze multiprocessor systems REQ15: No dedicated techniques for CAN, LIN or Flexray REQ16: Context switch overhead description, packet overheads  Cheddar : REQ13 & 14: Possibility to describe and analyze multiprocessor systems REQ15: No dedicated techniques for CAN, LIN or Flexray REQ16: Context switch overhead for task activation, no network overhead description  MAST : REQ17& 18: Description and analysis of systems with shared resources, data exchange through internal event concept REQ19: No joins/ forks supported, only linear transactions REQ20: No dedicated techniques for tasks with same priority levels REQ22: only preemtive/non- preemptive tasks, no cooperative tasks  Cheddar : REQ17, 18 & 19 : Description and analysis of systems with shared buffers, data exchange not supported, task precedence constraints description REQ20: possibility to use FIFO for tasks with same priority levels REQ22: only preemtive/non- preemptive tasks, no cooperative tasks Property protection  MAST : REQ22: No techniques for systems with black box components  Cheddar : REQ22: No techniques for systems with black box components

9. 9 SAM’2010, October Requirements and Solutions for Timing Analysis of Automotive Systems Scheduling Analysis of an Automotive Application Use case: knock system Knock Processor TASK_knk_kw Knk_kw Sporadic activation WCET: 200µs D: 500µs TASK_E1_SEGTASK_T1_100ms Knk_seg Angular activation WCET: 250µs D: 600µs Knk_100ms Periodic activation WCET: 85µs D: 600µs

10. 10 SAM’2010, October Requirements and Solutions for Timing Analysis of Automotive Systems Analysis Results FunctionsMAST resultsCheddar results Worst response time Worst blocking time Worst response time Worst blocking time KNK_Seg547855350 KnK_Kw4562502000 KnK_100ms55005200  Results are quite close to each other  MAST results are more precise  No possibility to describe allocation of functions to tasks with cheddar  Processor utilization with MAST: 97.66%  No possibility to calculate processor utilization with Cheddar, because of sporadic tasks  Results graphical display is interesting in Cheddar

11. 11 SAM’2010, October Requirements and Solutions for Timing Analysis of Automotive Systems Conclusion  Open source aspect is interesting for the two tools  possibility to integrate new automotive analysis techniques  MAST model is closer to concrete systems / Cheddar model is closer to scheduling theory  MAST seems to be more mature than Cheddar  Mast can be used for detailed scheduling analysis at implementation phase  Cheddar can be used for timing analysis in earlier development phases