Combining Theorem Proving and Model Checking in the Safety-Critical Software Development through Translating Event-B to SMV

Model checking and theorem proving are two key vertification techniques in the formal method, but each has its advantages and disadvantages. In this paper, we first try to present the general model transformation rules from Event-B to SMV in order to realize complementary advantages, and then design the model converter of Event-B to SMV according to the rules. ProB is the only tool to implement Event-B model checking, but it lacks the real-time property verification, while nuXmv is able to verify temporal logic formulas with the real-time property for SMV models. After completing the model transformation, we use ProB and nuXmv to make the verification of LTL and CTL formulas for two equivalent models respectively. Compared to the experimental results, in solving the same problem, nuXmv has more advantages over memory consumption, time efficiency and so on than ProB, especially when the formula to be verified is very complex. Therefore, if complex verifications of system models need to be performed, it is necessary to implement the model transformation between Event-B and SMV by using our translation rules, which is of great significance for the development, design and verification of safety-critical system softwares.


Introduction
Formal verification method can be divided into two broad categories: model checking and theorem proving. The advantage of model checking is that it can be automated and provide counterexample paths when a specification is discovered to be false; the disadvantage is that if the system has a high degree of concurrency, there exists a state explosion problem, moreover it generally can not verify the system with infinite states. Theorem proving uses mathematical reasoning and logic inference to prove the system correctness. Its advantage is that the model to be proved is independent of system states, so it has the ability to verify the system with infinite states; the disadvantage is that this approach is generally not fully automated and requires manual interaction.
SMV (Symbolic Model Verifier) is the first model checker based on BDDs (Binary Decision Diagrams), which uses the BDD to alleviate the state explosion problem, thereby implement the symbol model checking technology [1]. For the verification of concurrent systems with finite states, it first needs to use the SMV specification language to model the system, then, the transition system described by BDDs is extracted from the model, part properties of the system is expressed in CTL (Computation Tree Logic). Finally, the search algorithm based BDDs is used to identify whether the system satisfies verified properties. If a finite state system has a given property, the True is output, else the False is output, SMV also shows counterexamples of the specification the system does not meet. SMV was originally used only to check whether a finite state system satisfies the CTL formula.
The currently widely used NuSMV [2] is the reconstruction and extension of SMV, NuSMV supports all specifications described by the CTL and LTL (Linear Temporal Logic). In addition, it integrates bounded model checking technique based on SAT. The latest version of nuXmv [3] extends from NuSMV. nuXmv is a new symbolic model checking tool that can analyze synchronous finite and infinite state systems. For the case of finite state, nuXmv is an efficient verification engine based on SAT algorithm. For the case of infinite state, it is based on SMT verification technology, tightly integrated with MathSAT5. We choose nuXmv to complete the experimental part of this paper.
B method [4] is a verification method based on theorem proving proposed on the basis of VDM and Z language. The B# method was first proposed, based on which it was created as Event-B [5]. Compared to the traditional B method, introducing event is the new feature of Event-B. The event indicates that actions are completed by triggering a state. Therefore, it is well suited for modeling periodic behavior. Event-B also covers the entire development cycle of software from modeling, refinement and automatic verification to code generation, so it is applicable to complex software development.
Event-B reduces the modeling difficulty by the idea of preliminary abstract modeling and layer by layer refinement. Moreover, Event-B uses the proof obligations generated by axioms and theorems to ensure the consistency among different layers. It indicates the model meets software requirements through the fully proved obligations, but it can not verify specific model properties. While SMV is suitable for system property verification, and counterexamples can be generated to adjust the model, it is difficult to make a perfect SMV model for a complex system at once, whether the model is good or bad can not be proved.
Compared with the SMV language, the Even-B modeling language is more concise and easy to understand, but it is limited to model discrete systems, and can not describe system real-time properties. Both the current version of NuSMV and nuXmv support the description and verfication of real-time systems. Combining model checking and theorem proving is a recent important trend of formal verification [6][7][8], however, the existing work focuses on the state explosion problem and seldom considers the complementarity of the two technologies in software engineering practice. Therefore, a practical scheme is proposed in this paper, which combines model checking and theorem proving for software development.

