TRS Lustre Language

7/28/2019 TRS Lustre Language

1/16

The Synchronous Data Flow ProgrammingL anguage LUSTRENICHOLAS HALBWACHS, PAUL CASPI, PASCAL RAYMOND, A ND DANIEL PILAUDInvited Paper

This paper describes the language LUSTRE which is a data flowsynchronous language, designed for programming reactive sys-tems-uch as automatic control and monitoring systemsas wellas for describing hardware. The data flow aspect of LUSTRE makesit very close to usual description tools in these domains (block-diagrams, networks of operators, dynamical sample-systems, etc.),and its synchronous interpretation makes it well suited for han-dling time in programs. Moreover, this synchronous interpretationallows it to be compiled into an efficient sequential program.Finally, the LUSTRE formalism is very similar to temporal logics.This allows the language to be used for both writing programsand expressing program properties, which results in an originalprogram verification methodology.I. INTRODUCTIONA . Reactive Systems

Reactive systems have been defined as computing sys-tems which continuously interact with a given physicalenvironment, when this environment is unable to synchro-nize logically with the system (for instance it cannot wait).Response times of the system must then meet requirementsinduced by the environment. This class of systems hasbeen proposed [6], [21] so as to distinguish them fromtransformational systems-i.e., classical programs whosedata are available at their beginning, and which provideresults when terminating-and from interactive systemswhich interact continuously with environments that possesssynchronization capabilities (for instance operating sys-tems). Reactive systems apply mainly to automatic processcontrol and monitoring, and signal processing,-but also tosystems such as communication protocols and man-machineinterfaces when required response times are very small.Generally, these systems share some important features:

Manuscript received September 20, 1990; revised M arch 2, 1991. Thiswork was supported in part by the French M inisthe de la Recherche withincontract Informatique 88, and in part by PRC C3 (CNRS) IM AGL GI -Grenoble VERIL OG-Grenoble,N. Halbwachs, P. Caspi, and P. Raymond are with the Laboratoire deGenie Informatique, Institut IMAG, 38041 Grenoble, Cedex, France.D. Pilaud is with V ERIL OG, 38330 Montbonnot, St. Martin, France.IEEE Log Number 9102318.

0018-9219/91$01.00

PROCEEDINGS OF THE IEEE, VOL 79, NO. 9, SEPTEMBER 1991-~-

Parallelism: First, their design must take into accountthe parallel interaction between the system and itsenvironment. Second, their implementation is quiteoften distributed for reasons of performance, faulttolerance, and functionality (communication protocolsfor instance). Moreover, it may be easier to imaginea system as comprised of parallel modules cooperat-ing to achieve a given behavior, even if it is to beimplemented in a centralized way.Time constraints: These include input frequencies andinput-output response times. As said above, theseconstraints are induced by the environment, and shouldbe imperatively satisfied. Therefore, these should bespecified, taken into account in the design, and verifiedas an important item of the systems correctness.Dependability: Most of these systems are highly criti-cal ones, and this may be their most important feature.Just think of a design error in a nuclear plant controlsystem, and in a commercial aircraft flight control sys-tem! This domain of application requires very carefuldesign and verification methods and it may be oneof the domains where formal methods should be usedwith higher priority; design methods and tools thatsupport formal methods should be chosen even if theseimply certain limitations.

B. The Synchronous ApproachIn our opinion, most programming tools used in designingreactive systems are not satisfactory. Clearly, assemblylanguages do not, though they are widely used for rea-sons of code efficiency. Other methods include the useof classical languages for programming sequential tasksthat cooperate and synchronize using services providedby a real-time operating system, and the use of parallellanguages that provide their own real-time communicationservices. Even the later, which seems more promising, hasbeen criticized [6]since the services being provided are lowlevel; this does not allow programs to be easily designed

0 1991 IEEE

1305

__


2/16

properties. A lso, reuse is made easier, which is aninteresting feature for reliable programming concerns.synchronization constraints arise from data dependen-cies. This is a nice feature which all ows the naturalderivation of parallel implementations. It is also inter-esting to notice that, in the above domain, people wereaccustomed to parallelism, at much earlier times thanin other areas in computer science.

+ It is a parallel model, where any sequencing andx = 2Y + 2w = x + 1 +&--gjyFig. 1. A data flow description and its associated equations.

and validated, while appears to be rather expensive at runtime. Synchronous languages have been recently proposedin order to deal with these problems: such languages D. Synchronous Data F lowprovide idealized primitives allowing programmers tothink of their programs as reacting instantaneously toexternal events. Thus each internal event of a programtakes place at a known time with respect to the history ofexternal events. T his feature, together wi th the limitation todeterministic constructs, results in deterministic programsfrom both functional and temporal points of view. Inpractice, the synchronous hypothesis amounts to assumingthat the program is able to react to an external event, beforeany further event occurs. If it is possible to check that thishypothesis holds for given program and environment, thenthis ideal behavior represents a sensible abstraction. Thepioneering work on ESTEREL as led to propose a generalstructure for the object code of synchronous programs:a finite automaton whose transition consists of executinga linear piece of code and corresponds to an elementaryreaction of the program. Since the transition code has noloop, its execution time can be quite accurately evaluatedon a given machine; this enables us to accurately bound thereaction time of the program, thus allowing the synchronoushypothesis to be checked. Synchronous languages include(see this issue) ESTEREL, IGNA L , TAT ECHA RTS,ML ,ndseveral hardware description languages [101.

C. The Data F low ApproachOne method for reliable programming is to use high levellanguages, i.e., languages that allow a natural expressionof problems as programs. Wi thin the domain of reactive

programming, many people are used with automatic controland electronic circuits; traditionally, these people modeltheir systems by means of networks of operators transform-ing flows of data-gates, switches, analog devices-andfrom a higher level, by means of boolean functions andtransfer functions with block-diagram structures, and finallyby means of systems of dynamical equations which capturethe behavior of these networks. Such formalisms look quitesimilar to what computer scientists call data flow systems[25], [26] (cf. Fig. 1).Therefore data flow can be considered as a high level par-adigm in that field. Furthermore, as a basis of a high levelprogramming language, it possesses several advantages.It is a functional model with its subsequent mathemat-ical cleanness, and particularly with no complex sideeffects. This makes it well adapted to formal verifica-tion and safe program transformation, since functionalrelations over data flows may be seen as time invariant

It may thus seem appealing to develop a data flowapproach to reactive programming. However, up until nowdata fl ow has been thought of as essentiall y asynchronous,whereas a synchronous approach seems necessary to tacklethe problem of time, for instance by relating time with theindex of data in flows. This was the first concern of theLUSTRE 14] project which is reported here. It resulted inproposing primitives and structures which restrict data flowsystems to only those that can be implemented as boundedmemory automata-like programs in the sense of ESTEREL .The language, together with programming examples, willbe presented in Section 11. Then compiling and efficientcode generation matters will be discussed in Section 111.The second main concern of the project is to takeadvantage of the approach in developing techniques offormal verification (Section IV ). The idea is to considerLUSTRE s a specif ication language as well , thanks to itsdeclarative aspect. It is then shown that the same compilercan be used as a tool for verifying program correctness withrespect to such specif ications. Section V presents severalother current activities of the project, related to hardwareand distributed implementations. Finally comparisons withexisting approaches are discussed.11. TH E L USTRE A NGU A GEA . F laws and Clocks

In L USTRE ny variable and expression denotes a flow,a possibly infinite sequence of values of a given type;a clock, representing a sequence of times.

A flow takes the nth value of its sequence of values at thenth time of its clock. Any program, or piece of programhas a cyclic behavior, and that cycle defines a sequenceof times which is called the basic clock of the program: aflow whose clock is the basic clock takes its nth value at thenth execution cycle of the program. Other, slower, clockscan be defined, thanks to boolean-valued flows: the clockdefined by a boolean fl ow is the sequenceof times at whichthe flow takes the value true. For instance Table 1displaysthe time-scales defined by a flow C whose clock is the basicclock, and by a flow C whose clock is defined by C.It should be noticed that the clock concept is not nec-essarily bound to physical time. As a matter of fact, thebasic clock should be considered as setting the minimalgrain of time within which a program cannot discriminate

i.e., a pair made of

1306 PROCEEDINGS OF THE IEEE, VOL. 79. NO. 9, SEPTEMBER 1991


