IEEE TRANSACTIONS ON SOFTWARE ENGINEERING,
VOL.
18,
NO.
9,
SEPTEMBER
1092
785
Programming and Verifying Real-Time
Systems by Means
of
the Synchronous
Data-Flow Language LUSTRE
Nicolas Halbwachs, Fabienne Lagnier, and Christophe Ratel
Abstruct-
We investigate the benefits of using a synchronous
data-flow language for programming critical real-time systems.
These benefits concern ergonomy-since the dataflow approach
meets traditional description tools used in this domain-and
ability to support formal design and verification methods. We
show, on a simple example, how the language LUSTRE, and
its associated verification tool LESAR, can be used to design a
program, to specify its critical properties, and to verify these
properties.
As
the language LUSTRE and its uses have already been
published in several papers (e.g.,
[U],
[IS]),
we put particular
emphasis on program verification.
A
preliminary version of this
paper has been published in
[28].
Index Terms-Data-flow languages, formal verification, model
checking, reactive systems, synchronous programming.
I.
INTRODUCTION
T
IS
useless
to
repeat why real-time programs are among
I
those in which errors can have the most dramatic con-
sequences. Thus these programs constitute a domain where
there is a special need for rigorous design methods. We
advocate a “language approach”
to
this problem, arguing
that
the programming language used has a direct influence in the
quality of the software, from several points of view.
1.
The language should allow a natural description of the
problem
to
be solved. In particular, it should be close
to
the traditional tools used in its application field.
2.
The language should be formally sound, in order
to
support formal verification methods.
3.
The language should be simple enough
to
minimize the
risk of misunderstanding about program meanings.
These were our main goals in designing the language
LUSTRE
[Ill, [18]. To meet criterion
1),
we started from the traditional
differential equations, finite difference equations, and boolean
equations can be straightforwardly translated, respectively,
into analog schema, block-diagrams, and gate networks. At
least the class of high level tools also meets our criterion
2),
since they are derived from the mathematical language.
Other authors (e.g.,
[2],
[23])
claimed that such declarative
formalisms are simpler and cleaner than usual imperative
languages, where assignments, side-effects, aliasing, and pa-
rameter passing mechanisms, are unnatural phenomena which
are difficult
to
understand and manage. We agree with this
claim, and therefore consider that these declarative formalisms
constitute a good basis for designing a programming language
meeting the criterion
3).
Lustre is a synchronous data-flow language, initially in-
spired from
LUCID.
As
in
LUCID,
any
LUSTRE
variable or
expression is considered
to
represent the sequence of values
it takes during the whole execution of the program, and
LUSTRE
operators are considered
to
operate globally over these
sequences. The synchronous nature of the language consists in
assuming that all the variables and expressions in a program
take the n-th value of their respective sequences
at the same
time.
More concretely, a program is intended
to
have a cyclic
behavior, an execution cycle consisting in computing the n-th
value of each variable or expression. Basically, a program is a
set
of equations. When we write an equation “X=E,” where
X
is
a variable and
E
is an expression, we mean that the sequences
of values associated with
X
and E are identical (it is an actual
equation, in the mathematical sense), or equivalently, that at
any cycle of the program,
X
and
E
take the same value.
Time and Svnchronv
description tools used in the design of process control sys-
tems.
At
a higher level, these tools consist of mathematical
formalisms (differential equations, boolean equations, etc.),
while at a lower level, people often use data-flow nets (block-
diagrams, analog schemas, switch or gate networks, etc.).
These two classes of tools are closely related: for instance,
The “real time” capabilities of the language are derived
from this synchronous interpretation, like in other synchronous
languages [6],
[8],
[13],
[21],
[24].
We consider the following
logical notion of time: As soon as we can specify the order
or simultaneity relations between events occurring both inside
and outside the program, we can express time constraints about
~~
the behavior of the program. For instance, a constraint like
--
Manuscript received November
1,
1991; revised June 2, 1992. This work
was partially supported by ESPRIT Basic Research Action
SPEC
and by
a
contract from Merlin Gerin. Recommended by R. Kemmerer and C. Ghezzi.
~~any
Occurrence
of
a
dangerous situation must be followed
by
the
emissiorz
‘fan
within
Of2
seconds”
N. Halbwachs and
F.
Lagnier are with LGIIIMAG, 38041 Grenoble Cedex,
will be expressed as
France.
France.
“after any occurrence
of
the event
dangeroussituation
there
must be an occurrence
of
the event alarm before the
2nd
next
C. Ratel is with Merlin-GerinISES and IMAFILGI, 38041, Grenoble Cedex,
IEEE
Log
Number 9202409.
occurrence
of
the event
second.”
0162-8828/92$03.00
0
1992 IEEE