Simulation-Based Invariant Verification Technique for the OTS/CafeOBJ Method

We demonstrate the power of the simulation-based invariant verification technique through two case studies in which it is formally verified that two mutual exclusion protocols, MCS protocol and Anderson protocol, enjoy the mutual exclusion property by the simulation-based invariant verification technique. We initially attempted formally verifying that the two protocols enjoy the property by the induction-based invariant verification technique. We successfully completed the formal proof for MCS protocol by the simulation-based invariant verification technique earlier than the one by the induction-based invariant verification technique even though we started the latter earlier than the former. We did not successfully complete the formal proof for Anderson protocol by the induction-based invariant verification technique as of the time of this paper submission. We define a variant of simulation, “observably equivalent simulations,” and prove some theorems on them to conduct the MCS case study. Given a state machine <inline-formula> <tex-math notation="LaTeX">$M$ </tex-math></inline-formula>, another state machine <inline-formula> <tex-math notation="LaTeX">$M'$ </tex-math></inline-formula> constructed by introducing auxiliary variables into <inline-formula> <tex-math notation="LaTeX">$M$ </tex-math></inline-formula> observably equivalently simulates <inline-formula> <tex-math notation="LaTeX">$M$ </tex-math></inline-formula>. In this sense, <inline-formula> <tex-math notation="LaTeX">$M'$ </tex-math></inline-formula> can be regarded as an abstract version of <inline-formula> <tex-math notation="LaTeX">$M$ </tex-math></inline-formula>.


I. INTRODUCTION
Various kinds of systems (including algorithms, protocols, etc.) can be formalized as ''state machines'' (or (state) transition systems) or their variants, such as Fair Transition Systems [41], I/O-Automata [38], Timed Automata [3] and Kripke Structures [13]. Properties can also be formalized in several ways, such as temporal logics and traces. Among temporal logics are UNITY [9], Linear Temporal Logic (LTL) [41], Temporal Logic of Actions (TLA) [33] and Computational Tree Logic (CTL) [10]. Traces are used to express or formalize properties of I/O-Automata [38]. Once a system and a property are formalized, we can start formally verifying that the system enjoys the property. Formal verification can be largely classified into two: model checking [13] and (interactive) theorem proving.
The present paper is on ''interactive theorem proving'' and focuses on ''invariant properties.'' Invariant properties are the most fundamental ones because it is often necessary to use invariant properties as lemmas to prove different kinds of The associate editor coordinating the review of this manuscript and approving it for publication was Zhaojun Li .
properties, such as liveness properties, for state machines. Interactive theorem proving is supported by software tools called ''proof assistants,'' such as PVS [55], Isabelle/HOL [49] and Coq [7]. The present paper uses CafeOBJ [16] as a specification language for both systems and properties and as a proof assistant. CafeOBJ is an algebraic specification language/system and not inherently a proof assistant. It is, however, possible to conduct formal proofs with CafeOBJ by writing what is called ''proof scores'' [23], [50], [51] in CafeOBJ and executing them with CafeOBJ. Because proof scores can be regarded as programs written in an algebraic specification language, such as CafeOBJ and OBJ3 [25], proving by writing proof scores can be regarded as ''proving as programming'' [21], [28]. It is possible to talk about the sizes of proof scores as programs, such as lines of code. Proof scores may be referred to as formal proofs and if so, the sizes of formal proofs are those of proof scores.
There are at least two possible ways to formally verify that state machines enjoy invariant properties. One uses ''mathematical induction,'' while the other uses ''simulation.'' Structural induction on reachable states and induction on the number of atomic state transitions applied are often used.
Simulation involves two state machines: an abstract state machine and a concrete state machine. Simulation proves that an abstract state machine simulates a concrete state machine or a concrete state machine is a proper implementation of an abstract state machine. We may need to use mathematical induction to prove that an abstract state machine enjoys some invariant properties so that we can conclude that a concrete state machine enjoys the invariant properties as well from the simulation proof. We may also need to prove that the simulation preserves the invariant properties. Formal invariant verification technique by mathematical induction is called ''the induction-based invariant verification technique'' (or ''the induction-based technique''), while formal invariant verification technique by simulation is called ''the simulation-based invariant verification technique'' (or ''the simulation-based technique'') in the present paper.
Lynch and some others [30], [38], [47], [48] have demonstrated how useful simulation is to formally verify that distributed algorithms enjoy desired properties, while they have also used mathematical induction (which they call invariant assertions) to formally verify invariant properties for I/O-Automata. Chandy & Misra and some others [9], [38], [42], [50], [60] have used mathematical induction to formally verify invariant properties and some safety properties for state machines. Few researchers, however, have made comparison of the two formal verification techniques. Ogata and Futatsugi [52] compared the formal proofs that a communication protocol enjoys an invariant property by the simulation-based technique and the induction-based technique. They conclude that there is no significant difference between the two formal proofs in terms of their sizes.
We have conducted case studies in which we formally verify that two mutual exclusion protocols, Anderson protocol [4] and MCS protocol [43], enjoy the mutual exclusion property with the simulation-based technique. An informal description of the property is that there is always at most one process in the critical section. The two protocols are formalized as observational transition systems (OTS) [50], a variant of state machine, that can be naturally described in CafeOBJ. In addition to simulation relations from OTSs to OTSs [52], we introduce a variant of simulation relation, ''observably equivalent simulations'' from OTSs to OTSs, to conduct the formal verification for MCS protocol. We made two modified versions of MCS protocol called MCS2 and MCS3 such that MCS2 observably equivalently simulates MCS and MCS3 observably equivalently simulates MCS2. We also prove that observably equivalent simulations preserve the mutual exclusion property.
We first attempted to formally verify that MCS protocol enjoys the mutual exclusion property by the induction-based technique. However, we got stuck in our proof attempt for several months. We, meanwhile, found what was likely to play as an auxiliary (or ghost) variable [54], [60] topQ. The pseudo-code of MCS protocol uses a global variable glock shared by all processes. MCS protocol maintains a virtual queue. glock refers to the bottom element of the virtual queue if the queue is not empty; it is nop otherwise. topQ refers to the top element of the virtual queue if the queue is not empty; it is nop otherwise. MCS2 is obtained by inserting topQ into the pseudo-code of MCS protocol. We have some experiences of formally verifying that another mutual exclusion protocol called Qlock, an abstract version of Dijkstra binary semaphore, enjoys the mutual exclusion property. The experience of ours made us come up with insertion of topQ into the pseudo-code of MCS protocol. After that, we discovered two things that were likely to be invariant properties of MCS2. The two things are in the form of conditional equations. The two conditional equations were used to modify MCS2 and then MCS3 was obtained. Long after the successful completion of the formal proof by the simulation-based technique, we found a key lemma that made us (together with one more) complete the formal proof by the induction-based technique [61]. Size-wise, the two formal proofs are comparable. However, what we would like to claim in the present paper is as follows: we completed the proof by the simulation-based technique earlier than the one by the induction-based technique even though we started the latter formal verification earlier. This experience of ours demonstrates the power of the simulation-based technique.
We first attempted to formally verify that Anderson protocol enjoys the mutual exclusion property by the inductionbased technique. However, we got stuck in our proof attempt for a few months. This is because we needed an unbounded series of lemmas, which is described in detail in Sub-sect. IV-D. We then made an abstract version of Anderson protocol by replacing a finite array with an infinite array. The abstract version of Anderson protocol is called A-Anderson. We successfully completed the formal verification that A-Anderson enjoys the mutual exclusion property by the induction-based technique [62]. We also formally verified that A-Anderson simulates Anderson protocol and the mutual exclusion property is preserved by the simulation relation used. By the time when the present paper was submitted, we did not complete the proof that Anderson protocol enjoys the mutual exclusion property by the induction-based technique. This experience of ours backs up our claim that the simulation-based technique is powerful.
Our contributions of the present paper are summarized as follows: 1) We have formally proved that the two mutual exclusion protocols MCS and Anderson satisfy the mutual exclusion property with the simulation-based technique, which demonstrates the power of the simulation-based technique (see Sect. IV and Sect. VI except for Sub-sect. IV-D and Sub-sect. VI-F); 2) We describe the reason why we got stuck in our proof attempts that MCS and Anderson satisfy the property with the induction-based technique (see Sub-sect. IV-D and Sub-sect. VI-F); 3) We define a variant of simulation, ''observably equivalent simulations,'' and prove some theorems on them, which makes it possible to prove that a state machine M 93848 VOLUME 9, 2021 is simulated by another state machine M constructed by introducing auxiliary variables into M (see Sect. V); 4) We clarify the point that a state machine is simulated (more precisely observably equivalently simulated) by the state machine into which auxiliary variables are introduced (see Sect. V). The rest of the paper is organized as follows. Sect. II presents some preliminaries, such as OTSs, CafeOBJ and proof scores. A mutual exclusion protocol (called TAS) that uses test&set is used as an example in Sect. II. It is formally verified that TAS enjoys the mutual exclusion property by the induction-based technique. Sect. III gives the definition of simulations from OTSs to OTSs. As an example, it is formally proved that TAS simulates Qlock, from which we conclude that Qlock enjoys the mutual exclusion property. Sect. IV reports on the case study in which it is formally verified that Anderson protocol enjoys the mutual exclusion property by the simulation-based technique. We discuss why we cannot complete the formal verification by the induction-based technique. Sect. V defines observably equivalent simulations from OTSs to OTSs and proves some theorems on them. Sect. VI reports on the case study in which it is formally verified that MCS protocol enjoys the mutual exclusion property by the simulation-based technique. We discuss why we got stuck in our proof attempt that MCS protocol enjoys the mutual exclusion property by the induction-based technique, although the attempt finally succeeded. Sect. VII surveys some related work. Sect. VIII concludes the paper with some pieces of our future work.
All of the formal specifications and proof scores shown in the present paper are available at http://gitlab.com/ duongtd23/sim-vrf/.

