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
Requirements and Solutions for Timing Analysis of Automotive Systems 2SAM’2010, October
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
Requirements and Solutions for Timing Analysis of Automotive Systems 3SAM’2010, October
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 4SAM’2010, October
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 componentsNecessity to consider the black box aspect when analyzing the
system
Necessity to support this tasks models &
consider task dependency
Requirements and Solutions for Timing Analysis of Automotive Systems 5SAM’2010, October
Scheduling Analysis Tools Requirements (1/2)
Automotive Features Tools 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
Requirements and Solutions for Timing Analysis of Automotive Systems 6SAM’2010, October
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)
Requirements and Solutions for Timing Analysis of Automotive Systems 7SAM’2010, October
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
Requirements and Solutions for Timing Analysis of Automotive Systems 8SAM’2010, October
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 tasksProperty protection
MAST:
REQ22: No techniques for systems with black box components
Cheddar:
REQ22: No techniques for systems with black box components
Requirements and Solutions for Timing Analysis of Automotive Systems 9SAM’2010, October
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_SEG TASK_T1_100ms
Knk_seg
Angular activation
WCET: 250µs
D: 600µs
Knk_100ms
Periodic activation
WCET: 85µs
D: 600µs
Requirements and Solutions for Timing Analysis of Automotive Systems 10SAM’2010, October
Analysis Results
Functions MAST results Cheddar results
Worst response time
Worst blocking time
Worst response time
Worst blocking time
KNK_Seg 547 85 535 0
KnK_Kw 456 250 200 0
KnK_100ms 550 0 520 0
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 11SAM’2010, October
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