3/16

Table 1 Boolean Flows and Clocksbasictime-scale

Table2 Sampling and Interpolating1 2 3 4 5 6 7 8 BX

false true false true false false true trueX 1 X2 X 3 I 4 X 5 X6 271 i t; false tr; tr; false t r y false t r y

time-scale

Y = X when X4 27 I 8B

1; 1 false tr; false tr; tr;time-scale the expressionif X >0 then Y +1else 0

external events, and which corresponds to its responsetime. If real time is required, it can be implementedas an input boolean flow: for instance a flow whose truevalue indicates the occurrence of a mil li second signal.This point of view provides a multiform concept of time:mill isecond becomes a time-scale of the program amongothers.

B. Variables, Equations, Expressions, AssertionsVariables should be declared with their types, and vari-ables which do not correspond to inputs should be givenone and only one definition, in the form of equations. Theseare considered in a mathematical sense: the equation X =E ; defines variable X as being identical to expression E.Both have the same sequence of values and clock. Howeversuch an equation is oriented in the sense that it definesX. The way it is used in other equations cannot give itmore properties than those which arise from its definition.This provides one important principle of the language, thesubstitutionprinciple: X can be substituted toE anywhere inthe program and conversely. As a consequence, equationscan be written in any order, and extra variables can becreated so as to give names to subexpressions, withoutchanging the meaning of the program. LUSTREas onlyfew elementary basic types: boolean, integer, real, and onetype constructor: tuple. However, complex types can beimported from a host language and handled as abstract types(A similar mechanism exists in ESTEREL ).Constants are those of the basic types and those importedfrom the host language (for instance constants of importedtypes). Corresponding flows have constant sequences ofvalues and their clock is the basic one. Usual operatorsover basic types are available (arithmetic: +, -, *, / ,di v , mod ; boolean: and, or , not ; relational: =,< , < =, > >=; conditional: i f t h en el s e ) andfunctions can be imported from the host language. Theseare called data operators and only operate on operandssharing the same clock; they operate pointwise on thesequences of values of their operands. For instance, if X andY are on the basic clock, and their sequences of values arerespectively (z~:Q,. . z,, . . ) and (y1,y2,.. . yn r . .),

is a flow on the basic clock whose nth value for anyinteger n is:if Z >0 then y, +1else 0.

Besides these operators, LUSTRE as four more which arecalled temporal operators, and which operate specificallyon flows:pr e (previous) acts as a memory: if (el,e2,. . e,,. .) is the sequence of values of expression E, pr e (Ehas the same clock as E, and its sequence of valuesis (nil,el,e2,. .. ,e,-1,. . ), where ni l represents anundefined value denoting an uninitialized memory.-> (followed by): if E and F are expressionswith the same clock, with respective sequences(e1,e2.. . . e,, . .) and ( f 1 , f i , . . . , ,, . . ), then E->F is an expression with the same clock as E and F,and whose sequence is (el, 2 , f 3 . . . , ,, . . ). In otherwords, E- >F is always equal to F, but at the first timeof its clock.

Table2 shows the effect of the last two operators:when samples an expression according to a slowerclock: if E is an expression and B is a booleanexpression with the same clock, then E when B isan expression whose clock is defined by B, and whosesequence is extracted from the one of E by keepingonly those values of indexes corresponding to truevalues in the sequence of B. In other words, it is thesequence of values of E when B is true.c u r r e n t interpolates an expression on the clockimmediately faster than its own. LetE be an expressionwhose clock is not the basic one, and let B be theboolean expression defining this clock. Then cur -rent E has the same clock C that B has, and itsvalue at any time of this clock C, is the value of E atthe last time when B was true.

Besides being made of equations, the body of a LUSTREprogram may contain assertions. These generalize equa-tions and consist of boolean expressions that should bealways true. Their primary use is to give to the compilerindications in order to optimize the code when the environ-

HALBWACHS et a1 SYNCHRONOUS DATAFLOW PROGRAMMING LANGUA GE LUSTRE~ ~ ____ --

1307 ~-


4/16

Such a node can be functionally instanced in any expres-sion. For instance,s even = COUNTER( 0 , 2 , f a l se) ;modul o5 = COUNTER( O, l , pre( modul o5) =4) ;

n1

Fig. 2. Counter network.

ment of the program possesses some known properties (seeSection 111-D). For instance, if we know that two inputevents represented by boolean variables x and y neveroccur at the same time, we shall write:a ss e r t not ( x a nd y) ;

Similarly, the assertiona s s e r t ( t r u e -> no t ( x a nd pr e ( x ) ) ) ;says that event x never occurs twice in a row. Note theinitialization to t r ue , which prevents the occurrence ofvalue nil, which is forbidden in assertions, clocks, andoutput sequences (cf. Section 111-A). Besides their usein code optimization, assertions play a important role inprogram verifi cation (cf. Section IV ).

C. Program StructureA LUSTREystem of equations can be represented graph-ically as a network of operators. For instance, the equation:

define the sequence of even numbers and the cyclicsequence of modulo 5 numbers, over the basic clock.Similarly, if gamma is an acceleration expressed inmeter/secon,d2,and its clocks rate is onepersecond, onecould havespeed = COUNTER( O, gamma, f al se) ;pos i t i on = COUNTER( O, speed, f a l se) ;According to the substitution principle, this is equivalentto:pos i t i on = COUNTER( O, COUNTER( O, gamma,f a l s e) ,f al s e) ;A node may have several outputs; in that case, the outputis a tuple. For instance,node D- I NTEGRATOR( gamma: i nt ) r et ur nsl et( s p eed, pos i t i on: i nt ) ;speed = COUNTER( O, gamma, f al se) ;pos i t i on = COUNTER( O, speed, f a l se) ;t el .is instanced as( v , x ) = D- I NTEGRATOR( g) ;

Concerning clocks, the basic clock of a node is definedby its inputs, soas to be consistent with the data flow pointof view. For instance, expression:n = 0 -> p r e ( n ) + 1;COUNTER( ( O, l , f a l se ) when B )

which defines a counter of basic clock cycles, correspondsto the network of Fig. 2. This naturally suggests somenotion of subroutine: a subnetwork can be encapsulated asa new reusable operator which is called a node. A nodedeclaration consists of an interface specif ication-providinginput and output parameters with their types and possiblytheir clocks-optional internal variables declarations, anda body made of equations and assertions defining outputsand internal variables as a function of inputs.For instance, the following node defines a general pur-pose counter, having as inputs an initial-and-reset value, anincrement value, and a reset event:node COUNTER( va1- i n i t , Val - i nc r : i n t ;l etr es et : bo ol ) r e t u r ns ( n : i nt ) ;

n = Val - i ni t -> i f r e s et t henVal - i ni t el s e pr e ( n) + Val - i nc r ;t el .

counts only when B is true. In the example, operator whenapplies to the tuple (0, 1, f al s e) l Table 3shows theresult of the expression, and the difference with expression( COUNTER( 0, 1, a l se ) when B , where samplingapplies to the output of the node instead of i ts inputs.This example also stresses the interest of clocks in reuse;had clocks not been available, the only way of getting thesame effect would have required to modify the node byadding a do-nothing input.A node may admit input parameters with distinct clocks.Then the faster one is the basic clock of the node, and allother clocks must be in the input declaration list. In thefollowing example:no de N ( m l 1i s e co nd: b oo l ; ( x : i nt ;y : oo l )

whe n m l l i s e c on d) r et u r ns . . .when B)This is equivalent to COUNTER( 0 when B, 1 when B , false

1308 PROCEEDINGS OF THE IEEE, VOL. 79, NO. 9, SEPTEMBER 1991


5/16

Table3 Nodes and ClocksB( 0 , 1 , f a l s e )when BCOUNTER( ( O, l , f al s e)when B)COUNTER( 0,1, f a l s e)( COUNTER( O, l , f al s e) )when B

true false true false true(0, l fulse) (0,1 alse) (0, false)0 1 2

0 1 3 3 4

0 2 4

the basic clock of the node is the one of m l l i s e c -ond, and the clock of x and y is the one defined bym l l i s ec ond.Outputs of a node may have clocks different from itsbasic clock. Then these clocks should be visible from theoutside of the node. Note also that these clocks are certainlyslower than the basic one.D. Some Programming Examples

1) L inear Systems: Translating sampled linear systemsinto LUSTRE rograms is quite an obvious task: if systemsare expressed in z-transform equations, it amounts to trans-lating the z- l operator into 0.0 -> pr e ( ). For instance,consider the second-order filter:az2 +bz+cz2+dz +e H ( z )=

The output y =H( z ) z can be written:y =ax +(b:c- iy)z-l +( ex- ey)z-

and yields the following program:cons t a f b l c , d f e : eal .node SECOND- ORDER( x: r eal ) r et urnsv ar u, v: r e al ;l et

( y : r e al ) ;

y = a* x + ( 0. - >pr e ( u ) ) ;U = b* x - d* y + ( 0. - >pr e ( v ) ) ;v = c * x - e * y ;t el .

Furthermore, clocks allow an easy extension to multiplysampled systems.

3)Logical Systems: From the previous discussion, dataflow programs of signal processing systems are very closeto their specification in terms of systems of dynamicalequations. However, many systems have an important log-ical component, and some of them, for instance monitoringsystems, are essentially logical systems. Such systems aremost often described in terms of automata, parallel au-tomata (STATECHARTSor instance), and Petri nets, i.e.,imperative formalisms which describe states and transitionsbetween states. The question about the adequacy of dataflow paradigms to provide easy descriptions of such sys-tems should therefore be carefully checked. The followingexamples are intended to show that these paradigms mayallow easy, incremental and modular descriptions of logicalsystems. In this subsection we shall consider three versionsof a watchdog, i.e., a device that monitors response times.The first version receives three events: set and r ese tcommands, and de ad l i ne occurrence. The output is anal ar m that must be raised whenever a de adl i ne occursand the last received command was a se t .As usual, events are represented by boolean variableswhose value true denotes the presence of an event. Thewatchdog wil l be a LUSTREnode having three booleaninputs s et , e s et and d ea dl i ne and emitting a booleanoutput al ar m As the order of equations is unimportant,we begin by defining the output: al ar m is true whend ea dl i n e is true and the last true command is se t . Leti s - s et be a local boolean variable expressing the lattercondition. Then, we can write:al ar m = deadl i ne and i s - se t ;It remains to define i s - s et , which becomes true any times et is true, and false any time r ese t is true. Initially,it is true if s et is true and false otherwise:i s - s et = s et -> i f s et t he n t r u e e l s e i fr e s et t h en f a l s e e l s e pr e ( i s - s et ) ;

