Abstract. Determining upper bounds for the worst-case execution time (WCET) is mandatory to ensure timeliness of hard real-time systems. To be of practical use, such WCET estimates also have to be precise. In this paper we present the WCET analysis tool CalcWcet167, which supports the Infineon C167

into modern software engineering processes. In this paper we give an overview about the different aspects of WCET analysis. We clarify terms and categorise features of WCET analysis tools. Therefore we present a generic framework for WCET analysis and describe its fundamental operations. We present a

constraints to a WCET tool require a lot of work for the user to be done. Therefore methods for achieving flow constraints automatically are important. However, most of today 's WCET tools require manual annotations of loops for real sized programs. One of the reasons is that the most powerful analysis

-interpretation-based analysis tools and identify crite-ria for their successful application. The integration of static analyzers in the development process requires in-terfaces to other development tools, like code genera-tors or scheduling tools. Using them for certification re-quires an appropriate tool qualification. We

it is not possible to be sure that the worst case has been measured). In static analysis on the other hand, the estimation of the WCET should always be equal or greater than the actual WCET (ofcourse, assumed that the analysis tool is correct). In classic static WCET analysis, the upper bound of the execution time

if WCET analysis tool aiT can be used to find safe WCET estimates for the tasks in Volvo CE’s applications, and how much user input is needed to get the result. Analysis results from aiT are compared to measured results and the WCET estimates used today. We have found that the times set in Rubus

kinds of problems to be solved by the Challenge participants with their tools, WCET problems, which ask for bounds on the execution time, and flow-analysis problems, which ask for bounds on the number of times certain parts of the code can be executed. The benchmarks to be used in WCC’11 were debie1

  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

and tools for WCET analysis in order to separate feasible from infeasible program paths, have a crucial impact on the precision and performance of these algorithms and tools. In this paper, we thus propose to complement the WCET tool challenge, which has recently successfully been launched, by a second

Worst-case execution time (WCET) analysis tools are needed for the development of hard real-time systems. Despite the theoretic advances in academic research in WCET there has been hardly any impact on the industrial practice of timing analysis. The essential question is why it was not possible