Int J Softw Tools Technol Transfer (2013) 15:53–63
DOI 10.1007/s10009-012-0255-9
ALL-TIMES
Practical experiences of applying source-level WCET flow analysis
to industrial code
Björn Lisper · Andreas Ermedahl ·
Dietmar Schreiner · Jens Knoop · Peter Gliwa
Published online: 24 July 2012
© Springer-Verlag 2012
Abstract Code-level timing analysis, such as worst-case
execution time (WCET) analysis, usually takes place at the
binary level. However, many program properties that are
important for the analysis, such as constraints on possible
program flows, are easier to derive at the source code level
since this code contains much more information. Therefore,
various source-level analyses can provide valuable support
for timing analysis. However, source-level analysis is not
always smoothly applicable in industrial settings. In this
paper, we report on the experiences of applying source-level
analysis to industrial code in the ALL-TIMES project: the
promises, the pitfalls, and the workarounds that were devel-
oped. We also discuss various approaches to how the diffi-
culties that were encountered can be tackled.
Keywords Static analysis · WCET analysis · Source-level
analysis · Embedded software
B. Lisper (B) · A. Ermedahl
School of Innovation, Design, and Engineering,
Mälardalen University, 721 23 Västerås, Sweden
e-mail: bjorn.lisper@mdh.se
A. Ermedahl
e-mail: andreas.ermedahl@mdh.se
D. Schreiner · J. Knoop
Institute of Computer Languages, Vienna University
of Technology, 1040 Vienna, Austria
e-mail: schreiner@complang.tuwien.ac.at
J. Knoop
e-mail: knoop@complang.tuwien.ac.at
P. Gliwa
GLIWA GmbH embedded systems, Blütenstr. 20,
82362 Weilheim i.OB., Germany
e-mail: peter@gliwa.com
1 Introduction
The purpose of timing analysis is to find out whether the tim-
ing constraints of a system are met. It is usually divided into
system-level analysis, dealing with the combined execution
of different programs (“tasks”), and code-level analysis deal-
ing with the timing of individual tasks. The most important
entity to estimate on code level is the worst-case execution
time (WCET) of a task. WCET estimates are needed for many
system-level analyses. For these to yield reliable results, the
WCET estimates must be safe meaning that they never will
underestimate the true WCETs. Unsafe WCET estimates can
also be useful, in situations like early design phases where
they can help dimensioning the system.
WCET analysis assumes that the code is running to com-
pletion in isolation, without being interrupted. The two main
kinds of analysis are measurements and static analysis. In
general, measurements cannot give safe estimates and are
thus suitable for less time-critical software. For time-critical
software, where the WCET must be safely estimated, static
analysis is preferable. Hybrid analysis combines elements of
static and measurement-based analysis.
Static WCET analysis derives a WCET estimate from
mathematical models of the code and the hardware. If the
models are correct, then a static WCET analysis will always
derive a safe WCET estimate. The static analysis is usually
divided into three phases: a flow analysis where information
about the possible program execution paths is derived, a low-
level analysis where the execution times for atomic parts of
the code, like basic blocks, are decided from a performance
model of the target architecture, and a final calculation where
the flow and timing information is combined to derive a
WCET estimate.
The flow analysis must handle a possibly very large
number of paths. Thus, approximations are needed. If the
123
54
approximations are safe (representations include at least the
possible paths) then a WCET analysis is still safe, although it
might become pessimistic. Flow analysis research has mostly
focused on loop bound analysis [12] since upper bounds on
the number of loop iterations must be known in order to
derive finite WCET estimates. Automatic methods to find
these exist, but often some loops must still be bounded man-
ually. Flow analysis can also identify other types of program
flow constraints like infeasible paths [11] constraining the
number of times different program parts can be executed
together.
To be accurate, flow analysis should be performed on the
binary level, for the code actually being executed. However,
much information is often missing in this code. Therefore,
flow analysis is sometimes done on source code. An advan-
tage is that there is much more high-level information in the
code that can help obtaining precise flow analysis results.
Also, source-level analysis is potentially more portable as
the source code format should be independent of the target
platform. (However, this is not always true: see Sect. 7.2).
As a downside, the program flows in the source and the
binary are sometimes not exactly the same, especially if the
compiler applies heavy optimisations. Program flow con-
straints derived from the source code can then be unsafe for
the program flows of the binary. But there are still many situa-
tions where this is tolerable, for instance when making rough
timing estimates in early design phases. Also, the technique is
applicable for safety-critical applications where safety stan-
dards demand that compiler optimisations are turned off.
The purpose of the ALL-TIMES project was to create
methodologies and toolchains for combinations of different
timing tools and techniques, including source-level flow anal-
ysis. The techniques were finally tried out on an industrial
case study from the automotive area. In this paper, we report
on some practical experiences of source-level flow analysis in
the project. We ran into a number of problems when attempt-
ing to analyse the source code for the case study. We describe
these problems, and the workarounds that we had to make to
be able to proceed. The problems that we encountered seem
to be quite general for source-level analysis of this kind of
code, and we discuss a number of possible ways to tackle
them.
The rest of this article is organised as follows: in Sect. 2
we give an account for related work. Section 3 describes
briefly the role of source-level analysis in the ALL-TIMES
project. In Sect. 4, we describe the target system for which
we applied source-level flow analysis. Section 5 describes
how the results of the source-level analysis were used, and
which aspects were tested. Section 6 describes our analysis
tool SWEET, which was used in the case study, and its flow
analysis. Section 7 reports on the results and experiences of
the case study. Section 8, finally, wraps up and discusses
possible directions for future work.
123
B. Lisper et al.
2 Related work
There have been a number of studies of WCET analysis of
industrial code. There are some reports on using commer-
cial, static analysis WCET tools to analyze code for space
applications [14,15,24] and in avionics industry [8,21,29]. In
[4,26], time-critical parts of the commercial real-time oper-
ating system Enea OSE were analysed. Experiences from
WCET analysis of real-time communication software for
automotive systems was reported in [3]. All these case stud-
ies concern analysis of binary code only. A problem detected
in several of them is the need to provide manual annota-
tions for program flow properties at binary level, which was
often found to be cumbersome and error-prone. Binary level
annotations were necessary either because the source code
was not available, or because the optimizations performed
by the compiler would change the control flow too much.
Although research has been done how to transform program
flow annotations through code transformations [16,23], such
transformations are not done by any production compilers.
Sehlberg et al. [28] reports on WCET analysis of a number
of tasks in the transmission control of an articulated hauler.
This analysis was done on binary level. Also in this study, a
problem found was the sometimes large effort needed to pro-
vide manual program flow annotations in order to have tight
WCET estimates. For one task, several weeks were needed
to provide the appropriate annotations. In a follow-up study
[1], the program flow analysis was done on source level,
and the results passed to the binary level analysis by hand.
The experiment was successful in the sense that almost all
program flow constraints on the binary level could be auto-
matically derived on source level. Compiler optimisations
changing the control structure did not pose any big problems
for the translation. What did pose a problem was the fact that
the tasks communicate through data stored in intricate data
structures. Value annotations had to be provided for some of
these structures, which proved to be difficult for two reasons:
the inability of the annotation language to express accurately
the value fields in the data structures, and the difficulty to find
proper value ranges for data stored and updated by several
tasks. For this case study, there was access to all the source
code. The code was, with some exception, written in a way
adhering to existing C standards, and parsing did not pose
any major problems.
There are a number of general-purpose academic or com-
mercial tools for source-level static analysis. Some examples
are ASTRÉE [6], Coverity [2], Polyspace, and Klocwork.
These tools can check for a variety of possible errors such
as possible division by zero, array index out of range, or
potential memory leaks to name a few. A comparative eval-
uation of Coverity, Polyspace, and Klocwork is found in [7].
In [2], a number of practical problems for source-level
static analysis tools, when applied to industrial code, were
Practical experiences of applying source-level WCET
Fig. 1 Source-level analysis
tools and tool connections in
ALL-TIMES
reported. Among the experiences reported were the need
to handle different environments for program development,
problems parsing code accepted by the customers’ compil-
ers, and the need to reduce the ratio of false to true positives.
Clearly, these experiences apply to the source-level analyses
that support WCET analysis as well, and they are in line with
what we report here.
3 Source-level analysis in the ALL-TIMES project
One particular goal of ALL-TIMES has been to provide sup-
port for timing analysis from source-level analyses. Figure 1
shows the tool chains created in the ALL-TIMES project:
the parts that concern source-level analysis are the ones that
are not greyed out. Two kinds of program flow information
were found to be interesting to export to the WCET analysis
tools aiT and RapiTime: information about possible values of
function pointers in different program points, and traditional
program flow information such as bounds on the number of
loop iterations and infeasible path constraints. These analyses
are provided by the tools SATIrE and SWEET, which have
been briefly described in [19]. As mentioned there, SAT-
IrE is based on the Rose open source compiler infrastruc-
ture [25]. In particular, it uses the C/C++ frontend of Rose to
parse C source code before analysing it. It can deliver func-
tion pointer values to aiT and RapiTime using each tool’s
native format for manual source-level annotations. SATIrE
also has an experimental loop bounds analysis (see [27]).
SWEET can compute a number of program flow constraints,
ranging from simple loop bounds to complex constraints for
55
infeasible paths, and can export these to aiT and RapiTime
using the same annotation formats as SATIrE. SWEET’s flow
analysis analyses the ALF code format (see Sect. 6). SATIrE
can convert Rose’s internal program representation to ALF
through the “melmac” tool, and can thus act as a C frontend
to SWEET. Thus, the source-level analysis of SWEET uses
SATIrE as a frontend.
The results of ALL-TIMES were validated using indus-
trial code from the automotive domain (see Sect. 4). The
validation is described in detail in [20].
4 The target system
The target system that was used for the final validation in
ALL-TIMES is a fuel cell control system from Daimler,
for their experimental “F-Cell” fuel-cell powered version of
the Mercedes-Benz A-Class. This control system consists of
three ECUs. The source-level analysis in ALL-TIMES was
validated using the VECU (Vehicle Control Unit), which cal-
culates the torque necessary to fulfil the driver’s request in the
current situation. It also handles the buffer battery. For this
particular unit the project could obtain access to the source
code, which was crucial for the validation of the source-level
parts of the toolchains. (It should be mentioned that it is usu-
ally not easy for people outside the company in question to
have access to industrial source code. This can make it hard
to try out source-level analysis techniques on realistic codes.)
The VECU unit has a Freescale MPC 564 processor. It has
no hardware trace facilities, and it uses the ETAS ERCOSEK
operating system. The source code consists of ca. 685k lines
123
56
of code, divided on 1297 C files (.c), 768 C header files (.h),
and 28 assembly files (.a). The C files range in size from less
than 1 KB to 1997 KB (22910 lines of code), the largest .h
file is 611KB (12930 lines of code), and the largest .a file
is 1298KB. The source code is compiled with the Windriver
compiler (Diab Data).
In addition to the source code, the project had access to a
development environment including compiler, debugger, and
hardware. The target system is described in some more detail
in [20].
5 Source code analysis validation
The source code analyses developed within ALL-TIMES
were validated as parts of larger tool chains, involving also
the WCET analysis and system-level timing analysis tools
in the project (see [19,20]). The tool chains were validated
using two scenarios, in the following way. The first vali-
dation scenario was an “early design exploration” scenario,
where TimingExplorer [13] is used to select an appropriately
upgraded hardware platform for an existing application. For
this purpose, a set of approximate WCETs of the tasks were
computed for each investigated hardware configuration and
subsequently sent to SymTA/S for a schedulability analysis.
Computing bounded WCETs requires that all loops in the
code are bounded. TimingExplorer does perform an auto-
matic loop bounds analysis: however, this analysis is done
on the binary code, and so, for the target code of VECU,
TimingExplorer was unable to bound 102 loops. The source-
level analysis validation for this scenario was to see how
many loops SWEET could additionally bound by a source-
level analysis, and pass the results to TimingExplorer to avoid
the time-consuming process of manually annotating the loop
bounds.
The second scenario was a “late stage verification” sce-
nario, where SATIrE, SWEET, and RapiTime are used to ana-
lyse/measure the code and determine the WCETs of the tasks
in the target system. RapiTime produces traces that are vis-
ualised using one of the so-called “trace-viewers” provided
with T1 or SymTA/S. SymTA/S also performs a scheduling
analysis to verify schedulability under worst-case conditions.
Here, it was tested how well SATIrE could determine func-
tion pointer values. RapiTime needs these values to cut down
the set of possible execution paths when calling a function
that is indirectly referenced through such a pointer. SWEET’s
loop analysis was used in a different way than for the first
scenario. RapiTime measures execution times for program
fragments and combines this information into a WCET esti-
mate using program flow constraints. VECU has no hardware
tracing facilities, and thus the code had to be instrumented
for measuring execution times. The instrumentation had to
be sparse since otherwise buffers would overflow and data
123
B. Lisper et al.
would be lost. Therefore it was interesting to identify parts
of the code with little variability of the execution time since
such parts are prime candidates not to instrument. Loops that
always execute the same number of times are likely to have
low execution time variability. Since SWEET can compute
both upper and lower iteration bounds for loops, it was tested
how many loops SWEET could find where these bounds were
equal (and thus the loop always executes the same number
of times). This information could help reduce a time-con-
suming inspection of the code to find those parts of the code
where instrumentation could be reduced.
6 SWEET, and its flow analysis
SWEdish Execution Time tool (SWEET)1 is a WCET analy-
sis research tool from Mälardalen University. It has the stan-
dard WCET analysis tool architecture with a flow analysis,
a low-level analysis, and a final WCET estimate calculation.
The flow analysis of SWEET is the part currently being
most actively maintained and developed, and this is the part
of SWEET that has been of concern for the ALL-TIMES
project. The analysis is able to produce a number of pro-
gram flow constraints, ranging from simple upper and lower
loop iteration bounds to complex infeasible flow constraints.
The analysis is context-sensitive as well as input-sensitive,
the latter meaning that the analysis can take restrictions on
input values into account when computing the program flow
constraints.
The main analysis method of SWEET is called abstract
execution (AE) [11]. AE can be seen as a fully context-sen-
sitive abstract interpretation, where each loop iteration (or
recursive function call) is analysed separately. It is therefore
a “deep” analysis method, based on the semantics of the pro-
gram. Alternatively, AE can be seen as a kind of symbolic
execution where program variables store abstract values, and
where operators and functions are given their interpreta-
tions in the abstract value domain. Figure 2 illustrates how
AE works for a simple loop. Note the input-sensitivity: the
restricting interval for the initial value of i will directly influ-
ence the resulting iteration bounds for the loop. A simpler,
non-input sensitive analysis would not be able to bound this
loop. The current implementation of AE in SWEET uses the
abstract interval domain for numerical values, but AE can in
principle use any abstract domain.
AE uses abstract states, which consist of a program point
and a representation of a set of possible memory states, cur-
rently in the form of a function from program variables
to intervals. As the analysis proceeds, the abstract state is
updated according to the abstract semantics of the current
statement. Notably, several abstract states can be spawned
1 http://www.mrtc.mdh.se/projects/wcet/sweet.html.
Practical experiences of applying source-level WCET
Fig. 2 Example of abstract
execution
(a)
Table 1 SWEET’s different merge strategies
Merge strategy Explanation
No merge Never merge any abstract states
Each function entry Merge abstract states before making
point function calls
Each function return Merge before returning from function calls
point
Each loop exit edge Merge at each point where a loop can be
exited
Each back-edge Merge at each back-edge of each loop,
going back to its header node
Each point of joining Merge where program flows join,
edges like after conditionals
All Apply all the strategies above
when executing conditions: see Fig. 2 for an example, where
this happens for iterations 4 and 5. Thus, AE must be able to
handle several concurrent abstract states. To keep the number
of abstract states down, they can be merged into new abstract
states that safely overapproximate the union of the concrete
states involved. Merging may reduce the precision of the
analysis, so it should be used only when necessary. SWEET
offers a choice of user-selectable strategies to place points
where to merge, thereby providing several tradeoffs between
precision and analysis complexity: the current strategies are
given in Table 1. Of these strategies “no merge” gives the
highest precision but may cause the number of abstract states
to grow exponentially, “all” will give the largest reduction of
the number of abstract states, but will also give the lowest
precision, and for the other strategies the impact will depend
on the properties of the code under analysis.
As mentioned AE is context-sensitive, which implies that
different function calls will be treated separately by the analy-
sis. This will in general increase the precision of the analysis,
at the cost of possibly analysing the same function several
times. Reconsidering the example in Fig. 2, let us assume
that the code is included in the body of a function taking i
as a parameter. Depending on the possible values of i, for
different function calls, the loop may iterate a different num-
ber of times, and a precise WCET analysis should take this
into account. AE will analyse the function anew for each call,
using the actual interval for i, and will thus be able to derive
loop bounds that are specific for each call.
57
(b) (c)
The computed flow constraints are arithmetic constraints
on so-called execution counters, virtual variables that count
the number of executions in different program points. (In
Fig. 2, “#p” is such a counter.) SWEET has a general method
to collect information about possible executions into different
kinds of program flow constraints. The resulting constraints
can be directly used in the final calculation of the WCET esti-
mate. Below we show some simple program flow constraints:
an upper and a lower loop bound constraint restricting the
number of executions of program point p to be between 3
and 5 (like in the example in Fig. 2), and a constraint speci-
fying that the program points c1 and c2 can be executed at
most 100 times together:
#p <= 5
#p >= 3
#c1 + #c2 <= 100
SWEET has the ability to calculate these kinds of constraints,
as well as considerably more complex ones [11]. In par-
ticular, SWEET can calculate linear inequalities expressing
more complex infeasible path information that involve sev-
eral program points. SWEET can also generate context-sen-
sitive flow constraints for different call strings. Each flow
constraint is either a “foreach” constraint, valid for individual
iterations of an outer loop, or a “total” constraint restricting
the total number of executions of program points. See [9] for
details.
The analysis method of SWEET is general and not a pri-
ori tied to any language or instruction set. To take advantage
of this generality, SWEET’s flow analysis analyses the code
format ALF [10]. ALF is an intermediate format designed
to be able to faithfully represent code on different levels,
from source to binary level. It therefore contains high-level
concepts, such as functions and function calls, as well as
low-level concepts like dynamic jumps. Thus, SWEET can
analyse code both on binary and source level provided that
a translator into ALF is present. As mentioned, the melmac
tool is such a translator that maps the internal format of Rose
into ALF, thereby enabling SATIrE to be used as a C frontend
to SWEET.
The flow constraints generated by SWEET are by default
given in SWEET’s own “flow fact language”. This language
123
58
expresses flow constraints for ALF code. If the ALF code
is generated from C code by melmac, then SWEET can use
information provided by melmac to relate the flow constraints
to the C source code. This enables SWEET to generate code
in the AIS format for aiT [13], and RapiTime’s annotation
format for flow constraints.
7 Results and experiences
We now describe our experiences from doing source-level
analysis on the validator (automotive ECU) code in the ALL-
TIMES project.
We discuss the problems encountered for the source-level
program flow analysis performed by SWEET. Most of the
problems are common to SATIrE’s analyses as well, and
indeed they should be common to “deep”, semantics-based
source-level analyses in general. In our experiments, SWEET
was run under Windows XP whereas SATIrE was run under
linux: however, all conclusions to be drawn should be inde-
pendent of the environment used.
The steps necessary to perform SWEET’s flow analysis are
basically the following. This scheme should hold for source-
level analysis in general:
1. identify the source files that are needed for the analysis,
2. convert the files to a format suitable for the static analyses
to be applied,
3. “link” the converted files to enable program inter-proce-
dural analyses across file borders,
4. perform the program analyses, and
5. map the results back to the source code, in a format suit-
able for other tools.
We now describe our experiences for each step in turn.
7.1 Step 1: identify needed source files
Academic benchmarks for WCET analysis research tend to
consist of small, self-contained programs where each pro-
gram to analyse resides in a single source file. Not so in real
projects: they may consist of thousands of files, where the
code that needs to be analysed is scattered over many differ-
ent files.
The first step is to identify the entry points for the code
to analyse. For WCET analysis, this typically amounts to
finding the start functions for the tasks, or runnables, in the
system. If the application uses an operating system, then the
tasks can usually be found from some of its configuration
files. This is the method that we used. It requires knowledge
of how the specific operating system used is configured. We
identified 18 start functions for tasks in the VECU system
123
B. Lisper et al.
from the configuration files for the ETAS ERCOSEK oper-
ating system.
Second, the files containing code that is needed for the
analysis are to be identified. This may sound trivial: a brute
force approach that should seemingly work would be to
include all source files in the project. But this requires knowl-
edge of where the source files are located, which typically has
to come from the build tool (which, if unlucky, may be some
set of obscure scripts). A complication is that some source
files may include assembly code, or that they are simply miss-
ing (only binaries available): more on the consequences of
this in Sect. 7.4.
A further complication, which we encountered in the pro-
ject, is late binding. Functions with the same name may be
defined in different compilation units, and only at linking
time it is selected which of these functions to actually call by
including the corresponding object file. This is a simple way
to implement a “product line software architecture”, and it is
helpful in situations where variants of the same software are
used in different contexts. Consequently, late binding seems
to be very common for embedded codes. With late binding,
the source code simply does not contain sufficient informa-
tion which source files to include; information from the build
tool is needed.
To summarize: Step 1 in general requires information both
from the operating system configuration and the build tool,
and a source-level analysis tool must somehow acquire it.
7.2 Step 2: converting source files
For SWEET’s flow analysis, the conversion is done in two
steps: first, the source files are parsed into the internal format
of Rose, and then a translation to ALF is done by the melmac
tool.
Both these steps presented problems. The Rose compiler
framework uses a well-known commercial C/C++ frontend
from Edison Design Group (EDG). This frontend is distrib-
uted with Rose as a binary, so it cannot be changed. Much
to our surprise, it turned out that the parser could not pro-
cess some of the target system’s source files. The VECU
target system is compiled with the Windriver Diab compiler,
which also uses the EDG frontend, so we believed it would
be compatible with the frontend for Rose. However, the Diab
version of the frontend was configured to parse a different
dialect of C. Fundamental data types are customised for an
embedded platform in the Windriver compiler, while Rose’s
frontend targets 64-bit unix systems. Furthermore pragmas,
preprocessor directives, and especially packing options were
encoded in a format that was not understood by Rose’s ver-
sion of the EDG frontend.
Since we could not change the Rose frontend, we had to
rewrite some source files by hand to get them through the
parser. There were also a total of 46 occurrences of inlined
Practical experiences of applying source-level WCET
assembly code, located in 25 source files, which the frontend
could not process either. We dealt with this by simply com-
menting out the assembly code. The inlines assembly snip-
pets were mainly single instructions, or directives allocating
buffer areas in memory. Commenting them out is not a strictly
safe solution since the assembly code potentially could affect
the program flow: however, this seems very unlikely for the
inlined assembly that we encountered. Overall, the problems
encountered were very similar to those reported in [2].
It also turned out that Rose itself had problems to handle
some features of the target system’s C code. For instance it
failed to recognize equivalent typedefs as being aliased, it
was not able to handle all types of inline assembly codes,
and it was unable to represent static initialization of function
pointer arrays: the latter was especially problematic since
real-time operating systems like ETAS ERCOSEK often use
static arrays of function pointers to provide the start func-
tions for the tasks in the system. We had to rely on the Rose
developers for fixing the problems, which took time.
The C code of the target system would sometimes stretch
the limits of the C standard. While being handled by Rose,
this would tick off bugs in the melmac tool causing it to gener-
ate invalid ALF code. These bugs had gone unnoticed during
the test phase of melmac since the C code used for testing did
not contain these “features”. Examples of coding that trig-
gered melmac errors are functions being called with a differ-
ent number of arguments than declared, functions returning
no value while not being declared to be of type void, and the
same function being declared and imported at the same time.
Since these bugs were discovered late in the project, we dealt
with them by allowing SWEET to accept ALF code that was
not adhering to the ALF specification rather than correcting
the bugs in melmac (which would have taken more time).
After selecting files due to the late binding, there were
1234 C files to convert. Of these, eight would not pass Rose’s
frontend. For five files, the translation failed due to missing
declarations/include files, and for 21 files there were prob-
lems with the generated ALF code. Thus, in the end there
were only 1,200 files for which correct ALF could be gener-
ated.
The morale of this is that an industrial strength source
analysis tool, at least for C, must be able to adapt to the vari-
ety of C dialects defined by the C compilers that are in use.
It is hard to accomplish this without being in full control of
the translation chain.
7.3 Step 3: link the converted files
When analysing code that stretches several files or compila-
tion units, a global namespace has to be created where sym-
bols have an unambiguous meaning. This process can be seen
as a kind of linking [18], but on source-code level.
59
Source-level linkers exist. One example is cilly, from
the CIL framework [5], which merges a number of C files
into one large C file. However, cilly changes the line num-
bers of statements in a way that cannot be easily traced.
SWEET exports program flow constraints to aiT as source-
code annotations (tool connection S in Fig. 1). The original
line numbers are required for flow constraint annotations in
the annotation format for aiT, so if they are lost then such
annotations cannot be generated. For this and other reasons,
we decided to create our own ALF linker instead.
Our ALF linker works similarly to cilly, and merges
all the ALF files into one big file. However, it also main-
tains the relation between program code locations in C and
ALF files by creating a global map file from the merged ALF
files. To differ between local entities with the same name, the
ALF linker has to perform some “name mangling” to create
unique names. This is done essentially in the same way as by
conventional linkers [18].
A problem, somewhat similar to the late binding prob-
lems described in Sect. 7.1, was caused by the fact that some
header (.h) files contain full function definitions. The mel-
mac tool would simply include .h files, and generate ALF
code for them as well, when included in a C file. If such a .h
file was included in several C files, which was frequently the
case, then several copies (up to hundreds) of the same func-
tion declaration would result. The ALF linker, righteously,
did not accept this. Our solution was to change the linker to
eliminate all identical copies of a function declaration but
one.
The final linked ALF file for the target system became
quite large. This was inconvenient at times: for instance, just
the time to parse it became significant. When analysing a
certain start function, it would have been nice to be able to
do “smart linking” where only the entities required to ana-
lyse that function would be included. However, this turned
out to be hard: there is no way to identify in which source file
a declaration resides short of scanning them all, and making
some kind of symbol table telling in which file each entity
is declared. Also, the aforementioned problems caused by
late binding would have to be solved by a smart linker. Thus,
we abandoned the idea of having a smart linker. Instead we
linked all ALF files, as described above, and then extracted
from the resulting ALF file those declarations necessary to
analyse a certain start function.
7.4 Step 4: performing the flow analysis
The linked ALF file should in principle be ready for analy-
sis. Alas, a successful flow analysis for real industrial codes
typically requires additional information not present in the
available source code. This information must then somehow
be provided, or approximated.
123
60
When analysing the possible program flows of a task, typ-
ically some bounds must be known for inputs that may affect
the program flow (see Fig. 2 for an example). Inputs can
be either arguments to the start function of the task, if any,
and values of global variables when the start functions begin
executing.
It is especially important to restrict the possible values of
input pointers. If the abstract value of a pointer is TOP (any
address), and an assignment is done using the pointer value
as target, then the analysis must assume that the written value
may possibly be written to any data address. This typically
destroys the information needed to identify any interesting
program flow constraints.
SWEET provides value annotations for arguments and
variables, which allow the user to provide simple interval
bounds for these. Inputs that are not annotated will assume
the abstract value TOP (any value is possible). However, the
problem remains how to identify the important inputs and
find proper value ranges for these.
Since we had little time to make elaborate annotations in
the ALL-TIMES project, and little knowledge of the code,
we would mostly let input values default to TOP. We suspect
that this affected the precision of the analysis adversely in
many cases. Somebody more familiar with the code would
probably have been able to do a better job.
For systems that allow parallel or pre-emptive execution
of tasks accessing shared data areas, the additional complica-
tion arises that during the execution of a task, a variable can
be reassigned a new value by some other task. Such shared
variables must be treated differently in the analysis. If there
is no knowledge about the possible preemption points, then
the value of such a variable must be considered possible to
change, due to the actions of some other task in the system,
at any program point. An analysis that does not take this into
account is potentially unsafe.
C has a keyword “volatile”, which is a hint to the compiler
that the variable might be changed by some other activity in
the system. A variable might be marked volatile for many
other reasons, though, and conversely any “non-volatile”
global variable could potentially be shared between tasks
since neither the compiler nor the linker will make any
attempt to check that only variables declared as volatile can
be updated by one task and read by another. Analyses that
identify shared data and compute safe value bounds for these
are conceivable: however, we had no time to develop such
analyses in the project. SWEET currently deals with the prob-
lem by forcing declared volatiles to assume the abstract value
TOP throughout the program, but as explained this is poten-
tially unsafe since there may be variables not declared volatile
that still behave as such.
The second problem is that vital source code often is
missing. For the validator, the big problem turned out to be
that important parts of the code come from a subcontractor,
123
B. Lisper et al.
and we had no access to its source code. Apparently this
is a common situation in the automotive domain, and the
trend towards componentising the software and use third-
party code seems to become stronger. Thus, it is likely that
missing source code will become an increasingly significant
problem for source-level analysis in the future.
We tackled these problems in three ways. First, we added
a mode to SWEET where it will assume a certain default
semantics for unknown entities. Unknown variables will be
set to TOP, which is a safe overapproximation but may lead to
very imprecise results especially if the variable holds pointer
values. The default semantics for unknown functions is that
their return value is TOP, and that they do not affect any global
variables (no side-effects). The latter assumption is clearly
unsafe, but without knowledge of the function a safe analy-
sis will have to assume that it can set any global variable to
anything, which will render the resulting analysis extremely
imprecise.
Second, we extended SWEET’s annotation language to
give it some limited capability to express the semantics
of unknown functions. These annotations allow to specify
bounds on return values, and for possible side effects on given
global variables. When the abstract execution reaches a call to
an unknown function, it will simply skip the function call, and
update the abstract state according to the annotations. How-
ever, the current annotation language cannot express relations
between different values, and thus has strong limitations for
expressing the semantics of functions.
Third, we introduced value annotations for volatiles. Such
an annotation specifies an interval restricting the possible val-
ues of the volatile variable. This is useful if such restrictions
are known, e.g., if the value is read from a sensor with a cer-
tain signal range. We also added a mode for SWEET, which
the user can select, where SWEET simply treats volatile vari-
ables as ordinary ones. This is potentially unsafe, but useful in
situations where variables are declared volatile due to some
other reason than that their values might be changed from
outside. An example is to prevent compiler optimisations to
take place. This use of volatile declarations is not uncommon.
Missing code, and uncertainty about the nature of volatile-
declared variables, posed a problem for the validation of the
source-level analysis. As mentioned, TimingExplorer failed
to bound 102 loops, located in 50 different C functions. Of
these, only 19 functions could be translated into ALF (the
other ones failed mostly due to missing source code). 24 of
the loops that could not be bounded are present in those func-
tions. Two of these 19 functions refer to unknown entities,
and 18 functions refer to volatiles: see Table 2. Of the total
number of functions that could be translated into ALF, about
49 % contain neither undefined entities nor volatiles (and
should thus be possible to analyse with safe results, assum-
ing that no non-volatile globals can be affected from outside
the analysed task).
Practical experiences of applying source-level WCET 61

Table 2 The 19 functions containing loops to be bounded

Start function Unknown Unknown Volatiles # of
variables functions arguments

ATC_AVCONSCALCULATOR_IMPL_calc 0 0 Yes 3
ATC_RECUPPROTOCOLIMPL_IMPL_calc 0 0 Yes 4
ATC_VECTORCONTENT_IMPL_MoveAndInsertFront 0 0 Yes 4
ATC_VECTORCONTENT_IMPL_SNA_Array 0 0 Yes 2
ATC_VECTORCONTENT_IMPL_ZeroArray 0 0 Yes 2
ATC_VECTORCONTENT_Q05_IMPL_MoveAndInsertFront 0 0 Yes 2
ATC_VECTORCONTENT_Q05_IMPL_ZeroArray 0 0 Yes 1
CAN_CONF_EMU_HWE296_IMPL_CAN_TX_UserMessages_Calc 0 1 Yes 0
CRC_IMPL_calc 0 0 Yes 2
CcpCan_RxMsg 2 0 No 2
EMU_BATTERY_GET_IMAX_IMPL_calc 0 0 Yes 3
EMU_BATTERY_GET_IMAX_IMPL_init 0 0 Yes 1
EMU_FEHLERBEHANDLUNG_IMPL_Fehlerbehandlung 0 0 Yes 1
distab_A 0 0 Yes 0
roelFindQueueEntry 0 0 Yes 1
search_s16 0 0 Yes 4
search_s8 0 0 Yes 4
search_u16 0 0 Yes 4
search_u8 0 0 Yes 4

There are 18 start functions for tasks in the system. Of Table 3 The 18 VECU start functions
these 10 refer to unknown variables in the final, linked ALF Start function Unknown Unknown
code, and 16 to unknown functions. See Table 3, which shows variables functions
the number of undefined variables and functions, respec-
ar_100ms 0 1
tively, that are reachable from each start function. Nine start ar_10ms 0 12
functions contain loops for which we had ALF code, and ar_Background_run 1 3
which TimingExplorer could not bound. For a number of rea- CanInterrupt 0 3
sons, we could not obtain any bounds for any of these loops CAN_TX_mode_10ms 0 1
CAN_TX_mode_2ms 0 3
by analysing the start functions. This was due to imprecision dr_100ms 4 8
from unknown entities (especially unknown pointers), but dr_10ms 4 30
also the presence of volatiles whose safe treatment required dr_50ms 0 3
them to be set to TOP, and infinite for(;;); loops that dr_Background 1 5
dr_EMU_10ms 5 5
pose problems for the abstract execution algorithm used by dr_ErrorManager_100ms 3 0
SWEET. dr_VCU_1000ms 1 0
Thus, we resorted to analysing functions deeper in the dr_VCU_100ms_delay2 2 1
call tree. This had the advantage of avoiding to analyse dr_VCU_10ms 9 18
dr_VCU_20ms 2 2
much problematic code. First, we tried to analyse directly MoCMEM_Cyclic 0 1
the 19 functions containing problematic loops that are listed SciInterrupt 0 1
in Table 2. However, we were still not able to bound any
loops. As seen from the table, all but two of these functions were able to bound three of the previously unbounded loops
take arguments. So although these functions refer to very few by a safe analysis (w.r.t. undefined entities and volatiles), and
undefined entities, information about the calling context was two more by a potentially unsafe analysis making default
missing. We thus had to set argument values to TOP in the assumptions about undefined entities, and treating volatiles
analysis, which is the main reason why the analysis failed for as “ordinary” variables. We believe that the low number of
these functions. interesting loops that we were able to bound mainly is due
We finally managed to bound some loops by analysing a to imprecision from undefined entities.
set of functions in-between the start functions and the func-
tions containing the loops in the call tree. 7.5 Step 5: map results back to source code
These functions take no arguments, but since they appear
deeper in the call tree than the start functions they refer to The last step is to map flow constraints back to TimingEx-
fewer undefined functions. By analysing these functions, we plorer or RapiTime, using their native source-level annotation

123
62
formats, in order to support a subsequent WCET estimation.
As mentioned in Sect. 6, SWEET can generate flow con-
straints in these formats. Also here, we encountered some
practical problems. One problem is that some precision was
lost in the translation to these formats: for instance, SWEET
can generate highly context-sensitive flow constraints [9]
which cannot be expressed to the same degree in the for-
mats of TimingExplorer and RapiTime. Another issue is that
SWEET derives loop bounds as bounds on the number of
times the loop header executes, while both annotation for-
mats use the number of times that the loop body executes.
This forced us to make adjustments in the generated loop
annotations.
8 Conclusions
We have identified a number of problems with source-level
program flow analysis. Most problems should be common to
deep, semantics based source-level analysis in general. Thus,
solutions to these problems should be important not only for
WCET analysis but for source-level analysis in general.
Obviously, standardization is desirable as it will relieve
tool providers from the burden of creating a large number of
versions of their tools. Weak language standards, allowing
different compilers to define different dialects, will inevi-
tably provide problems for source-level analysis tools: we
experienced a fair amount of this. However also information
for build processes and tools, like linkers, should prefera-
bly be standardized since this information is important for
source-level analysis. For instance, it is needed to resolve late
binding. On the operating system level, clean standards for
task communication are very desirable. It should be possible
to provide metadata, in standardised formats, that describe
the task communication as well as the task entry points. Also
other information about the execution environment of the
code, such as value ranges for input data, should be possible
to provide in a standardized way.
For the latter, the natural place to put the information is in
software components where it can be shipped together with
the code. Components providing functions should also pref-
errably carry some information about the semantics of these,
like which side effects they might have. Component mod-
els already provide some of the above: for instance AUTO-
SAR provides means to specify input ranges, but components
would need to carry more information. Here, the static analy-
sis community should cooperate with industry to define new
standards for component metadata carrying relevant infor-
mation.
WCET analysis tools need specific information, in partic-
ular regarding program flow constraints. The current situa-
tion is that each tool has its own annotation format for this.
This creates problems with portability between tools, as well
123
B. Lisper et al.
as for third-party tools producing program flow information.
Again, it would be helpful to have an expressive, standard-
ized format. This need was identified already in [17], where
an “annotation language challenge” was suggested to stimu-
late the development of such formats, but little has happened
since then.
It is also possible to develop supporting analyses that can
find some of the information that is needed, but not readily
available in the local code. For instance, type-based static
analyses are known that can detect possible side effects of
functions [22], and in particular safely detect when a func-
tion is free from side effects. This information can be used
for two things: to restrict possible side effects from imported,
unknown functions, and to find global data that is written
by some tasks and read by others (and thus ought to be
declared as volatile in the latter). The side effects are cap-
tured as enriched types, and are therefore suitable to provide
as metadata to modules or components. Another interesting
possibility is to develop mixed source/binary-level analyses
that can be used for code with inlined assembler, or when
only binaries are available for some parts of the code. Using
a multilevel language as ALF for the analysis, which allows
translations from both source-level and binary-level code, is
then clearly an advantage.
Effective use of static analysis tools is immensely helped
by knowing the code well. Many of our difficulties arose from
lack of knowledge of the code: not knowing the intention
with volatile declarations, or which variables would possi-
bly be shared among tasks, or possible side effects of called
functions, etc. On the other hand, successful application of
static analysis also requires good knowledge how tools and
methods work. Thus, to successfully apply static analysis
methods in the development of production code, we believe
that software developers must have proper training in these
techniques. This puts an obligation on universities to move
these topics into their curricula, where they are rarely found
today. Another conclusion is that the people that perform the
verification should be the same as the ones developing the
code.
However, even if advances are made as outlined above,
static analysis will in practice often rely on assumptions that
have to be made to obtain a reasonably precise analysis when
information is lacking. The results are then valid only as
far as the assumptions are, which may render the analysis
unsound if the assumptions are not fulfilled. Static analysis
will thus sometimes not provide a safe guarantee that bugs
are absent (or that the WCET is safely overestimated), it will
do so only with a certain confidence level. This has to be
kept in mind, but will in no way render static analysis use-
less. For instance, when certifying safety-critical systems,
static analysis can provide an additional, independent source
of evidence which will then provide increased confidence in
the result of the verification.
Practical experiences of applying source-level WCET
Finally, note that quite a few of the problems described
above will not arise for a binary level analysis of a stati-
cally linked executable. All the code will then be available,
and all ambiguities will have been resolved by the compiler
and linker. However, binary level analysis is difficult since
it requires a fair amount of reverse engineering, recreating
structure that is readily available in the source code. This
reverse engineering can be hard to carry out, especially for
heavily optimized embedded code. We are thus convinced
that source-level analysis has its place both in general, and
specifically to support timing analysis.
References
1. Barkah, D., Ermedahl, A., Gustafsson, J., Lisper, B., Sandberg, C.:
Evaluation of automatic flow analysis for WCET calculation on
industrial real-time system code. In: Burns, A. (ed.) Proceedings
of 20th Euromicro Conference on Real-Time Systems, pp. 331–340
(2008)
2. Bessey, A., Block, K., Chelf, B., Chou, A., Fulton, B., Hallem, S.,
Henri-Gros, C., Kamsky, A., McPeak, S., Engler, D.: A few billion
lines of code later: using static analysis to find bugs in the real
world. Commun. ACM 53(2), (2010)
3. Byhlin, S., Ermedahl, A., Gustafsson, J., Lisper, B.: Applying static
WCET analysis to automotive communication software. In: Pro-
ceedings of 17th Euromicro Conference on Real-Time Systems
(ECRTS’05) (2005)
4. Carlsson, M., Engblom, J., Ermedahl, A., Lindblad, J., Lisper, B.:
Worst-case execution time analysis of disable interrupt regions in
a commercial real-time operating system. In: Pettersson, P., Yi,
W. (ed.) Proceedings of 2nd International Workshop on Real-Time
Tools, Copenhagen (2002)
5. CIL infrastructure for C program analysis and transformation
(2010) http://manju.cs.berkeley.edu/cil
6. Cousot, P., Cousot, R., Feret, J., Mauborgne, L., Miné, A., Monni-
aux, D., Rival, X.: The ASTRÉE analyzer. In: Sagiv, M. (ed.) Pro-
ceedings of 14th European Symposium on Programming. Lecture
Notes in Computer Sci., vol. 3444, pp. 21–30. Springer, Berlin
(2005)
7. Emanuelsson, P., Nilsson, U.: A comparative study of industrial sta-
tic analysis tools (extended version). Technical report, Linköping
University (2008)
8. Ferdinand, C., Heckmann, R., Langenbach, M., Martin, F.,
Schmidt, M., Theiling, H., Thesing, S., Wilhelm, R.: Reliable and
precise WCET determination for a real-life processor. In: Proceed-
ings of 1st International Workshop on Embedded Systems (EM-
SOFT2001), LNCS, vol. 2211 (2001)
9. Gustafsson, J.: SWEET manual, 2011. http://www.mrtc.mdh.se/
projects/wcet/sweet/manual/
10. Gustafsson, J., Ermedahl, A., Lisper, B., Sandberg, C., Källberg L.:
ALF—a language for WCET flow analysis. In: Holsti, N. (ed.) Pro-
ceedings of 9th International Workshop on Worst-Case Execution
Time Analysis (WCET’2009), pp. 1–11, Dublin, Ireland (2009)
11. Gustafsson, J., Ermedahl, A., Sandberg, C., Lisper, B.: Automatic
derivation of loop bounds and infeasible paths for WCET analysis
using abstract execution. In: Proceedings of 27th IEEE Real-Time
Systems Symposium (RTSS’06), pp. 57–66, Rio de Janeiro, Brazil,
Dec. (2006). IEEE Computer Society
12. Healy, C., Sjödin, M., Rustagi, V., Whalley, D., Engelen,
R.van : Supporting timing analysis by automatic bounding of loop
iterations. J. Real-Time Syst. 18(2–3), 129–156 (2000)
63
13. Heckmann, R., Ferdinand, C., Kästner, D., Nenova, S.: Architec-
ture exploration and timing estimation during early design phases
(this volume)
14. Holsti, N., Långbacka, T., Saarinen, S.: Using a worst-case execu-
tion-time tool for real-time verification of the DEBIE software. In:
Proceedings of DASIA 2000 Conference (Data Systems in Aero-
space 2000, ESA SP-457) (2000)
15. Holsti, N., Långbacka, T., Saarinen, S.: Worst-case execution-time
analysis for digital signal processors. In: Proceedings of EUS-
IPCO 2000 Conference (X European Signal Processing Confer-
ence) (2000)
16. Kirner, R.: Extending Optimising Compilation to Support Worst-
Case Execution Time Analysis. PhD thesis, Technische Universität
Wien, Vienna, Austria (2003)
17. Kirner, R., Knoop, J., Prantl, A., Schordan, M., Wenzel, I.: WCET
analysis: the annotation language challenge. In: Rochange, C. (ed.)
Proceedings of 7th International Workshop on Worst-Case Execu-
tion Time Analysis (WCET’2007), pp. 83–99, Pisa, Italy (2007)
18. Levine, J.: Linkers and Loaders. Morgan Kaufmann, 2000. ISBN
1-55860-496-0
19. Lisper, B.: The ALL-TIMES project: Introduction and overview
(this volume)
20. Merriam, N., Lisper, B.: Estimation of productivity increase for
timing analysis tool chains (this volume)
21. Montag, P., Goerzig, S., Levi, P.: Challenges of timing verification
tools in the automotive domain. In: Margaria, T., Philippou, A.,
Steffen, B. (ed.) Proceedings of 2nd International Symposium on
Leveraging Applications of Formal Methods (ISOLA’06), Paphos,
Cyprus (2006)
22. Nielson, F., Nielson, H.R., Hankin, C.: Principles of Program Anal-
ysis, 2nd edn. Springer, Berlin. ISBN 3-540-65410-0 (2005)
23. Prantl, A., Schordan, M., Knoop, J.: TuBound—a conceptually new
tool for worst-case execution time analysis. In: Kirner, R. (ed.) Pro-
ceedings of 8th International Workshop on Worst-Case Execution
Time Analysis (WCET’2008), pp. 141–148, Prague, Czech Repub-
lic (2008)
24. Rodriguez, M., Silva, N., Esteves, J., Henriques, L., Costa, D.,
Holsti, N., Hjortnaes, K.: Challenges in calculating the WCET of
a complex on-board satellite application. In: Proceedings of 3rd
International Workshop on Worst-Case Execution Time Analysis
(WCET’2003), Porto (2003)
25. Rose http://www.rosecompiler.org(2012)
26. Sandell, D., Ermedahl, A., Gustafsson, J., Lisper, B.: Static timing
analysis of real-time operating system code. In: Proceedings of 1st
International Symposium on Leveraging Applications of Formal
Methods (ISOLA’04), (2004)
27. Schreiner, D., Barany, G., Schordan, M., Knoop, J.: Comparison
of type-based vs. alias-based component recognition for interface-
level timing annotations (this volume)
28. Sehlberg, D., Ermedahl, A., Gustafsson, J., Lisper, B., Wiegratz,
S.: Static WCET analysis of real-time task-oriented code in vehi-
cle control systems. In: Margaria, T., Philippou, A., Steffen, B.
(eds.) Proceedings of 2nd International Symposium on Leverag-
ing Applications of Formal Methods (ISOLA’06), Paphos, Cyprus
(2006)
29. Thesing, S., Souyris, J., Heckmann, R., Randimbivololona, F.,
Langenbach, M., Wilhelm, R., Ferdinand, C.: An abstract interpre-
tation-based timing validation of hard real-time avionics software.
In: Proceedings of the IEEE International Conference on Depend-
able Systems and Networks (DSN-2003) (2003)
123