We can furthermore assume that set and reset commandsnever take place at the same time, which can be expressedby an assertion. The full program is:node WD1 ( se t , r ese t , deadl i ne: boo l )v ar i s - s et : b oo l ;l et

r e t u r n s ( al ar m bool ) ;

al ar m = d ea dl i n e and i s - s e t ;i s - s et = s et -> i f s et t he n t r u eel s e i f r es et t h enf a l s e e l s e pr e ( i s - s et ) ;2)Nonlinear and Time-Varying Systems: Letting a b c d e asser t not ( set an d r e s e t ) ;be parameters of the SECOND- ORDER node, instead ofconstants, yields a time-varying filter. Nonlinear systems

are also easy to describe. For instance: Let us consider now a second version which receives thesame commands, but raises the al ar m when no r ese thas occurred for a given time since the last se t , this=rho c cos(theta0- >pre(theta));HALBWACHS et al.: SYNCHRONOUS DATAFLOW PROGRAMMING LANGUAGE LUSTRE 1309


6/16

time being given as a number of basic clock cycles. Thisnew program reuses node WD1, by providing it with anappropriate d ea dl i n e parameter: on reception of a s etevent, a register is initialized, which is then decremented.Deadline occurs when the register value reaches zero; it isbuilt from a general purpose node EDGE which returns trueat each rising edge of its input:node EDGE ( b: bool ) r et urns ( edge: boo l ) ;l et

edge = f a l s e -> ( b a nd not p r e ( b ) ) ;t el .node WD2 ( se t , r eset : boo l ; de l ay: i n t )v ar r e ma i n: i n t ; d ea dl i ne : bo ol ;l et

r e t u r ns ( al ar m b ool ) ;

al ar m = WDl ( s e t , r e s et , d ea dl i n e) ;de ad l i n e = f a l s e -> EDGE( r emai n = 0) ;r emai n = i f s et t h en de l aye l s e i f p r e ( r e ma i n ) >Ot hen pr e ( r ema i n ) - 1e l s e p r e ( r e ma i n ) ;t el .Assume now that the delay is expressed according toa given time-scale, i.e., as a number of occurrences of anevent t i me-uni t . We just have to call WD2 with an appro-priate clock: WD2 must catch any time units t i me - u ni t ,any commands, and must be properly initialized so thatalarm never yields nil:

node WD3 ( se t , r eset , t i me-uni t : bool ;v ar c l o ck : bo ol ;l et

del ay: i n t ) r et u r ns ( al ar m b ool ) ;

al ar m = cur r ent ( WD2( ( se t , r eset , de l ay)c l oc k = t r u e -> ( s e t o r r e s et orwhen c l ock) ) ;t i me- uni t ) ;

t el .Coming back to the question raised at the beginning ofthe section, we can see that programs have been writtenwithout referring to transitions between states, but rather bydescribing states in terms of state variables, and by statingthe strongest invariant property of each state variable. Then,all state variables wil l evolve in parallel, thus recreating theglobal state of the system. It has been shown in [8] that anyfinite state machine can be described by a boolean LUSTREprogram.4) Mixed Logical and Signal Processing Systems: Finally,mixing signal processing and logical systems is quite aneasy task: Signal processing parts provide logical oneswith boolean expressions by using relational operators,

and conversely, logical components control signal flows bymeans of conditional operators: i f t h en el s e, wh enand cur rent .

111 THE LUSTRE COMPILERLet us describe now the main techniques used in theLUSTRE-v2ompiler [30].This prototype compiler has beenwritten in Le-Lisp by J ohn Plaice.

A . Static VerificationsStatic well-formedness checking is clearly an importantissue within the framework of reliable programming, andaims at avoiding the overhead of dynamic checks at run

time. Besides classical type checking, the main checksperformed by the compiler are:Definition checking: any local and output variableshould have one and only one equational definition.Absence of recursive node call: in view of obtainingautomata-like executable programs, LUSTRE llows upto now only static networks to be described. Theproblem of structuring recursive calls so that the aboveproperty is maintained, has not yet been investigated.Clock consistency, which will be more intensivelydiscussed in the following.Absence of uninitialized expressions (yielding ni l val-ues). Such expressions are accepted as far as these donot concern clocks, outputs, and assertions.Absence of cyclic definitions: any cycle in the networkshould contain at least one pr e operator. In the senseof [25]an equation such that: X = 3* X + 1 has ameaning which is the least solution with respect to theprefix ordering of sequences; in this case, the solutionfor X is the empty sequence, and it can be interpretedas a deadlock. It is therefore rejected. Note also thatLUSTRE lso rejects structural deadlocks which are nottrue ones, such that:

X =if C the Y else 2 ;Y = if C then 2 else X ;

The reason is that the analysis of such networks isundecidable, in general.Let us discuss now the clock calculus which representsan original aspect of L USTREwith respect to data flow

languages. The following program il lustrates the reason forsuch a calculus: b = t r ue- > not pre b;y = x + ( x when b) ;In the second equation, a data operator combines twoflows of distinct clocks. According to standard data flowphilosophy, such a program has a meaning. However, itis easy to see that the computation of the 2nth value of

y needs both the 2nth and the nth values of 2. Since areactive system may be assumed to run for ever, its requiredmemory will certainly overflow. Such a program couldnot be compiled into a bounded memory object code, notto speak of the physical incoherence consisting of addingsomething at time nwith something at time 2n.The clock calculus consists of associating a clock witheach expression of the program, and of checking that anyoperator applies to appropriately clocked operands:



7/16

Fig. 3. A cyclic call.

any primitive operator with more than one argumentapplies to operands sharing the same clock;the clock of any operand of a c u r r e n t operator isnot the basic clock of the node it belongs to;2the clocks of a node operands should obey the clocksrequirements stated in the node definition header.

