A Lift Controller in Lustre. (a case study in developing a reactive system) Leszek Holenderski

Transcription

1 Presented at 5 th Nordic Workshop on Program Correctness, Turku, Finland, October 25{28, Published in Proc. of the 5 th Nordic Workshop on Program Correctness, ed. R.J.R. Back and K. Sere, Abo Akademi Report B/18, 1994, pp 96{111. A Lift Controller in Lustre (a case study in developing a reactive system) Leszek Holenderski GMD-SET, Schloss Birlinghoven, D Sankt Augustin, Germany lhol@gmdzi.gmd.de Abstract We show how to develop (i.e. specify, program and verify) a nontrivial reactive system, in a relatively easy way, using existing software tools and a bit of elementary mathematics. The reactive system is a lift controller, the software tools are the Lustre compiler [2] and the symbolic model checker Lesar [4], and the elementary mathematics is simply a basic propositional calculus. 1 Introduction We have chosen the well-known lift example since it suits well our purposes: its requirement specication is obvious (since we all know the application domain) and it is simple enough to be fully specied, yet complex enough to be non-trivial. We program the lift controller in Lustre, which is a data-ow language for programming synchronous reactive systems. Since Lustre is a declarative, high-level language, it can be considered to be a specication language as well. In Lustre, a behaviour of a reactive system with input channels a, b, : : : and output channels x, y, : : :, is specied by equations of the form x = expr where x is an output channel, expr (built from various built-in operators) may depend on both input and output channels. There must be exactly one such a equation for every output channel. In the computational model for synchronous system, time is assumed to be discrete, i.e. modelled by natural numbers. The equation simply means that in every instant of time the value On leave from Institute of Informatics, Warsaw University, Poland 1

2 emitted on channel x should be the value of expr. Since Lustre expressions may involve an operator which allows to refer to the previous value of a channel, the current value emitted on x may depend on the communication history of the system. In the paper we show how to formally verify several properties of our lift controller. They are listed in section 5. All of them can be veried either manually or automatically. Manual verication consists in proving that a formula encoding the property to be veried follows from the equations which constitute a Lustre program. Due to a precise, yet intuitively simple, formal semantics of Lustre, such proofs can be made formal in the usual mathematical sense, i.e. presented on the level of formality accepted by humans. Automated verication was done using a symbolic model checker called Lesar. Both the model and the formula to be checked can be specied in Lustre itself. The latter is possible since, in fact, Lustre boolean expressions can be seen as formulas in a simple temporal logic with an immediate past operator, and using Lustre recursive equations one can dene more complex temporal past operators. Lesar can be applied only to pure Lustre programs, i.e. those operating on boolean values only, and it can check only invariance properties. Although the lift controller is not a pure Lustre program, it was possible to extract from it a purely boolean part for which all the properties we have veried manually could be veried also automatically. On the other hand, due to the limitations of the Lesar tool, even a simple property that the lift does not change its position unless it is forced to by some requests, could not be veried automatically. However, it could easily be veried manually. All the properties we have veried for the lift controller are invariance (safety) properties. As is well-known, in the context of real-time reactive systems, most liveness properties are reducible to invariance properties since one is usually interested in events happening at moments of time bounded by some other events, e.g. ticks generated by a clock. However, in the case of the lift controller, there is an important property, namely that every request should eventually be served, which does not t this scenario. We analyse this property in [5]. Using Lesar to fully automate verication of a reactive system has already been reported in [4]. Although we show how to extend those results by applying a similar approach to a more complex (and not purely boolean) system, here we concentrate on the manual verication. 2

3 2 A quick introduction to Lustre Lustre is a declarative data-ow language for programming synchronous reactive systems. In what follows, we only describe the fragment of Lustre which we use in the paper. The full language is described in [3]. A reactive system is viewed in Lustre as a network of reactive components, called nodes in Lustre parlance, connected by communication channels. With every node there are associated its input and output channels through which the node interacts with its environment. Channels are typed, and as usual, the types simply restrict the set of possible values which can be transmitted via channels. A declaration of a node has the following syntax: node name (inputs) returns (outputs); local declarations let body tel; where inputs and outputs are lists of channels (together with their types), local declarations introduce some auxiliary objects used by the node, if any, and body species the node's reactive behaviour, i.e. what it sends to its outputs in response to what it receives on its inputs. A program in basic Lustre is a set of declarations of nodes, with one node being distinguished as a main node. The main node's interface becomes the interface of the whole network. The topology of the network, i.e. what channels connect what nodes, is not given explicitly (since Lustre, being a data-ow language, has no explicit parallel composition operator), but instead can be deduced from the source of a Lustre program. The topology is not that important anyway, since the declarative reading of Lustre programs, which is given later, does not rely on this notion. What is important is that the syntax of the language guarantees that every input channel of a node is either an input channel of the network, or is an output channel of exactly one other node in the network. There is no such a restriction for output channels. One output channel of a node may be an input channel of several other nodes, and simultaneously, it may be an output channel of the whole network. The underlying computational model is that for synchronous data-ow languages: Time is discrete, i.e. continuous real-time is divided into a denumerable set of disjoint segments called instants of time. The segments are numbered by successive natural numbers. 3

4 0 1 2 At the beginning of every instant an environment must provide values on all input channels of a network, and then all nodes in the network perform a reaction step, which results in sending some values to all output channels of the network. This ends the instant. For one node, the reaction step consists in sending values to all its output channels. The value sent to an output channel may depend on the values currently present on the node's input channels. It is immediately available to all nodes which use the output channel as their input channels. Thus, the communication mechanism is based on instantaneous broadcasting. In any instant of time all channels in the network transmit exactly one value of a respective type. The value is either supplied by an external environment, in the case of the network input channels, or is a result of sending a value, in the same instant, by an internal node. Thus, a communication history of a channel can be represented by an innite sequence of values (called streams) transmitted through the channel, and a node can be viewed as a function from tuples of input streams to tuples of output streams. For a stream s = hv 0 ; v 1 ; v 2 ; : : :i its ith component is denoted by hsi i. The input-output function of a node is specied by a set of (possibly recursive) equations which form the node's body. An equation has the form variable = expression where variable is either a name of an output channel of the node, or an auxiliary variable declared in the local declarations part. Both variables and expressions denote streams, and v = e simply means that 8 i 0 : hvi i = hei i. Expressions are built from constants, variables and operators. Constants denote constant sequences (e.g. h1i i = 1). Variables are either input, output or auxiliary channels. Operators are of two kinds: data operators and sequence operators. The data operators (e.g. arithmetic +, -, *, /, : : : or boolean and, or, not, : : :) are applied point-wise, i.e. hop(e 1 ; e 2 ; : : :)i i = op(he 1 i i ; he 2 i i ; : : :) Conditional expression if e then e 0 else e 00 is a special case of a data operator. 4

5 The sequence operators are pre(e) (previous value) and e -> e 0 (initialisation). pre(e) returns the value of e in the previous instant, i.e. hpre(e)i 0 = undened; hpre(e)i i+1 = hei i In the rst instant, e -> e 0 value of e 0, i.e. returns the value of e, and in all later instants, the he -> e 0 i 0 = hei 0 ; he -> e 0 i i+1 = he0 i i+1 Operator -> is called an initialization operator since it is usually used to initialize pre(e), which is not dened in the rst instant. It has the weakest binding power. Nodes may be applied in expressions as functions in other programming languages. Assuming the following declaration node name (i1:t1; i2:t2;: : :) returns (o1:t1 0 ; o 2:T2 0 ;: : :); local declarations let body tel; name(e 1 ; e 2 ; : : : ) returns a tuple of streams (o 1 ; o 2 ; : : :) dened by body with all occurrences of i 1, i 2, : : : replaced by e 1, e 2, : : :, respectively. For example, the following program node edge (x: bool) returns (y: bool); let y = false -> (x and pre(not x)); tel; node main (x: bool) returns (rising, falling: bool); let rising = edge(x); falling = edge(not x); tel; species a reactive system which recognizes rising and falling edges in a supplied input signal. The signal is encoded as a stream of boolean values with true interpreted as up and false interpreted as down. Node edge recognizes rising edges. A declarative reading for the denition of y is the following: initially y equals false, and afterwards it is true i currently x is up and in the previous instant it was down. Substituting not x for x in the body of edge gives the denition of the falling edge. The network for the program has the following structure: 5

6 x - main - edge - not - edge - falling - rising where x - edge false - - not - pre - a n d - - -> - y 3 The lift example Lift moves and stops while reacting to requests caused by pressing buttons. There are 3 kinds of buttons. They are called lift, up and down buttons, respectively. The lift buttons are in the lift itself; up and down buttons are at oors (of course, there is no up button on the last oor and down button on the ground oor). With every button there is associated a lamp which represents a pending request caused by pressing a respective button. A lamp should be switched on when the respective button is pressed, and switched o when the respective request is served. In our simplied version of the lift example, observable positions of the lift are just oors at which it stops or which are passed during its movement. Thus, in every observable state of the lift's behaviour, i.e. in every instant of time, the lift is at some oor, either stopped at it or passing it. When the lift is stopped at a oor it can either start moving up or down, if respective requests appear, or otherwise remain at the oor. When the lift is approaching a oor during its movement it should decide whether to stop at the oor or continue the movement. The decision is based on the current 6

7 requests which are the pending requests from the previous position plus the new requests accumulated during the movement of the lift. The main tasks of the lift controller is to decide at any observation point what action the lift should perform next. The possible actions are called stop, up and dn. The stop action causes the lift either to stop (if it moves) or to remain at the same oor (if it is stopped). The up action causes the lift either to start moving (if it is stopped at a oor) or to continue its movement (if it passes a oor). In any case, up increments the lift's position by one oor. The dn action is dual to up. In addition, the lift controller should decide whether doors should be opened and what lamps should be on. The lift is operating according to the following strategy: the direction of the movement is not changed before all requests in that direction have been served. 4 Lift in Lustre In Lustre, there are only 3 built-in types: bool, int and real. More complicated user-dened types can easily be incorporated into a program, as abstract data types, by dening names of types and signatures of applicable functions. Implementation of user-dened types is given in a host language, which currently is C. In our Lustre program we use an abstract data type, called Flags, which is implemented as a boolean array indexed by oors. The type is declared as type Flags; function At (pos: int; f: Flags) returns (b: bool); function Above (pos: int; f: Flags) returns (b: bool); function Below (pos: int; f: Flags) returns (b: bool); function SwitchOff (pos: int; f: Flags) returns (x: Flags); function OR (f1, f2: Flags) returns (f: Flags); where At returns the value of f at index pos (i.e. f[pos]), Above returns true i f[i] is true for some i > pos (and returns false if pos is greater or equal to the last oor), Below is a dual to Above, SwitchOff returns f with f[pos] set to false, and OR returns the result of element-wise disjunction of f 1 and f 2. The node implementing our lift controller has the following interface: node lift (LB, UB, DB: Flags) returns (pos: int; stop, up, dn, opened: bool; LL, UL, DL: Flags); 7

8 The inputs represent current requests, i.e. those accumulated since the previous instant. They encode the state of respective buttons, as either being pressed or not, at the beginning of a current instant. The outputs encode the reaction of the lift to the current requests: pos is the number of the current oor; one of stop, up and dn is true, indicating what action the lift should perform at the current oor; opened indicates whether the doors should be opened or closed; LL, UL and DL indicate the state of respective lamps. The rest of this section is devoted to listing the equations which constitute the body of the node lift. The current position of the lift is initially 0 and afterwards is incremented, decremented or left unchanged, depending on the previous action of the lift: pos = 0 -> pre(pos) + if pre(up) then 1 else if pre(dn) then -1 else 0; There are some auxiliary variables involved in dening the rest of the outputs. The rst group is dened as LR = LB -> OR(pre(LL), LB); -- lift request UR = UB -> OR(pre(UL), UB); -- up request DR = DB -> OR(pre(DL), DB); -- down request AR = OR(LR, OR(UR, DR)); -- any request and denotes the requests which have not yet been served. Initially, these are just current requests, and afterwards they are simply a disjunction of pending requests (i.e. the state of lamps in the previous instant) and current requests. The second group is dened as RequestAbove = Above(pos, AR); RequestBelow = Below(pos, AR); StopWhileUp = At(pos, LR) or At(pos, UR); -- stop while moving up StopWhileDn = At(pos, LR) or At(pos, DR); -- stop while moving dn where RequestAbove is true i there is some pending request above the current oor, and StopWhileUp is true i the lift should stop when approaching the current oor while moving up (which is the case when there is either a lift or an up request at the current oor). RequestBelow and StopWhileDn are respective duals. The lift should move up if there is a pending request above the current oor, provided that it is neither currently serving down requests, nor needs to stop while moving up: up = RequestAbove and not(onwaydn or StopUp); OnWayDn =...; StopUp = false -> pre(up) and StopWhileUp; 8

9 The condition OnWayDn should become true if the lift starts moving down, and should remain true during a lift movement, until there are no requests below. This can be done by sustaining condition up until not RequestBelow. Thus, OnWayDn = sustain(false->pre(dn), not RequestBelow); where the auxiliary function sustain is declared as node sustain (on, off: bool) returns (s: bool); let s = on -> if on then true else if off then false else pre(s); tel; which reads \sustain condition on until condition o becomes true" (the output s becomes true whenever on is true, and remains true until off is true, whereupon it becomes false and remains false until on is true again). Note that in Lustre, nodes are used in expressions as user-dened operators, i.e. as functions in other programming languages. The denition of dn is almost dual to up. The dierence is caused by the need to choose between going up or down when both cases are possible, e.g. when the lift is stopped at a oor and there are both requests above and below. We decided that in such a case going up has priority, and thus dn = not up and RequestBelow and not(onwayup or StopDn); OnWayUp = sustain(false->pre(up), not RequestAbove); StopDn = false -> pre(dn) and StopWhileDn; Now, the denition of stop and opened is obvious: stop = not up and not dn; opened = stop; The denitions of lamps are the following: LL = if stop then SwitchOff(pos,LR) else LR; UL = if up or stop and not RequestBelow then SwitchOff(pos,UR) else UR; DL = if dn or stop and not RequestAbove then SwitchOff(pos,DR) else DR; They follow from the fact that lamps should represent pending requests which are simply those requests recorded at the beginning of an instant, which have not been served during that instant. 9

10 5 Verication In this section we prove that our lift controller satises the following properties: 1. the doors are always opened when the lift stops at some oor; 2. the doors are always closed when the lift is moving; 3. the lift can never change the direction of its movement without previously stopping at some oor; 4. the lift may decide to go up only if there is a request concerning a oor above a current oor; 5. similarly for going down (observe that (4) and (5) imply that the lift may only move if there is a request); 6. the lift should not make unrequested stops. The properties can be veried either manually or automatically. 5.1 Manual verication Manual verication of a Lustre program consists in proving that a formula encoding the property to be veried follows from the equations which constitute the Lustre program. Due to a precise, yet intuitively simple, semantics of Lustre such proofs can be made formal in the usual mathematical sense, i.e. presented on the level of formality accepted by humans. All the properties we verify can be formulated as always (i.e. in every instant of time, is true) where is a propositional formula containing some variables appearing in the lift controller program. For example, property (1) can be formalized as always stop ) opened, which immediately follows from the equation opened=stop by an observation that equality of booleans is their logical equivalence. In an equally easy way we can prove property (2). The property can be formulated as always up _ dn ) :opened which, by transposition of implication, is equivalent to always opened ) :up ^ :dn, and this follows directly from the denitions of opened and stop. Property (4) can be formulated as always up ) RequestAbove, which follows directly from the equation up=requestabove and... Property (5), i.e. always dn ) RequestBelow, can be proven in the same way. Properties (3) and (6) are more dicult to prove. Their proofs need two additional lemmas, which themselves are interesting facts about our lift controller. 10