II. PRELIMINARIES
This section presents some basic notions needed for the rest of the paper: observational transition systems (OTS) and CafeOBJ. OTS is a variant of state machine. A simple mutual exclusion protocol called TAS that uses test&set, an atomic instruction, is used as an example to describe how to describe OTSs in CafeOBJ and formally verify that OTSs enjoy invariant properties by writing proof scores in CafeOBJ.

A. OBSERVATIONAL TRANSITION SYSTEMS (OTS)
We suppose that there exists a universal state space denoted ϒ and that each data type used in OTSs is provided. The data types include Bool for Boolean values. A data type is denoted D with a subscript, such as D o1 and D o .
• I: The set of initial states such that I ⊆ ϒ.
• T : A finite set of transitions. Each transition t : ϒ D t1 . . . D tn → ϒ is a function that takes one state and n (≥ 0) data values and returns one state, provided that t(υ 1 , y 1 , . . . , y n ) = S t(υ 2 , y 1 , . . . , y n ) for each [υ] ∈ ϒ/ = S , each υ 1 , υ 2 ∈ [υ] and each y i ∈ D ti for i = 1, . . . , n. Each transition t has the condition c-t : ϒ D t1 . . . D tn → Bool, which is called the effective condition of t. If c-t(υ, y 1 , . . . , y n ) does not hold, then t(υ, y 1 , . . . , y n ) = S υ. Each transition t is defined as how the value observed by each observer o changes. If the effective condition of t holds, t is defined for each o as follows: . , x m , y 1 , . . . , y n ) is a value of D o that can be determined based on υ, x 1 , . . . , x m , y 1 , . . . , y n . Each of the variables υ, x 1 , . . . , x m , y 1 , . . . , y n used in the conditional equation is universally quantified, which is omitted. In what follows, each variable used in a conditional equation or an equation is universally quantified, which is omitted. If the effective condition of t does not hold, t is defined for each o as follows: This means that t does not change the value observed by each o if c-t(υ, y 1 , . . . , y n ) does not hold. If c-t(υ, y 1 , . . . , y n ) does not hold, we may use the following abbreviation: t(υ, y 1 , . . . , y n ) = υ if ¬c-t(υ, y 1 , . . . , y n ) I is described as follows. Let init be an arbitrary initial state. For each o ∈ O, we have the following equation: where init-val-o(x 1 , . . . , x m ) is a value of D o that can be determined based on x 1 , . . . , x m . init may have some parameters, although it suffices to use init without any parameters in the present paper.
A pair (υ, υ ) of states is called a transition instance and υ is called a successor state of υ with respect to (wrt) S if there exists t ∈ T such that υ = S t(υ, y 1 , . . . , y n ) with y i ∈ D ti where i ∈ {1, . . . , n}. Such a pair (υ, υ ) may be denoted υ S υ to emphasize that υ directly goes to υ by one step. When k time steps of transitions move υ to υ , we write υ k S υ . That is, υ 0 S υ such that υ = S υ , and υ k+1 S υ if there exists υ ∈ ϒ such that υ k S υ and υ S υ . We write υ * S υ if there exists a natural number k such that υ k S υ . Each state that is reachable from an initial state through transitions is called a reachable state.
Let R S be the set of all reachable states wrt S. Lemma 1: Given an OTS S and arbitrary two states Proof: The proof is done by induction on k in υ k S υ . If k is 0, it is obviously true. Suppose that it is true with k. If υ k+1 S υ , there exists υ such that υ k S υ and υ S υ . From the induction hypothesis, υ is reachable wrt S. From Definition 2 (ii), υ is reachable wrt S.
Predicates whose types are ϒ → Bool are called state predicates. State predicates may have universally quantified variables. State predicates that hold in all reachable states wrt S are invariants wrt S.

