3 Tool Usage

FFX is basically a way of communication, communication not only between user and analysis tools but also between analyse tools. An important concept that has driven the design of FFX is that the production of a WCET is the result of the composition of several analysis that, in turn, produces more and more precise understanding of the real-time application.

The following paragraph details the different use case where FFX may be used.

3.1 Tool - Tool Use Case

Whatever the surveyed use case, the final user of information of FFX is a tool that computes the WCET. The idea, in this use case, is that the WCET computation tool has not the ability to analyze some aspects of the program: for example, the loop bounds.

In this case, the WCET computation tool may require help of another tool with this ability. The loop bound computation tool produces an FFX file that will contain the lacking information. The WCET computation tool, in turn, loads this FFX file to get the lacking information and to obtain a WCET as in figure below.

This use case may easily be extended with different types of information. This may drives to have several FFX files and to have the ability to merge their content when loaded by the WCET computation tool.

In the communication of analysis tools with FFX, a very delicate and complex case concern the transmission of information between tools working at different levels of program representation. A program is usually expressed at a higher level of representation (model, source language, etc) and is transformed to a lower level (usually machine or virtual machine languages). It is often easier to compute complex information at the higher level but the WCET needs to be computed at the lower level to taker into account precisely the effect of the host hardware. Yet, this transformation may change the structure of the program and may make the high-level unsound to apply at the lower level.

Resolving all problems caused by such a case is out of the scope of this document. Yet, FFX provides some facilities to create a link between the high-level and the low-level program representation. Although the preferred representation is the low-level one (with addresses, labels, offsets, etc), one may pass references to the high-representation based on the debugging information found in the executable program, mainly, as a pair (name of the source file, line number in the source file).

3.2 Hybrid Use Case

By the time this document is written, there is no whole solution of the loop bound determination issue. Even if powerful tools exists that resolve the loop bounds for most cases, it remains loops that cannot be bound automatically.

A common approach to solve this problem is the hybrid approach. The automatic tool resolve as many as possible loop bounds and, if it remains unbound loop, the user is asked to complete the FFX information. The use of XML, a textual format, makes this work easier and requires only a usual text editor to let the human user complete the lacking information. In addition, FFX provides a program information representation relatively close to the source language, possibly locating the information based on the source file: this makes easier for the user to identify the link between the lacking information and his source files

We get the following use case:

Yet, this approach may be pushed on step further. The WCET is not a unique value attached to a task of a real-time application. Some users may be interested in different times corresponding to different configuration of the task that, in this case, may drive to different scheduling of the whole application. For example, this is the case of mode support in real-time application. In the normal mode, the whole system is working but in failure or error mode, some devices may be disabled that drives to different constraint on the scheduling.

Such analyses may be achieved by adding constraints on the control or the data flow depending on the target mode. The idea is that several times will be exhibited for a given task according the activation of some contextual information (provided by the human user): in FFX, this is called a scenario and several scenario may be proposed for task and possibly melted.

3.3 Collaboration Use Case

In this last use case, the computation of the WCET is viewed as applying several analyses recursively until reaching the maximal quantity of precision on a program. The idea is that each tool may improve the work of other tools thanks to the information it is providing.

For example, an loop bound analysis may provides bounds for code that is easily reachable from the entry but can ignore safely complex control flow like indirect branch. In turn, the indirect branch analyzer add this information that is used then to perform an interval analysis. The resulting intervals are then used both by the loop bound and the indirect branch analyses to improve the precision of their outcome. The loop bound analysis is also helped by the branch analysis and, recursively, may help other invocation of the indirect branch and interval analyzers.

In such a case, the FFX format is the axis which the analyzers work around. A first version is generated by the initial tool while other takes this information as input and as an outcome. The idea here is that each tool in turn takes the existing information available in the FFX and then add more information to improve the knowledge of the behavior of the application. The extensibility, the openess and the flexibility of FFX makes it a good candidate for such a use.