Worst-Case Execution Time Analysis from UML-based RT/E Applications

Worst-Case Execution Time Analysis from UML-based RT/E Applications Chokri Mraidha, Sébastien Gérard, François Terrier, David Lugato Chokri.Mraidha@cea.fr Lisbon, October 11 2004 1

Introduction PhD student in the Software for Process Safety Laboratory in the French Atomic Energy Agency (CEA) Director: Judith Benzakki Advisor: Sébastien Gérard PhD topic Optimized software synthesis in model driven development of real-time embedded systems Quantitative analysis of models Execution time Lisbon, October 11 2004 2

Plan of the presentation Context Related works on WCET analysis methods A hybrid method for WCET estimation An analysis-based method for WCET estimation Conclusions and perspectives Lisbon, October 11 2004 3

Context Domain: Distributed Real-time and Embedded Systems (DRES) Accord/UML An MDD approach for DRES Based on the UML RTE profile specializing the SPT profile Set of modeling rules for RT applications development Accord/UML tool support Implementation of the Accord/UML profile Accord framework» Kernel and virtual machine (UNIX, Linux, VxWorks) Lisbon, October 11 2004 4

Highlight: an execution model based on RTOs RTO: An autonomous computing entity! Global scheduling policy arealtimeobject Operation calls External interface operation 1 operation 2... Message processing & attribute access control Method code Attributes Tasks method_1 method_2 method_1 Operation calls Lisbon, October 11 2004 5

Communication mechanisms and task model Two main schemes of communication Synchronous or asynchronous Task 1 with RTF Task 2 creation Task 2 with RTF Accord/UML tasking model underlying Real-Time Object concept General computational model: One task per operation call Real-time features Scheduling policy EDF TimeRef, Deadline, ready time, period and period number Lisbon, October 11 2004 6

Schedulability analysis on UML models Task model calculus & schedulability analysis If not schedulable system: Model correction Real-time constraints adaptation Accord/UML-models with RT specification 1 Adaptated application models + all required RT specification for schedulability analysis Formal behavioral analyser tool (AGATHA) 2 3 36 P 3 3 4 9 1 8 3 94 8 3 7 7 0 7 8 5 0 P 2 3 0 9 8 Q 3 7 9 Real-time symbolic execution tree of the application 4 Mapping between UML models and AGATHA formal language with clear modelling of the scheduling policy Need the Worst Case Execution Time of each operation (~ task) Lisbon, October 11 2004 7

Analysis-based methods (static) No execution of the program A two-phases process High-level analysis: computes all execution paths Low-level analysis: estimates execution time of these paths Requires Task specification Timing model of the microprocessor Result An upper bound of the WCET: safe Main issues Avoid overestimation of the WCET Requires an elaborated timing model of the microprocessor Not easily retargetable (timing model) Lisbon, October 11 2004 9

Measurement-based methods (dynamic) Measurement of the execution time at runtime Find input values having the longest execution time A two-phases process Find input values covering all execution paths Measure execution time for every input value at runtime Requires A set of input values A binary of the task to measure its execution time Result A lower-bound of the WCET Main issues Find all input values for measurement Impossible for infinite domains Lisbon, October 11 2004 10

Outcome ++ -- Analysis-based approaches High-level analysis: execution path computing exhaustive Low-level analysis: execution time estimation overestimations Measurement-based approaches Execution time measurement for given input values more precise results than analysis ones Find input values for measurement how to find input values covering all execution paths? Lisbon, October 11 2004 11

A hybrid method for WCET estimation A two-phases approach A static analysis phase High-level analysis of static analysis methods Automatic test cases generation» Tests covering all possible execution paths» Analysis techniques: model checking, constraintbased techniques, symbolic execution A measurement-based phase Runtime measurement Measurement using tests of the previous phase Lisbon, October 11 2004 13

Hybrid approach overview Set of automata communicating by rendezvous Train Circuit Control Code Generation & Compiling Application Code generation with timing measurement routines Path Conditions for every execution path (equivalence class of tests for each path) AGATHA Measurement of execution time J1 J1 = (Vit=120, (Vit=120, dist=150) (Vit (Vit < 100 100 )) (( dist dist < 200) 200) J2 J2 = (Reg=true, Vit=55) Vit=55) (Reg (Reg = true) true) (Vit (Vit 50) 50) Constraints solver One test for every path (one representant of the Path Conditions Dtsi/SOL/L-LSP equivalence class) SVERTS 2004 Lisbon, October 11 2004 14

Advantages and limitations of the approach Advantages Automatic process No code or model annotation required from the user Integrated into a development toolchain No timing model required Easily retargetable to new sw/hw components Good scalability with symbolic execution Limitations First order logic models (Presburger arithmetic) Limitation due to the Agatha tool Ongoing work to compute more complex models Possible scalability improvements Explore the longest path first execution tree prunning Test selection criteria Apply the method to sub models iterative process Gives only a lower bound of the WCET (measurement)! Lisbon, October 11 2004 15