B. CafeOBJ
CafeOBJ [16] is an algebraic specification language. We describe how to specify OTSs in CafeOBJ through a simple mutual exclusion protocol as an example. The mutual exclusion protocol written in Algol-like pseudo-code for each process is as follows: Loop ''Remainder Section'' rs : repeat while test&set(locked); ''Critical Section'' cs : locked := false; where test&set(locked) atomically does the following: if locked is false, then it sets locked to true and returns false; otherwise it just returns true. Since the protocol uses test&set, it is called TAS protocol or simply TAS. Each process is located at either rs (Remainder Section) or cs (Critical Section) and initially at rs. locked is a Boolean variable shared by all processes and initially false. The body of the loop at the label rs (between repeat and while) is empty.
To specify TAS protocol in CafeOBJ as an OTS S TAS , we use two observers and two transitions. The two observers are expressed by the operators declared as follows: op pc: SysA Pid -> Label. op~locked: SysA -> Bool.
The two transitions are expressed by the operators declared as follows: We use one more operator that represents an arbitrary initial state of S TAS . The operator is declared as follows: op init: -> SysA {constr}.
init does not have any parameters. Such an operator is called a constant. init is a constant of SysA. constr stands for constructor. init, enter and exit are used to construct reachable states of S TAS . SysA is the sort that expresses R S TAS . Sorts correspond to types in programming languages. Pid, Label and Bool are the sorts that express the set of process IDs, the set of labels (rs and cs) and the set of the Boolean values (true and false), respectively. Constants rsA and csA of Label are used to denote rs and cs. Observers and the operators that express the observers are interchangeably used and so are transitions and the operators that express the transitions in this paper.
The specification of S TAS in CafeOBJ has three sets of equations. One is for defining init and the other two are for defining enter and exit. init is defined as follows: eq pc(init,P) = rsA. eq~locked(init) = false.
P is a CafeOBJ variable of Pid. The equations say that each process P is located at rs and locked is false in init. enter is defined as follows: that means that the process P is located at rs and locked is false in S. The equations say that if c-enter(S,P) holds, P moves to csA from rsA, locked is set to true and any other processes Q keep staying their locations; otherwise nothing changes. exit is defined likewise.
One desired property of mutual exclusion protocols, such as TAS, is the mutual exclusion property. An informal description of the property is that there always exists at most one process located at the critical section. The predicate used to define the property is defined as follows: ops i j k: -> Pid. op~sa: -> SysA. eq pc(sa,k) = rsA. eq locked(sa) = false. eq i = k. eq~j = k. red invA1(sa,i,j) implies invA1(enter(sa,k),i,j). close The sub-case is characterized by the four equations: eq pc(sa,k) = rsA. eq~locked(sa) = false. eq~i = k. eq~j = k. ops i j k: -> Pid. op~sa: -> SysA. eq pc(sa,k) = rsA. eq locked(sa) = false. eq i = k. eq~(j = k) = false. red invA1(sa,i,j) implies invA1(enter(sa,k),i,j). close CafeOBJ does not return true for the open-close fragment. We need a lemma to eventually discharge the sub-case. Such a lemma is as follows: Precisely, the lemma is (∀SA : SysA)(∀I : Pid) invA2(SA, I ). By using the lemma (precisely an instance of the lemma), the proof of the sub-case is as follows: open INV. ops i j k: -> Pid. op~sa: -> SysA. eq pc(sa,k) = rsA. eq locked(sa) = false. eq i = k. eq~(j = k) = false. red (invA2(sa,j) and invA1(sa,i,j)) implies invA1(enter(sa,k),i,j). close The other sub-cases of the induction case in which enter is taken into account can be tackled likewise. The induction case in which exit is taken into account can be tackled likewise. (∀SA : SysA)(∀I : Pid) invA2(SA, I ) can be proved likewise.

III. SIMULATION FROM OTSs TO OTSs
The paper [52] defines the simulation from one OTS to another OTS. Although the definition used in the present paper is essentially the same as the one used in the paper [52], we explicitly treat extra data parameters. In the paper [52], VOLUME 9, 2021 (∀d 1 ∈ D 1 ) . . . (∀d k ∈ D k ) r(υ, υ A , d 1 , . . . , d k ) is expressed as r(υ, υ A ).
Definition 4: Given OTSs S & S A and data types D 1 , . . . , D k , a relation r : R S R S A D 1 . . . D k → Bool is called a simulation from S to S A with D 1 , . . . , D k if the following conditions are satisfied: (ii) For each υ, υ ∈ R S and each υ A ∈ R S A such that υ S υ and r(υ, Fig. 1 depicts the two conditions. An informal description of a simulation from S to S A with D 1 , . . . , D k is that S can be simulated (or followed) by S A or S A can simulate (or follow) S. Note that if υ A ∈ R S A and υ A * S A υ A , then υ A ∈ R S A from Lemma 1.
If there exists a simulation r from S to S A with D 1 , . . . , D k , for each s ∈ R S there exists s A ∈ R S A such that r(υ, υ A , d 1 , . . . , d k ) for each d i ∈ D i for i = 1, . . . , k. This is described as the following lemma: Lemma 2: Given any OTSs S & S A and any data types D 1 , . . . , D k such that there exists a simulation from S to S A with D 1 , . . . , D k and any such simulation r : . . , k from Definition 4 (i). Let υ be an arbitrary reachable state in R S and consider an arbitrary υ such that υ S υ . υ ∈ R S from Lemma 1. By the induction hypothesis, there The following theorem guarantees the correctness of the simulation-based technique for the OTS/CafeOBJ method. If S is simulated by S A , a state predicate ρ A is an invariant wrt S A and ρ A is preserved by the simulation, then the counterpart state predicate ρ is an invariant wrt S. Theorem 1: Given any OTSs S & S A and any data types D i for i = 1, . . . , k, k +1, . . . , k +l, k +l +1, . . . , k +l +m such that there exists a simulation from S to S A with D 1 , . . . , D k , any such simulation r : (referred as (1)) and (referred as (2)). Then, we have the following: Assumption (1) of Theorem 1 can be interpreted as follows: the state predicate ρ A of S A is preserved by r from S A to S as the counterpart state predicate ρ of S.
For two OTSs S & S A and two state predicates ρ & ρ A of S & S A , to prove that ρ is an invariant wrt S with the simulation-based technique, there are three steps to do: 1) To prove that ρ A is an invariant wrt S A somehow, for example, with the induction-based technique; 2) To conjecture a candidate simulation relation r from S to S A with D 1 , . . . , D k , where each D i is a data type, and prove that r satisfies the two conditions (i) & (ii) of Definition 4; 3) To prove that ρ A is preserved by r from S A to S as the counterpart state predicate ρ. To prove that r satisfies condition (ii) of Definition 4, it suffices to prove r(s , . . , d k ) for fresh constants s, s of the sort denoting R S , a fresh constant s A of the sort denoting R S A , a witness s A of the sort denoting R S A and a fresh constant d i of the sort denoting D i for i = 1, . . . , k. We may use instances, say r(s, s A , d 1 , . . . , d k ), of (∀d 1 ∈ D 1 ) . . . (∀d k ∈ D k ) r(s, s A , d 1 , . . . , d k ) as premises of the implication in a proof fragment written in CafeOBJ. We may need to use some invariants wrt S A (and S as well) to exclude unreachable states wrt S A (and S as well).
Let us exemplify how to do the simulation-based technique by using TAS and Qlock, where Qlock is another mutual exclusion protocol in which an atomic queue is used. The pseudo-code of Qlock for each process i can be written as follows: Loop ''Remainder Section'' rs : enqueue(queue, i); ws : repeat until top(queue) = i; ''Critical Section'' ws : dequeue(queue); queue is an atomic queue of process IDs shared by all processes. Initially queue is empty and each process i is located at rs. If process i wants to enter the critical section (cs), it first enqueues its ID i into queue and moves to ws. It waits there until the top of queue becomes i, when it is allowed to enter the critical section. When it leaves the critical section, it deletes the top from queue and goes back to the remainder section (rs).
Let Sys be the sort that represents R S Qlock and Queue be the sort that represents the set of process ID queues. We use the following observers, transitions and one constant of Sys that represents an arbitrary initial state: c-try(S,P) is pc(S,P) = ws and top(queue(S)) = P which means that the process P is located at ws and the top of queue is P. want and exit are defined likewise.
Because step 1 has already been done, we conduct step 2. Let us conjecture a simulation from S Qlock to S TAS as follows: and pc(S,top(queue(S))) = cs iff locked(SA)).
We prove that r satisfies the two conditions. The proof of Condition (i) is written in CafeOBJ as follows: op i: -> Pid. red r(init,init,i). close SIM is the module in which the specification of TAS, the specification of Qlock, the two invariants of TAS and the simulation candidate are available. CafeOBJ returns true for the open-close fragment, meaning that the proof of Condition (i) is done.
The proof of Condition (ii) is split into three sub-cases in which want, try and exit are taken into account. Each of the three sub-cases is split into further sub-cases. We may need to use some lemmas, such as invA1 and invA2 to discharge some sub-cases. The proof of one sub-case is written in CafeOBJ as follows: ops i k: -> Pid. op~q: -> Queue. op s: -> Sys. op~sa: -> SysA. eq pc(s,k) = ws. eq~queue(s) = k | q. eq (i = k) = false. eq~pc(sa,k) = rsA. eq locked(sa) = false. red r(s,sa,i) implies r(try(s,k),enter(sa,k),i). close k | q denotes the queue such that k is the top element and q is the queue obtained by deleting the top element. υ, υ A , υ and υ A correspond to s, sa, try(s,k) and enter(sa,k), respectively. CafeOBJ returns true for the open-close fragment, meaning that the sub-case is discharged.
The proof of yet another sub-case is written in CafeOBJ as follows: open SIM. ops i k: -> Pid. op~s: -> Sys. op sa: -> SysA. eq~pc(s,k) = cs. VOLUME 9, 2021 eq i = k. eq~pc(sa,k) = csA. eq locked(sa) = false. red (invA2(sa,k) and r(s,sa,i)) implies r(exit(s,k),sa,i). close We use invA2(sa,k) as a lemma. CafeOBJ returns true for the open-close fragment. The remaining part of the proof can be conducted likewise.
We finally conduct step 3. The state predicate used to define the mutual exclusion property for Qlock is defined as follows: Consequently, from Theorem 1, we can conclude that Qlock satisfies the mutual exclusion property.

