Approximation of Worst-Case Execution Time for Preemptive Multitasking Systems

Abstract

The control system of many complex mechatronic products requires for each task the Worst Case Execution Time (WCET), which is needed for the scheduler's admission tests and subsequently limits a task's execution time during operation. If a task exceeds the WCET, this situation is detected and either a handler is invoked or control is transferred to a human operator. Such control systems usually support preemptive multitasking, and if an object-oriented programming language (e.g., Java, C++, Oberon) is used, then the system may also provide dynamic loading and unloading of software components (modules). Only modern, state-of-the art microprocessors can provide the necessary compute cycles, but this combination of features (preemption, dynamic un/loading of modules, advanced processors) creates unique challenges when estimating the WCET. Preemption makes it difficult to take the state of the caches and pipelines into account when determining the WCET, yet for modern processors, a WCET based on worst-case assumptions about caches and pipelines is too large to be useful, especially for big and complex real-time products. Since modules can be loaded and unloaded, each task must be analyzed in isolation, without explicit reference to other tasks that may execute concurrently. To obtain a realistic estimate of a task's execution time, we use static analysis of the source code combined with information about the task's runtime behavior. Runtime information is gathered by the performance monitor that is included in the processor's hardware implementation. Our predictor is able to compute a good estimation of the WCET even for complex tasks that contain a lot of dynamic cache usage, and its requirements are met by today's performance monitoring hardware. The paper includes data to evaluate the effectiveness of the proposed technique for a number of robotics control kernels that are written in an objectoriented programming language and execute on a PowerPC 604e-based system.

Approximation of the worst-case execution time using structural analysis

“…If p is the single predecessor of b, and bcr(b) is empty, we simply copy the range of iterations of the edge to the node (Figure 8.a). Otherwise, we have detected a loop breaking edge (p → b), and the number of iterations of b is set equal to the number of iterations of the loop preheader 4 (Figure 8.b). If we have more than one predecessor, we look for the first common predecessor of all the predecessors of b (Figure 8.c).…”

“…For our application domain we do not need an exact result and we try to compute a good and conservative approximation of the worst-case execution time using some heuristics and approximations. We implemented a first prototype for the PowerPC platform which used statistic information to estimate the pipeline stalls and cache misses [4]. This approach was further refined replacing some of the empirical approximations with a partial and simplified simulation of the processor behavior [5].…”

"May you have a strong (-typed) foundation" why strong-typed programming languages do matter

“…The scheduler tests new tasks for admission in the task set upon task creation, while continuously monitoring the application run-time for constraints violations. A novel approach enables the application programmer to perform a reliable estimate of the task's duration-its worst-case execution time-by harnessing the performance monitoring hardware of the underlying processor architecture, as disclosed in [8].…”

Timing Analysis of TCP Servers for Surviving Denial-of-Service Attacks

“…Our new timed automaton for modeling TCP has a number of states which is linear in the size of the buffer. We use worst-case execution time (WCET) analysis [33], [34], [2], [16], [13], [25], [20] to compute the timings needed in the timed automaton.…”