Requirements and Solutions for Timing Analysis of Automotive Systems

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

2. Timing Analysis in Automotive Software Design Timing Verification in automotive software design Automotive Applications • Increasing Complexity • Limited Resources • Timing Constraints • Safety Requirements • 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 Requirements and Solutions for Timing Analysis of Automotive Systems • 2

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

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

5. Scheduling Analysis Tools Requirements (1/2) Requirements and Solutions for Timing Analysis of Automotive Systems

6. Scheduling Analysis Tools Requirements (2/2) Requirements and Solutions for Timing Analysis of Automotive Systems

7. Scheduling Analysis Tools Capabilities (1/2) Limited hardware resources Timing Constraints • 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 • 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 • MAST: REQ1: Calculation of Processor utilization & processor slack 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 Requirements and Solutions for Timing Analysis of Automotive Systems

8. Scheduling Analysis Tools Capabilities (2/2) Distributed Architecture Task concurrency and dependency • 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 • 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 • 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 Property protection • Cheddar: REQ22: No techniques for systems with black box components • MAST: REQ22: No techniques for systems with black box components Requirements and Solutions for Timing Analysis of Automotive Systems

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

10. Analysis Results • 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 Requirements and Solutions for Timing Analysis of Automotive Systems

11. 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 Requirements and Solutions for Timing Analysis of Automotive Systems