Bertraneetal Uml FN Ieee Nov 2010
Bertraneetal Uml FN Ieee Nov 2010
Julien Bertrane Patrick Cousot Radhia Cousot Jérôme Feret Laurent Mauborgne
ENS∗ ENS∗ & CIMS§ CNRS & ENS∗ INRIA & ENS∗ IMDEA∗∗
Antoine Miné Xavier Rival
CNRS & ENS∗ INRIA & ENS∗
Abstract
Formal methods are increasingly used to help ensuring the
modeling
correctness of complex, critical embedded software systems.
We show how sound semantic static analyses based on Ab-
S static analysis
stract Interpretation may be used to check properties at var- A
O
ious levels of a software design: from high level models to low
level binary code. After a short introduction to the Abstract code
generation V
Interpretation theory, we present a few current applications: a
checking for run-time errors at the C level, translation val- l
static analysis i
idation from C to assembly, and analyzing SAO models of C d
a
communicating synchronous systems with imperfect clocks. t
translation i
We conclude by briefly proposing some requirements to ap- compilation validation
o
n
ply Abstract Interpretation to modeling languages such as
UML.
B static analysis
I
keywords: Abstract interpretation, Critical software, Em- N test
bedded systems, Static analysis, System design, System
modeling, System verification. execution
1 Introduction
Ensuring the correctness of software systems constitutes a Figure 1: Example workflow for designing an embedded ap-
large part of software development budgets. It is particu- plication.
larly important for critical embedded systems, such as found
in automotive, aerospace and medical applications, as the
slightest programming “bug” may have catastrophic finan- based static analysis, which always terminates and covers all
cial and even human cost. In this article, we build a case executions, albeit in an over-approximated way. For example
for using static analysis based on Abstract Interpretation to it can detect dead code (never executed) or dead data struc-
help ensuring software correctness. tures (constructed but never used) but cannot always prove
We illustrate a possible use for static analysis in Fig. 1. In their absence. Moreover, static analysis can be applied at
this drastically simplified workflow inspired from a real in- many levels: machine-readable specification, program source
dustrial case [27], an engineer (not necessarily a programmer) or binary. The higher level the better, as it provides purer in-
models a control system using the SAO graphical language, formation to the tool and its feedback is easier to understand
TM
a precursor and similar tool as SCADE [14] — a Simulink to the designer. However, higher levels abstract away some
fragment similar to SAO is also shown in Fig. 2. It is then au- aspects of computations, which makes it impossible to check
tomatically translated to the programming language C and some properties of actual executions. For instance, SAO and
then compiled to produce the actual binary software exe- SCADE have real arithmetics and do not specify how actual
cuted by the device. Validation includes testing, which re- numerical computations are performed nor the type of num-
quires executing (part of) the binary with some monitoring bers, so that a static analysis of numeric overflows (as done
and is able to check a wide range of properties (including by Astrée [1, 11, 5], Sec. 3) or of the precision of floating-
functional ones) but is costly and never achieves a full cover- point computations (as done by Fluctuat [17]) is done at the
age of all possible executions (path- and data-coverage). For- C level — a static analysis of real expressions at the SCADE
mal methods can also be employed. In particular, semantic- level may however be used to determine its numerically most
precise float compilation to C [20]. Likewise, neither SAO nor
(∗) ÉcoleNormale Supérieure, 45, rue d’Ulm, Paris, France, C make any guarantee about the worst-case execution time,
[email protected]
(§) Courant Institute of Mathematical Sciences, NYU, New York, NY so, such an analysis (as done by AbsInt’s aiT [18]) is done at
(∗∗) Fundación IMDEA Software, 28660-Boadilla del Monte, Madrid, the binary level and for a specific processor. A SAO model
Spain, [email protected] can also be enriched with non-software elements, such as real-
1
a b 2 Abstract Interpretation
-
We provide a succinct introduction to Abstract Interpreta-
tion, more details are provided e.g. in [3].
++
+ z-1 z-1
t Unit delay
Switch
Unit delay
2.1 Small-Step Operational Semantics
Switch
2
Define F (X) , I ∪ post[t]X where post[r]X , r(X) ,
{s0 | ∃s ∈ X : r(s, s0 )} is the image of the set X by the
relation r. We have F ∈ ℘(S) → ℘(S)(4) is additive(5) hence
strict(6) and increasing.(7) We have R = F (R) since a state
is reachable iff it is an initial state or the successor of a reach-
able state. If F (X) ⊆ X then X contains the initial states
I and, transitively, any of its successors so R ⊆ X. This
⊆
implies that R = lfp F , which is not computable either. Figure 3: A set and its interval and octagonal abstractions.
2.4 Abstraction
octagons [25] that infer relations of the form ±X ± Y ≤ c
2.4.1 Intervals (where c is a constant automatically inferred by the static
analysis), see Fig. 3.
Let us start with the simple example of abstracting a set
V ⊆ Z of integers (e.g. the set of possible values of an integer
variable) by an interval of values αi (V ) , [min V, max V ] 2.4.3 Transformers
(where min Z , max ∅ , −∞ and max Z , min ∅ , +∞). Transformers, that is, relations between states, can also be
In particular for the empty set ∅, αi (∅) = [+∞, −∞]. In abstracted. Consider for example the abstraction of a rela-
general, this is obviously an over-approximation since the tion r ⊆ S × S by its right image αI (r) , r(I) , post[r]I ,
interval αi (V ) may contain spurious values not in V . So {x0 | ∃x ∈ I : r(x, x0 )} of a given set I ⊆ S (e.g. of initial
from z 6∈ αi (V ) we can conclude z 6∈ V whereas knowing that states). For example, the reachable states of hS, I, E, ti are
z ∈ αi (V ) in the abstract, we do not know whether z ∈ V R = αI (t? ) so reachability is an abstraction of the big-step
or z 6∈ V in the concrete since z might be a spurious value. semantics. We have:
The concretization is γi ([`, h]) , {z ∈ Z | ` 6 z 6 h}. Let
˙ R
αI (r) ⊆
us define the abstract domain of intervals Vi] , {[`, h] | ` ∈
Z ∪ {−∞} ∧ h ∈ Z ∪ {+∞} ∧ ` 6 h} ∪ {[+∞, −∞]}. We have ⇔ {x0 | ∃x ∈ I : r(x, x0 )} ⊆ R Hdef. αI I
AIAA Infotech@Aerospace 2010, Atlanta, georgia, 04/20/2010
0 0 0 2
∀V ∈ ℘(Z) : ∀[`, h] ∈ Vi] : αi (V ) ⊆ [`, h] ⇐⇒ V ⊆ γi ([`, h]) ⇔ ∀x ∈ S : (∃x ∈ I : r(x, x )) =⇒ x ∈ R Hdef. ⊆I
and so, by definition, the pair hα, γi is a Galois connection,(8) ⇔ ∀x0 ∈ S : ∀x ∈ I : r(x, x0 ) =⇒ x0 ∈ R HgeneralizationI
γi
written h℘(Z), ⊆i ← −−−−−− hVi] , ⊆i. ⇔ ∀x, x0 ∈ S : r(x, x0 ) =⇒ (x ∈ I =⇒ x0 ∈ R) Hdef. =⇒ I
α→ i
⇔ r ⊆ {hx, x0 i | x ∈ I =⇒ x0 ∈ R} Hdef. ⊆I
2.4.2 Cartesian Abstraction ⇔ r ⊆ γI (R)
Hby defining γI (R) , {hx, x0 i | x ∈ I =⇒ x0 ∈ R}I
A set V ⊆ Zn of vectors of n > 1 integer values (e.g. the set
of possible values of n integer variables) can be abstracted Qn which is the characteristic property of the Galois connection
γI
by projection along each component αC (V ) , i=1 {z | h℘(S × S), ⊆i ←−−−−
−− h℘(S), ⊆i.
∃z1 , . . . , zi−1 , zi+1 , . . . , zn ∈ Z : hz1 , . . . , zi−1 , z, zi+1 , . . . , α→ I
3
which is the idea of the calculational design of static analyz- verification purposes (e.g. to prove the absence of run-time
ers [7]. errors).
More generally, under suitable hypotheses of existence of
joins in posets and fixpoints [8, 7], if f ∈ C → C, hC,
i←
γ
−−
−− −− hA] , vi and f ] ∈ A] → A] satisfy α ◦ f = f ] ◦ α, 3 Checking Run-Time Errors with
α→
then α(lfp f ) = lfp f ] .
v
Astrée
Faced with undecidable problems, α(lfp f ) is often non- We now describe a first concrete application of Abstract In-
computable, in which case it must be over-approximated terpretation: the static analyzer Astrée [4] that checks for
v
α(lfp f ) v lfp f ] , which follows from the local condition run-time errors in embedded C programs and has been suc-
α ◦ f v̇ f ] ◦ α.(10) This is the case for example for interval cessfully used in aeronautics [13] and aerospace [6]. It started
analysis [8]. in 2001 as an academic project [11] and is industrialized by
AbsInt Angewandte Informatik [1] since 2009.
2.4.5 Fixpoint Approximation
Under suitable hypotheses of existence of joins in posets and 3.1 Semantics
fixpoints [8, 7],
Snfixpoints can be computed iteratively. For ex- 3.1.1 Operational Semantics of C
ample, R = i=0 F n (∅)(11) with the intuition that the reach-
able states are reachable in either 0, 1, 2, . . . , n, . . . compu- Astrée accepts a fairly large subset of C, excluding dy-
tation steps. However, in general, convergence of the iterates namic memory allocation, recursivity, and parallelism, that
to a fixpoint may require infinitely many iterations (for unde- are often unused (even forbidden) in embedded code. The
cidable problems) or suffer a combinatorial explosion in time language syntax and concrete semantics are based on the
and memory (for finite but complex problems). But for rare C99 norm [21], supplemented with the IEEE 754-1985 norm
cases where the fixpoint can be computed directly (e.g. by [19] for floating-point computations. However, the C99 norm
elimination), convergence must in general be accelerated, e.g. leaves many aspects of the semantics unspecified and lets
using a widening O [8] at the prejudice of precision. A naı̈ve implementations decide. As embedded software are rarely
example of widening for intervals is [`i , hi ]O[`i+1 , hi+1 ] , strictly conforming but rely instead on platform-specific fea-
[if `i+1 < `i then − ∞ else `i , if hi+1 > hi then + ∞ else `i ] tures, Astrée also takes them into account and provides
so that unstable bounds are pushed to infinity, which en- options for the user to tune some semantic aspects (e.g. the
forces rapid although imprecise convergence. A narrowing bit-size, alignment, and byte order of data-types).
can then be used to remove some of the infinite bounds [8].
3.1.2 Run-Time Errors
2.4.6 Design of a Static Analyzer
Astrée checks for run-time errors, that is, operations that
The design of a static analyzer for a (specification or pro- are either undefined on the user-defined platform (e.g. out-of-
gramming) language starts with the definition of its seman- bound array accesses) or have unintended results (e.g. wrap-
tics and the properties of interest for each program of the around after integer overflows). The property to verify (ab-
language, often in the form of fixpoints lfp F correspond- sence of run-time errors) is thus implicit and derived from the
ing to an abstraction of the notion of computation (e.g. program’s own source. More precisely, Astrée checks over-
reachability). F is then designed by induction on the lan- flows in unsigned and signed integer and float arithmetics and
guage syntax. Then, an abstraction α is defined, which casts, divisions by zero, out-of-bound array accesses, NULL,
is a complex task, hence must be done by composition of dangling, out-of-bound and misaligned pointer dereferences,
simpler abstractions, using standard composition methods and assertion failures (in calls to the assert C function).
Vm
such as the reduced product α(X) , i=1 αi (X) combin- Astrée does not stop at the first encountered error but
ing different abstractions αi (X) [9] and standard abstrac- instead continues the analysis for all executions that have
tions (some already implemented in libraries [22]). The a well-defined semantics (e.g. integer overflows with wrap-
static analyzer is then designed by induction on the language around). Thus, if there are no alarms, or if all executions
syntax. It reads a program, computes the abstract trans- leading to alarms can be proved by other means to be spuri-
former F ] (designed to satisfy α ◦ F v F ] ◦ α) for that ous, then the program is indeed free from run-time errors.
v
program, over-approximates the abstract fixpoint lfp F ]
by an iterative computation with convergence acceleration 3.2 Analyzed Codes
with widening/narrowing. This ensures that the result A Although Astrée accepts a large variety of C codes, it can-
(e.g. an abstract invariant for reachability) is sound (i.e. not analyze most of them precisely and efficiently. It is
v
α(lfp F ) v lfp F ] v A). The result A is then used for mainly specialized, by its choice of abstractions, to analyze
(10) The pointwise ordering is f v̇ g if and only if ∀x : f (x) v g(x).
control/command synchronous programs automatically gen-
(11) The powers of a function f are: f 0 is the identity, f 1 , f , and erated from higher level specifications. Once generated, such
f n+1 = f ◦ f n. codes have the following structure:
4
initialize state variables errors in the main loop, and a domain to handle quaternion
loop for 10 h computations.(13)
read inputs from sensors
In addition to numerical domains, a specific memory do-
update state and compute output
write outputs to actuators
main [24] has been developed to abstract structures and ar-
wait for next clock tick (10 ms) rays in a field-sensitive way, and to handle pointers and type-
unsafe C constructions (such as type-punning, physical casts,
(where the read, update and write instructions may be scat- or union types). Finally, an abstraction of execution traces
tered in the source or encapsulated within functions) and fea- [29] partitions the reachable states with respect to the his-
ture a large number of global variables (the state), floating- tory of computation and permits some path-sensitivity.
point computations, few nested loops, and a limited number The various abstractions are independent modules, each
of recurring code patterns (a few macros widely instanti- with its own private abstract representation of properties and
ated). algorithms, that communicate using a sophisticated commu-
Programs analyzed by Astrée should be stand-alone, i.e., nication network [10] approximating the classic notion of re-
have no undefined symbols. Nevertheless, programs are run duced product [9].
within an environment and typically fetch external data, e.g.
sensor values, through memory-mapped registers. Astrée
3.3.2 Ensuring Precision and Efficiency
allows specifying these memory locations as “volatile” with
a range of expected values (or possibly the full range of the A key to the efficiency of Astrée is its parsimonious and
type, including special NaN or ±∞ float values). The analy- localized use of carefully limited abstract domains. One ex-
sis naturally considers all possible sequences of inputs in the ample is the use of octagons [25] which are less expressive but
specified ranges. cheaper than general polyhedra [12] (cubic versus exponen-
tial cost). Moreover, relational domains, such as octagons
3.3 Design of Astrée and boolean trees, do not relate all variables together, but
are limited to small packs of variables. Likewise, trace par-
Astrée is an abstract interpreter: it traverses the program titioning is only performed on limited portions of the source
by structural induction on its syntax, iterating loops and code, after which all partitions are merged together. Code
stepping into functions, to collect an abstraction of all pos- portions and variable packs are determined automatically by
sible execution traces. The analysis is thus fully flow- and simple, syntax-directed pre-analyses. Finally, domains only
context-sensitive. Its termination is guaranteed by the use of communicate a selected portion of the information they infer
widening operators O [8] to accelerate loops and the absence to other domains — a fully reduced product would not scale
of recursion. up given the amount of information inferred by the many
domains.
3.3.1 Abstractions A key to the precision of Astrée is its design by refine-
ment, which is made easy by its very modular design. We
Astrée does not use a single abstraction, but rather many
actually started from a simple interval-based analyzer and
abstractions (more than 20) that can be switched on and off.
improved it until it reached zero alarms on a first family
For instance, expressing the absence of many run-time er- of realistic code [4], then considered other, more complex,
rors requires information on variable bounds, and so, As- codes. When encountering a new kind of codes, the analy-
trée implements the interval domain [8] based on interval sis generally terminates quickly but with some false alarms,
arithmetics [26].(12) However, discovering precise bounds of- which must be investigated by hand to find the cause of
ten requires stronger properties, especially for loops that re- imprecision. The analysis can then be improved in various
quires invariant relations between variables (e.g. between the ways, from easiest and most common, to most time consum-
loop index and other variables used in the loop body). Hence, ing but thankfully seldom required. Often, it is sufficient to
Astrée uses relational domains, such as octagons [25] that tune some parameters of the abstractions that are exposed
infer relations of the form ±X ± Y ≤ c, and boolean deci- through around 150 command-line options (such as iteration
sion trees that handle disjunctions precisely — for instance strategies, domain aggressiveness, pack size, etc.), which any
(B ∧ X > 1) ∨ (¬B ∧ X < −1). trained end-user can do. When Astrée already contains a
Beside these classic, general-purpose domains, Astrée domain able to infer the missing information, a solution is to
features domain-specific abstractions, tailored to its use in update the pre-analysis of variable packs and code portions
control/command software. Examples include a domain to where the domain is activated — this happened, in particu-
handle digital filters [15], as presented in Fig. 2, a domain lar, once while analyzing programs in the same application
of geometric-arithmetic deviations [16] X ≤ α(1 + β)clock domain but with a new code generator [3]. The regularity of
used to bound the accumulation of floating-point rounding automatically generated code is very helpful to design robust
(12) However interval arithmetics is used statically (at compile-time) full-scale pre-analyses by generalisation of test cases. When
with a widening to accelerate convergence of iterative fixpoint compu-
tations, not at all dynamically (at run-time) as in the traditional use (13) In mechanics, quaternions extend the complex numbers to desig-
of interval arithmetics to evaluate expressions of numerical programs. nate rotations in the 3-dimensional space.
5
the information is inferred but fails to be exploited, new com- that approach is hard to scale, as the analysis of low level
munication channels between domains can be opened. These operations is often complex. A second technique proceeds
two cases require minor modifications to the analyzer source. by an automatic proof of equivalence (also known as trans-
When all fails, it is always possible to design and implement lation validation) of both programs. Note that translation
a new abstract domain focusing on the missing properties, validation is closely linked to the proof of absence of run-
but this is a research-grade activity. This last case happened time errors at the source level: indeed, semantic equivalence
when extending Astrée from aeronautic to space applica- can only be guaranteed on safe executions, whereas unsafe
tions [6]: the later required a domain to handle quaternion runs typically have undefined semantics.
computations, which were absent in the former application. Both techniques can be formalized in the Abstract Inter-
pretation framework [28], since the compiler semantic effect
3.4 Applications reduces to a classic fixpoint transfer, where C computation
steps are translated into assembly computation steps. Such
A first application of Astrée was the proof of absence of run- a formalization allows for the translation certification to in-
time errors in two families of industrial embedded avionic terface well with the C code analysis.
control/command software generated from SAO specifica-
tions [13]. Programs in the first family have around 100 K The Lcertify tool was developed as a library of data-
code lines and 10 K global variables (half of which are floats) structures and algorithms for translation validation, follow-
and can be analyzed in around 2 h on a 64-bit 2.66 GHz intel ing the framework exposed in [28]. It comes with a C front-
workstation using a single core. Programs in the second fam- end, but it can also be used with a custom front-end, adapted
ily control more modern systems and are both more complex to a user-specific imperative language, as used for some ap-
and longer: up to 1 M code lines. They are analyzed in 50 h. plications. At the assembly level, it takes 32-bit PowerPC bi-
Both analyses give zero false alarms. naries. It can certify the compilation of industrial-size codes
in a few minutes including disassembly.
A second application was the analysis of space software
[6] or, more precisely, a 14 K lines C code generated from a
SCADE [14] model designed by Astrium ST. After special-
ization required by a change of application domain and code
generator, the code could be analyzed in 1 h, with zero false 5 Imperfectly-Clocked Synchronous
alarm.
Since its industrialization by AbsInt, Astrée is being Systems
adapted to handle code generated by dSPACE TargetLink (a
popular code generator for MATLAB, Simulink and State- 5.1 Proving Temporal Specifications
flow) with encouraging preliminary results [23].
The analysis presented in Sec. 4 allows binaries obtained
through the process explained in Fig. 1 to be proved safe
4 Translation Validation with respect to specifications expressed at the C language
The analysis described in Sec. 3 is performed at the source level or at the assembly language level. This is a huge part
level, thus its results hold true at the assembly level only of the control units of embedded systems which are then cer-
if the compilation of the C code is semantically correct. tified. On the other hand, the temporal specifications are
In some application domains, such as avionics, certification rather expressed at SAO level, where the synchronous hy-
rules state that the development process should be certified pothesis and the syntax make them easier to define and read.
and that the final version of the software should be certi- As many systems are designed in a distributed way, this im-
fied [30]. From this point of view, the analysis of the C code plies studying multi-clock, inherently asynchronous systems.
cannot be considered a sufficient guarantee, as the use of an These systems are luckily not arbitrary asynchronous sys-
incorrect compiler may ruin the whole certification effort. tems but rather imperfectly-clocked, meaning that we have
While analysis of the target code is adequate for some some information about their physical clocks and their com-
applications such as worst-case execution time [18], higher munication channels that may be enough to prove the desired
level properties such as absence of run-time errors are easier specification. A typical specification for a clock is that its pe-
to reason about at the C level, since many simple C oper- riod (the time between two consecutive clock ticks) is equal
ations turn into complex pieces of assembly code, as is the to some fixed value δ with a possible imprecision of x%.
case for floating point conversions or code in which the notion A particular case is redundant sub-systems. The whole
of error has disappeared (such as memory accesses). Thus, system is made safer by detecting the failures of one of the
it is preferable to exploit the results obtained at the source redundant units and by considering only the results of other
level in order to cope with the target code certification in a equivalent units. The synchronous language community pro-
more efficient way. A first approach relies on the translation posed safe ways to handle this case, we thus developed ab-
of invariants obtained in Sec. 3 into assembly level proper- stract domains that can be very precise on the code produced
ties, which can be checked using an independent analysis, yet following these guidelines.
6
5.2 Continuous-Time Semantics and Tem- other one must be validated, since the different levels can
poral Abstract Domains significantly differ in their description of the target system.
A modeling language like UML describes nothing but dif-
We consider a continuous-time semantics since it allows ab- ferent abstractions of the target system, at different levels
stract domains to compute a precise fixpoint abstracting this of abstraction, and so, Abstract Interpretation is certainly
semantics. This is because the mathematical properties of applicable both to formalize these abstractions and to de-
continuous spaces are richer than those of discrete ones, and velop static analysis techniques at each level of abstraction.
maybe also because these systems are actually designed in a However, modeling languages are usually not formalized and
continuous world through differential equations. subject to multiple, if not contradictory, interpretations. As
By defining an universal constraint on a time interval [a; b] with any formal method, the first task towards the use of
and a Boolean x, denoted ∀ha; bi : x, we can describe signals Abstract Interpretation on UML would therefore be to pro-
that take the value x during the whole time interval [a; b]. vide a rigorous mathematical definition of the meaning of the
Similarly, an existential constraint, denoted ∃[a; b] : x, de- data, business, object, and component modeling, and their
scribes signals that take the value x at least once during [a; b]. diagramatic representations. It will then be possible to de-
This abstract information can be propagated abstractly in fine in what sense modeling languages do abstract the design
an efficient way. For example, the effect of a negation oper- process and ultimately the target system. Then, the devel-
ation on a ∀ha; bi : x signal turns it into ∀ha; bi : ¬x. In a opment of tools, going beyond mere syntactic checks, will be
more complex way, yet at the cost of only two additions, a possible.
communication channel transmitting information in a serial
way with at least α and at most β delay, submitted with a Acknowledgments. We thank Isabelle Perseil for her kind
∃[a; b] : x constraint results in ∃[a + α; b + β] : x. invitation to the UML&FM 2010 workshop.
By considering conjunctions of these elements, we may ex-
press temporal properties. This abstract domain thus plays
a similar role as the one of the interval domain presented in References
Sec. 2 for the analysis of the code of one unit only.
[1] AbsInt, Angewandte Informatik. Astrée run-time error
Additional domains on time properties were defined in [2]. analyzer. http://www.absint.com/astree/.
This temporal aspect does not only enable proving tempo-
ral properties, but also allows the automatic definition of a [2] Bertrane, J. Proving the properties of communicating
imperfectly-clocked synchronous systems. In Proceedings of
reduced product [9], the time becoming a common language
the Thirteenth International Symposium on Static Analysis
between them.
(SAS 06) (Seoul, 29–31 Aug. 2006), K. Yi, Ed., vol. 4134 of
LNCS, Springer, pp. 370–386.
5.3 Implementation and Experiments [3] Bertrane, J., Cousot, P., Cousot, R., Feret, J.,
Mauborgne, L., Miné, A., and Rival, X. Static analysis
Relaxing the synchrony hypothesis allows the certification of and verification of aerospace software by abstract interpreta-
a bigger subset of the whole embedded system, at the price of tion. In AIAA Infotech@Aerospace (I@A 2010), AIAA-2010-
a much more complex analysis that actually depends on the 3385. AIAA (American Institute of Aeronautics and Astro-
imprecision of the clocks and the communication systems. A nautics), Apr. 2010, pp. 1–38.
prototype static analyzer has been developed according to
[4] Blanchet, B., Cousot, P., Cousot, R., Feret, J.,
these ideas and was able to prove some temporal properties
Mauborgne, L., Miné, A., Monniaux, D., and Rival,
of redundant SAO systems with a voting system arbitrat- X. Design and implementation of a special-purpose static
ing among them. Furthermore, when the analyzer cannot program analyzer for safety-critical real-time embedded soft-
prove the specification, looking at the abstract fixpoint is ware, invited chapter. In The Essence of Computation: Com-
sometimes sufficient to devise an erroneous trace. When this plexity, Analysis, Transformation. Essays Dedicated to Neil
is not the case, it may be due false alarms that might be D. Jones, T. Mogensen, D. Schmidt, and I. Sudborough,
removed by creating more precise abstract domains. Inci- Eds., LNCS 2566. Springer, 2002, pp. 85–108.
dentally, by trying the prototype on systems with different [5] Blanchet, B., Cousot, P., Cousot, R., Feret, J.,
parameters, interesting information can be obtained, such as Mauborgne, L., Miné, A., Monniaux, D., and Rival,
the minimal synchrony for the stabilization of the values read X. A static analyzer for large safety-critical software. In
by sensors such that the specification is proved. Proc. ACM SIGPLAN ’2003 Conf. PLDI (San Diego, 2003),
ACM Press, pp. 196–207.
[6] Bouissou, O., Conquet, E., Cousot, P., Cousot, R.,
6 Conclusion Feret, J., Goubault, E., Ghorbal, K., Lesens, D.,
Mauborgne, L., Miné, A., Putot, S., Rival, X., and
We have shown that static analysis by Abstract Interpreta- Turin, M. Space software validation using abstract inter-
tion can be applied from the design to the implementation pretation. In Proc. of the Int. Space System Engineering
of software systems. Each level of description of the system Conference, Data Systems In Aerospace (DASIA’09) (Istan-
must be checked, and the translation from one level to an- bul, Turkey, 26–29 May 2009), ESA publications, pp. 1–7.
7
[7] Cousot, P. The calculational design of a generic abstract programs. In Tools for Automatic Program AnalysiS (TAPAS
interpreter. In Calculational System Design, M. Broy and 2010), Perpignan, France (17 Sep. 2010).
R. Steinbrüggen, Eds. NATO ASI Series F. IOS Press, Am- [21] ISO/IEC JTC1/SC22/WG14 Working Group. C stan-
sterdam, 1999. dard. Tech. Rep. 1124, ISO & IEC, 2007.
[8] Cousot, P., and Cousot, R. Abstract interpretation: a [22] Jeannet, B., and Miné, A. Apron: A library of numer-
unified lattice model for static analysis of programs by con- ical abstract domains for static analysis. Computer Aided
struction or approximation of fixpoints. In Conf. Rec. of the Verification, CAV’2009 5643 of LNCS (2009), 661–667.
4th ACM Symp. on Principles of Programming Languages
(POPL’77) (Jan. 1977), pp. 238–252. [23] Kästner, D., Wilhelm, S., Nenova, S., Cousot, P.,
Cousot, R., Feret, J., Mauborgne, L., Miné, A., and
[9] Cousot, P., and Cousot, R. Systematic design of program
Rival, X. Astrée: Proving the absence of rutime er-
analysis frameworks. In Conference Record of the Sixth An-
rors. In Proc. of Embedded Real-Time Software and Systems
nual ACM SIGPLAN-SIGACT Symposium on Principles of
(ERTS’10) (Toulouse, France, May 2010), pp. 1–5. (to ap-
Programming Languages (San Antonio, Texas, 1979), ACM
pear).
Press, pp. 269–282.
[24] Miné, A. Field-sensitive value analysis of embedded C pro-
[10] Cousot, P., Cousot, R., Feret, J., Mauborgne, L.,
grams with union types and pointer arithmetics. In Proc.
Miné, A., Monniaux, D., and Rival, X. Combination
of the ACM SIGPLAN-SIGBED Conf. on Languages, Com-
of abstractions in the Astrée static analyzer. In Proc.
pilers, and Tools for Embedded Systems (LCTES’06) (June
of the 11th Annual Asian Computing Science Conference
2006), ACM Press, pp. 54–63.
(ASIAN’06) (Tokyo, Japan, 6–8 Dec. 2006), M. Okada and
I. Satoh, Eds., vol. 4435 of LNCS, Springer, pp. 272–300. [25] Miné, A. The octagon abstract domain. Higher-Order and
Symbolic Computation 19 (2006), 31–100.
[11] Cousot, P., Cousot, R., Feret, J., Mauborgne, L.,
Miné, A., and Rival, X. The Astrée static analyzer. [26] Moore, R. E. Interval Analysis. Prentice Hall, Englewood
http://www.astree.ens.fr. Cliffs N. J., USA, 1966.
[12] Cousot, P., and Halbwachs, N. Automatic discovery of [27] Randimbivololona, F., Souyris, J., Baudin, P.,
linear restraints among variables of a program. In Conf. Pacalet, A., Raguideau, J., and Schoen, D. Applying
Rec. of the 5th Annual ACM SIGPLAN-SIGACT Symp. on formal proof techniques to avionics software: A pragmatic
Principles of Programming Languages (POPL’78) (Tucson, approach. In Proc. of the World Congress on Formal Meth-
USA, 1978), ACM Press, pp. 84–97. ods (FM’99) (1999), vol. 1709 of LNCS, Springer, pp. 1798–
[13] Delmas, D., and Souyris, J. Astrée: from research to 1815.
industry. In Proc. of the 14th Int. Static Analysis Sympo- [28] Rival, X. Symbolic transfer functions-based approaches
sium (SAS’07), G. Filé and H. Riis-Nielson, Eds., vol. 4634 to certified compilation. In Conf. Rec. of the 31st Annual
of LNCS. Springer, Kongens Lyngby, Denmark, 22–24 Aug. ACM SIGPLAN-SIGACT Symp. on Principles of Program-
2007, pp. 437–451. ming Languages (POPL’04) (Venice, Italy, Jan. 2004), ACM
[14] Esterel Technologies. Scade suiteTM , the standard Press, pp. 1–13.
for the development of safety-critical embedded software in [29] Rival, X., and Mauborgne, L. The trace partitioning
the avionics industry. http://www.esterel-technologies. abstract domain. ACM Trans. Program. Lang. Syst. 29, 5
com/. (2007).
[15] Feret, J. Static analysis of digital filters. In Proc. of the [30] Technical Commission on Aviation, R. DO-178B. Tech.
13th European Symp. on Programming Languages and Sys- rep., Software Considerations in Airborne Systems and
tems (ESOP’04) (27 Mar.–4 Apr. 2004), D. Schmidt, Ed., Equipment Certification, 1999.
vol. 2986 of LNCS, Springer, pp. 33–48.
[31] von der Beeck, M. A formal semantics of uml-rt. In
[16] Feret, J. The arithmetic-geometric progression abstract do- Model Driven Engineering Languages and Systems, 9th In-
main. In Proc. of the 6th Int. Conf. on Verification, Model ternational Conference, MoDELS 2006, Genova, Italy, Octo-
Checking and Abstract Interpretation (VMCAI’05) (Paris, ber 1-6, 2006, Proceedings (2006), O.Nierstrasz, J. Whittle,
France, 17–19 Jan. 2005), R. Cousot, Ed., vol. 3385 of LNCS, D. Harel, and G. Reggio, Eds., vol. 4199 of LNCS, Springer,
Springer, pp. 42–58. pp. 768–782.
[17] Goubault, E. Static analyses of floating-point operations.
In Proc. of the 8th Int. Static Analysis Symposium (SAS’01)
(2001), vol. 2126 of LNCS, Springer, pp. 234–259.
[18] Heckmann, R., and Ferdinand, C. Worst-case execu-
tion time prediction by static program analysis. In Proc. of
the 18th Int. Parallel and Distributed Processing Symposium
(IPDPS’04) (2004), IEEE Computer Society, pp. 26–30.
[19] IEEE Computer Society. IEEE standard for binary
floating-point arithmetic. Tech. rep., ANSI/IEEE Std. 745-
1985, 1985.
[20] Ioualalen, A. SARDANA: an abstract interpretation based
tool for Optimization of numerical expressions in LUSTRE