by Elie Manouel Assaf
Department of Computer Science and Engineering
Mälardalen University, Västerås, Sweden
CC Systems AB, Västerås, Sweden.
Today, Embedded Computer Systems are integrated in many products that are employed to perform tasks of safety-critical nature (ex. nuclear power plants, airbags in vehicles and auto-pilots in airplanes etc.). These computers run heard real-time applications that are to satisfy stringent timing constraints derived from the systems they control. Any deviation from these constraints can result in catastrophic consequences. To ensure the safety and the correctness of these applications, it is of crucial importance to know the timing behavior of each task running on the system.
The static Worst Case Execution (WCET) analysis is a relatively young science that tries to determine upper bounds on the execution time of a program running on specific hardware. The upper bounds are time estimations, determined by analyzing the program instead of running it. There are a few commercial static WCET tools on the market today and a handful of prototypes that are more or less complete. The static WCET-tools strive to provide WCET-estimations that are safe and tight. How successful these tools can be; that depends on the characteristics of both the software and hardware that are subject to the analysis, as well as on how well the target hardware is modeled in tool.
In this research, the commercial static WCET Tool, Bound-T was used to conduct a WCET analysis on parts of a C++ code that was automatically generated from the component-based modular Rhapsody. The C++ code was generated for an application of a hard real-time nature that runs on a bridge control panel installed in a Rolls Royce marine vessel. The application contained many tasks, which are running in parallel, in the absence of any operating system (OS). The absence of an OS was compensated by the use of the Interrupt Driven Framework (IDF), which is set of collaborating classes that are implemented to simulate the behavior of the OS and allowed the existence of only one "real" thread. The C++ code had an extremely complex structure, because it was generated in a way that allows many tasks to run in parallel even though only one thread was allowed to exist in reality. The running tasks were invoked by the IDF according a fixed "execution-pattern", which made it possible to track the execution-path of a particular task and conduct the analysis on it.
Some of the problems that came up during the analysis were due to a bad design in some of the classes in the IDF-library. Other problems were due the implemented control flow in some of the generated methods, that was unsuitable to the static WCET analysis. In some case, Bound-T failed to track the values of some variables that were passed from one method to another, because it was unable to understand neither the type-conversion operations that were performed by the compiler nor the multiplication operations that were performed by the target processor. The hidden functions that belong to the C++/compilers runtime environment represented also a big challenge during the analysis. Despite all these restrains, it was possible to conduct the analysis on the code and obtain results.
In this paper we present a detailed description of each of the problems mentioned above, what methods were used to solve them and the results obtained from conducting the analysis.