11 5.1.1 At any time, exactly one of stop, up or dn is true The property can be formalised as always (1) stop ) :up (2) stop ) :dn (3) up ) :stop (4) up ) :dn (5) dn ) :stop (6) dn ) :up (7) stop _ up _ dn (1) and (2) follow directly from the denition of stop, and (6) follows directly from the denition of dn. (3), (4) and (5) follow from (1), (6) and (2) by transposition of respective implications. (7) is equivalent, by simple propositional reasoning, to :up ^ :dn ) stop, which in turn follows directly from the denition of stop. Remark Since any propositional formula can be treated as a Lustre expression denoting a boolean stream, the proof shows that the above formulas (1){(7) denote the constant stream true. Since pre distributes over all data operators, if (stop => not up) = true then also (pre(stop) => not pre(up)) = pre(true) = true, in all the instants in which the pre's are dened. Hence, pre(stop) ) :pre(up). In other words, pre(stop), pre(up) and pre(dn) are also mutually exclusive, whenever they are dened. This observation is used later on OnWayDn and OnWayUp are mutually exclusive By transposition, it suces to prove that always OnWayDn ) :OnWayUp. The proof is done by induction on the number of a current instant of time. In the rst instant, both OnWayDn and OnWayUp are false. The inductive hypothesis can be formalised as pre(onwaydn ) :OnWayUp). By unfolding sustain in the denitions of OnWayDn and OnWayUp, one gets OnWayDn = false -> if pre(dn) then true else if not RequestAbove then false else pre(onwaydn); from which it follows that OnWayDn ) pre(dn) _ pre(onwaydn). Similarly, OnWayUp ) pre(up) _ pre(onwayup). Assume that OnWayDn is true in the current instant, hence pre(dn) _ pre(onwaydn) is also true. If pre(dn) is true then pre(up) is false (from 11

12 the mutual exclusion of up and dn) and pre(onwayup) is false (from the denition of dn), thus OnWayUp is false. If pre(onwaydn) is true then pre(up) is false (from the denition of up) and pre(onwayup) is false (from the inductive hypothesis), thus OnWayUp is false The lift cannot change the direction of its movement without stopping Property (3) can be formulated as always (up ) pre(stop _ up)) ^ (dn ) pre(stop _ dn)). Notice that the formula makes sense only in all instants of time but the rst one, and in such a case, from the remark in section 5.1.1, up ) pre(stop_up) is equivalent to up ) :pre(dn), which in turn is equivalent to pre(dn) ) :up, by transposition. The last implication follows directly from the denition of up, by observing that pre(dn) ) OnWayDn, which follows from the unfolding of sustain in the denition of OnWayDn (see section 5.1.2). In a similar way one can prove dn ) pre(stop _ dn), which nishes the proof of property (3) The lift should not make unrequested stops Property (6) can be formulated as always stop ) (:RequestAbove _ :RequestBelow _ StopWhileUp _ StopWhileDn) From the denition of stop, and by simple propositional reasoning, this is equivalent to ) up _ dn, where = RequestAbove ^ RequestBelow ^ :StopWhileUp ^ :StopWhileDn. Thus, it is sucient to prove that dn is true provided is true and up is false, and this can be further reduced, by the denition of dn, to proving that ^ :up ) :OnWayUp. Let us assume that up is false then from the denition of up, and under the assumption, it follows that OnWayDn must be true. By the mutual exclusion of OnWayDn and OnWayUp, OnWayUp must be false. 5.2 Automated verication A fully automated verication can be applied to pure Lustre programs, i.e. those operating on boolean values only, and when the property describing some relation between its inputs and outputs can be encoded as a Lustre boolean expression. In such a case, the Lesar [4] tool (included in the Lustre programming environment) can produce a yes/no answer to the question 12

