The Synchronous Data Flow Programming Language LUSTRE NICHOLAS HALBWACHS, PAUL CASPI, PASCAL RAYMOND, AND DANIEL PILAUD Invited Paper This paper describes the language LUSTRE which is a data flow Parallelism: First, their design must take into account synchronous language, designed for programming reactive sys- the parallel interaction between the system and its tems-uch as automatic control and monitoring systemsas well environment. Second, their implementation is quite as for describing hardware. The data flow aspect of LUSTRE makes it very close to usual description tools in these domains (block- often distributed for reasons of performance, fault diagrams, networks of operators, dynamical sample-systems, etc.), tolerance, and functionality (communication protocols and its synchronous interpretation makes it well suited for han- for instance). Moreover, it may be easier to imagine dling time in programs. Moreover, this synchronous interpretation a system as comprised of parallel modules cooperat- allows it to be compiled into an efficient sequential program. ing to achieve a given behavior, even if it is to be Finally, the LUSTRE formalism is very similar to temporal logics. This allows the language to be used for both writing programs implemented in a centralized way. and expressing program properties, which results in an original Time constraints: These include input frequencies and program verification methodology. input-output response times. As said above, these constraints are induced by the environment, and should I. INTRODUCTION be imperatively satisfied. Therefore, these should be specified, taken into account in the design, and verified A. Reactive Systems as an important item of the system’s correctness. Reactive systems have been defined as computing sys- Dependability: Most of these systems are highly criti- tems which continuously interact with a given physical cal ones, and this may be their most important feature. environment, when this environment is unable to synchro- Just think of a design error in a nuclear plant control nize logically with the system (for instance it cannot wait). system, and in a commercial aircraft flight control sys- Response times of the system must then meet requirements tem! This domain of application requires very careful induced by the environment. This class of systems has design and verification methods and it may be one been proposed [6], [21] so as to distinguish them from of the domains where formal methods should be used with higher priority; design methods and tools that transformational systems-i.e., classical programs whose data are available at their beginning, and which provide support formal methods should be chosen even if these results when terminating-and from interactive systems imply certain limitations. which interact continuously with environments that possess synchronization capabilities (for instance operating sys- B. The Synchronous Approach tems). Reactive systems apply mainly to automatic process In our opinion, most programming tools used in designing control and monitoring, and signal processing,-but also to reactive systems are not satisfactory. Clearly, assembly systems such as communication protocols and man-machine languages do not, though they are widely used for rea- interfaces when required response times are very small. sons of code efficiency. Other methods include the use Generally, these systems share some important features: of classical languages for programming sequential tasks Manuscript received September 20, 1990; revised March 2, 1991. This that cooperate and synchronize using services provided work was supported in part by the French Ministhe de la Recherche within contract “Informatique 88,” and in part by PRC C3 (CNRS) IMAGLGI- by a real-time operating system, and the use of parallel Grenoble VERILOG-Grenoble, languages that provide their own real-time communication N. Halbwachs, P. Caspi, and P. Raymond are with the Laboratoire de services. Even the later, which seems more promising, has Genie Informatique, Institut IMAG, 38041 Grenoble, Cedex, France. D. Pilaud is with VERILOG, 38330 Montbonnot, St. Martin, France. been criticized [6] since the services being provided are low IEEE Log Number 9102318. level; this does not allow programs to be easily designed 0018-9219/91$01.00 0 1991 IEEE PROCEEDINGS OF THE IEEE, VOL 79, NO. 9, SEPTEMBER 1991 1305 ~~ ~-~ - ~~ __ properties. Also, reuse is made easier, which is an x = 2.Y + 2 interesting feature for reliable programming concerns. It is a parallel model, where any sequencing and w=x+1 + +&--gjysynchronization constraints arise from data dependen- cies. This is a nice feature which allows the natural Fig. 1. A data flow description and its associated equations. derivation of parallel implementations. It is also inter- esting to notice that, in the above domain, people were accustomed to parallelism, at much earlier times than and validated, while appears to be rather expensive at run in other areas in computer science. time. Synchronous languages have been recently proposed in order to deal with these problems: such languages D. Synchronous Data Flow provide “idealized” primitives allowing programmers to It may thus seem appealing to develop a data flow think of their programs as reacting instantaneously to approach to reactive programming. However, up until now external events. Thus each internal event of a program data flow has been thought of as essentially asynchronous, takes place at a known time with respect to the history of whereas a synchronous approach seems necessary to tackle external events. This feature, together with the limitation to the problem of time, for instance by relating time with the deterministic constructs, results in deterministic programs index of data in flows. This was the first concern of the from both functional and temporal points of view. In LUSTRE[14] project which is reported here. It resulted in practice, the synchronous hypothesis amounts to assuming proposing primitives and structures which restrict data flow that the program is able to react to an external event, before systems to only those that can be implemented as bounded any further event occurs. If it is possible to check that this memory automata-like programs in the sense of ESTEREL. hypothesis holds for given program and environment, then The language, together with programming examples, will this ideal behavior represents a sensible abstraction. The be presented in Section 11. Then compiling and efficient pioneering work on ESTERELhas led to propose a general code generation matters will be discussed in Section 111. structure for the object code of synchronous programs: The second main concern of the project is to take a finite automaton whose transition consists of executing advantage of the approach in developing techniques of a linear piece of code and corresponds to an elementary formal verification (Section IV). The idea is to consider reaction of the program. Since the transition code has no LUSTREas a specification language as well, thanks to its loop, its execution time can be quite accurately evaluated declarative aspect. It is then shown that the same compiler on a given machine; this enables us to accurately bound the can be used as a tool for verifying program correctness with reaction time of the program, thus allowing the synchronous respect to such specifications. Section V presents several hypothesis to be checked. Synchronous languages include other current activities of the project, related to hardware (see this issue) ESTEREL,SIGNAL, STATECHARTS, SML, and and distributed implementations. Finally comparisons with several hardware description languages [ 101. existing approaches are discussed. C. The Data Flow Approach 11. THE LUSTRELANGUAGE One method for reliable programming is to use high level languages, i.e., languages that allow a natural expression A. Flaws and Clocks of problems as programs. Within the domain of reactive In LUSTREany variable and expression denotes a flow, programming, many people are used with automatic control i.e., a pair made of and electronic circuits; traditionally, these people model a possibly infinite sequence of values of a given type; their systems by means of networks of operators transform- a clock, representing a sequence of times. ing flows of data-gates, switches, analog devices-and A flow takes the nth value of its sequence of values at the from a higher level, by means of boolean functions and nth time of its clock. Any program, or piece of program transfer functions with block-diagram structures, and finally has a cyclic behavior, and that cycle defines a sequence by means of systems of dynamical equations which capture of times which is called the basic clock of the program: a the behavior of these networks. Such formalisms look quite flow whose clock is the basic clock takes its nth value at the similar to what computer scientists call “data flow” systems nth execution cycle of the program. Other, slower, clocks [25], [26] (cf. Fig. 1). can be defined, thanks to boolean-valued flows: the clock Therefore data flow can be considered as a high level par- defined by a boolean flow is the sequence of times at which adigm in that field. Furthermore, as a basis of a high level the flow takes the value true. For instance Table 1 displays programming language, it possesses several advantages. the time-scales defined by a flow C whose clock is the basic It is a functional model with its subsequent mathemat- clock, and by a