IV. FORMAL VERIFICATION OF ANDERSON PROTOCOL
This section describes the proof that Anderson protocol enjoys the mutual exclusion property with the simulationbased technique. We first describe Anderson protocol and its specification in CafeOBJ. Then, we introduce an abstract version of Anderson, which is called A-Anderson. After that, we prove that Anderson enjoys the mutual exclusion property by showing a simulation from Anderson to A-Anderson.

A. ANDERSON PROTOCOL AND ITS SPECIFICATION IN CafeOBJ
Anderson protocol [4] is a mutual exclusion protocol. The protocol uses a finite Boolean array whose size is the same as the number of processes participating in the protocol. It also uses the modulo operation of natural numbers and an atomic operation fetch&incmod. Suppose that there are N processes participating in Anderson protocol. The pseudo-code of Anderson protocol for each process i can be written as follows: := false, true; Let us suppose that each process is located at rs, ws or cs and initially located at rs. place is an array whose size is N and each of whose elements stores one from {0, 1, . . . , N−1}. Initially, each element of place can be any from {0, 1, . . . , N−1} but is 0 in this paper. Although place is an array, each process i only uses place[i] and then we can regard place[i] as a local variable to each process i. array is a Boolean array whose size is N. Initially, array[0] is true and array[j] is false for any j ∈ {1, . . . , N − 1}. next is a natural number variable and initially set to 0. fetch&incmod(next, N) atomically does the following: setting next to (next + 1) % N and returning the old value of next. x, y := e 1 , e 2 is a concurrent assignment that is processed as follows: calculating e 1 and e 2 independently and setting x and y to their values, respectively.
Let Sys be the sort that represents R S ADS . To specify Anderson protocol in CafeOBJ as an OTS S ADS , we use the following observers, transitions and one constant of Sys that represents an arbitrary initial state: Pid and Label are quite similar to the same name sorts used so far. SNat is the sort that expresses the set of natural numbers formalized à la Peano. You can imagine how to use the observers pc, next, place and array. The observer count keeps track of the number of processes that would like to enter the critical section and/or to be there. If N+1 or more processes participate in the protocol, the protocol does not enjoy the mutual exclusion property, which we realized when we were formally specifying the protocol in CafeOBJ. This is implicitly assumed by the protocol but it is necessary to make the assumption explicit so as to do formal verification. This is tiny but important, demonstrating worth formally specifying systems.
We have the declaration of N and its property as follows: SNzNat is the sort of non-zero natural numbers and a subsort on SNat. N is expressed as the constant N of SNzNat. The property says that N is greater than 1 because if there is only one process, we do not need to use any mutual exclusion protocols. In the formal specification, we declare 1 as a constant of SNzNat that equals s(0).
P is a CafeOBJ variable of Pid and I is a CafeOBJ variable of SNat.
want is defined as follows:  Although it is straightforward to prove inv0 as we did in Sect. II for TAS, it is not that simple to prove mutex. As of the submission of this paper, we were not able to directly prove mutex as we did in Sect. II for TAS. Therefore, we make an abstract version of Anderson protocol and prove mutex as we did in Sect. II for Qlock, namely that we prove that the abstract version enjoys the mutual exclusion property, the abstract version simulates Anderson protocol and the mutual exclusion property is preserved by the simulation.

B. THE ABSTRACT VERSION: A-ANDERSON
We make an abstract version of Anderson protocol, which is called A-Anderson protocol (or just A-Anderson). The pseudo-code of A-Anderson protocol for each process i can be written as follows: We use an infinite Boolean array array instead of a finite one and no longer use %. fetch&inc is used instead of fetch&incmod. fetch&inc(next) atomically does the following: setting next to next + 1 and returning the old value of next. We also suppose that each process is located at rs, ws or cs and initially located at rs. Initially, each element of place can be any natural number but is 0 in this paper, array[0] is true, array[j] is false for any non-zero natural number j and next is 0.
The specification of A-Anderson in CafeOBJ is almost the same as the one of Anderson, although the former does not use the modulo (or remainder) operator rem, the constant N and the observer count. Let Sys2 be the sort that expresses R S AADS , the set of the reachable states of S AADS , where S AADS is the OTS formalizing A-Anderson. want is defined as follows: S is a CafeOBJ variable of Sys2 and the other variables are the same as those used in the specification of Anderson. c-want(S,P) is pc(S,P) = rs. try and exit can be defined likewise, and init can be defined as the counterpart of Anderson.
The predicate used to define the mutual exclusion property is defined as follows: eq mutex(S,P,Q) = (pc(S,P) = cs and pc(S,Q) = cs) implies (P = Q).
Let AADS-INV be the module in which the specification of A-Anderson and the predicates defined above are available.