13 whether the property holds invariantly during all possible computations of the program. This can be done by using a technique called a symbolic model checking. More precisely, Lesar accepts as its input a pure Lustre program whose main node has only one output. It returns yes if the output is invariantly true for all possible inputs. Thus, assuming the output is called OK, it checks whether the condition dening OK is always true during execution of the node, no matter what inputs are. Although the lift controller is not a pure Lustre program, it was possible to extract from it a purely boolean part for which properties (1){(6) could be proved by Lesar. The extracted program has the property that whatever can be proved about it also holds for the original program. The denition of OK for the properties we want to verify is the following. Properties (1) and (2) can be encoded as OK = (if stop then opened else true) and -- prop (1) (if up or dn then not opened else true); -- prop (2) where if p then q else true encodes p ) q. In a similar way, property (3) can be encoded as OK = (true -> if up then pre(stop or up) else true) and -- prop (3) (true -> if dn then pre(stop or dn) else true); -- prop (3) where true ->... takes care for a proper initialization of otherwise undened expressions. And nally, properties (4), (5) and (6) can be encoded as OK = (if up then RequestAbove else true) and -- prop (4) (if dn then RequestBelow else true) and -- prop (5) (if stop then StopWhileUp or StopWhileDn or -- prop (6) not RequestAbove or not RequestBelow else true); For the following verify program, Lesar returns yes: node verify (RequestBelow, RequestAbove, StopWhileUp, StopWhileDn: bool) returns (OK: bool); var opened, stop, up, dn, OnWayUp, StopUp, OnWayDn, StopDn: bool; let up = RequestAbove and not(onwaydn or StopUp); OnWayDn = sustain(false->pre(dn), not RequestBelow); StopUp = false -> pre(up) and StopWhileUp; 13

