In critical systems, it is a matter of great importance to ensure correctness of both software and hardware as errors or failures have the potential to result in large financial losses and can lead to fatal consequences, especially in safety-critical sys- tems [30,31]. Verification techniques’ formal methods have became of considerable interest when building high assurance systems and in avoiding failures in critical system. The most successful technique used by both the industry and in research is model checking.
Model checking is an automatic verification method for finite state concurrent systems to check if a system model M or a protocol satisfies its formal specifica- tions as written in logic as temporal logic [30]. The model represents all possible behaviours of the system [5, 12]. The properties of the system are written as formulae. A property formula φ is checked by exploring all possible system execu- tions in the state space of the model to demonstrate whether the correctness of the system is satisfied by the model. This is represented as M |= φ [32]. An advant- age of model checking is that it is fully automatic and does not require particular expertise in mathematics to run or interpret. The automatic tool which achieves this job is called the model checker. Another advantage of model checking is that if a property is not satisfied (i.e., an error is found), a counterexample is given showing the reason for the problem and the state of the system which led to this error [31, 12].
In software engineering, the costs of testing software can range from 30% to 50% of the total cost of the software development [5]. Test generation and test execution can be automated in some areas, but the comparison is usually carried out by human beings. Correctness is determined by making the software travel across a set of execution paths, but ensuring the exhaustive testing of all paths is not possible, which is a big disadvantage in cases where only software testing is carried out. This means that testing can never be complete. On the other hand, in model checking, correctness is checked by an exhaustive exploration of the state space of the model, which makes model checking the rigorous method of choice for use with concurrent and critical systems. State explosion is considered to be the main disadvantage of model checking; when the system has a large number of interacting components or when the system data structure contains a large number of differing values, state explosion can occur because of the huge number of states the system can potentially adopt. The size of the system becomes a problem when it grows exponentially as a result of an increase in the number of state variables. For example, in a system which is composed of n processes and each process has k states, the possible number of states by the asynchronous composition of these processes can be defined by mk.
For the past 30 years, researchers have tried to solve the state explosion prob- lem so as to be able to provide better model checking approaches. Two main solutions to avoid the state explosion problem are used: the first is to reduce the size of the state space to be searched, and this is generally accomplished using abstraction; the second, which was first introduced in 1987 by Ken McMillan, is to use Binary Decision Diagrams (BDDs) to represent the state space [33]. The latter solution made it possible to verify systems that have more than 1020 states
subsequent to this accomplishment, and in which the number of states can be more than 10120 [35]. The well-known model checker NuSMV is based on these
ideas.
This allowed model checking to be successfully used in verifying larger systems than could previously have been attempted, and to successfully detect otherwise highly obscure errors in communication protocols and hardware controllers [31].
2.6.1
Stages of Model Checking
The phases of model checking are as follows:
• Modelling: In this phase, through the use of the formal description language of the model checker, the design is converted into an acceptable form by the tool, where this form is called the model.
• Specification: In this stage, the design properties are written.
• Verification: This step includes verifying the specifications against the design to determine whether the specifications are valid or otherwise. In this stage, an exhaustive search of the model state space is carried out using the model checker, which determines if the specification has satisfied or otherwise. If the specification is not satisfied, a counterexample is instead given by the model checker.
2.6.2
Transactions and Temporal Logic
It is clear that temporal logic is particularly powerful when dealing with the reas- oning adopted in concurrent systems. We can use temporal logic to conduct auto- matic proofs of this kind of systems to avoid the errors often inherent to manual mathematics proofs. To this end, there are various powerful model checkers avail- able such as NuSMV [36] and SPIN [37], but we need to select which temporal logic is supported by these model checkers. CTL and LTL are supported in these model checkers and can be used in this case.
Serializability is considered to be a safety property [38]. Temporal logic can be used to specify other properties of the histories of an unlimited number of transactions, such as starvation. In starvation, some transactions are not served for an indefinite period of time while the system is executing [13]. In [39, 40], starvation is considered a liveness property. The most common problems that face database transaction schedulers are deadlock and starvation [13]. Using temporal logic, deadlock-freedom (which is considered as a safety property) can be achieved if required, especially in transactions that have the potential to iterate an unlimited number of times.