C. SIMULATION-BASED VERIFICATION OF ANDERSON
This subsection describes the proof that the original Anderson protocol enjoys the mutual exclusion property by using the simulation-based technique.
where S is a CafeOBJ variable of Sys2 and P is a CafeOBJ variable of Pid. Feeding the proof fragment into CafeOBJ, CafeOBJ returns true.  s,s2,z,i) as a premise. The other cases can be discharged straightforwardly.
Consequently, from Theorem 1, we can conclude that the original Anderson protocol satisfies the mutual exclusion property.

D. DISCUSSION
By the time when the present paper was submitted, we did not complete the proof that Anderson protocol enjoys the mutual exclusion property by the induction-based technique.
We describe where we got stuck in our verification attempt that Anderson protocol enjoys the mutual exclusion property with the induction-based technique.
inv1' is the same as inv1 used as a lemma for the proof of mutex wrt S AADS except for the sort of the first parameter S. One lemma needed to prove inv1 wrt S AADS is inv3. The counterpart lemma needed to prove inv1' wrt S ADS is inv3' that is as follows: If inv3' is not an invariant wrt S ADS , two different processes P and Q wait on the same place place(S,P) (that equals place(S,Q)) to enter the critical section, which may lead to a state in which P and Q may enter the critical section simultaneously and the mutual exclusion property is broken. Because Anderson enjoys the mutual exclusion property, however, inv3' is logically very likely to be an invariant wrt S ADS .
inv7'-1 intuitively says that if there exists a process located at ws or cs in a state S, count(S) is greater than 0. Considering the roles of count that keeps track of the number of processes that have moved to ws and not yet left cs, namely the number of processes that are located at ws or cs, inv7'-1 is likely to be an invariant wrt S ADS .
inv7'-2 intuitively says that if there are two different processes located at ws or cs in a state S, count(S) is greater than 1.
To prove that inv7'-2 is an invariant wrt S ADS , we need to use as a lemma inv7'-3 that is as follows: inv7'-3 intuitively says that if there are three different processes located at ws or cs in a state S, count(S) is greater than 2. Accordingly, it seems necessary to use an unbounded series of similar lemmas, such as inv7'-2 and inv7'-3, to complete the proof of inv7'-1 wrt S ADS . If CafeOBJ made it possible to use an operator with a variable number of parameters, we could generalize the lemmas: eq inv7'-k(S,P1,\ldots,Pk) = ((pc(S,P1) = ws or pc(S,P1) = cs) and \ldots and (pc(S,Pk) = ws or pc(S,Pk) = cs) and (P1 = P2) = false and \ldots and (P(k-1) = Pk) = false) implies (s^{k-1}(0) < count(S)).
where s^{k-1}(0) denotes k −1. k can vary like a variable and the number k of parameters can change. It is, however, impossible to deal with such an operator with a variable number of parameters in CafeOBJ.
To complete the proof of mutex wrt S ADS , it seems necessary to avoid using inv7'-1, inv7'-2, inv7'-3, etc. There might be a different lemma than inv7'-1 that can be used to complete the proof of inv3' wrt S ADS . However, we did not conjecture such a lemma as of the time when the present paper was submitted. Because we have successfully proved that Anderson enjoys the mutual exclusion property with the simulation-based technique, while we did not yet successfully prove it with the induction-based technique, the case study demonstrates the power of the simulation-based technique over the induction-based technique.

V. OBSERVABLY EQUIVALENT SIMULATIONS FROM OTSs TO OTSs
We define a variant of simulation from OTSs to OTSs called observably equivalent simulations from OTSs to OTS. An informal description of an observably equivalent simulation from S to S A is that S can be simulated (or followed) by S A or S A can simulate (or follow) S such that for each υ ∈ R S its counterpart state υ A ∈ R S A is observably equivalent to υ. By definition, we implicitly assume that O ⊆ O A .
Proof: The conclusion part is straightforwardly derived from the premise part.
Theorem 2: Given two OTSs S & S A such that S A observably equivalently simulates S, if a state

predicate ρ never uses any observers o such that
Proof: It follows from Proposition 1 and Theorem 1.

Proposition 2: Given two OTSs
Proof: By the definition of the equivalence relation between states of OTSs.
Proof: We prove what is depicted in Fig. 3 in which we use Proposition 2. It is straightforward to prove Condition (i). We suppose that the number of transition steps in υ 1 * S 1 υ 1 in the left-top diagram of Condition (ii) in Fig. 3 is i, a natural number, namely that υ 1 i S 1 υ 1 . We prove Condition (ii) by case splitting: (1) i = 0 and (2) i > 0. When i = 0, it is straightforward to prove Condition (ii) because of Lemma 2. When i > 0, there exists υ 2 ∈ R S 2 such that υ 2 * S 2 υ 2 and υ 1 = S 1 υ 2 (and then υ 1 = S 0 υ 2 ) from Lemma 3. Accordingly, there exists υ 2 ∈ R S 2 such that υ 2 * S 2 υ 2 and υ 0 = S 0 υ 2 .
Proof: The proof is done by induction on l. The base case (l = 1) is directly derived from the assumption. The induction case (l = l + 1, where l is an arbitrary positive integer) is taken into account. From the induction hypothesis, S l observably equivalently simulates S 0 , which implies that O l ⊆ O 0 . From the assumption, S l +1 observably equivalently simulates S l . Therefore, S l +1 observably equivalently simulates S 0 from Lemma 4.