14 dn = not up and RequestBelow and not(onwayup or StopDn); OnWayUp = sustain(false->pre(up), not RequestAbove); StopDn = false -> pre(dn) and StopWhileDn; stop opened = not up and not dn; = stop; OK =...; tel; node sustain (on, off: bool) returns (s: bool);... Observe that all the equations in the verify program are taken from the original program for the lift controller (besides the equation for OK, of course). Thus the verify program has the following property: if OK is invariantly true for all possible streams RequestBelow, RequestAbove, StopWhileUp and StopWhileDn, then OK is also invariantly true for all possible stimuli to the original program. This follows from the fact that the stimuli can generate (using the denitions removed from the original program) only a subset of all the possible streams. Thus, all the properties which hold for the verify program also hold for the original program, in particular properties (1){(6). 6 Conclusions We have shown how, using existing software tools, one may specify and partly verify a non-trivial reactive system. Using Lustre and Lesar in such a context has many advantages. Lustre, due to its declarativness, allows for concise specications which can then be easily veried, either manually or automatically. The former is possible due to the precise, yet relatively simple, semantics which is intuitive enough to allow a presentation of proofs on a level of abstraction suited for humans. This is a very important issue, since the automation of proofs is still quite limited. Lesar can prove only those safety properties of a program which depend on purely boolean parts of the program and which can be reduced to an invariance of propositional formulas in a kind of a temporal logic with the immediate past operator. For example, it cannot deal with the property always pre(stop) ) pos = pre(pos) which states that the lift does not move unless it is forced to. On the other hand, the property can easily be proven manually, just by inspecting the equa- 14

