Programming with 1 Using tools This tutorial shows how to use the tool on a tiny program (the rising edge detector). You can indeed write your own program and experiment with it. 1.1 Writing the edge program is a data-flow language: each variable or expression denotes a (virtually infinite) sequence of values. As a first example, consider a sequence of Boolean value X = (X 0, X 1,..., X t,...). We whant to define, according to X, a sequence of Boolean values corresponding to the rising edges of X, i.e. such that Y t is true if and only if X t is true and X t 1 is false. Note that this definition does not hold for t 0, we must define also an initial value: by definition Y 0 is false. This specification can be easily translated in lustre: node edge(x : bool) returns (Y : bool); let Y = false -> X and not pre X; tel Write this node into a file edge.lus 1.2 Simulation The simpliest way to test/simulate a program is to use the graphical tool luciole. The arguments of the command must be: first the file name, second the node name (n.b. in general, a file may contain several nodes): luciole edge.lus edge tip: you can simply type luciole, a file/node browser will then appear to select the program. Luciole opens a simulation window (figure 1) containing a press-button for the input X, plus a label for the output Y (Booelan labels are displayed in red when the value is true, grey otherwise). Figure 1: Command : luciole edge.lus edge Clicking X makes the time pass with X = vrai. Clicking step makes the time pass with X = false. The result can be observed on the label Y. Timing diagrams (chronograms): The command Tools sim2chro 1 opens the timing-diagram displayer (figure 2). The dynamic behavior can be observed in a more convenient way. 1 Several versions may be available, typically a pure-x11 version, and a gtk-based version. They are equivalent, but may or may not work depending on the platform. 1
Figure 2: Chronogramme Boolean modes, auto-step vs compose : In the auto-step mode (default), clicking a Boolean input enforces the time to pass. This can be a problem, in particular for programs with several inputs (indeed, it is not the case here). The command Clocks Compose switches to the compose mode: Bolean inputs become check buttons, that can be selected/unselected without making the time pass. In this mode, it is necessary to press the Step button for enforcing the time to pass. Real-time clock: The commande Clocks Real time clock swithes to the auto-step mode: a step occurs automatically at each period of an internal clock (default 1000 ms). The period can be modified with Clocks Change period. 1.3 C code generation 1.3.1 Step by step Compilation requires several steps. The front-end transforms a program into a Kernel program, called expanded code: lus2ec edge.lus edge This command produces the edge.ec, which, in this case, is completly similar to edge.lus. C code generation is performed by the command: ec2c edge.ec -v The argument -v is just for making the compilation verbose. Almost all the tools presented here have a -v option. The results are: a file edge.c containing the step (transition) procedure, the corresponding header file edge.h containing in particular the definition of the program internal memory (called context structure). By default, the compiler only generates this reactive kernel. The user has to write his own main loop and input/output functions to concretly run the program. However, the compiler has an option -loop that generates an extra file: ec2c edge.ec -loop -v produces (in addition to edge.h and edge.c) a file edge loop.c that contains a main procedure, with all the glue code necessary to run the program in a file-to-file manner. For simple programs (like edge) the set of file is self-containt, and an binary code can be optained using (for instance) gcc: 2
gcc edge.c edge loop.c -o edge This command produces an exec file edge, that reads inputs on stdin and write outputs to stdout. 1.3.2 Shortcuts A shell-script is available for combining the compilation steps: lus2c edge.lus edge combines lus2ec and ec2c. lux edge.lus edge combines lus2ec, ec2c -loop and calls gcc. 1.3.3 Running C code within luciole Using luciole for simulation programs is much more convinient than using the stdin/stdout program obtained with ec2c -loop. The compiler has an option that produce the necessary glue for running the generated C program within the graphical interface. More precisely, this code must be compiled into a dynamic linked library (instead of an executable), using (for instance) gcc. Compiling dll may be somehow tricky, and a shell-script command is provided, that does the whole job: lus2dro edge.lus edge produces a file edge.dro that can be loaded into luciole: luciole edge.dro Running a.dro file in luciole gives exactly the same simulation as running the corresponding.lus program. The difference is inside:.dro files are executed, while.lus (or more precisely,.ec ) files are interpreted. 1.4 Compilation into automata 1.4.1 Step by step There exists a way for compiling a program into an explicit Mealy machine (i.e. automata where transitions are labelled with reactions). finite state The front-end is the same: lus2ec edge.lus edge and produces the file edge.ec. The command: ec2oc edge.ec generates the Mealy machine, in a particular format called oc, in the file edge.oc. This format can be translated into a C with the command: poc edge.oc The result is similar to the one obtained with ec2c: a code file edge.c and a header file edge.h. The poc command provides a -loop option equivalent to the one of ec2c. The full chain for optaning am executable edge is then: lus2ec edge.lus edge ec2oc edge.ec poc edge.oc -loop gcc edge.c edge loop.c -o edge 3
1.4.2 Shortcuts and options lus2oc edge.lus edge combines lus2ec and ec2oc. ec2oc (i.e. lus2oc) has numerous options (lus2oc -help to see them). Explaining all these options is out of the scope of this tutorial. 1.4.3 Visualization of automata with atg The interest of the automaton is not clear when the goal is just to simulate/execute the program. It is more precious when the goal is to check/analyse the behavior of the program. For small programs (and thus, hopefuly small automata), it may be very interesting to draw the corresponding automaton. We can use the tool autograph to visualize automata. Firat, use the following tool to generate the format suitable for autograph: lus2atg edge.lus edge This command produces a file edge.atg taht can loaded into autograph: atg edge.atg This command opens the graphical automaton explorer. Exloration is done with the mouse, in an intuitive clic/pull/release manner. Once fully explored, the result is the graph shown in figure 3. Figure 3: The edge automaton This figure summerizes all the possible behaviors of the program: From the initial state (double circle), if X is true, the program loops on this state, otherwise it enters the other state. The second state loops while X remains false, and when X becomes true, the output Y is emited (concretely it takes the true value), and the program returns to the initial state. 1.5 Formal verification The lustre toolset provides a tool dedicated to the formal verification of safety (invariant) properties. The user specify a set of properties that the program should satisfy, and the tool try to establish that these 4
properties hold for any execution of the program. The edge is very simple, and properties are likely to be trivial. The exercise is then not to find relevant properties, but rather to become familiar with the tool. We use xlesar, which is a gui above the real verification tool called lesar. First, select the file and the node to validate (button Browse ). Inputs/outputs variables are then displayed (figure 4). Figure 4: L outil xlesar The bottom part of the window is the property manager, showing the current list of properties, that allows to create New, edit Edit or remove Delete properties. The edit-property windows (figure 5) contains the name and the definition the property (left) and the verification launcher (right). Figure 5: Property editor/verifier The property must be a Boolean expression in. By default, the expression is true, which is trivially an invariant. We can try to check a less trivial property, which is informally the output cannot be true unless the input is true. This property can be formalized by stating that output implies input 5
is an invariant, that is, always true in any execution of the program. In syntax, this invariant is simply y => x. We can launch the verifier by pressing RUN PROOF. The result (in the dialog windows) is TRUE PROPERTY. A satisfied property: We try now to check a less trivial property, informally: output Y cannot be true twice in a row in any execution. The translation into a (expected) invariant is based in the following remarks: At the very first instant, there is nothing to check: the property cannot be violated since the past doest not exist. In any non-initial instant, if the output is true, then it must have been false just before. Finally, the invariant is: true -> (Y => not pre Y) We can then launch the verifier RUN PROOF ), and obtain (as expected) TRUE PROPERTY. Tips: select the Verbose to get informations on how the verification is performed. Try the same proof with different algorithms Enumerative, Symbolic forward, Symbolic backward etc.. Complexity of the proof: In verbose mode, one can deduce the complexity of the proof: in enumerative mode, the number of states (and transitions) is a relevant approximation of the complexity (4 and 8 in this example). in symbolic mode, the number of iterations is a good measurement (here 2 computaion steps either with forward or backward ). A false property: We now try to see what happens with a (clearly) false property, for instance: X => Y. Without options, we simply get FALSE PROPERTY. By checking first the Diagnosis option, we get a counter example, that is, a sequence of inputs that violates the invariant: DIAGNOSIS: --- TRANSITION 1 --- X In this case, the sequence is of length 1: the invariant is violated from the very first instant if the input X is true. When validating a program, it often occurs that the verification fails because of a lack of precisions in the formulation of the property. For instance, it is often the case that the expected property holds almost all the time, expected in some particular situations (typically the very first instant). We can try here to precise the property by stating that, except for the initial step, X implies Y. The modified invariant is then: true -> (X => Y). Here again, the verification fails, but with a longer counter-example: DIAGNOSIS: --- TRANSITION 1 --- X --- TRANSITION 2 --- X 6
Assertions: A more general and powerful way for specifying hypothesis is to use assertions. For instance, suppose that we want to express that the property (X => Y) holds under the condition that X is false at the first instant. This hypothesis can be expressed by the invariance of the expression (not X) -> true. Select the Edit/New assertion menu, type this assertion, and run the proof. Once again it fails, with a longer counter-example: --- TRANSITION 1 --- not X --- TRANSITION 2 --- X --- TRANSITION 3 --- X FALSE PROPERTY Indeed, the property (X => Y) is likely to be false unless stating very strong assumptions. Try for instance: X is always false X toggles (i.e. (not X) -> (X <> pre X) 7
2 Utilities The goal is to program a library of reusable utility operators in the file utils.lus. 2.1 Well initialized register Write and simulate a node jafter (just after): Input: x, Boolean Output: y, Boolean Function: y t true iif x t 1 exists and is true 2.2 Rising edge (strict) Write and simulate a node edge: Input: x, Boolean Output: y, Boolean Function: y t true iif x t 1 exists and is false, and x t is true Remarks: Falling edges of x are simply rising edges of x (edge(not x)). This is the strict version: if x is true initially, this is not considered as an edge. The weak version is obtained with x -> edge(x). 2.3 Two states automaton Write and simulate a node switch: Input: orig, on, off (Boolean). Output: state (Boolean). Function: output raise from false to true when on, falls from true to false when off. Behaves as state was equal to orig at the beginning. 8
3 Observers An observer of a property P is a program with a single Boolean output (e.g. ok) such that ok remains invariably true iff P holds. For instance: ok = (x => y); implements the property x cannot be true unless y is true too. ok = true -> (pre x => not x); implements the property x cannot be true twice in a row. Properties involving temporal intervals are useful. For instance: X must be true continuously between an occurrence of A and the next occurrence of B. X must be true at least once between an occurrence of A and the next occurrence of B. These properties are rather imprecise, more precisely: the intervals are not retriggerable, i.e. an occurrence of A between a A and the next B doest not start a new interval (similar to switch). the bounds are excluded, e.g. X must be true continuously (resp. once) between the occurrence of A excluded, and the next occurrence of B excluded. Propose an observer for those two properties, that is: once from to(x, A, B : bool) returns (ok : bool) always from to(x, A, B : bool) returns (ok : bool) 9
4 Car lights The goal is to write a controller of car lights. Commands are coming from a lever and buttons. Lights are side lights, low lights and high lights (figure 6). The lever can be turned left or right or pulled (and released): lever steering wheel TL TR LH Figure 6: Board control 4.1 Behaviour from the state all lights off, the user can turn left the lever and set the side lights, another turn left switches off the side lights and sets the low lights, in low or high light state, pulling the lever switches from low to high, in low or high light state, turning right switches pulling the lever switches between low and high, turning right in low/high state returns to side lights, turning right in side state returns to all lights off. 4.2 Inputs and outputs Inputs: 3 Boolean variables, TL, TR and LH, representing turn left, turn right and low/high. Outputs: 3 Boolean variables, representing the state of the lights side, low and high. 4.3 Question Write and simulate a car light controller in. 10
5 Car lights (extended version) We add to the specification two new lights: fog lamps are selected using a check button, and are effective only with low lights, long-range lamps are selected using a check button, and are effective only with high lights. The new inputs are FL and LRL, the new outputs are fog, long (Figure 7), plus two Boolean indicating whether fog and long-range lamps are selected. lever steering wheel TR TL LH FL LRL Figure 7: Board control 5.1 Behaviour The behaviour of lever is unchanged. Fog lamps are selected (unselected) by pressing FL. Similarly for longrange and LRL. When selected, the corresponding indicator diode is set (fog select and long select). When selected, fog lamps (resp. long-range) are actually switched on only in low mode (resp. high mode). 5.2 Question Write and simulate the extended controler. 5.3 Verification Check, using Lesar (or xlesar), the following properties: Side, low and high lights are exclusive. Fog lamps are effective only with low lights. Long-range are effective only with high lights. Remark: some assumptions will certainly be necessary, try to find a set of assertions as weak as possible. 11