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