15 tion dening pos (and using the fact that pre(stop), pre(up) and pre(dn) are mutually exclusive). Although formal verication adds yet another step to a software development process, it is obviously worth the eort since it provides a sound justication of system's correctness with respect to the veried properties. On the other hand, formal verication has its own disadvantages. It is usually complex, and thus needs special skills and time. It is also error-prone itself, unless done automatically (but even in this case a formal proof of the correctness of the tool used for such an automation would be necessary, in principle). Furthermore, the state of the art in formal verication methods is far from being satisfactory, in the sense that it is feasible to verify only relatively simple properties of relatively simple systems. For those reasons formal verication should be still complemented by systematic testing. In [5] we extend the results presented in the current paper, by combining formal verication and systematic testing to validate the lift controller. References [1] P. Caspi, N. Halbwachs, D. Pilaud, J. A. Plaice, Lustre: a declarative language for programming synchronous systems, Proc. of the 14th Symposium on Principle of Programming Languages, Muenchen, Sep. 1987, 178{188. [2] N. Halbwachs, P. Caspi, P. Raymond, D. Pilaud, The Synchronous Data Flow Programming Language Lustre, IEEE Special Issue on Real Time Programming, Proceedings of the IEEE, 79(9), Sep. 1991, 1305{1320. [3] N. Halbwachs, A Tutorial of Lustre, Lustre distribution, available by anonymous ftp from imag.imag.fr as le /ftp/pub/lustre/tutorial.ps, Jan. 1993, 1{19 [4] N. Halbwachs, F. Lagnier, C. Ratel, Programming and Verifying Real-Time Systems by Means of the Synchronous Data-Flow Language Lustre, IEEE Trans. on Software Eng., 18(9), Sep. 1992, 785{793. [5] M. Mullerburg, L. Holenderski, Combining Testing and Formal Verication for Validating Reactive Systems, submitted to the Fourth European Conference on Software Quality, Basel, Switzerland, Jan Appendix: The Full Lustre Program type Flags; function At (pos: int; f: Flags) returns (b: bool); function Above (pos: int; f: Flags) returns (b: bool); function Below (pos: int; f: Flags) returns (b: bool); function SwitchOff (pos: int; f: Flags) returns (x: Flags); function OR (f1, f2: Flags) returns (f: Flags); 15