Model-based WCET static analysis overview AGATHA Model Transformation Accord/UML task model Infeasible paths removal Optimized task model WCET analysis model with symbolic WCETs Path analysis with symbolic execution (optimization phase) Infeasible paths removal execution tree prunning Model transformation (computation phase) Assign symbolic WCET values to primitive actions of the action langage WCET_ReadAction; WCET_WriteAction; WCET_AddAction Compute symbolic WCET for every execution path WCET is obtained by replacing symbolic values by numerical values Lisbon, October 11 2004 17

Illustration with an example Model transformation to add symbolic timing values of elementary actions x := a [x <= 10] [x > 10] x := a WCET := WCET_ReadAction + WCET_WriteAction [x <= 10] [x > 10] WCET := WCET_ReadAction + WCET_WriteAction + WCET_TestAction x := x+a x := b x := x+a WCET := WCET_ReadAction + WCET_WriteAction + WCET_TestAction x := b WCET := 2* WCET_ReadAction +.. WCET := WCET_AddAction + 2*WCET_ReadAction + 2* WCET_WriteAction + WCET_TestAction Lisbon, October 11 2004 18

Results Advantages Good results for systems using simple microprocessors Sequential execution: no pipeline No cache Systems where architectural mechanisms harming time predictability are switched off (critical systems) Drawback Overestimated WCET for systems using these architectural features (increasingly frequent) Need to take into account architectural features to reduce overestimation Pipeline Cache Branch predictors Out of order execution Lisbon, October 11 2004 19

Perspectives: improvements How to take into account architectural features? Timing models of microprocessors Implement this model in a static analysis tool (Agatha in our case) Not interesting because not flexible, not portable Extract architectural elements timing properties in a dedicated model Platform Real-time Description Model What should this model contain? Timing properties of architectural elements pipeline, cache Accuracy of results increases with number of modeled elements Stay at a some level of abstraction in order to be usable by tools Lisbon, October 11 2004 20

Perspectives: Model-driven WCET analysis Apply Model Driven Engineering tenets for WCET analysis Benefits Task model Platform RT Description Model Model transformations to map the platform model on the task model WCET Analysis Model Portability Reusablity Maintainability Model-level automated process Model transformations We can analyse WCET for several platforms and choose the best suited one before implementation Lisbon, October 11 2004 21

Example: a simple pipelined architecture Instruction Cache Registers IF Instr. Fetch ID Instr. Decode RR Read Registers EX Execution WR Write Registers No memory, no data cache All operands are in registers or in the instruction itself (constants) No branch prediction mechanisms No out of order execution No short-circuit mechanisms A data dependency costs a pipeline stall of 2 cycles Only RAW (Read After Write) data dependencies are possible Occurs when instr n+1 needs to read data processed by instr n Lisbon, October 11 2004 22

Example: a simple pipelined architecture (cont.) 1 2 3 4 5 6 7 8 9 10 x:=a IF ID RR EX WR y:=x+2 IF ID stall stall RR EX WR z:=x+3 IF stall stall ID RR EX WR t:=x+4 WCET The cycle number of WR unit of the last instruction Model transformation rules Computes cycle of WR for every instruction WR n : cycle of WR of instruction n WR n = WR n-1 + 1 = WR n-1 + 1 + RAW if RAW(n-1, n) IF ID RR EX WR Lisbon, October 11 2004 23

Model transformation x := a y := x+2 z := x+3 t := x+4 Model transformation: WR n = WR n-1 + 1 = WR n-1 + 1 + RAW if RAW(n-1, n) x := a WCET := 5 y := x+2 WCET := 8 z := x+3 WCET := 9 t := x+4 WCET := 10 Without taking into account the pipeline: sequential execution WCET = 4 x 5 = 20 cycles A saving of 50% For 4 instructions only! For a very simple architecture Taking into account the architecture improves accuracy! Lisbon, October 11 2004 24

Plan of the presentation Context Worst-Case Execution Time methods A hybrid method for WCET estimation An analysis-based method for WCET estimation Conclusions and perspectives Lisbon, October 11 2004 25

Conclusions Estimation of WCET from UML-based RT models A hybrid approach Provides lower-bound of WCET Precise results useful for soft real-time systems An analysis approach Safe bounds Model-driven analysis technique Task model + Platform RT Description model WCET analysis model» Flexible, portable technique Model Transformation process The architecture becomes a parameter of the analysis (SoC) Perspectives Take into account more architectural features Refine the model transformation rules by taking into account the data cache Lisbon, October 11 2004 26