VI. FORMAL VERIFICATION OF MCS PROTOCOL A. MCS PROTOCOL AND ITS SPECIFICATION IN CafeOBJ
MCS is a mutual exclusion protocol invented by Mellor-Crummey and Scott [43]. Variants of MCS have been used in Java VMs and therefore the 2006 Edsger W. Dijkstra Prize in Distributed Computing went to their paper [43]. MCS written in Algol-like pseudo-code for each process p is as follows: rs : ''Remainder Section'' l1 : next p := nop; l2 : prede p := fetch&store(glock, p); l3 : if prede p = nop { l4 : lock p := true; l5 : next prede p := p; l6 : repeat while lock p ; } cs : ''Critical Section'' l7 : if next p = nop { l8 : if comp&swap(glock, p, nop) l9 : goto rs; l10 : repeat while next p = nop; } l11 : lock next p := false; l12 : goto rs; MCS uses one global variable glock and three local variables next p , prede p and lock p for each process p. Process IDs are stored in glock, next p and prede p , while a Boolean value is stored in lock p . There is one special (dummy) process ID nop that is different from any real process IDs. Initially, each of glock, next p and prede p is set to nop and lock p is set to false. We suppose that each process is located at one of the labels, such as rs, l1 and cs. Initially, each process is located at rs. When a process wants to enter ''Critical Section,'' it first moves to l1 from rs.
MCS uses two non-trivial atomic instructions: fetch&store and comp&swap. For a variable x and a value a, fetch&store(x, a) atomically does the following: x is set to a and the old value of x is returned . For a variable x and values  a, b, comp&swap(x, a, b) atomically does the following: if x equals a, then x is set to b and true is returned; otherwise false is just returned.
MCS maintains a virtual queue as shown in Fig. 4 that is constructed from next p for each process p and glock. Enqueuing of an element into the virtual queue is not atomic as shown in Fig. 4. Elements of the virtual queue could be considered where Sys is the sort denoting R S MCS , Pid is the sort denoting process IDs, Pid&Nop is the sort denoting process IDs and nop and Label is the sort denoting the 14 labels. I MCS is specified as follows: op init: -> Sys {constr}. eq~glock(init) = nop. eq~pc(init,P) = rs. eq~next(init,P) = nop. eq~prede(init,P) = nop. eq~lock(init,P) = false.
where P is a CafeOBJ variable of Pid. T MCS has the 14 transitions that are declared as follows: The first (want) through sixth (stnpr) operators express state transitions such that a process (given as the second parameter) moves to l1, l2, l3, l4 or cs, l5 and l6 from rs, l1, l2, l3, l4 and l5, respectively, in a state (given as the first parameter). chlck expresses a state transition such that a process tries to move to cs from l6 in a state. The eighth (exit) through 11th (go2rs) operators express state transitions such that a process moves to l7, l8 or l11, l9 or l10 and rs from cs, l7, l8 and l9, respectively, in a state. chnxt2 expresses a state transition such that a process tries to move to l11 from l10 in a state. stlnx and go2rs2 express state transitions such that a process moves to l12 and rs from l11 and l12, respectively, in a state. Some more descriptions on the operators are given. For example, if a process p is at l2 in a state s, then stprd(s,p) denotes the state just after p has executed the statement at l2 and moved to l3 from l2; if p is at l6 in s, then chlck(s,p) denotes the state just after p has exited the loop at l6 and moved to cs if lock p is false and the state just after p has done one iteration of the loop at l6 if lock p is true. The transitions are defined in terms of equations that specify how the values observed by the five observers change. For example, stprd is defined as follows: where S is a CafeOBJ variable of Sys and P & Q are CafeOBJ variables of Pid. The remaining transitions can be defined likewise.
Because MCS is a mutual exclusion protocol, one desired property is the mutual exclusion property that is expressed as an invariant. The state predicate is defined as follows: op mutex: Sys Pid Pid -> Bool. eq~mutex(S,P,Q) = (pc(S,P) = cs and pc(S,Q) = cs) implies (P = Q).
We will make two modified versions of MCS (MCS2 and MCS3) such that (1) MCS2 is an SOA-OTS of MCS and (2) MCS3 observably equivalently simulates MCS2. Because of (1), it follows that (3) MCS2 observably equivalently simulates MCS from Proposition 3. Because of (2) and (3), (4) MCS3 observably equivalently simulates MCS from Lemma 4 (or Lemma 5). We will formally verify that MCS3 enjoys the mutual exclusion property with the induction-based technique, from which we conclude that MCS enjoys the mutual exclusion property from Theorem 2 because of (4).

B. THE FIRST MODIFIED VERSION -MCS2
We make a modified version of MCS protocol, which is called MCS2. In MCS2, we only add one more global variable topQ capturing the top process of the virtual queue and keep all of the original MCS. The pseudo-code of MCS2 for each process p is written as follows: rs : ''Remainder Section'' l1 : goto rs; l10 : repeat while next p = nop; } l11 : lock next p := false; (&& topQ := next p ; ) l12 : goto rs; where label : action 1 (&& action 2 ) means that action 2 is done at the same time when action 1 located at label is carried out. topQ is updated at l2, l8, l11 and initially topQ is set to nop.
where S2 is a CafeOBJ variable of Sys2.

D. PROOF THAT MCS3 ENJOYS THE MUTUAL EXCLUSION PROPERTY
The proof is accomplished by simultaneous structural induction on S by writing proof scores in CafeOBJ. The base case init can be discharged directly. Let us consider the induction case chprd. The proof of chprd includes a sub-case whose proof score is as follows: op s: -> Sys3. ops p q r: -> Pid. eq pc(s,r) = l3. eq~p = r. eq (q = r) = false. eq~pc(s,q) = cs. eq topQ(s) = r. red mutex(s,p,q) implies mutex(chprd(s,r),p,q). close CafeOBJ returns false for this fragment. We then conjecture a new lemma inv1 and add it to module MCS3-INV: eq inv1(S,P) = (pc(S,P) = cs or pc(S,P) = l8 or pc(S,P) = l11 or pc(S,P) = l7 or pc(S,P) = l10) implies topQ(S) = P.
where S is a CafeOBJ variable of Sys3 and P is a CafeOBJ variable of Pid. The red (reduce) command in the above proof fragment uses inv1 to strengthen the induction hypothesis as follows: red (inv1(s,q) and mutex(s,p,q)) implies mutex(chprd(s,r),p,q).
CafeOBJ now returns true for the proof score fragment. In addition to the induction case chprd, the proof of the induction case chlck also needs to use inv1 as a lemma. The remaining induction cases can be discharged by just splitting cases, no lemmas are required. inv1 can be proved independently, without any lemmas. The complete proof scores of mutex, as well as inv1, are available at the webpage presented in Sect. I.
We partially show the proof of (∀S2 ∈ Sys2)(∀P ∈ Pid) inv2(S2, P) or that inv2 is an invariant wrt S MCS2 . The proof is accomplished by simultaneous structural induction on S by writing proof scores in CafeOBJ. The base case init can be discharged straightforwardly. Let us consider the induction case stprd in the proof of inv2. The proof of stprd includes a sub-case whose proof score fragment is as follows: open MCS2-INV. op s: -> Sys2. ops p q r: -> Pid. eq pc(s,r) = l2. eq~p = r. eq glock(s) = nop. eq (topQ(s) = nop) = false. red inv2(s,p) implies inv2(stprd(s,r),p). close MCS2-INV is the module in which the specification of MCS2 and the predicates inv2 together with inv3 are available. false is returned when feeding the fragment into CafeOBJ. This is why we need a lemma to discharge the subcase. Let us focus on two last equations glock(s) = nop and (topQ(s) = nop) = false. This is because glock points to the last process of the virtual queue, while topQ is introduced in MCS2 to capture the top process of the virtual queue. If the last element of the virtual queue is nop, then the top element also should be nop. We then conjecture that the following predicate is an invariant wrt S MCS2 : eq inv4(S) = ((topQ(S) = nop) = (glock(S) = nop)).
inv4 says that topQ is nop if and only if glock is nop. Then, in the above fragment, inv4 can be used as a lemma to discharged the sub-case as follows: red (inv4(s) and inv2(s,p)) implies inv2(stprd(s,r),p).
The remaining sub-cases can be discharged likewise. To complete the proof of inv2, inv4 together with two more new invariants inv5 and inv6 are used as lemmas. They are as follows: We did not come up with the these lemmas from the beginning, but we have gradually constructed each of them when conducting formal verification. For example, inv4, together with inv5 and inv6, is constructed in the proof of inv2.