16 node sustain (on, off: bool) returns (s: bool); -- sustain 'on' until 'off' let s = on -> if on then true else if off then false else pre(s); tel; node lift (LB, UB, DB: Flags) returns (pos: int; stop, dn, up, opened: bool; LL, UL, DL: Flags); var LR, UR, DR, AR: Flags; RequestAbove, RequestBelow, StopWhileUp, StopWhileDn: bool; OnWayUp, StopUp, OnWayDn, StopDn: bool; let LR = LB -> OR(pre(LL), LB); -- lift request UR = UB -> OR(pre(UL), UB); -- up request DR = DB -> OR(pre(DL), DB); -- down request AR = OR(LR, OR(UR, DR)); -- any request RequestAbove = Above(pos, AR); RequestBelow = Below(pos, AR); StopWhileUp = At(pos, LR) or At(pos, UR); -- stop while moving up StopWhileDn = At(pos, LR) or At(pos, DR); -- stop while moving down pos = 0 -> pre(pos) + if pre(up) then 1 else if pre(dn) then -1 else 0; up = RequestAbove and not(onwaydn or StopUp); OnWayDn = sustain(false->pre(dn), not RequestBelow); StopUp = false -> pre(up) and StopWhileUp; dn = not up and RequestBelow and not(onwayup or StopDn); OnWayUp = sustain(false->pre(up), not RequestAbove); StopDn = false -> pre(dn) and StopWhileDn; stop = not up and not dn; LL = if stop then SwitchOff(pos,LR) else LR; UL = if up or stop and not RequestBelow then SwitchOff(pos,UR) else UR; DL = if dn or stop and not RequestAbove then SwitchOff(pos,DR) else DR; tel; 16