ALF - A Language for WCET Flow Analysis

2000

There is an increasing demand for methods that calculate the worst case execution time (WCET) of real-time programs. The calculations are typically based on path information for the program, such as the maximum number of iterations in loops and identification of infeasible paths. Most often, this information is given as manual annotations by the programmer.

10th IEEE International Workshop on Object-Oriented Real-Time Dependable Systems, 2005

Reliable program Worst-Case Execution Time (WCET) estimates are a key component when designing and verifying real-time systems. One way to derive such estimates is by static WCET analysis methods, relying on mathematical models of the software and hardware involved. This paper describes an approach to static flow analysis for deriving information on the possible execution paths of C programs. This includes upper bounds for loops, execution dependencies between different code parts and safe determination of possible pointer values. The method builds upon abstract interpretation, a classical program analysis technique, which is adopted to calculate flow information and to handle the specific properties of the C programming language.

2011 International Conference on Embedded Computer Systems: Architectures, Modeling and Simulation, 2011

Obtaining tight worst-case execution-time (WCET) estimations of real-time tasks is crucial since overly-pessimistic estimations are deemed impractical. One way of making WCET estimations tighter is to incorporate more program-flow information e.g., context-sensitive loop bounds, infeasible-path and same-path information, etc. In this paper we present and evaluate a completely automatic analysis that dynamically derives program-flow information to use in WCET analysis. Flow information is derived by a combination of test-data generation and parsing of programexecution traces to obtain flow-fact hypotheses which are then fed to a model checker to establish their correctness. Experimental evaluation shows that our method help achieve considerable tightness in WCET estimations at a manageable cost.

8th Intl. Workshop on Worst-Case Execution Time (WCET) Analysis}, 2008

Following the successful WCET Tool Challenge in 2006, the second event in this series was organized in 2008, again with support from the ARTIST2 Network of Excellence. The WCET Tool Challenge 2008 (WCC'08) provides benchmark programs and poses a number of "analysis problems" about the dynamic, runtime properties of these programs. The participants are challenged to solve these problems with their programanalysis tools. Two kinds of problems are defined: WCET problems, which ask for bounds on the execution time of chosen parts (sub programs) of the benchmarks, under given constraints on input data; and flowanalysis problems, which ask for bounds on the number of times certain parts of the benchmark can be executed, again under some constraints. We describe the organization of WCC'08, the benchmark programs, the participating tools, and the general results, successes, and failures. Most participants found WCC'08 to be a useful test of their tools. Unlike the 2006 Challenge, the WCC'08 participants include several tools for the same target (ARM7, LPC2138), and tools that combine measurements and static analysis, as well as pure staticanalysis tools.

Abstract—We construct a fully automatic static WCET analysis suitable for real-time embedded systems applications by augmenting a high-level static analysis technique (originally aimed at heap-space) with a machine-level worst-case execution time tool. We evaluate this approach by studying two typical and realistic real-time control applications, using a readily available commercial microcontroller. Keywords-WCET; analysis; static; type system;

Deutschsprachige WCET-Tagung

Real-Time Systems, 2010

Lecture Notes in Computer Science, 2006

Methods for Worst-Case Execution Time (WCET) analysis have been known for some time, and recently commercial tools have emerged. However, the technique has so far not been much used to analyse real production codes. Here, we present a case study where static WCET analysis was used to find upper time bounds for time-critical regions in a commercial real-time operating system. The purpose was not primarily to test the accuracy of the estimates, but rather to investigate the practical difficulties that arise when applying the current WCET analysis methods to this particular kind of code. In particular, we were interested in how labor-intense the analysis becomes, measured by the number of annotations to explicitly constrain the program flow which is necessary to perform the analysis. We also make some qualitative observations regarding what a WCET analysis method would need in order to perform a both convenient and tight analysis of typical operating systems code. In a second set of experiments, we analyzed some standard WCET benchmark codes compiled with different levels of optimization. The purpose of this study was to see how the different compiler optimizations affected the precision of the analysis, and again whether it affected the level of user intervention necessary to obtain an accurate WCET estimate.

Analyzers (SSQSA) is a set of software tools for static analysis that is incorporated in the framework developed to target the common aim-consistent software quality analysis. The main characteristic of all integrated tools is the independency of the input computer language. Language independency is achieved by enriched Concrete Syntax Tree (eCST) that is used as an intermediate representation of the source code. This characteristic gives the tools more generality comparing to the other similar static analyzers. The aim of this paper is to describe an early idea for introducing support for static timing analysis and Worst Case Execution Time (WCET) calculation at code level in SSQSA framework.

Computing Worst Case Execution Time (WCET) is crucial in the area of Real-Time Embedded Systems. In order to ease this computation, we developped a tool, named oRange, able to provide loops upper bounds of C programs. These bounds are obtained by static analysis while combining flow analysis and abstract interpretation. oRange covers binary operators (+, −, *,) as loop increment, nested loops, non-recursive function calls and simple loop conditions (==, ! =, <, <=, >, >=, &). We also provide a comparison to the recent work of Ermedahl et al., based on the Mälardalen benchmark suite.