Top Banner

of 16

TRS Lustre Language

Apr 03, 2018




  • 7/28/2019 TRS Lustre Language


    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.



    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



  • 7/28/2019 TRS Lustre Language


    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 ti

Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.