Let us define here what we mean by the same clock.Ideally, it could mean the same boolean flow, but this mayrequire semantic analysis which are undecidable in general.Thus the compiler uses a more restricted notion of equality:two boolean expressions define the same clock if and only ifthese can be unified by means of syntactical substitutions.Consider the example:x = a when ( y > z ) ;y = b+c;U = d when ( b+c > z ) ;v = e when ( z < y) ;x and U share the same clock, which is considered to bedistinct from the clock of v.The rules of the clock calculus are formally described in1141, 1301.B. Node Expansion

The LUSTRE ompiler produces purely sequential code.This raises the question of compiling separated nodes whichare used in other nodes. The following example shows thiscannot be easily done for L USTRE:n od e t wo - c o pi es ( a , b: i n t ) r e t u r n sl et x = a ; y = b ; end.( x , y: i nt ) ;

Clearly, there are two possible sequential codes fora basic cycle of this node, either x: =a; y: =b; ory: =b; x: =a;But the choice between those two programs may dependon the way the node is used within another node; forinstance:( x l y ) = t wo -copi es ( a , x )corresponding to Fig. 3. In this case, only the formerprogram is correct.Thus before compiling a program, the compiler first ex-pands recursively all the nodes called by that program, i.e.,formal parameters are substituted with actual ones, local

21n contrast with S IGNAL,USTRE oes not allow basic clock timeintervals to be split into smaller ones.

variables are given an unique name (so as to distinguishthat node call from other instances of the same node) andthen the called node body is inserted into the calling nodebody. The code generation step will then start from a flatnode which does not call any other node.3C. Single-Loop Code

An obvious way of associating an imperative programwith a LUSTREnode consists of constructing an infiniteloop whose body implements the inputs to outputs trans-formation performed at any basic cycle of the node. Thisis done by:choosing variables to be computed (the output onesand the least possible number of local ones, whichimplement either memories or temporary buffers);defining the actions which update these variables;choosing an ordering of these actions, according tothe dependencies between variables induced by thenetwork structure of the node.

A s an example, let us consider a modified version of thewatchdog WD3:node WD4 ( se t , r eset , u - t ps : boo l ; del ay:i nt ) r et ur n s ( a1ar m bool ;v ar i s - s et : bo ol ; r e ma i n: i nt ;l et al ar m = i s - se t and ( r ema i n = 0 ) a ndpre ( r ema i n ) > 0;i s- et = f a l s e -> i f s et t h e t r uee l s e i f r e s et t he nf a l s ee l s e pr e ( i s - s et ) ;

e l s e i f u- t ps a ndpre ( r ema i n ) > 0t h enpr e ( r e ma i n) - 1

r emai n = 0 -> i f s et t h en de l ay

e l s e p r e ( r e ma i n) ;a s s er t no t ( s e t a nd r e s e t ) ;t el .

The single-loop body, which is executed at each programreaction. looks like:i f - i ni t t h en % f i r s t cyc l e %i s - s et := f al s e; r e ma i n := 0;al ar m : =f a l s e; - i ni t := f a l s e

i f s e t t h en i s - s et : = t r u e; r e ma i n: =el s e

el s e % o t h er c y c l e s %d el a y

i f r es et t h en i s _ s et : = f a l s e endi f ;i f u- tps and ( - pre- r emai n>O) t henr emai n := - r e - r ema i n- 1 endi f ;end i f3However, we shall see in Section V-A that some separate compilingtechnique can also apply.

HALBWACHS et al., SYNCHRONOUS DATAFLOW PROGRAMMING LANGUAGE LUSTRE 1311

~- _ _ _ ~~


8/16

al ar m := i s - set and ( r emai n=O) and( - pre- remai n > 0) ;e ndi fwr i t e ( a1ar m) ; - pre - r emai n := r emai n;1)Remarks:

The compiler has defined auxiliary variables: the vari-able A ni t-whi ch is assumed to be initialized to trueand is used to implement the operator ->-and thememory variable - pre- r emai n.Note that the expres-sion pr e( i s - s et ) did not result in the creation ofa memory variable since the compiler found a way toavoid it.A lthough it is easy to find an ordering of actionswhich meets the dependency relations between vari-ables (static checks described above ensure that suchan order exists), the choice of a good order is quitedifficult: particularly, the order according to whichconditional statements are opened and closed is criticalwith respect to code length.The code speed could be improved. Note for instancethat at any cycle the program tests whether this is thefirst one or not, and this is particularly awkward. Asolution consists of using more complex control struc-tures than the single-loop structure. This is discussedin the following section.

D. Automaton-Like CodeThe search for more complex control structures is bor-rowed from the compiling technique of EST EREL nd isbased on the following remarks:

The classical concept of control of imperative pro-grams is represented in L USTRE y means of booleanvariables acting over conditional and clock handlingoperators.If a condition or a clock depends on valuesof a booleanvariable computed at previous cycles (by means of anexpression like p r e ( B) or c u r r e n t ( B ) ) the codeof the actual cycle could be made simpler if thatvalue could be assumed to be known. One could thendistinguish the code to be executed according to thatvalue.

The synthesis of the control structure consists of choosinga set of state variables of boolean type, whose values areexpected to influence the code of future cycles. This set ofvariables is called the state of the program and it takes onlya finite set of values. For each possible value of the state,one defines the sequential code which would be executedduring a cycle if the state of the variables had the abovevalues just before the execution of the cycle. Hence, startingfrom a given state and executing the corresponding codewould result in computing the next state, and be ready forthe execution of the next cycle. Finally, a static reachabili tyanalysis can be performed so as to delete state values andtransitions which cannot be reached from the initial state(Asa matter of fact, this reachabil ity analysis is done while

generating state values and transitions, so as to avoidgenerating useless items). The result is a fi nite state au-tomaton, whose transitions are labeled with the code of thecorresponding reaction.State variables can be chosen in several ways among thefollowing:boolean expressions resulting from pr e and cur rentoperators,auxil iary variables like L ni t - C, associated with someclock C whose value is true at the first clock cycleand then false, and which allow the evaluation of ->operators.

This control synthesis is i llustrated on the watchdog exam-ple WD4 (cf. Section 111-C): The chosen state variables arepr e ( i s - s et ) and - i ni t . Then:The first cycle yields pr e ( i s - s et ) =ni l and- i ni t =t r ue. Let So be this initial state. Since- i ni t =t r ue in this state, the value of all-> operators is the one of their first operand.Thus i s - s e t =f al s e, and r emai n=O. Elementaryboolean calculus yields al ar m=f al s e. Further-more, since i s - s et evaluates to false, this will bethe value of pr e( i s - s et ) at the next state. Thenext state, 51, is then pr e ( i s - s e t ) =f al s e and- i ni t =f al s e. State So code looks like:SO : r emai n := 0;al ar m := f al s e;pre- r emai n := r emai n;got o s1;

In state SI, since pr e ( i s - s e t ) value is false,i s - s et evaluates to true if and only if the in-put set value is true. Let Sz be the state wherepr e ( i s - s et ) is true and - i ni t is false. The codefor stateSI s:S1 : i f s et t he n

r emai n := del ay ;al ar m := ( r e ma i n = 0) and( pre- r emai n > 0 ) ;pre- r emai n := r emai n;got o s2;r emai n := i f u- t ps andel s e pre- r emai n > 0t hen pre- r emai n-1el se pr e- r emai n;al ar m := f al s e;pre- r emai n := r emai n;got o s1;end i f

The code of state S2 ( p r e ( s - s e t ) is true andAn i t is false), isas follows:1312 PROCEEDINGS OF THE IEEE, VOL. 79, NO. 9, SEPTEMBER 1991


9/16

se t

Fig. 4. The watchdog control automaton.

S 2 : i f s e t t h enr emai n := d el a y;al ar m := ( r e ma i n = 0) and( pre - r ema i npre- r emai n := r emai n;got o s2;> 0 ) ;

el s ei f r es et t henr emai n := i f u- tps andpre- r emai n > 0 t henpre- r emai n-1al ar m := f al s e;pre- r emai n := r emai n;got o s1;

el se pre- remai n;

el s er emai n := i f u- t ps andpre- r emai n > 0t hen pr e- r emai n- 1el se pre- r emai n;al ar m := ( r ema i n = 0 ) and( pre - r ema i n > 0 ) ;pre- r emai n := r emai n;g ot o s 2;e nd i fend i fAll reachable states being processed, this ends the codeI ) Remarks:

The obtained transition codes are much simpler thanthe single-loop code, particularly for SOand 51 codes.This reduction may be even more impressive for largerprograms.In contrast, the overall length of the code may becomevery large. That is why, in practice, an action codetable is built which uniquely identifies actions thatmay belong to several transitions, and transition codesrefer to actions by means of their indexes in the table.Boolean expressions depending on non boolean vari-ables, which are needed for computing state variables(integer comparison for instance) are handled as inputsby means of tests on their value.This technique allows assertions to be fully taken intoaccount. Assertions are computed in the same way

generation. Figure 4 displays the resulting automaton.

as state variables, and any branch yielding a falseassertion is deleted. A state whose total code has beendeleted is then declared unreachable, and branchesalready computed which lead to that state are recur-sively deleted. It should be noticed that assertions mayincrease the number of state variables and reachablestates, as well as increase code length by inducingextra tests.In contrast with ESTEREL automata, the obtainedLUSTREautomata are often far from being minimal(this question will be further discussed in Section V-A). This entails a need for minimization.

E. The ESTERELILUSTRE EnvironmentAutomata produced by the L USTRE compiler are ex-pressed in the OC format [32], which is also used by theESTEREL ompiler. Several common tools take this formatas input:..

.

IV .

Code generators: Translators toward C, Le-Lisp, andADA languages have been designed by the ESTERELteam. They produce the procedure which implementsthe code corresponding to a transition of the automa-tion.Automaton minimizer: The ALDEBARAN161mini-mizer has been interfaced with OC. It allows minimalequivalent automata to be obtained in OC, and this isparticularly useful in the case of LUSTRE.Interfaces with proof tools: Automata are a commonbasic model in many analysis and verification toolsfor parallel systems. It was therefore appealing toexperiment with the use of such tools operating on Ocautomata. Thus OC has been interfaced with AUTO[39]. Some experiments have also been performedwith EM C [13] and XESAR [36]. However, we shallsee in Section IV other proof techniques which applyspecifically to LUSTRE.Display tools: The OC language has been designedfor internal code representation, and it thus lacks ofreadability. For checks and debugging purposes, trans-lators toward readable representations, and graphicdisplay based on the AUTOGRAPH34] code, have beendeveloped.VERIFICATION

As noted in the introduction, reactive systems oftenconcern critical applications, and thus program verificationis a key issue. However, many practitioners in the fieldare skeptical with the use of formal verification methods,and convincing arguments need to be provided in order tosupport our claim that indeed, such methods are of practicalinterest. This is the object of the following discussion.The research on program verification which started in theearly seventies intended to provide complete proofs ofvery general programs. Though this work has led to im-portant contributions concerning programming techniquesand language design, one should admit that its use inpractice is very limited. However, our goal concerning

HALBWACHS et a1 SYNCHRONOUS DATAFLOW PROGRAMMING LANGUAGE LUSTRE~- - --- - 1313


10/16

reactive systems may be less ambitious. Almost always,the safety of a critical application does not depend onthe total correctness of its control program, but rather onan often small set of properties that the program shouldfulfill. For instance, the occurrence of a critical situationshould raise an alarm within a given delay. From ourexperience, the proof of such properties can often behandled within the framework of simple decidable theories,as these properties seldom depend on numerical relationsand computations. Furthermore, most of these propertiesare safety properties which state that a given situationshould never appear, or that a given statement shouldalways hold, in contrast with liveness properties whichstate that a given situation should eventually appear in thefuture. For instance, a relevant question is not that a trainwill eventually stop, but that it never crosses a red light.This is an important remark as proof techniques for safetyproperties are known to be much simpler than for livenessproperties:

A safety property can be verified by simply check-ing properties of reachable states, without taking intoaccount the transition relation (i t is used only forconstructing the reachable states). This allows the useof very efficient methods based on reachability 1151,A safety property can be checked on an abstractionof the actual program. Informally, if a safety propertyholds for a program, it also holds for programs whoseset of behaviors is a subset of the initial one. Thus it ispossible to abstract programs by ignoring details, forinstance numerical computations; their set of behaviorswill become larger and properties that hold on theseabstractions will also hold on the actual programs.Safety properties can be checked modularly. Propertiesof submodules can be combined so as to derive aproperty of the whole module. This allows proofcomplexities to be reduced, thanks to modular decom-position according to a program structure. In view ofthis discussion, we will propose methods for specifyingand checking simple safety properties about LUSTREprograms.

1201.

A . Specification of Safety Properti esMany formalisms have been proposed in order to ex-press properties of real time parallel programs. Two mainapproaches can be distinguished: those based on temporallogics 1281, [31]and those based on automata theory (Petrinets, STATECHARTS,imed graphs [I] and process calculi[27]). Such formalisms should clearly allow any interestingproperty to be expressed, but should also provide an easyand readable expression for it; proving a certain propertyis of poor interest if one cannot be convinced that it isactually the desired property of the system. This led us toinvestigate if it were possibleto take advantage of LUSTRE S

declarative aspect, so as to use it for expressing propertiesof LUSTRE programs 1231. A positive answer is based onthe following considerations:

0

.

.Let

LUSTRE an be considered as a subset of a temporaltemporal property P by a boolean expression B, suchduring any execution path of the program. Accordingto [8], any safety property can be expressed in sucha way.The above proposal is easily implementable by usingthe assertion mechanism of LUST RE: USTRE ssertionsare already a means of expressing properties of aprograms environment.The use of a programming language for expressingboth programs and their properties is interesting sinceall the structuring facilities of the language becomeavailable for the sake of readability and expressiveness.For instance, as we will show, the node concept willallow the user to define its own temporal operators.us show here how some useful nontrivial temporal

logic [8], [29]. Our proposal is then to express anythat P holds i f and only if enpresqion B i s always t r r z e

operators can be expressed as LUSTRE odes. Consider thefoll owing property:any occurrence of a critical situation must befol lowed by an alarm within a five seconds delay.Such a property relates three events: the critical situationoccurrence, the alarm, and the deadline. The latter can beprovided externally as well as it can easily be expressed inLUSTRE . general pattern for this property is the fol lowingone:A ny occurrence of event A is followed by anoccurrence of event B before the next occurrenceof event C.However, this formulation is not directly translatable intoLUST RE, s it refers towhat happens in the future followingan A occurrence, while L USTR E nly allows references tothe past with respect to the current instant. That is why wefirst translate it into the equivalent past expression:Any timeC occurs, either A has never occurredpreviously, or B has occurred since the lastoccurrence of A.Let us define a node, taking three boolean input parametersA, B, C, and returning a boolean output X such that suchthat X is always true if and only if the property holds:node onceBf r omAt oC( A, B, C: bo ol )l etr e t u r n s ( X: bool);X = i mpl i es ( C, n ev er ( A) o rs i nc e( B , A) ) ;t elThe..

equation defining x uses three auxiliary nodes:The nodes implies implements the ordinary logicalimplication:node i mpl i es( A, B: bool ) r e t u r n s( Ai mpl i esB: bool ) ;l et A i mpl i e sB = not A o r B; t e l .The node never returns the value true as long as its



11/16

input has never been equal to true.Then it returnsfalsefor ever:node never ( B: boo l ) r e tu rns( neverB: bool ) ;l et neverB = ( n ot B) -> ( not B andpr e (never B) ) ;t el .

Finally, the node s i nc e has two inputs and it returnstrue if and only if , either its second input has stil l notbeen true, or its first input has been true at least oncesince the last true value of the second input:no de s i nc e( X, Y: b oo l ) r e t u r n s( Xs i nc eY: bo ol ) ;l et Xs i nceY = i f Y t h en X el s e( t r u e -> X o r p re (Xs i nceY) ) ;t el .

A realistic example has been studied in [17]:Most criticalproperties of a nuclear plant monitoring program have beenexpressed in LUSTRE, thanks to a small set of generalpurpose temporal operators similar to onceBf r omAt oC,never or s i nce.B. Verification