Model Structure Analysis
The formal Event-B model is based on first-order logic and typed set-theory [9], which is mainly used to describe the relationship among system components. Relatively speaking, SMV model has its own SMV input language. They are very different in terms of system modeling, but the two essentially describe the state transition of discrete systems. ProB is the only tool currently available for Event-B model checking, it is originally designed to verify program specifications written in the B language. ProB uses SICStus Prolog to execute model checking in a constrained logic programming (CLP) environment [10][11]. Because Event-B and B are similar in many ways, Event-B model checking is also supported now. In addition, it can be combined with B-Motion Studio [12] tools to realize the visual simulation and other functions in the software design process.

Event-B model structure
The core concept of Event-B formalization method is the model, a typical Event-B model contains a context that describes static system properties and an abstract machine that describes dynamic system behaviors, context and machine organize model elements into the basic model architecture [5]. Abstract machine and context have the following relationship: an abstract machine can be refined by another machine, and a context can be extended by another context, also, a machine can see a number of contexts. The relationship between machine and context is described in Figure1. The main model elements in the context include constant, set, axiom, and theorem. constants set and constants describe the static and intrinsic attributes for the system. Axioms specify the types, attributes, and relations of constants in the form of predicate formulas, which are used as fundamental assumptions in proof obligations. Theorems contain important inferences from axioms, which is the important basis for proof obligations. It ensures the correctness of axioms and eliminates the ambiguity.
Abstract machine contains the following main elements: variable, event, invariant and theorem. Variables are used to describe system states, all dynamic system properties can be characterized by variables. Events are used to describe changes for dynamic system properties and state transitions. The function of theorems of the abstract machine is analogous to theorems of the context. Before theorems are proved, axioms and theorems in the seen context, invariants of a refined machine and the current machine have been proved.
Event has three definations, as shown in Table 1. In definition 3, the any statement defines the parameter t in event, the where statement is used to introduce the guard of event, the guard condition is the triggering condition for event, which exists in the form of predicate formula. The event is allowed to be triggered only when the guard condition is true, that is, when the constraint G (v) is satisfied, the action S (v) is executed under the then statement, where v is the system variable. S (v) may contain one or more different actions, actions describe the evolution of state variables when event is triggered. Guard conditions contain attribute restrictions for parameters, if there are no parameters in the event, the where statement is reduced to the when statement in defination 2. In definition 1, an event without parameter is used to describe the initialization event.

SMV model structure
SMV model is used to describe Kripke structure and specification to be verified. The Kripke structure is often called the Finite State Machine (FSM) in the SMV. The corresponding SMV program can be used as the input language for nuXmv, the SMV program is composed of modules. A module consists of name and definition, and the module definition is composed of parameters and the main body. The main body of a module is divided into three categories: Variable section, Constraint section and Specification section. The Variable section describes the state set, the Constraint section describes the transition relationships and some restrictions of the model, the Specification section describes the properties to be verified. SMV program must have at least one main module, and the main module has no formal parameter. Multiple modules can be used to describe the FSM, and then combined into a whole FSM, a typical SMV program structure is as follows: There are two main categories in the Variable section: State Variable (state assignment indicates a specific state) and Input Varible (state represented by labeled relationships), they are represented by the keyword VAR or IVAR, respectively. The Variable type can be boolean, integer and enum, etc. The Constraint type can be assign, trans, init, invar and fairness, etc., respectively, using keywords ASSIGN, TRANS, INIT, INVAR, FAIRNESS as declarations. The Specification section uses the SPEC, LTLSPEC and CTLSPEC as keyword declarations, using CTL and LTL as specific property description.

Translation rules
After introducing composition structures of the two models, we propose a combination of Event-B theorem proving and SMV symbolic model checking for the safety-critical software development. The software model is constantly modified and perfected by formal verification technologies, the framework is shown in Figure 2.
The Event-B model design and proof obligation to be proved can be implemented by Rodin platform [13]. Rodin is a tool platform based on the Ecplise framework, which extends the advantages of open source feature and plugin scalability. With rich plugin support system, it can complete visual modeling, graphic simulation, automatic proof, model checking and so on. Models in Rodin will generate a variety of record files in the form of XML Figure 2. Development framework of safety-critical softwares syntax, the file format includes bcc, bcm, bpo, etc. The bcc file is used to record the machine, and the bcm file is used to record the context. ProB can be used as a plugin for Rodin to support Event-B, and the implementation principle is to extract file whose suffix is .eventb from the Event-B model. It can also make model checking by the .eventb file directly in the command line version of ProB. After refinement and verification by Rodin and ProB, we can get the Event-B XML file directly from record files, the basic structure of the Event-B XML file is as follows:

Variable declaration
The process mutual exclusion as an example, B1 and B2 are the variable declaration in Event-B, and S1 is the variable declaration in SMV, the correspondence between them is shown in Figure 3. In the context description section of B1 and the machine variable declaration and definition section of B2, system property definitions are extracted. The relationships are described by sets and partitions in Event-B model, but in SMV, they are implemented by the enumeration type. For example, we can get STATE: {non_crit, wait, crit} from partition(STATE, {non_crit}, {wait}, {crit}) and proc ∈ STATE. Thereby the process proc is one of the elements in {non_crit, wait, crit}, that is, proc1: {non_crit1, wait1, crit1}; the range of integer y is 0 to 1, which is expressed as inv3 in Event-B: y ∈ 0‥1, corresponding to y: 0..1 in SMV.

Variable initialization
All Event-B variables are initialized in the event INITIALISATION, as shown by B3 in Figure 4, SMV sets the initial value for each variable in the ASSIGN section: init(variable):= value, the equivalent SMV expression of B3 is shown in S2.

State transition
For the expression of state transition, Event-B takes it as multiple Actions to be executed when the event satisfies the guard, and multiple variables may be changed in an event. For example, modeling the corresponding request event, enter event and release event for each process, the value of the mutex y also varies with process states, the details are shown as B5 and B6 in Figure 5.
The state changes of proc1 are executed in the act1 of B4, B5, and B6 respectively, meanwhile the variable y is changed in the act2 of B5, B6. In SMV, for each variable, the next statement describes the transitions when the precondition is satisfied, the specific format is as follows: next(variable):= case cond1 : expr1; cond2 : expr2; ... TRUE : exprN; esac; In Figure 5, the equivalent SMV expressions of B4, B5 and B6 of the Event-B model are presented in S3 and S5. If all conditions are not satisfied, the corresponding TRUE expression is executed in SMV. In Event-B, you can describe it directly as an event without any guard, that is, the guard of the when statement in the event definition 2 is null.
The operations of proc2 are the same as that of proc1, as shown in Figure 5, the request event, enter event and release event of proc2 correspond to B7, B8 and B9, respectively.

Basic symbol correspondence
In the basic symbolic expression, there exist intersections between Event-B and SMV. The following are semantically equivalent symbols, some are just different forms, summarized as follows in Table 2. To sum up, the nuXmv expression is more powerful in the temporal logic expression of model checking. We still use the process mutex exclusion as a example, then select randomly 6 groups of LTL and CTL formulas to compare the performance in ProB and nuXmv. In terms of formula expression, there is a slight difference between them. In each group, the former is the formula supported by ProB, and the latter is the equivalent SMV formula.
Formula3: AG({proc1 = wait1} => {proc1 = crit1})  AG(proc1 = wait1 -> proc1 = crit1). Formula4 The experimental results of ProB and nuXmv are shown respectively in Table 3 and table 4:  Experimental results show that, in memory consumption, nuXmv's memory occupancy is always maintained at 8.556MB, the reason is easy to find, NuXmv uses BDDs to describe state transitions, then the number of nodes of BDDs remains unchanged, thus, the memory occupancy is maintained in a stable state. ProB's memory consumption is related to formula complexity, which is consistent with the principle of model checking in the CLP environment. In terms of time consumption, nuXmv has an overwhelming advantage over ProB, the time that ProB returns verification results is rather slow. In addition, we have made lots of experimental comparisons by using various examples, then the analysis results are consistent with the above.

Conclusion
Model translation of Event-B to SMV combines theorem proving and symbolic model checking technique. The method not only uses the strict mathematical formula of theorem proving to guarantee systems meet the design requirements, but also takes advantage of the automated features of model checking tool and counterexample generation for error specifications. As a result, bugs or errors during the software model designment can be modified as soon as possible. The verified model is also refined and simulated by Event-B method, and then the correct software source code is generated directly, which is of great importance to the design and implementation for safety-critical softwares.
The Event-B model also includes complex functional relation, such as Total injection(↣), partial injection (⤔), total surjection (↠), etc. Direct conversion is not possible for these functional relations, thereby, for the complex system model described by Event-B, the modeler needs to modify the transformed SMV model according to the actual situation in the problem, making it more realistic. Our future work is to modify our conversion algorithm based on more instances to maximize the conversion for the two models, then reduce the workload of software design and verification process. While ensuring the reliability, correctness and security of softwares, it also greatly improves the development efficiency.