Requirements and Solutions for Timing Analysis of Automotive

  • Slides: 11
Download presentation
Requirements and Solutions for Timing Analysis of Automotive Systems Saoussen Anssi 1, Sébastien Gérard

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, Power. Train 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

Timing Analysis in Automotive Software Design Automotive Applications Timing Verification in automotive software design

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

Work Context q Part of a study to define a model based scheduling analysis

Work Context q 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, . . . ) q Current work (Q. 1): Evaluate the capability of two scheduling analysis tools Ø MAST Ø Cheddar Requirements and Solutions for Timing Analysis of Automotive Systems SAM’ 2010, October 3

Scheduling Analysis Needs for Automotive Applications Necessity to consider the distributed aspect when analyzing

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

Scheduling Analysis Tools Requirements (1/2) Automotive Features Tools Requirements Limited Hardware resources REQ 1:

Scheduling Analysis Tools Requirements (1/2) Automotive Features Tools Requirements Limited Hardware resources REQ 1: Analysis tools should have techniques to determine the processor utilization and perform memory analysis REQ 2: Analysis tools should allow specifying task or function deadlines REQ 3: Analysis tools should allow specifying bounds on the output jitters of functions or tasks REQ 4: Analysis tools should Allow specifying jitters (either in percentage or absolute value) related to the functions or tasks activation instants Timing Constraints REQ 5: Analysis tools should Allow specifying data synchronization constraints between the inputs or the outputs of functions REQ 6: Analysis tools should allow specifying end-to-end timing constraints REQ 7: Analysis tools should have techniques to verify if a deadline is respected REQ 8: Analysis tools should have techniques to verify if bounds imposed on output jitters are respected REQ 9: Analysis tools should have techniques to verify if data synchronization constraints between the inputs or the outputs of functions are respected REQ 10: Analysis tools should have techniques to verify if end-to-end timing constraints are respected. Various Triggering Patterns REQ 11: Analysis tools should allow specifying periodic, sporadic and singular events REQ 12: Analysis tools should allow specifying angular events Requirements and Solutions for Timing Analysis of Automotive Systems SAM’ 2010, October 5

Scheduling Analysis Tools Requirements (2/2) Automotive Features Tools Requirements REQ 13: Analysis tools should

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

Scheduling Analysis Tools Capabilities (1/2) Limited hardware resources Timing Constraints q MAST: q Cheddar:

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

Scheduling Analysis Tools Capabilities (2/2) Distributed Architecture Task concurrency and dependency q MAST: q

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

Scheduling Analysis of an Automotive Application Use case: knock system Knock Processor TASK_knk_kw TASK_E

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

Analysis Results Functions MAST results Cheddar results q Results are quite close to each

Analysis Results Functions MAST results Cheddar results q Results are quite close to each other Worst response time Worst blocking time q MAST results are more precise KNK_Seg 547 85 535 0 q Processor utilization with MAST: 97. 66% Kn. K_Kw 456 250 200 0 q No possibility to calculate processor utilization with Cheddar, because of sporadic tasks Kn. K_100 ms 550 0 520 0 q Results graphical display is interesting in Cheddar Requirements and Solutions for Timing Analysis of Automotive Systems q No possibility to describe allocation of functions to tasks with cheddar SAM’ 2010, October 10

Conclusion q Open source aspect is interesting for the two tools possibility to integrate

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