The proposed verification method is very similar tomodel checking [13], [36]: first, the state graph of theprogram is built (this assumes obviously a finite numberof states), and then each property is checked on this stategraph. The critical issue in this approach is clearly the num-ber of states which can be very large for realistic programs.We shall see that the restriction to safety properties, andthe expression of properties in the same language as theprogram may help in solving this problem.In the LUSTRE ase, a state graph already exists corre-sponding to the control automaton built by the compiler.This graph is an abstraction of the actual state graph sinceit expresses only the control and ignores many detailsconcerning non boolean variables, and boolean ones whichdo not influence that control. Asnoticed above, if propertiesto be checked depend essentially on booleans taken intoaccount in the control graph, and if these properties aresafety ones, such an abstraction is a sensible one forchecking purposes and yields in general much smallergraphs. An important observation for decreasing the totalgraph size consists of taking into account the property tobe checked when building the state graph. In the case ofLUSTRE his is easily achieved since the same languageapplies to properties and programs: in order to prove thatan expression B is an invariant of the program P,we builda new programP made of the body of P and of the system

_ _ _ _ _ _ _ _ _ _ _ _ _ - - - - - - -II n !q-t p_ , QI B I - IP

Fig. 5. Verification program.

of equations defining B, and whose only output is B (cf. Fig.5. Since the compiler is then requested to only computeB, it will only take into account the part of the programwhich concerns that computation, and this can be expectedto yield a smaller graph. Given that graph, verifying theproperty corresponds to check that in none of the states,the code performs an assignment of the output to false.A third issue in reducing the size of the graph consistsof using assertions for expressing assumptions when theproperty to be checked is suspected to hold only onthese assumptions. A ssertions are also useful for expressingproperties of numbers which otherwise would be ignoredby the compiler. For instance, if a program uses numericaltests such as X


12/16

(a)Fig. 7. Modular verification.

Fig. 6. Assumption-dependent equivalenceof programs.

STATE = I NI T -> i f ON and notpre( STATE) t hen t r ueel s e i f OFF andp r e ( S T AT E) t h en f a l s ee l se p r e (STATE) ;t el .We could wish toverify that this generalization i s correct,in the sense that both versions behave in the same way assoon as the inputs ON and OFF are never true at the sametime. This is achieved by constructing a comparison nodewhich calls both nodes with same inputs and compares theiroutputs, under the assumption that ON and OFF inputs are

exclusive (cf. Fig. 6):node COMPARE( ON, OFF, I NI T: bo ol )r e t u r n s ( OK: boo l ) ;l et v ar s t a t e , s t at e - 1 : bool ;s t a t e = SW TCH( ON, OFF, I NI T) ;St at e- 1 = SW TCH_l ( ON, OFF, I NI T) ;OK = ( s t a t e = s t a t e - 1 ) ;assert not ( 0N and OFF);t el .

Compiling this node yields a five states automaton, eachtransition of which assigns the value true to the output OK.The last way to tackle the state explosion problem ismodular veri fication. Having to prove that an expression Bis always true during the execution of a program P, callinga node Q (cf. Fig. 7(a)), the idea is to decompose the proofinto a sub-proof concerning Q and a sub-proof concerningP without Q:

Find (by intuition) a property of Q, i.e., an expressionCon the input/output parameters of Q, and prove thatC is always true during any execution of Q.Now, consider Q as being part of the environment ofP, i.e., replace in P the call to Q by the assertionassert C. Then try to prove the invariance of B onthe modified program (cf. Fig. 7(b)).An example making use of this modular decompositionmay be found in [18].A prototype verif ication tool called LESARby analogy

with the CESAR amily of model checkers) has been im-plemented: given a program with a single boolean output,it goes through the states and checks that the output is1316

never assigned false. It has been used to check the abovementioned nuclear plant control system [171. Though thisprogram used computations on real numbers, the stategraphs it needed to build appeared to be quite small (upto 1000 states).Of course, the validity of the proof relies on the satisfac-tion of the synchrony hypothesis: A ll the proof is performedinside the synchronous model, and has nothing todo withperformance analysis. A s mentioned before, checking thevalidity of the synchrony hypothesis amounts to evaluatethe maximum reaction time of the program on a givenmachine.V . CURRENT CTIVITIESA . The Next Compiler Version

In Section 111, the LUSTRE-V2 compiler currently availablewas described. However, from experiments conducted withthis version, some serious drawbacks have been identified,and an improved version is currently being designed. Webriefly discuss here the main trends adopted in this newdesign.Automata minimization: As indicated above, automataprovided by the current compiler are far from being min-imal, while this is not the case with ESTEREL eneratedautomata. T he suspected reason for this may be the fol -lowing one: ESTEREL s an imperative language offeringpowerful control structures (sequencing, interruptions, etc.).Furthermore, it is a medium to large grain parallel languagein the sense that its parallel construct is an explicit one, andits use may be tightly controlled by a pr~grammer.~hisallows good programming rules to be stated which leadto minimal automata. On the contrary, control in LUSTREshidden as it results from data dependencies, and L UST REs afine grain parallel language in the sense that any expressionis a potentially parallel construct. T hus minor changes in aprogram text may induce large variations in the automatonsize, and though some causes of state explosion have beenidentified, these cannot be easily synthesized as sensibleprogramming rules. The problem of efficiently compilingLUSTREs therefore intrinsically difficult. Several solutionsare currently investigated:

A posteri ori minimization: The use of an automatonminimizer such that AL DEBA RA Ncf. Section 111-E)which has already been interfaced so as to processOC automata, is a low cost solution. But it appliesThough the main ESTERELssumption is that the synchronous productof automata limits state explosion with respect to an asynchronous product,it still may be the main cause of state growth.

PROCEEDINGS OF THE IEEE, VOL. 79, NO. 9, SEPTEMBER 1991


13/16

only after a successful automaton generation, and thiscannot be the case when a state explosion occurs.On the fly minimization: It is based on an analysisof state explosion. The main reason seems to bethat LUSTREvariables are defined during the wholeprogram execution, without taking much care of theireffective use. A lthough this is a nice feature of thelanguage from a programmers point of view, it leadsthe compiler to distinguish states which differ only onvalues that have no influence on the present and futuresequence of outputs. This suggests a demand drivenstate generation strategy, where states are created ifand only if their influence on the input output behaviorof the program is asserted [7]. This strategy has beensuccessfully implemented.Source code optimization: A s mentioned above, somerules are known which could reduce the automatonsize, but cannot be sensibly edicted as programmingrules. The idea is then to take advantage of the largeversatility of LUSTREprograms which is due to itsmathematical aspect (for instance the definition princi-ple) so asto use these rules as optimizing rules. Thereare experiments being carried on in this direction aswell.

Transition code size: Besides the automaton size, ithappens that the codes of transitions become exceedinglylarge. This results from an inadequacy of the schedulingalgorithm which produces that sequential code. One of itstasks consists of transforming conditional expressions intoconditional statements and the order according to whichtests are opened and closed appears to be critical withrespect to code size (cf. Section 111-C).Heuristics are beinginvestigated so as to solve this problem.M odular compiler: It may also happen that a minimalautomaton of a program still remains very large. This hap-pens when the program is made of many quasi-independentparts, and then its number of states become as large asthe product of state numbers of the parts. A good solutionin this case would consist of generating an automaton foreach part and then of linking together these automata. Thisraises two problems. First, it has been noted (Section 111-B)that modularly compil ing pieces of L USTRE rograms is ingeneral impossible. However [33]proposed a method foridentifying in a program those pieces that can be compiledseparately. Second, this may result in a significant decreaseof the code length, but at the expense of execution time.Although the method has not yet been implemented, i tis foreseen that it should keep under the programmerscontrol, so as to reach a satisfactory balance between codelength and execution time.B. Distributed Programming

Up until now, the only execution scheme considered forLUSTRE rograms is a purely sequential one. This does notseem very consistent with the highly parallel aspect of thelanguage and with the fact that most parallel languagessuch that OCCAMand ADA have parallel and concurrentHALBWACHS et al.: SYNCHRONOUS DATAFLOW PROGRAMMING LANGUAGE

execution schemes. There can be at least two reasons forthat discrepancy:Parallelism in LUSTRE s intended toward expressive-ness and adequacy with the culture of control systemsengineers, and this is independent of any executionscheme.In contrast with the above mentioned languages, paral-lelism in LUSTREs a fine grain one, and its concurrentexecution would be rather inefficient. On the contrary,we have seen that very efficient sequential codes(with respect to execution time) can be generated, andfurthermore, sequential execution allows the transitiontime to be accurately bounded.