F. DISCUSSION
While proving that MCS protocol enjoys the mutual exclusion property with the induction-based technique, we used as a lemma the following in the proof: eq inv40(S,P) = (pc(S,P) = l3 or pc(S,P) = l4 or pc(S,P) = l5 or pc(S,P) = l6 or pc(S,P) = cs or pc(S,P) = l7 or pc(S,P) = l8 or pc(S,P) = l10 or pc(S,P) = l11) implies (not glock(S) = nop).
When a process p is located at l3, l4, l5, l6, cs, l7 or l8, because p has conducted fetch&store(glock, p) and has not conducted comp&swap(glock, p, nop), glock refers to p or another process but never nop. When a process p is located at l10 or l11, another process q is located at l3, l4, l5 or l6, which implies that q has conducted fetch&store(glock, q) and has not conducted comp&swap(glock, q, nop), and then glock refers to q or yet another process but never nop. Therefore, inv40 is likely to be an invariant wrt the state machine formalizing MCS protocol. However, we did not successfully complete proving inv40.
In our proof attempt of inv41, there are some sub-cases in which we need another lemma. Let υ 41 be an arbitrary state that represents the sub-cases. υ 41 can be depicted as shown in Fig 5 (a). To discharge the sub-cases, we need to use another lemma inv42 that is similar to inv41 but different from it: eq inv42(S,P,Q,R) = (glock(S) = Q and next(S,R) = Q and (pc(S,R) = cs or pc(S,R) = l7 or pc(S,R) = l8 or pc(S,R) = l10 or pc(S,R) = l11 or (pc(S,R) = l6 and not lock(S,R))) and (not P = R) and (not Q = R) and (not P = Q)) implies (not (pc(S,P) = l3 or pc(S,P) = l4 or pc(S,P) = l5 or pc(S,P) = l6)).
In our proof attempt of inv42, there are some sub-cases in which we need another lemma. Let υ 42 be an arbitrary state that represents the sub-cases. υ 42 can be depicted as shown in Fig 5 (b). To discharge the sub-cases, we need to use another lemma that is similar to inv42 and inv41 but different from them. What if we keep on doing this series of proof attempts? Let inv43 be the lemma needed to discharge the sub-cases of the proof attempt of inv42. Proving inv43, we must encounter some sub-cases where we need to use another lemma that is similar to inv43, inv42 and inv41 but different from them. Let υ 43 be an arbitrary state that represents the sub-cases. υ 43 can be depicted as shown in Fig 5 (c). The states υ 41 , υ 42 and υ 43 can be generalized as υ 4n that is depicted as shown in Fig 5 (d).
As described in Sub-sect. IV-D, if CafeOBJ made it possible to use an operator with a variable number of parameters, we could generalize the lemmas inv41, inv42 and inv43 as inv4n, where an arbitrary number (or variable number) n of processes are handled. Because CafeOBJ does not, however, inv4n cannot be expressed in CafeOBJ.
We, together with one more, discovered a different lemma than inv40 that is weaker than inv40 and successfully proved that the different lemma is an invariant wrt the state machine formalizing MCS protocol [61]. Please refer to the paper [61] for details.
Although it is possible to formally verify that MCS protocol enjoys the mutual exclusion property by either of the induction-based technique and the simulation-based technique, we found the proof by the simulation-based technique earlier than the one by the induction-based technique even though we started the latter formal verification earlier. This experience of ours demonstrates the power of the simulation-based technique.

