Programming and Verifying Real-Time Systems by Means of the Synchronous Data-Flow Language LUSTRE Nicolas Halbwachs, Fabienne Lagnier, and Christophe Ratel Abstract—We lvestigate the benefits of using synchronous dataflow language for programming critical real-time ystems ‘These benefits concern ergonomy—siace the dataflow approach formal design and verifcation methods. We imple example, how the language LUSTRE, and its msoctatedveriication tool Lisa, cam be tved to design program, to specify its critical properties, and to verify these published in several papers (e, (11, {18}, we put particular ‘emphasis on program verfeaton. A preliminary version ofthis paper has been published in [28]. Index Terms—Datatow languages, formal verification, model checking, reactive systems, synchronous program 1. twrronuerion TIS useless to repeat why real-time programs are among those im arhich errors can have the most dramatic con: Sequences. Thus these programs constitute a domain where there is special need for rigorous design methods. We advocate “language approach” to this problem, arguing that the programming langsage used has a direct influence in the ‘quality ofthe sofware, from several points of view. 1, The language should allow a natural description of the problem fo be solved. In articular, it should be close 10 {he traditional tools used in its application fet The language should be formally sound, in order to support formal verification methods 5. The language should be simple enough to minimize the risk of misunderstanding about program meanings. These were our main goals in designing the language LUSTRE [11], 18}. To meet criterion 1), we started from the traditional ‘escrition tools used in the design of process contol syS- tems. AL a higher level, these tools consist of mathematical formalisns (diferential equations, boolean equations, et.) ‘while ata lower level, people often use dataflow nets (block- diagrams, analog schemas, switch of gate networks, etc) ‘These two classes of tools are closely related: for instance, Mansrip received November 1 19: eised Jue 2.1982. Tis work sem pally supper ty ESPRIT Bsc Kesar Aon SPEC and by 9 ON Tuba dF agar wik LOMAS, tl Crh Cos tel Metin erin SES and IMAGVLOI 36041, rm Cee, PAE Lng Number 932409, Aitferemtial equations, finite diference equations, and boolean equations can be sttaightforwardly translated, respectively, 10 analog schema, block-diggrams, and gale networks. At Teast the cliss of high level fools also meets our criterion 2), since they are derived from the mathematical language. (Other authors (eg, [2. [23]) claimed that such declarative formalisms are simpler and cleaner than usual imperative languages, where assignments, side-effects, aliasing, and pa- rameter passing mechanisms, are unnatural phenomena which are difficult «0 understand and manage. We agree with this lim, and therefore consider that hese declarative formalisms constitute a good basis for designing 2 programming language meeting the criterion 3). Lse is a synchronous dat-ow language, intially in- spired from LUcib. As in LUCID, any LUSTRE variable of ‘expression is considered to represent the sequence of values it takes during the whole execution of the program, and LUSTRE operator ae considered to operate globally over these sequences, The synchronous nature ofthe language consists in assuming that all the variables and expressions in a program take the nth value oftheir respective sequences af the same time. More conereely, a program is intended to have a cyclic ‘behavior, an execution cyele consisting in computing the n-th value of each variable or expression. Basically program is & Set of equations, When we write an equation "XE," where Xis A variable and isan expression, we mean thatthe sequences fof values associated with X and B are identical (it i an actual fequation, in the mathematical sense) or equivalently, that at any cycle of the program, and B tke the same valu Time and Synchrony The “real time” capabilities of the language are derived from this synchronous interpretation, like in other synchronous Fanguages (6) [}. [13]. (21) [24] We consid the following Topical notion of time: As soon as we can specify the order or simultane relations between events occuring both inside land outside the program, we can express time constrains about the behavior of the program. For instance, a constraint Ike “any occurrence of a dangerous situation must be followed by the emission of an alarm within a delay of 2 seconds” will be expressed as “after any occurrence of the event dangerous situation there Imust be an occurrence of the event alarm before the 2nd next ‘occurrence of the event second.”‘This example shows thal, in synchronous programming, the “real” physical ime is considered as an external event (here second), which has no privileged nature. This is the muiform time point of view: Time may be counted in “seconds” as wol asin “meters,” since there is no conceptual difference between the two following requitements: the train ‘must stop within 10. ad the train must stop within 100 meer ‘In a synchronous language, these constraints are expressed in similar ways, in contrast with languages like ADA, where “real” time is handled by special statements. In LUSTRE, an event willbe modeled hy # hoolean variable, whose value is true whenever the event occu ‘The synchronous interpretation isan abstract point of view that considers the program reaction time to be negligible with respect tothe reaction time of is environment. The advantages ‘of this abstraction have Been pointed out [3}-(5) concerning the semantics cleanness and the fact that it reconciles con- currency and determinism. In particular, (4) argues that syn- ctronous languages are particularly well-suited for program- ring reactive kernels of realtime systems, while complex systems generally require the combination of asynchronous land syachronous modules. We do not claim, therefore, that synchronous Tanguages are general purpose languages, but rather specialized tools to design such kernels One may wonder about the realism of the synchronous hypothesis, since it assumes that the machine instantly reacts to input evens. In fact, it only assumes that the reaction time is short enough to accurately distinguish and order the incoming events. In practice, it ean be checked by measuring the maximum reaction time of the program. Synchronous languages can be implemented in a particulary efficent and measurable way, following technique developed fot ESTEREL [6}. Two versions of LUSTRE compilers have been writen {11 [20}, which use this technique. The object code is structured 88 finite automaton, a transition of which corresponds to a reaction of the program! The code coresponding to such a teanstion is linear (lop-fre), and its maximal execution time can be accurately bounded, on a given machine. Therefore, the vali of the synchrony hypothesis ean be checked, and i is ‘the only “real-time” issue in the synchronous approach. All the design and verification we will perform rely on that checking. In Section I we briefly present the language, whose use is lustrted in Section IIL on «small example adapted from an actual subway device Specification and Verification ‘The remainder of the paper is devoted t0 program veri cation, As said before, the synchronous approach limits the “timing” verification to checking the validity ofthe synchrony hypothesis. So, the kind of verification we have in mind is similar to standatd verification on transition systems. It has nothing to do with methods and modes (like, e.g. (16, [26]) taking into account the program execution time—which is always assumed to be zero in the synchronous mode "Tis comping technique i psi to paca anges sine a an synchonas ingung the mndtermse insta of sy acheooes ‘her woud imei move sca expsom of he atrton Morcover, our goal is not t prove the corrctness of a program with respect to some complete specifications, but father 1 express and verily some critical properties. For instance, in an aiteraft fight control system, an error in the speed computation can have only slight consequences, whereas itis critical that the undercarriage be locked when landing. Our claim is that these critical properties are usually simple, and ‘can be verified by means of available automatic techniques. “The main reason for this elaim is that experience shows that ‘most of these properties ar “safety” properties which state that «given situation should never occur or that a given statement should always hold, in contrast with “liveness” properties ‘which state that a given situation should eventually occur in ‘he future For instance, a relevant question isnot that a train ‘ill eventually stop, bu hat it never crosses red light, This is ‘an important remark as proof techniques for safety properties ‘are known tobe much simpler than for liveness properties + Safety properties ean be checked oa program abstractions Inwitively, one can simplify @ given program P? into an abstract program P”, having “more behaviors” than P. It P satisfies a safety property, so does P. This abstraction technique is valuable all the more as experience shows that the considered critical properties seldom depend on numerical relations and computations, but more often on logical dependencies over events, So thei proof can often bbe handled on finite state abstractions of programs. + Safety properties can be checked on program sates, rather ‘han on execution paths: In the approach we will propose, any verification problem amounts at proving that some program never outputs the value false. In the finite sate ‘ase, such a verification canbe done by a simple traversal fof the state graph, without keeping tack of any path in that graph. Very efficient methods [22] have been proposed for such a traversal Safety properties can be modularly verified. With any process composition operator +, one can easily associate fn operator» suc tha, for any two processes P and Ps, respectively satisfying safety properties 6, and g, their ‘composition Py + Ps satisfies & + db, So, a verification ‘problem can be decomposed ino simpler ones So, ovr ambition i rather madest—since we restrict ourselves to checking safety properties on finite state (abstractions of) programs-—with the hope of getting efficient tools tackling many realli cases. Tn view of this discussion, we propose a method for spec- ifying and checking simple safety properties about LUSTRE programs. In Section IV, we show that we can take advantage Of the declarative nature of LUSTRE, to express the properties in the same language. It has been shown (7] that any safety property about a program can be expressed by the invariance ff some boolean LUSTRE expression. This is due to the fact that LUSTRE can be viewed as an executable temporal logic. ‘Concerning ergonomics, there is an obvious advantage of wing a full programming language instead of a temporal Topic. Ia 2A mater of a veses popes ae fie nos “abt espns ime sonst whih be ly tent sos eeparticular, the user can define its own temporal operators, thus Teducing the complexity of property expression, “Moreover, LUSTRE provides a means of expressing assump- tions about the program environment. This is an essential feature, since the iteration ofa real-time program with it en vironment is particularly important. In general, the properties (of a real-time program are intended 0 hold only under some assumptions about the behavior of its environment, and these ‘assumptions ean be quite complex. So, the verification process deals with tree entities: The program, the property (expressed by an invariant) andthe assumptions under which the property is intended to hold (also expressed by an invatiant), Sections Vand VI illustrate the proposed approach on our example, Verification (Section VID) is performed on a finite State abstraction of the program, which models only the be- havior of boolean variables. verification tol, called LESAR, js available, which can apply two Verification techniques: + the former is an exhaustive enumeration of the states of the (abstraction ofthe) program, similar standard mode checking (12). 27 + the latter is a symbolic construction of the set of states that satisly the property, analogous to “symbolic model checking” [10} (14, [13} These techniques will be applied to the example introduced in Section Ih Finally, Section VIL outlines @ method for modular ver ification: taking advantage of the fact that the program and its properties aze expressed in the sime language, we can use the proved properties of a subprogram in the verification of fall program. This technique can reduce the complexity of the verification 1. THe LANQUAGIE LusTRE ‘We do not give here a detiled presentation of the language LUSTRE, which ean be found elsewhere (11), [18]. We only recall the elements which are necessary for understanding the paper. 'A LUSTRE program specifics a relation between input and output variables, Any variable or expression is intended 0 bbe function of time. Time is assimilated tothe set of natural numbers. Variables are defined by means of equations (one and fly one equation for each variable which is not an input) ‘As said before, an equation “X=B," where is a LUSTRE expression, specifi thatthe variable X is always equal 10. Expressions are made of variable identifiers, constants (con- sidered as constant functions), usual arithmetic, boolean and conditional operators (considered as pointwisely applying 10 functions), and only 1w0 specific operators: the “previous” ‘operator and the “follawed-by” operator: + if Bis an expression denoting the function An.e(n) then “pre ()” isan expression denoting the function nil if n=0 {teed itn>0 where nif fs an undefined value; >This 2 mae power mschinin tan he mcr-ettion ofr by some spect ngs [12h [91 ‘say Us etn + if E and F are two expressions of the same type, respec tively denoting the functions Xn.e(n) and An.f(n). then "E -> is an expression denoting the function wfc” meh In alton wo equation, a LUSTRE progam can contain astrton, ofthe frm “amsezt "whet E any boolean Shpreson This means ta Es assumed w Be aways te Shing the excetion of the progam. For instance. fore noe (om and OFF)" exjrescs tha th input evens ON an OF never ect atthe same tine. Assertons were froued in ode express some known propertis ofthe fnvitonment fr opinzaton purposes. "They will play an Smporant olin progam verieaton LUST: progam is sutured into noes: 9 node i « sutpropm spoaying a elauon betwen i inp and ouput Jace Thin tlaton is expressed by am unordered Set of utons and assertions, poly involving local variable. ‘hee declared. anode may be fanctonallywsed in any txresion a5 bie operator. For intance the following Jsarstion dies 2 nde of ete cra usage, mbich etn re whens oolean parame tabs fom fae to te: ifn=0 itn>o. node edge(x: bool) returns (EDGE: bool); let ‘EDGE = x -> x and not pre(x); tel [Now the expression e@ge (not. C) is zmue whenever the variable € has a falling edge I, EXAMPLE OF PROGRAM Let ws trode an example adapted from a subway device. ‘Ateach end of a subway line, aspeeal “U-turn” section allows trains to switch from one tack (0 the other, and 10 go back in the opposite direction (See Fig, 1). A U-turn section is ‘composed of three tracks A, B, C, and a switch S, Assuming the eneting track is A and the exiting track is C, tains ‘switching ftom A to C must fst wait for $ to connect A With B, then transit on Band wait again for S to connect B with C before going back on C. ‘Considering that several tains move along the tracks and thatthe switch is not a safe device, two kinds of accidents may occur within the Scetion: + if several train ae allowed to access the section together, they may collide; + ifthe switch isnot well positioned, trains will deri Ie is therefore clear that controlling a Usturn section is a highly eitical task. Any automatic U-turn section management ‘system (later on called UMS) must bath drive the switeh and