However, many control and monitoring systems whichconstitute the main application domain of LUSTRE, aredistributed systems for several reasons: performances, faulttolerance, location of sensors and actuators, etc., and thesesystems are most often programmed separately. This maynot be a bad solution, as it may correspond to a modulardecomposition of systems, but it frequently raises difficultdebugging problems, and an overall validation of suchsystems is usually impossible. An alternative method canbe based on an automated tool producing distributed codefrom L USTRE rograms and user-provided distribution com-mands (for instance, compute variable X on location Ll ).This would allow a whole application to be programmedin LUSTRE,without taking care of distribution problems,and then, this application could be easily debugged andvalidated using standard LUSTREmethods. Provided the au-tomatically produced distributed program preserves LUSTREsemantics, it can be expected that any debugging andvalidation performed on the centralized program will alsohold for the distributed one. Such a tool, called OC2REP, isdescribed in [4], and has been implemented. Given an OCprogram and a set of distribution commands, it automat-ically produces several OC programs which communicatethrough FIFO queues thanks to statements such that:put - t y pe( i : l oc at i on; exp: t ype) ;whose execution at location j consists of inserting the valueof ex p in the queue j of location i , and:get - t y pe( j : l oc at i on; v ar x: t y pe) ;whose execution at location i consists of waiting if queue jis empty, and else, of assigning the head of the queueto x.Note that the queue mechanism and the fact that put sand get s are inserted in convenient order allow messagesnot to identify the transmitted values, but only the sendingand destination locations. The distributed programs arewell synchronized, deadlock free, and meet the functionalsemantics of LUSTRE^ Experiments also show that thismethod avoids difficult distributed debugging problems.However, accurate bounds on the transition times are diffi-cult to get, and their evaluation constitutes a real problem.

6This also appliestoEsterel since the input of the tool isan OCprogram.USTRE 1317


14/16

C. Hardware IssuesThe adequacy of L USTRE or the description of digitalcircuits has been shown in several papers [19], [22], [38].Moreover, it can be expected that circuit proof and valida-tion may benefit from LU STRE roof techniques. Anotherinteresting issue is hardware design from boolean LUSTREspecifications and descriptions. Some work on this topic iscurrently undertaken in cooperation with Digital EquipmentParis Research L aboratory [35]. The idea is to implement

on hardware the network of operators corresponding to theprogram, and successful achievements have been obtainedin this direction, using programmable active memorycircuits [12].VI. CONCLUSION

In this paper, the LUSTREanguage, its main applications,and its associated tools have been presented.Asconcludingremarks, we will compare the LUSTRE pproach with somealternative approaches, from both programming languageand verification points of view.A . Related Programming Languages

1) Data Flow: The data flow model has been a basis ofseveral programming languages, for instance [3], [9], [ l l ] ,[26] and it has been given a nice formal definition by K ahnin [25]. When trying to locate LU STRE ithin the data flowworld, it looks very close to LU CIDrom a syntactical pointof view. This similarity is not casual since LUCI Dwas thefirst main reference in the design of L USTRE. owever, thefinal language is quite different from its model. This isdue to the choice of the Kahn model as the basic one forLUSTRE : n this model, newly computed values can onlybe appended at the end of a sequence of already computedvalues, while LUCIDmodel allows them to be appendedanywhere in the sequence. Thi s raises a lot of problemswhen efficient execution mechanisms are required, and itpoorly meets the point of view of reactive systems. ThusLUSTRE an be first seen as some restriction of LUCI D o theKahn model. But the latter soon appeared still too generalwhen bounded memory and bounded reaction time wererequired. Clearly, recursive node call had to be forbidden,but also the use of sampling and blocking operators had tobe strictly restricted for that purpose. This originated theconcept of LUSTRE locks which i s the final distinguishingfeature of the language.2) Signal: Another language quite similar to L USTRE sSIGNALsee this issue), and comparing both is not an easytask. A main issue here is their distinct semantic model;in our opinion SIGNAL oes not belong to the Kahn familyof languages, which is based on functions over sequences,and on functional composition, but on a concept of pro-gramming by constraints: each SI GN AL onstruct denotesa finite-memory relation between hiatonised sequences,and a program is the intersection of such relations. Aprogram has a bounded memory but it can be relational(i.e., non deterministic), and the object of SIGN AL lockcalculus consists of finding an execution scheme such that

the program be deterministic and deadlock-free. The freeuse of hiatons (i.e., absent data symbols) in the semanticsmakes SIGNA L more powerful l anguage than L USTRE nthe sense that the internal clock of program can be fasterthan the inputs faster clock. In our opinion, the drawback ofthe approach lies in the fact that the clock calculus is muchmore complex, and can hardly be mentally performed bya programmer.3) mperative Synchronous Languages: Most synchronousmodels and languages are imperative ones-e.g., SCCS[27], ESTEREL,SML, STATECHARTS-and therefore theirprogramming style is very different. Comparison ex-periments undertaken with ESTERELshowed that someproblems could fit better with the imperative style, whileothers did not. This seems to indicate that a good reactiveprogramming tool box should offer the possibility ofmixing both approaches. As both languages share manytools in common, this may become a practical objectivein the future. It should also be noted that the data-flowaspect of LUSTREmakes it less dependent on synchronousexecution schemes than imperative languages. For instancea denotational semantics of L USTREs given in [5], whichdoes not impose a synchronous execution. This may openthe door to many asynchronous execution schemes togetherwith their semantic interpretation.

B. Proof TechniquesThe use of LUSTRE s a language for expressing programproperties allows it to be compared with so-called real-time logics [2], [24], [28], [37]. These logics are mainlyobtained by adding a quantitative time dimension to ordi-nary temporal logics where time is only seen as an orderingof events. Our proposal differs in that we remain within theframework of temporal logics, and consider time as a givenexternal event. This presents two advantages: fi rst, the logicdoes not grow in complexity, and it allows a multiform con-cept of time to be handled. On the same topic, we have alsostressed in the paper the interest of using the same languagefor both writing programs, and expressing properties to besatisfied by these programs. Concerning proof techniques,

we fi rst began by considering inductive methods, basedon an axiomatic approach. Though some work has beendone in that direction [14], it soon appeared that methodsbased on state enumeration (model checking) could bemore efficient. Several improvements of the method in theparticular case of LUSTRE re described in the paper.ACKNOWLEDGMENT

Many people have been involved in the project: J.-L.Bergerand and E. Pilaud played a great part in the languagedefinition, . Plaice defined and implemented the LUSTRE-V2compiler, Anne-CCcile Glory and F. Ouabdesselam wereinvolved in the work on program specification and proofwithin the framework of a contract with Merlin-Gerincompany. The LUSTRE roject received constant attentionand help from G. Berry and the ESTERELeam. In particular,the authors are indebted to them for the compiling technique



15/16

of L USTRE. hey are also indebted to A . Benveniste forits energy spent in promoting synchronous programming.Finally, they thank Costas Courcoubetis and the refereesfor their careful rereading of the manuscript.REFERENCES[I ] R. A lur, C. C ourcoubetis, and D. Dil l, M odel checking ofreal-time systems, in Fifth IEEE Symp.Ton Logic in ComputerScience, 1990.[2] R. A lur and T. A . Henzinger, A really temporal l ogic, in 30thIEEE Symp. on Foundations of Computer Science, 1989.[3] E. A . Ashcroft and W. W. Wadge, LUCID, the data-flowprogrammng language.[4] B. Buggiani, P. Caspi, and D. Pilaud, Programmng distributedautomatic control systems: A language and compiler solution,Tech. Rep. SPE CT RE L4, IM A G, Grenoble, France, July 1988.[5] J .-L . Bergerand, LUSTRE: un langage declaratif pour le tempsriel, masters thesis, Inst. National Pol ytechnique de Grenoble,France, 1986.[6] G. Berry Real time programming: special purpose or generalpurpose languages, in IFIP Congress, 1989.[7] A . Bouajjani, J . C. Fernandez, and N. Halbwachs, M inimalmodel generation, in Workshop on Computer-Aided Verifica-tion, J une 1990.[8] A . Bouajjani, J . C . Fernandez, and N. H albwachs, On theverification of safety properties, Tech. Rep. SPECTRE LIZ,IM AG, Grenoble, France, Mar. 1990.[9] S.A . Babiker, R. A. F leming, and R. E. Milne, A tutorial forLTS, RR 225. 84. 1, Standard Telecommunication L abs., 1984.101 D. Borrione and C. Le Faou, Overview of the CASCADE