VII. RELATED WORK
''Refinement'' (or step-wise refinement) has been intensively used in one main stream of formal methods, such as Vienna Development Method (VDM) (or VDM++) [31], Z method [63], Abstract State Machine (ASM) [8], B method [1] and Event-B [2]. Starting with a very abstract formal specification (or requirements specification), a bit more concrete formal specification is made such that the latter refines the former or the latter is a proper implementation of the former, which is repeated until an executable program or a detailed design that can be straightforwardly written in a programming language is obtained. This way to develop software systems is called ''correct-by-construction.'' It is formally proved that a bit more concrete formal specification is a refinement or a proper implementation of a bit more abstract formal specification. Refinement goes back to the work done by those among who are Milner [46], Hoare [29], Liskov et al., [36] and He et al. [27].
''Simulation'' is the reverse direction of refinement. Given an algorithm or protocol, an abstract version of the algorithm or protocol is made such that the abstract version simulates the algorithm or protocol and the simulation relation preserves some properties so as to verify that the algorithm or protocol enjoys the properties. It is necessary to formally prove that an abstract version simulates an algorithm or protocol and the simulation relation preserves some properties. Simulation has been intensively used in I/O-automata [38] invented by Nancy Lynch, et al. It has also been intensively used in process calculi, such as Communicating Sequential Processes (CSP) [30] and a Calculus of Communicating Systems (CCS) [47], [48], where bi-simulation has often been used. I/O-automata and process calculi have been used to formally verify concurrent and/or distributed algorithms or protocols. Simulation goes back to the work done by those among who are Park [56], Lamport [32] and Lynch [37].
Lynch and Vaandrager [40] have defined refinement as the simplest simulation. They have also defined several variants of simulation, such as forward simulation and backward simulation. Simulation from OTSs to OTSs used in the present paper corresponds to forward simulation.
''Abstraction'' [12] is one important concept that makes it possible to apply model checking for large-state or even infinite-state machines. Abstraction is a key concept in refinement and simulation and then we can say that refinement and simulation have been also used in model checking. Refinement is explicitly used in one significant technique in model checking: Counterexample-guided abstraction refinement (''CEGAR'') [11]. Some techniques that implement abstraction have been proposed. Among them are predicate abstraction [6], [14], [15], [26], [59] and equational abstraction [44], [45].
Mathematical induction has also been often used to formally verify that state machines enjoy invariant properties [9], [38], [42], [50], [60]. The proof that a state predicate p is an invariant wrt a state machine or a concurrent (or distributed) program that describes a state machine is carried out as follows: (1) the initial condition implies p or p holds in all initial states and (2) p is preserved by all statements in the program or all transitions in the state machine. This proof strategy suffices for what is called ''inductive invariants'' but not for generic invariants. Thus, they have used a generalized proof strategy: (1) the initial condition implies another state predicate q, (2) q is preserved by all statements in the program or all transitions in the state machine and (3) q implies p. There are cases such that it is necessary to introduce auxiliary variables into a system under formal verification so that we can prove that the system enjoys properties by mathematical induction. Given a system M and a state predicate p, we may need to modify M as well as p. Let M be the revised version of M , which is obtained by introducing auxiliary variables into M . Let q be the revised version of p such that q is an inductive invariant of M and q implies p. M can be regarded as an abstract version of M because of Proposition 3 and Lemma 5. This approach to formal systems verification with auxiliary variables plus mathematical induction uses simulation as we described in Sect. V. Lamport and Merz [34] have described how to introduce auxiliary variables into TLA+ specifications. They classify auxiliary variables into three kinds: history, prophecy and stuttering variables. History variables are used to record what has happened in the past (including the present). Prophecy variables are used to predict what will happen in the future. Stuttering variables are used to introduce stuttering steps. topQ we have used corresponds to a history variable. Lamport and Merz use auxiliary variables to make it possible to find a refinement map from a TLA+ specification to another TLA+ specification. We have used topQ to make an intermediate version MCS2 between MCS and MCS3 for the following purposes: (1) MCS3 observably equivalently simulates MCS2 and MCS2 observably equivalently simulates MCS, (2) we can formally verify that MCS3 enjoys the mutual exclusion property by the induction-based technique and then (3) we can conclude that MCS enjoys the mutual exclusion property.
We mention some recent advancements on refinement/simulation. Ge et al. [22] point out that there are two challenges when developing software systems with Even-B: (1) generating/writing executable programs based on the final Even-B models obtained by a series of refinements and (2) the proof gaps in the Event-B method and the tools, such as Rodin. To address the two challenges, they have proposed an intermediate verification language called High-Level Language (HLL) between Event-B model and C programming language. They claim that it is more tractable to prove the correctness of programs written in HLL than those in C; it is also reasonably doable to translate programs written in HLL to those in C than Event-B models to C programs.
Cyber-Physical Systems (CPS) are inevitable in modern life. Among them are smart home systems, aviation autopilot systems and autonomous robots. To develop reliable CPSs, studies have been conducted. Hybrid automata have been introduced and some model checkers that can handle hybrid automata have been developed. CSP has been extended to be able to model CPSs: HybridCSP. A proof assistant Coq has been used to prove the correctness of CPSs. Dupont et al. [18] claim that these existing research achievements need formal modeling expertise, where developers need to establish correctness using complex proof systems involving discrete and continuous mathematics features and proof rules. They have then proposed a systematic correctby-construction approach to designing hybrid systems based on the definition of architecture patterns: formally verified architecture patterns of hybrid systems [18]. They use Event-B and Rodin.
The logic used in ASM is first-order logic (FOL), while it is necessary to use higher-order logic (HOL) to handle many graph algorithms. To make it possible to deal with such graph algorithms with ASM, Ferrarotti et al. [19] have extended ASM so that its extension can deal with HOL. They have shown that it is possible to transform HOL formulas into second-order logic (SOL) ones and then that there exists a refinement from SOL formulas to FOL ones that can be described in the standard ASM.
It is often the case that programs are available, while highlevel formal specifications are not, although it is worth having the latter. Therefore, Ferrarotti et al. [20] have proposed a semi-automatic approach to generating high-level formal specifications from programs. The approach consists of two phases. The first phase automatically transforms Java programs into base-level ASM specifications. The second phase is a series of abstraction steps (counter-refinement steps) from more concrete ASM specifications to more abstract ASM specifications.
Dynamic distributed systems are different from static ones in that components, such as processes and nodes, are newly created and destroyed on the fly. To rigorously analyze such systems, it is preferable to have formal foundations for them. Attie and Lynch [5] have proposed dynamic input/output automata (DIOA) as such a foundation. DIOA makes it possible to change signatures of I/O-automata on the fly so that automata can be dynamically created and/or destroyed. DIOA enjoys simulation proofs inherited from (static) I/Oautomata. The current version of OTSs does not make it possible to handle dynamic systems. One possible piece of our future work is to extend OTSs by adopting the idea of DIOA.
To the best of our knowledge, no studies have been recently conducted on comparison of proofs done by simulation and mathematical induction. Nancy Lynch, et al. have conducted many case studies, demonstrating how useful simulation is to formally verify distributed algorithms and have used invariant assertions or mathematical invariant to formally verify that distributed algorithms satisfy invariant properties. Although they have implicitly shown when invariant assertions should be used and when simulation should be used for formal verification of distributed algorithms, they did not make any comparisons of invariant assertions and simulation, although they have made comparison of simulation techniques and (process) algebraic techniques for verifying concurrent systems [39].
Ogata and Futatsugi [52] have conducted one case study in which it is formally proved that Alternating Bit Protocol (ABP) enjoys an invariant property by both the inductionbased technique and the simulation-based technique. They conclude that they did not find any significant differences between the sizes of the proofs by both techniques.
The present paper has reported on the two case studies in which it is formally verified that the two mutual exclusion protocols enjoy the mutual exclusion property by the simulation-based technique. It is also formally verified that MCS protocol enjoys the mutual exclusion property by the induction-based technique as well [61], while it is not yet completed to attempt formally verifying that Anderson protocol enjoys the property by the induction-based technique. Size-wise, the proofs by both the induction-based technique and the simulation-based technique for MCS protocol are comparable. However, we completed the proof by the simulation-based technique earlier than the proof by the induction-based technique even though we started the latter formal verification earlier. Abstraction would be the key reason why we made it possible to complete the two formal verification experiments with the simulation-based technique. Hence, the present paper also demonstrates the power of abstraction. Note that the simulation-based technique needs to use the induction-based technique. We may need to use the induction-based technique to formally verify that an abstract OTS enjoys invariants. It is often the case to exclude unreachable states of OTSs while conducting proofs with the simulation-based technique. To this end, we need to use invariants of OTSs. We may need to use the induction-based technique to formally verify that OTSs enjoy invariants. We may also need to use the induction-based technique to formally verify that conditional equations are invariants of an OTS so that we can construct a CEM-OTS from the OTS.
OTSs are a restricted class of behavioral specifications [17], [24] in that each data component used can be entirely observed or can be entirely hidden. For example, OTSs never use a stack whose top element can only be observed and remaining elements cannot be. One important concept used in behavioral specifications is behavior equivalence. Two states are behaviorally equivalent if and only if any experiments (any sequence of actions) never distinguish the two states. Observable equivalence relation = S is behavioral equivalence of OTSs. Observably equivalent simulations use = S and then have something to do with behavioral equivalence of behavioral specifications in this sense.

VIII. CONCLUSION
The paper has demonstrated the power of the simulationbased technique through two case studies. The first one has formally proved that Anderson protocol enjoys the mutual exclusion property by making an abstract version A-Anderson, and using a simulation from the OTS formalizing Anderson to the OTS formalizing A-Anderson. The second one has formally proved that MCS protocol enjoys the mutual exclusion property by making two variants MCS2 and MCS3 of MCS such that MCS2 observably equivalently simulates MCS, MCS3 observably equivalently simulates MCS2 and proving that observably equivalent simulations preserve the mutual exclusion property.
We have used CafeOBJ, an algebraic specification language/system, as a formal specification language of systems and properties, and as a tool that supports our formal verification experiments. CafeOBJ is equipped with a proof assistant like Coq, Isabelle/HOL and PVS. There is the second implementation of CafeOBJ called CafeInMade [58]. CafeInMade is also equipped with a proof assistant called CiMPA [57]. The proof assistants for CafeOBJ support the induction-based technique but do not support the simulation-based technique. It is one piece of our future work to extend the proof assistants so that the simulation-based technique can be supported. There is an existing study [35] on automatic refinement checking for B method that has been integrated into ProB, a tool supporting B method. The automatic refinement checker is able to deal with finite-state systems, while we would like to treat unbounded-state systems.
It is not straightforward to come up with a simulation relation candidate from an abstract OTS and a concrete OTS. We did not immediately find the simulation relation from the OTS formalizing Anderson to the OTS formalizing A-Anderson. We did some trial and error steps to arrive at the final simulation relation. It would be very useful to have a methodology that helps users find a good simulation relation candidate from an abstract OTS and a concrete OTS, which is also a piece of our future work. We need to conduct some more case studies with both the simulation-based technique and the induction-based technique so as to further back up our claim.