Cyber Physical System Verification Seminar: Event-B

Transcription

1 Cyber Physical System Verification Seminar: Event-B Sebastian Schumb University of Kaiserslautern Embedded Systems Group s schumb10@cs.uni-kl.de 1 Introduction A Cyber-physical systems is a system of computer hard and software used to control a physical entity. In contrast to a traditional embedded system a cyber-physical system usually has a more intense link between the controlled physical outputs, the monitored physical inputs and the controller. Additionally the controller can consist of more then piece of hardware leading to a rather distributed system. The purpose of this paper is to evaluate the capabilities of the modeling language Event-B for verifying a system, which is specified in the Quartz programming language. The following sections of this document contain a short introduction into Quartz, Event-B and the tools, which are required to work with them. 1.1 Quartz The listing below contains simple example for a Quartz module. 1 module ABRO( e v e n t? a,? b,? r,! o ) { 2 loop 3 a b o r t { 4 {wa : a w a i t ( a ) ; wb : a w a i t ( b ) ; } 5 emit ( o ) ; 6 wr : a w a i t ( r ) ; 7 } when ( r ) ; 8 } s a t i s f i e s { 9 p r o p e r t y 0 [ DisProveA ] : a s s e r t A G ( o > a ) ; 10 p r o p e r t y 1 : a s s e r t A G ( o > a b ) ; 11 p r o p e r t y 1 a : a s s e r t A G! ( r & o ) ; 12 p r o p e r t y 2 : a s s e r t A G ( o > [ a PWB r ] & [ b PWB r ] ) ; 13 / / p r o p e r t y 2 a : a s s e r t A (G ( r > X ( [ [! o WU a ] & [! o WU b ] WU r ] ) ) ) & X ( [ [! o WU a 14 p r o p e r t y 3 : a s s e r t A G ( o > X! o ) ; 15 } This example can be compiled into an xml-based aifs-file, which represents the modules behavior with synchronous guarded actions. Using the aifs2txt utility, the xml-based aifs-files can be transformed in a more human readable text form. Invoking aifs2txt yields the following output for the above example (which was shortened here to the relevant parts) : 1 system ABRO: 2 i n t e r f a c e :

2 2 3 a : i n p u t e v e n t bool 4 b : i n p u t e v e n t bool 5 r : i n p u t e v e n t bool 6 o : o u t p u t e v e n t bool 7 l o c a l s : 8 i n i t : l o c a l memorized bool 9 wa : l a b e l bool 10 wb : l a b e l bool 11 wr : l a b e l bool 12 i n i t : 13 c o n t r o l flow : 14 d a t a flow : 15 a s s e r t i o n s : 16 main : 17 c o n t r o l flow : 18 i n i t => n e x t ( wa ) = True 19 i n i t => n e x t ( wb ) = True 20! r &! r&wa&!a r&wr r &(wr wa wb ) => n e x t ( wa ) = True 21! r &! r&wb&!b r&wr r &(wr wa wb ) => n e x t ( wb ) = True 22! r &! r&wr&! r! r &! r &(a&wa&b&wb! wa&b&wb! wb&a&wa ) => n e x t ( wr ) = True 23 d a t a flow : 24! r &(a&wa&b&wb! wa&b&wb! wb&a&wa ) => o = True The state of the system is encoded in the three local variables wa, wb and wr. A good example for guarded actions evaluated in parallel can be found in line 20 and 21. If any of those variable is True and the input r is true as well, both guarded actions in line 20 and 21 will be executed simultaneously setting wa and wb to True in the next step. 1.2 Event-B There are many different approaches in software development to simplify the way a software system is modeled and verified. One of them is the B-method, a so called formal method for modeling and verification of software. A supporting tool which is used in this context is the mathematical modeling language B. B allows a developer to model a system in abstract machine notation, which is then used to verify the system. Event-B is considered a evolution of the B language. It provides an easier notation as well as better tool support through the Rodin tool, a fork of the eclipse IDE. It was developed as a part of the Deploy project, an EU funded Information and Communication Technologies FP7 project. The not for profit company Rodintools will be responsible for further development of the software, after the EU funding ends. A model in Event-B consists of three main components: machines, contexts and refinements. The behavior of a system is specified as a machine, which is basically a special form of an extended finite state machine. Since it is possible to describe a different aspects of a systems behavior using separate machines, contexts can be used to provide an common environment for these machines. Refinements are used to ensure consistency between different versions of a machine, if machine is modeled using an incremental approach, as suggested by the B-Method.

3 Machines A machine in Event-B is a special form of a finite state machine. It s state is kept in a set of variables. Events are used to change these variables and thus change the state of the machine. An event is specified by a list of conditions, which are also referred to as guards in the Event-B terminology and a list of actions. If the conditions are met, the event can fire and its actions are executed changing the state of the machine. It is also possible to specify event parameters for an event, which can then be used in the conditions and actions. Parameters serve as an interface through which a machine can receive input from the outside world. A machine is also required to have a set of invariants. An invariant in Event-B is a conditional statement using first order predicate logic, which has to evaluate to true in every state reachable for the machine. When using the Rodin tool to edit a machine, this is checked automatically by the ProvB theorem solver. If an violation is detected the user informed via an error message, similar to a compiler error when using Eclipse. It is also possible to use Rodins proofing perspective to further analyze the violation Contexts A context contains a common environment for multiple machines. It may contain carrier sets, constants, axioms and theorems. If a machine sees a context all definitions inside the context will be used by the theorem prover for verifying a machine. Carrier sets are special sets, containing all possible states for a variable in the model. E. g. in model for traffic lights a appropriate carrier set may be Colors := {RED,Y ELLOW, GREEN}. The value of variable inside a machine can the be restricted to elements of a carrier set, using invariants like lightcolor Colors. Axioms can be specified as predicates in the axiom part of a context. They are usually used to provide additional informations about carrier sets, like relations between members. E. g. for a carrier set defining a set of coins, like coins := {2euro,1euro,50cent,10cent}, a is bigger relation might be of use. A first axiom can be used to define is bigger as relation on coins : axiom1 : is bigger coins coins. Since no coin is bigger then itself, an axiom marking the relation as irreflexive is needed: is bigger id =. Also the relation is transitive : axiom2 : ( x,y,z (x y is bigger y z is bigger)) (x z is bigger) Further axioms like axiom3 : 2euro 1euro is bigger can be used to specify the concrete relation between the set members. The prover will not try to proof axioms, but it will take them for granted in other proofs. Axioms marked as theorems are an exception to this, since the prover will try to prove them using any previously defined axioms and theorems. If this fails an error is reported to the user. This feature can be used to check assumptions, like theorem1 : 2euro 10cent is bigger, about the axioms previously defined. A context can also be specified as an extension of an other context, using the extends keyword Refinements Refinements are an other important part of a Event-B model. In the work flow, suggested by the B- methode, modeling starts with a rather abstract model of the system. This model usually consists of an so called abstract machine and an abstract context. Using the refinement mechanism of the Event-B modeling language, details can then be added to the abstract machine and the abstract context, leading to a more detailed model. The model with most details, which is referred to as concrete model, is usually gained via multiple refinement steps. In order to ensure that a model is a correct refinement of a an

4 4 abstract model, the prover needs additional information about which events in the refined machine correspond to which event in the more abstract machine. This information can be provided using the witnesses section of an event. Witnesses are predicates that indicate how a parameter in the abstract event can be mapped into parameters of the new event. Since the model obtained from Quartz is already a concrete model of a system, specifying refinements is not necessary and therefore not further discussed in this document. 1.3 Rodin Rodin, short for Rigorous Open Development Environment for Complex Systems, is an integrated development environment derived from the widely used eclipse IDE. The Rodin tool allows the editing of definitions for machines and contexts, as well as running the theorem prover and displaying results. More feature can be added using plugins. The basics installation of the Rodin tool provides two eclipse perspectives. The first perspective is the interactive editor for machine and context models. It performs automatic Figure 1: Machine editor perspective checks for type-correctness and well-formedness of statements and provides immediate feedback to the user. Editing is done using a special graphical editor, since the Event-B language requires a rather mathematical notation, using special symbols like, which are not easy to access with normal keyboard based input methods. The data will then be saved in an xml-format, which is less human readable then the representation provided by the graphical editor. Also the saving of a model will automatically generate proof obligations for a model, using the invariants and the events in the machine, as well as the theorems and axioms from the machines context. These proof obligations are then discharged automatically using the theorem solver. If the discharging fails for some reason, a list of found problems is generated and presented to user, similar to the list of compiler errors when using eclipse for Java or C++. The user can use this list to load undischarged obligations in

5 5 the proofing perspective for further investigations. The second perspective implemented is the interactive proofing perspective. In this perspective the user Figure 2: Proof obligation in proofing perspective can manually discharge the proof obligations generated for a model. Usually this perspective is also used to view and debug the proofs generated by automated provers. Other features are provided by plugins, which have to be installed separately Atelier B Provers The atelier B provers are the successors for the B4free provers. Provers are use to discharge proof obligations automatically where ever possible. Being optimized for set theory and first order logic the atelier B provers, are recommend provers to use with the Roding tool ProB The ProB plugin provides a third eclipse perspective that can be used for model animation. Model animation allows a user to set event parameters and fire the events of machine, while simulating the machines behavior. In a complex machine it is not alway trivial to understand the sequence of events leading to the violation of an invariant. Even though inspecting the proof obligation can reveal its source, it is often easier to understand the problem by skipping through the sequence in the model animation. A second application for the animation perspective is to understand to behavior of a foreign model. While the possible changes to a state can be trivially derived from the event specification, it is often not obvious in which state a certain event can be triggered. In this situation experimenting with a model in the animation perspective can provide valuable insights in the behavior of a model.

6 ProB - Disprover The ProB disprover is an experimental addition to the atelier B provers. Discharging a proof obligation is mostly done by weakening or strengthening invariants and guards. Generally there are two common reasons that require a proof obligation to be discharged manually. The first cause is a to weak guard. A to weak guard for an event can lead to an invalid state, which is forbidden by an invariant. In this case a stronger guard is needed to discharge the proof obligation. Alternatively a to strong invariant may contradict with valid states. This would require a weaker invariant for the proof obligation to be discharged. An other possible cause for a proof obligation, which can t be discharged by the automatic prover, is that an unspecified state can be reached. In this case the state is invalid due to being no part of the model. Using a disprove the user can generate variable assignments, which violate an invariant. This simplifies the solution of the above problems, especially for inexperienced users. 2 Translation of the Examples Translating a given Quartz module with its properties into an Event-B machine and verifying it properties requires basically 6 steps. It is assumed that the Rodin tools machine editor is used to perform the steps, presented in the following section. As a first step the aifs-file generated from the Quartz has to be transformed in an EFSM as described in Section 2.1. Then a new Event-B machine can be created and the variables from the Quartz module can be added to it. The measures required to translate variables from Quartz to Event-B are explained in Section 2.2. Special care is required when translating the boolean logic as part of guarded actions into the predicate logic needed for Event-B. The necessary transformation is discussed in Section 2.3. Having transformed the guards, the guarded actions can be rewritten into events for the Event-B machine. See Section 2.4 for further details. Section 2.5 explains how the properties can be translated into the syntax required by Event-B. As a last step the properties can the be verified using the prover included in the Rodin tool. This procedure is described in Section Transforming to an EFSM Modules specified in Quartz and compiled into an aifs-file usually consist of a set of variables and a set of guarded actions for control and data flow, similar to a machine in Event-B. The main difference to an Event-B machine is, that in Quartz all guards are checked in parallel and all actions with guards activated are executed in parallel as well. Event-B only supports evaluating one event at a time. Hence translating guarded actions directly into an Event-B machines events would result in a different behavior. E. g. in the example in Section 1.1, prover would assume that the events, resulting from line 20 and 21, are evaluate after another, leading to an intermediate state where r is still true but either wa or wb has not been set to True yet. This state is not possible in the original model and will therefore violate the specification. Therefore the guarded actions in the aifs-file need to be transformed in a sequential representation first. This can be done using the aifs2aifs tool included with the averest tool chain. a i f s 2 a i f s t efsm i n p u t. a i f s o u t p u t. a i f s

7 7 This transformation will introduce a state variable and combine the guarded actions into transitions for an efsm. Applying the efsm transformation to the example from Section 1.1 before exporting the system into the text format results in the following listing: 1 system ABRO: 2 i n t e r f a c e : 3 a : i n p u t e v e n t bool 4 b : i n p u t e v e n t bool 5 r : i n p u t e v e n t bool 6 o : o u t p u t e v e n t bool 7 l o c a l s : 8 s t a t e : l a b e l n a t {65536} 9 i n i t : 10 c o n t r o l flow : 11 True => n e x t ( s t a t e ) = 1 12 d a t a flow : 13 a s s e r t i o n s : 14 main : 15 c o n t r o l flow : 16 r& s t a t e ==4 => n e x t ( s t a t e ) = 1 17 a&! r& s t a t e ==4 => n e x t ( s t a t e ) = 2 18! a&! r& s t a t e ==4 => n e x t ( s t a t e ) = 4 19 r& s t a t e ==3 => n e x t ( s t a t e ) = 1 20 b&! r& s t a t e ==3 => n e x t ( s t a t e ) = 2 21! b&! r& s t a t e ==3 => n e x t ( s t a t e ) = 3 22 r& s t a t e ==2 => n e x t ( s t a t e ) = 1 23! r& s t a t e ==2 => n e x t ( s t a t e ) = 2 24 r& s t a t e ==1 => n e x t ( s t a t e ) = 1 25 b&a&! r& s t a t e ==1 => n e x t ( s t a t e ) = 2 26! b&a&! r& s t a t e ==1 => n e x t ( s t a t e ) = 3 27 b&!a&! r& s t a t e ==1 => n e x t ( s t a t e ) = 4 28! b&!a&! r& s t a t e ==1 => n e x t ( s t a t e ) = 1 29 d a t a flow : 30 a&! r& s t a t e ==4 => o = True 31 b&! r& s t a t e ==3 => o = True 32! r&a&b& s t a t e ==1 => o = True The state of the system is now encoded in the integer state000 and all guards are now mutually exclusive. A very good example for this is the state 4, which only allows the guarded actions in line 16,17 and 18. Factoring out state000==4 from each guard yields r, a r and ā r which are obviously mutually exclusive. It also important to notice that in this example the dataflow guards are all equal to controflow guards. Therefore these guarded actions can later be merged into a single event in the Event-B machine, that contains all their actions. This is of course not always the case, more advance models can contain guarded actions, which do not depend on external inputs, e. g. counters for timeout.

8 8 An other possible case is that variable assignment required for a dataflow guard to evaluate to True is a subset of the assignment required by more then one controflow guard. In this case the guarded action in the dataflow region, is execute in paralell with each of these controflow actions. Therefore its actions needs to merged in each event of the Event-B machine, corresponding to those controflow actions. 2.2 Transforming the Variables To add a new variable to an Event-B machine, two steps are required. First the name for the new variable has to be added to the variables block at the beginning of the machine specification. The the type of the variable has to be specified. Since Event-B uses a set-theoretical approach to variables and data types, this is done by adding a invariant that defines the variable as member of a carrier set. This carrier set can either be one of the predefined sets, usually N, Z, R and BOOL, or a set defined in a context seen by the machine. There are 3 possible cases for transforming a variable from the EFSM. For local variables in the Quartz system simply adding a local variable and invariant, defining the variable as an element of a carrier set, corresponding to the data type in Quartz is sufficient. Finite datatypes like nat{3} require an additional invariant that defines bounds for the variables. Special care must been taken for event variables. In Event-B all variables preserve their value until it is explicitly altered, whereas in Quartz this applies only to variables declared as memorized. Variables declared using the event-keyword preserve their value only for a single macro step. This causes the variable to be reset to 0 or False if it is not explicitly set in a macro step. To emulate this behavior in Event-B, any event, that does not explicitly assign a value to variable, must set this variable to 0 or FALSE with respect to its data type, which can be trivially accomplished by adding a corresponding assignment action to those events. The third case is a variable that is declared as an input to the quartz module. In contrast to Quartz modules an Event-B machine does not have a global set of inputs variables. Instead each event has an own set of local parameters, that act as inputs for this specific event only. As a consequence each event can have its own set of inputs and it is not possible to refer to event parameters in invariants. Invariants are statement required to hold for every state, whereas event parameters only exist during transitions from one state into an other. Quartz on the other hand allows to refer to module inputs, when specifying the properties used for verification. A simple way to work around this different concepts is to simply copy all event parameters to the machines variables for each event. This can be accomplished by declaring an machine variable for each module input. Then each event will need a corresponding event parameter for each input, and the input value has to be copied to the machine variable in the events action block. The following listing contains a Quartz module with 2 actions, q as an input variable and p as an ouput variable. 1 system ABRO: 2 i n t e r f a c e : 3 q : i n p u t e v e n t bool 4 p : o u t p u t e v e n t bool 5 i n i t : 6 c o n t r o l flow : d a t a flow : a s s e r t i o n s :

9 main : 13 c o n t r o l flow : => p = True =>... This example can be translated into a Event-B machine using workaround explained previously. The syntax used for this examples is adapted from the draft book System Modelling & Design Using Event-B [4]. 1 MACHINE i n p u t e x a m p l e 2 VARIABLES 3 q 4 p 5 INVARIANTS 6 q BOOL 7 p BOOL 8 EVENTS 9 I n i t i a l i s a t i o n = 10 THEN 11 a c t 1 : q := FALSE 12 a c t 2 : p := FALSE 13 END e v t 1 = 16 ANY 17 new q 18 WHERE 19 grd1 : new q BOOL 20 grd2 : THEN 22 a c t 1 : q := new q 23 a c t 2 : p := T RUE 24 END e v t 2 = 27 ANY 28 new q 29 WHERE 30 grd1 : new q BOOL 31 grd2 : THEN 33 a c t 1 : q := new q 34 a c t 2 : p := FALSE 35 END 36 END

10 10 Note that all parameters in Event-B machines derived from Quartz modules, are derived from module inputs. Therefore they will have their variable names prefixed with new in further examples for better readability. 2.3 Transforming the Guards Having added the variables to Event-B machine, the next step is to create Event-B events from the guarded actions. There are multiple issues to take care of for translating guarded actions from Quartz Modules, to Event-B events. A guard found in the text file generated by aif2txt uses the same syntax as the Quartz language itself uses for boolean expressions. The main difference between Averest and Event- B is that Event-B uses predicate logic, whereas Averest uses boolean logic to express guards. Since the conjunction, disjunction and negation-operator is only defined on predicates and not on boolean variables, every boolean variable has to be translated into a predicate for Event-B. This is done by replacing every occurrence of a variable a in a boolean expression, with (a = T RUE). E. g. a & b becomes (a = T RUE) (b = T RUE). Additionally the notation for most operators in Quartz differs from the one used in Event-B. The interactive editor of Rodin requires the usage of special ASCII characters, like instead of & and!. Therefore the operators in the guards obtained from the Quartz module need to be translated into their Event-B equivalents. See Table 1 for a more detailed comparison between the two notations. Quartz Event-B Meaning a & b p a p b Disjunction a b p a p b Conjunction!a p a Negation e a == e b e a = e b Equality a = e b a := e b Assignments Table 1: Operators in Quartz and Event-B An other issue that needs to be addressed when converting guards between Quartz and Event-B, is the operator precedence. In Quartz the & has a higher precedence then the operator, whereas in Event-B the precedence of both operators is equal. This requires the addition of new parentheses to the guard in Event-B. E. g. the XOR function can be written in Quartz without any parentheses: a&!b!a&b. If this same is done in Event-B: (a = T RUE) (b = T RUE) (a = T RUE) (b = T RUE) the prover can not decide on how to group the expression into subexpression for evaluation. An error will be displayed by the editor, when attempting to save a machine containing the above expression. This issue can be resolved by adding the required parentheses : ((a = T RUE) (b = T RUE)) ( (a = T RUE) (b = T RUE)). The last step for translating the guard is to use event parameters where needed. As discussed in Section 2.2, input variables are translated into event parameters and machine variables. Guards must use the event parameters and not the machine variables for input variables, since otherwise it would be impossible to trigger events using external input to the machine. Therefore every input variable in guards has to be substituted with its corresponding event parameter. An extended version of the above example including a simple local variable could look like this : a&!b!a&b l where a and b are input variables and l is local variable. In Event-B the new example

11 11 would result in this guard: ((new a = T RUE) (new b = T RUE)) ( (new a = T RUE) (new b = T RUE)) (l = T RUE). 2.4 Transforming the guarded actions After the guards are rewritten into a format that is accepted by the Event-B prover, the guarded actions can be translated into Event-B events. In the AIF representation there is distinction between guarded actions responsible for control flow and data flow. This distinction is not present in an Event-B machine. The control flow region can easily translated into events, by creating an appropriate event for each guarded actions, transforming the guards as discussed in Section 2.3 and adding the parameters derived from input variables as mentioned in Section 2.2. When transforming the guarded actions inside the data flow region into events, some additional issues need to be addressed. As mentioned before in Section 2.1, there are two possible cases to be considered Fully identical guards The first case is that the variable assignment which triggers the action is exactly identical with the one required to trigger a control flow action. In this case both actions can be trivially merged into a event with two actions. An Example where a and b are input variables: 1 c o n t r o l f l o w : 2 a &! b => n e x t ( s t a t e ) = 4 3 d a t a f l o w 4 a &! b => n e x t ( ouput ) = f a l s e The above example translated into Event-B code: 1 e v t 1 = 2 ANY 3 new a 4 new b 5 WHERE 6 grd1 : new a BOOL 7 grd2 : new b BOOL 8 grd3 : (new a = T RUE) (new b = T RUE) 9 THEN 10 a c t 1 : state := 4 11 a c t 2 : out put := FALSE 12 a c t 3 : a = new a 13 a c t 4 : b = new b 14 END Partly identical guards The second case possible is that a guard in the data flow has no directly corresponding guard in the control flow region, but the variable assignment that triggers it, is a subset of the variable assignment

12 12 required to trigger one or more guards in the control flow region. In this case the data flow action needs to be added to all events derived from these control flow actions. A modified version of the previous example: 1 c o n t r o l f l o w : 2 a &! b => nex ( s t a t e ) = 4 3 a & b => n e x t ( s t a t e ) = 5 4 d a t a f l o w 5 a => n e x t ( ouput ) = f a l s e The modified example translated into Event-B: 1 e v t 1 = 2 ANY 3 new a 4 new b 5 WHERE 6 grd1 : new a BOOL 7 grd2 : new b BOOL 8 grd3 : (new a = T RUE) (new b = T RUE) 9 THEN 10 a c t 1 : state := 4 11 a c t 2 : out put := FALSE 12 a c t 3 : a := new a 13 a c t 4 : b := new b 14 END e v t 2 = 17 ANY 18 new a 19 new b 20 WHERE 21 grd1 : new a BOOL 22 grd2 : new b BOOL 23 grd3 : (new a = T RUE) (new b = T RUE) 24 THEN 25 a c t 1 : state := 5 26 a c t 2 : out put := FALSE 27 a c t 3 : a := new a 28 a c t 4 : b := new b 29 END A special form of this case occurs, when a data flow action depends the state variable and not on external inputs. E. g. a system waiting for input while using a counter to implement a timeout. In this case the data flow action has to be merged with a large number of events. The first example in an other modified version: 1 c o n t r o l f l o w : 2 a &! b & s t a t e = 4 => n e x t ( s t a t e ) = 5

13 13 3 a & b & s t a t e = 4 => n e x t ( s t a t e ) = 7 4 d a t a f l o w 5 s t a t e = 4 => n e x t ( c o u n t ) = c o u n t 1 The Event-B code for this example: 1 e v t 1 = 2 ANY 3 new a 4 new b 5 WHERE 6 grd1 : new a BOOL 7 grd2 : new b BOOL 8 grd3 : (new a = T RUE) (new b = T RUE) (state = 4) 9 THEN 10 a c t 1 : state := 5 11 a c t 2 : counter = counter 1 12 a c t 3 : a := new a 13 a c t 4 : b := new b 14 END e v t 2 = 17 ANY 18 new a 19 new b 20 WHERE 21 grd1 : new a BOOL 22 grd2 : new b BOOL 23 grd3 : (new a = T RUE) (new b = T RUE) (state = 4) 24 THEN 25 a c t 1 : state := 7 26 a c t 1 : counter = counter 1 27 a c t 2 : a := new a 28 a c t 3 : b := new b 29 END In any case the action itself generated by aifs2txt do not use the syntax used by Event-B. Therefore the actual action has to transformed in a similar manner then the guards. Simple assignments can rewritten using the := operator as shown in Table 1. E. g. next(state) = 4 becomes state := 4. This only works if the right hand side operant is either an arithmetic expression or constant, which is a member of carrier set that can be seen by this machine. Since Event-B does not directly support boolean logic, assignments like a = b c can not be made. The only valid right hand side expressions for assigning to boolean variables are TRUE and FALSE. Therefore guarded actions containing such assignments need to split in two events, where one has an assignment of FALSE and the other one assigns TRUE. It is also important to notice that Event-B does not implement an equivalent to the next statement. An assignment to a variable in Event-B can not alter the value in the current step. All changes will be applied after all actions of an event have been evaluated. Therefore all assignments in Event-B implicitly work like assignments using next. This might lead to problems in some cases, where immediate assignments

14 14 are required. Since invariants are only checked for the state after the evaluation of an event, in some cases assignments without next can be translated the same way, then assignment with next, without violating invariants. If this is not possible, a workaround can be implemented by adding additional states to the machine. 2.5 Transforming the properties The last step needed to verify the Quartz module using Event-B is to rewrite the properties into invariant for the machine generated in the previous steps. In Quartz the properties are specified using temporal logic, which is not implement in Event-B. Theoretically it is possible to implement some temporal operators by inserting additional intermediate states into the machine, but this would lead to an exponentially growing state space, which would make the machine very difficult to understand and to debug. Also if the original Quartz module violated a property, the violation would result in a large number of prove obligations, requiring a lot of time and effort to track down the actual problem. An another feature often used in used in properties specified in Quartz, is the ability to disprove properties. Even though there is a disprover plugin for the Rodin tool, it is not possible to explicitly specify a an invariant that should be disproved. An example for a properties the requires disproving may look like this : [DisProveA] : assert A G (o > a);. In this example the assertion that o a holds henceforth (G operator) for all computations paths (A operator: universal path quantifier). Disproving this assertion requires to prove that at least one path exists that contradicts o a. This can t be achieved using the invariant checking as implemented in Event-B. In conclusion the only properties that can be verified have the form assert A G < boolean statement >. Again it is required to translate the boolean statement found in the property into predicate logic. For this translation the same rules as described in Section 2.3 have to applied. The assert-statement and the A and G operators can be dropped, since only the translated boolean statement is used in the invariant. The following example contains multiple properties specified in the Quartz language: 1 s a t i s f i e s { 2 p r o p e r t y 0 [ DisProveA ] : a s s e r t A G ( o > a ) ; 3 p r o p e r t y 1 : a s s e r t A G ( o > a b ) ; 4 p r o p e r t y 1 a : a s s e r t A G! ( ( r c ==0) & o ) ; 5 p r o p e r t y 2 : a s s e r t A G ( o > [ a PWB ( r c ==0)] & [ b PWB ( r c = = 0 ) ] ) ; 6 p r o p e r t y 3 : a s s e r t A G ( o > X! o ) ; 7 } The properties 0,2 and 3 can t be translated into Event-B since they either contain temporal logic or use the Disprove keyword. The remaining properties 1 and 1a can be translated into Event-B: 1 INVARIANTS : 2 p r o p e r t y 1 : (o = T RUE) (a = T RUE) 3 p r o p e r t y 1 a : (((r = T RUE) (c = 0)) (o = T RUE)) 2.6 Verifying the properties After the original Quartz module have been translated into an Event-B machine and the properties have been translated into invariants where possible, the properties can finally verified using Event-B. This is done automatically in the background, whenever the machine is saved in the machine editor. A result where all invariant have been verified without undischarged prove obligations can be found in Figure 3.

15 15 Figure 3: The machine has been saved without generating undischarged prove obligations If there were any undischarged proof obligations a brown P would be shown in the Event-B explorer, instead of the green check markers. In this case either one of the properties can t be satisfied or the machine contains errors. If there is an undischarged proof obligation, the ProB Disprover can be used to find the conflicting variable assignment. Then the animation perspective provided by the ProB plugin can be used to further track back the problem. 3 Problems and Limitations The approach to verifying Quartz modules presented in this document has several limitations. The first problem with this approach is that one of the most powerful features of Event-B is not used at all: Refinements. The usual process that leads to model in Event-B, involves using the B-Methode to model a system. Therefore Event-B and in consequence the Rodin tool was developed to be used in this context. Usually a developer starts with a rather simple abstract model and uses refinements to incrementally add complexer aspects to it. The final model will then be implemented in the actual programming language. Using Event-B in the way described in this document, the user will not derive a model from the actual implementation and he will furthermore have no real use for refinements. The second drawback that Event-B can not directly implement synchronous guarded actions, since its events are evaluated in a sequential manner. While it is possible to circumvent this problem using the EFSM transformation provided by the aifs2aifs tool, the transformation will add an new level of abstraction and complexity to the original system. Even simple examples can easily result in more then 10 events, which unnecessarily increases the effort for debugging problems. Additionally Event-B has no explicit concept of steps or time. It rather assumes that a machines events occur in sequential manner, creating an implicit concept of steps. As a consequence operators like next()

16 16 can not be converted directly into Event-B. Even though an workaround can be found by adding intermediate states or using more variables, this is again a significant increase in complexity. Also it might not always be possible to find such workarounds. An other obstacle when translating a Quartz module into an Event-B machine are the different approaches to logic used in Quartz and Event-B. Being developed with a focus rather on abstract modeling, then on actually implementing software or hardware, Event-B uses a first order predicate logic for its guards and actions where as Quartz uses boolean logic. Converting between these two as explained in Section 2.3 lead to more complicated expressions, which are harder to read for humans. Also the differences in operator precedences makes it difficult to write an automated tool for this conversion, since a simple textual replacement does not suffice. An other feature present in Quartz, but missing in Event-B is support for temporal logic. In Quartz the properties can contain operators like PWB (weak past before) or X (next), that can be used to refer to future or past system states inside properties. Again it be possible to find a workaround for this issue, but it would add a enormous amount of complexity. The last issue does not concern the Event-b language itself, but the machine editor included in the Rodin tool. While the WYSIWYG editor is helpful for viewing machines, it causes several problem when editing. In contrast to normal text editor, with one large editor field, the graphical machine editor uses ready made text blocks with many small edit fields in between. As a result the users is forced to use the mouse to skip between fields, which slows down work unnecessarily. There is also a feature to collapse and expand certain regions of machine definition, which is, while useful for overview reasons, but obstructive for reading a machine event by event. Additionally events are autocollapsed at the most inconvenient times. Also editing multiple events becomes a very labor intensive task, since well known operations from normal text editor like copy and paste or search an replace are not really well implement, forcing the user to change each event manually. 4 Conclusions and Results Event-B is powerful tool for creating and verifying models. When used within the B-Method it provides an fast and intuitive way to model greater systems and to refine these models. Even though the user interface of the Rodin tool does not always work flawlessly, the prover in the backend is capable of handling complex models and provides well readable output. Additionally the ProB animation and disprover plugins can dramatically speed up the process of tacking down problem within a model, which cause undischarged proof obligations. Unfortunately documentation regarding Event-B and the Rodin tool is rather scattered over multiple websites and papers, which makes it hard for beginners to find a starting point to learn Event-B. While it is possible to check properties for Quartz modules using Event-B and the Rodin tool, this approach has several drawbacks. First Quartz heavily relies on the concept of synchronous guarded actions, which are execute in parallel. Since Event-B models a rather based on a finite state machine it is required to the module transform between the two. The resulting EFSM is usually larger and more complex then the original Quartz module, making it harder to understand its behavior. This also causes difficulties when tracking problems occurring during verification back to the Quartz source in order to fix them. Furthermore the concept of variables and scopes is slightly different to Quartz, therefore additional actions have to added to each Event-B, again resulting in extra work for the user and in further obfuscation of the systems behavior. Due to all this modifications and workarounds required during the conversion special care is needed to ensure that the converted system is still a valid representation of the original.

17 17 Additionally Event-B does not support temporal logic, which is an often used feature in Quartz for specifying the properties to be checked. Therefore only a few, if any, properties can be checked using the Rodin tool. In some cases it might be possible to find a workaround, but this will again result in additional work and complexity. In conclusion Event-B is suitable for verifying simple properties for simple Quartz modules. For complexer systems the work required for the conversion and the trouble dealing with the increased complexity of the resulting model outweighs the possible benefits. References [1] Jean-Raymond Abrial, Michael Butler, Stefan Hallerstede, ThaiSon Hoang, Farhad Mehta & Laurent Voisin (2010): Rodin: an open toolset for modelling and reasoning in Event-B. International Journal on Software Tools for Technology Transfer 12(6), pp , doi: /s y. Available at dx.doi.org/ /s y. [2] Michael Butler & Stefan Hallerstede (2007): The Rodin Formal Modelling Tool. Available at http: //eprints.soton.ac.uk/264949/. [3] Ken Robinson (2010): A Concise Summary of the Event B mathematical toolkit. Available at event-b.org/images/eventb-summary.pdf. [4] Ken Robinson (2011): System Modelling & Design Using Event-B. [5] K. Schneider (2009): The Synchronous Programming Language Quartz. Internal Report 375, Department of Computer Science, University of Kaiserslautern, Kaiserslautern, Germany.