multilevel hardware description language and its mixed modesimulation mechanisms, in Computer hardware descriptionlanguagcs arid their applications. Amsterdam, The Nether-lands: North Holland, Elsevier Science, 1985.111 M. Broy, Functional specif ication of time sensitive communi-cating systems, in REX Workshop, 1989.121 P. Bertin, D. Roncin, and J. Vuillemin, Introduction to pro-grammable active memories, Tech. Rep., Digital Paris Res.Lab., J une 1989.[13] E. M . Clarke, E. A . Emerson, and A. P. Sistla, A utomaticverification of finite-state concurrent systems using temporallogic specifications,TOPL AS, vol. 8, no. 2, 1986;[14] P. Caspi, D. Pilaud, N. Halbwachs, and J . Plaice, LUSTR E: Adeclarative language for programming synchronous systems,in 14th ACM Symp. on Principles of Programmng Languages,J an. 1987.[15] C. Courcoubetis, M . Vardi, P. Wolper, and M. Y anakakis,M emory eff icient algorithms for the verif ication of temporalproperties, in Workshop on Computer-Aided Verification, une1990.161 J . C . Fernandez, Aldebaran :un systkme de vtri fication parrtduction de processus communicants, M asters thesis, Univ.6J oseph Fourier, G renoble, France, 1988.171 A -C. G lory, V4rification de propri itks de programmes pots dedonntes synchrones, M asters Thesis, Univ.6 Joseph Fourier,Grenoble, Dec. 1989.181 N. H albwachs and F. Lagnier, Anexperience in proving regularnetworks of processes by modular model checking, Tech. Rep.SPEC TR E L 13, IM AG, Grenoble, France, Mar. 1990.[19] N. Halbwachs, A. Lonchampt, and D. Pi laud, Describingand designing circuits by means of a synchronous declarativelanguage, in IFIP Working Conf FromHDL Descriptions ToGuaranteed Correct Circuit Designs, Sept. 1986.[20] G. J . Hol zmann, On limits and possibil ities of automatedprotocols analysis, in I F IP WG-6.1 7th. Int. Conf on Proto-col Specification, Testing and Verification. Amsterdam, TheNetherlands: North Holland, 1987.[21] D. Hare1 and A . Pnueli, On the development of reactivesystems, in Logic and Models of Concurrent Systems, NATOAdvanced Study Inst. on Logics and M odels for Verificationand Specification of Concurrent Systems, New York: SpringerVerlag, 1985.

[22] N. H albwachs and D. Pi laud, Use of a real- time declarative lan-guage for systolic array design and simulation, in InternationalWorkshop on Systolic Arrays, July 1986.

New Y ork: Academic, 1985.

[23] N. Halbwachs, D. Pi laud, F. Ouabdesselam, and A . C. Glory,Specifying, programming and verifying real-time systems,using a synchronous declarative language, in Workshop onautomatic verification methods for finite state systems, LNCS407.[24] F . Jahanian and A. K. M ok, Safety analysis of timing prop-erties in real-time systems, IEEE Trans. Sofmare Eng., vol.[25] G. K ahn, The semantics of a simple language for parallel pro-gramming, in IFIP 74 Amsterdam, The Netherlands: NorthHolland, 1974.[26] J . R. M c Graw, T he VAL language: Description and analy-sis,TOPLAS, vol. 4, no. 1, J an. 1982.[27] R. M ilner, Calculi f or synchrony and asynchrony, TCS, vol.25, no. 3, J uly 1983.[28] B . M oszkowski and Z. M anna Reasoning in interval temporallogic, in Workshop on Logics of Programs, LNCS 164. NewY ork: Springer V erlag, 1984.[29] D. Pilaud and N. Halbwachs, From a synchronous declarativelanguage to a temporal logic dealing with multiform time, inSymp. on Formal Techniques in Real-Time and Fault-TolerantSystems, LNCS 332, M . J oseph, Ed. New Y ork: SpringerVerlag, Sept. 1988.[30] J . A. Plaice, Skmantiqueet compilation de LUSTRE, un langagedeclaratif synchrone, M asters thesis, Inst. National Polytech-nique de Grenoble, France, 1988.[31] A . Pnueli , T he temporal logic of programs, in 18th Symp. onthe Foundations of Computer Science, IEEE, 1977.[32] J . A. Plaice and J-B. Saint, The LUSTR E-EST EREL portableformat, 1987, IN RI A , Sophia Antipoli s, France, unpublished

New Y ork: Springer Verlag. J une 1989.SE-2, 1986.

report.[33] P. Raymond, Compilation stpari e de programmes LUSTRE,Tech. Rep. SPEC TR E L5, IM AG, Grenoble, France, J une 1988.1341 V . Roy and R. de Simone, AnAUTOGRAPH Primer, Tech.Rep. IN RI A , M ay 1989.[35] F. Rocheteau, Programmation dun circuit massivement par-allele a laide dun langage dtclaratif synchrone, Tech. Rep.SPEC TR E L 10, I M AG, Grenoble, France, June 1989.[36] J . L . Richier, C. Rodriguez, J . Sifakis, and J. V oiron, Verifica-tion in XE SAR of the sliding window protocol, in IFI P WG-6.17th. Int. Conf on Protocol Specification, Testing and VerificationA msterdam, The Netherlands: North Hol land, 1987.[37] R. L. Schwartz, P. M. Melliar-Smith, and F. H. Vogt, Aninterval logic for higher-level temporal reasonning: Languagedefini tion arrd examples, Res. Rep. C SL -138, Computer Sci-ence Lab., SRI International, Feb. 1983.[38] G. Thuau and D. Pil aud, Using the declarative languageLUSTRE for circuit verifi cation, in Workshop on DesigningCorrect Circuits.[39] D . Vergamini, Verification by means of observational equiva-lence on automata, Tech. Rep. 501, IN RI A , 1986.

Oxford, U.K., Sept. 1990.

Nicholas Halbwachs received the Ph.D. degreein 1984 on the modeling and analysis of real-time system behavior after a first thesis on thesemantic analysis of programs.Together with Paul Caspi, he participated inthe design of the language LUSTRErom its be-ginning. H is domain of interests concerns paral-lel and real-time system design and verification,both from formal (semantics, specifi cation, andverifi cation methods) and practical (compilers,verification tools) points of view.

HALBWACHS et al.: SYNCHRONOUS DATAFLOW PROGRAMM ING LANGUAGE LUSTRE

-

1319


16/16

Paul Caspi received the Docteur Cs Sciencesthesis from INPG, Grenoble, France.Currently, he is ChargC de Recherche CNRSat the Laboratoire de Genie lnformatique ofIM AG in Grenoble, France. H is previous re-search activities mainly dealt with the use ofcomputers in process control, and were espe-cially concerned with dependability problemsin critical appli cations, from both hardware andsoftware points of view. This led him to partic-ipate in the design of the synchronous data flowLUSTRE.e is now mainly concerned with the theory of synchronous dataflow, and the problem of building distributed systems from synchronousprograms. He also acted as a consultant for several companies and Frenchadmistrations, on problems of dependable computing systems design andvalidation.

specification implemental

Daniel Pilaud received the Docteur de 3cycle in computer science from the lnstitutNational Polytechnique de Grenoble in 1982.From 1982 until 1989 he was teacher cumresearcher at the Ecole Nationale SupCrieuredhformatique et de MathCmatiques AppliquCesde Grenoble. In 1989, he joined VERIL OG. Heis currently manager of the VERILOG Rhone-Alpes Research and Development Center, wherea CA SE tool based on the language LUSTREsbeing developed. His research interests includetion and validation of real time systems.

Pascal Raymond is working towards the Ph.D.degree at the Ldboratoire de GCnie Informatiqueunder a grant from the French Department ofResearch and Technology.He designed the new compiler LUSTRE-v3

1320 PROCEEDINGS OF THE IEEE, VOL 79, NO 9, SEPTEMBER 1991~ _ _ ~- -

TRS Lustre Language

Documents

TRS Lustre Language