Towards Support for Software Model Checking : Improving the Efficiency of Formal Specifications

The Property Specification (Prospec) tool uses patterns and scopes defined by Dwyer et al., to generate formal specifications in Linear Temporal Logic (LTL) and other languages. The work presented in this paper provides improved LTL specifications for patterns and scopes over those originally provided by Prospec. This improvement comes in the efficiency of the LTL formulas as measured in terms of the number of states in the Büchi automaton generated for the formula. Minimizing the size of the Büchi automata for an LTL specification provides a significant improvement for model checking software systems using such tools as the highly acclaimed Spin model checker.


Introduction
The process of model checking a system consists of developing a model of the system to be verified and writing specifications in a temporal logic such as Linear Temporal Logic (LTL) [1] or Computational Tree Logic (CTL) [2].In automata-based model checking, both the model M and the complement of the temporal specification S are represented by a special type of state machine called a Büchi Automaton (BA) [3].To check the consistency of M with S, the model checker calculates the intersection of M and S where S is the complement of S. If the intersection is empty, then M is consistent with S. In other words, if M and S each represent a set of specifications and if M ∩ S = ∅, then the system satisfies the specification; otherwise, the system is inconsistent with the specification and a counter-example is returned.
The process of writing formal specifications is not easy because of the required mathematical sophistication and depth of knowledge in the specification language.For this reason, tools that simplify the creation of formal specifications in logics such as LTL are of interest to the model checking community and others.In the case of automatabased model checkers such as Spin [4], it is important that these tools generate efficient formulas, since the model checker complements the formulas, translates the result into a BA, and intersects the BA with the automaton of the system.The size of the automaton that results from the intersection of two automata has as its upper bound the product of the number of states in each of the two.One way to avoid the classical problem of state space explosion is to minimize the number of states generated by the negation of the specification.This will reduce the number of states generated by the automaton of the intersection, and as a result, it will reduce the time required to model check a software system.
The Property Specification (Prospec) [5][6][7] builds on the Property Specification Patterns system (SPS) [8,9], and it uses property pattern and scope to assist in the specification of formal properties in LTL as well as other languages.Patterns are high-level abstractions that provide descriptions of common properties, and scopes describe the extent of program execution over which the property holds.Prospec also introduces the notion of composite propositions to allow for the definition of more complex behavior to represent the behaviors for patterns and scopes.
This paper introduces more efficient LTL formulas for patterns and scopes than those originally generated by Prospec.In defining the new formulas, we tried to limit the number of temporal operators in a formula because we believe this reduces the number of states in the neverclaim.The formulas are compared in terms of the number of states in the never-claim generated by the negation of these formulas since it is actually the complement of a formula that the model checker uses.To generate Büchi automata, we used the model checker SPIN, and the LTL to BA translators: LTL2BA [10], the Temporal Message Parlor [11], and LTL2NBA [12], all of which efficiently convert LTL specifications into BAs.Notice that some of these tools produce a BA in the form of a never-claim, which is a specific representation of BA used by the model checker Spin.In this article we use the terms Büchi automata and never-claims interchangeably.This paper also shows an approach for proving the equivalence of different LTL formulas.Finally, this paper describes the impact that more efficient formulas have when using composite propositions [6] to define pattern and scope limits.
The paper first presents a background on LTL and Büchi automata (BA), including the semantics of the languages.The Prospec tool is introduced in Section 3. Section 4 describes the new formulas and the process used to verify the semantic equivalence of the two sets of formulas.Section 4 also provides the results of the comparisons of the formulas.Finally, the impact of the work on composite propositions is presented in Section 5 followed by brief discussion and references.

Background
2.1.Linear Temporal Logic.This section briefly describes Linear Temporal Logic (LTL) and its semantics.A more detailed description of LTL can be found in Manna [13].
Temporal Logic has been used to verify concurrent systems.There are three well used types of temporal Logic: Linear Temporal Logic (LTL), Computational Tree Logic (CTL), and CTL * [3].Both LTL and CTL are subsets of CTL * .While CTL allows for branching type of behavior (i.e., semantically, formulas are defined both using the universal and existential quantifiers), LTL formulas describe specific path behavior (i.e., semantically, formulas are defined only using the universal quantifier).Formulas in this paper deal only with LTL.
LTL is used in various model checkers such as SPIN [4], NUSMV [14], and Java Path-Finder [15] and is also used in runtime verification of Java programs [16].
In LTL, a temporal formula is constructed inductively from a set of propositions P by applying Boolean connectives ¬ and ∨ and temporal operators next (X) and until (U) as follows.
(i) A proposition is a temporal formula.(ii) If p and q are temporal formulas, then the followings are also temporal formulas: (i) ¬p, (ii) p ∨ q, (iii) X p, (iv) pUq.
A temporal formula that makes use only of Boolean connectives ¬ and ∨ is called a state formula, whereas a formula that makes use of temporal operators X and U is called a temporal formula.
Let P be a set of propositions; let σ be an infinite sequence of states or computation, denoted by σ: s 0 , s 1 , . .., let be a set of states; let I(s) be an interpretation such that for all s ∈ , I(s) ⊆ P specifies the propositions that are true in state s.For a state formula, the satisfaction relation is defined as follows: for a state s ∈ and a proposition p in P, s satisfies p, denoted s p, if and only if p ∈ I(s).In addition, an inductive definition for the notion that a computation σ satisfies formula p at i > 0, denoted (σ, i) p, follows [1,13]: p if and only if s i p, where p is a state formula, (ii) (σ, i) ¬p if and only if (σ, i) p, (iii) (σ, i) p ∨ q if and only if (σ, i) p or (σ, i) q, (iv) (σ, i) X p if and only if (σ, i + 1) p, (vi) (σ, i) pUq if and only if (σ, k) q for some k ≥ i, and (σ, j) p for all j, i ≤ j < k.
Additionally, the temporal operators (eventually, always, and weak-until) are derived as follows: (i) p ≡ trueU p,

Büchi
An execution is a sequence s 0 , s 1 , . .., where for all is i ∈ Q and for all i ≥ 0, (s i , s i+1 ) ∈ δ.A finite execution is an accepting execution if it terminates in a final state s f ∈ F. An infinite execution, also called an w-execution or w-run, is accepting if it passes through a state s f ∈ F infinitely often.An empty BA (accepts no words) is one that either terminates in a state that is not an accepting state or has no accepting state that is reachable from the initial state and that is visited infinitely often.The set of executions accepted by a BA is called the language of the BA.
Languages of BAs represent a superset of those of LTL; every LTL formula can be represented by a BA.When a BA is generated from an LTL formula, the language of the BA represents only the traces accepted by the LTL formula.For example, the BA in Figure 1 represents the language accepted by the LTL formula (a ∪ b).This formula specifies that b holds in the initial state of the computation, or a holds until b holds.The language of the BA in Figure 1 accepts the set of traces {b. .., ab. .., aab. .., . .., aaab}.Notice that each of these traces passes through the accepting state Final.This state is both reachable from the initial state and is visited infinitely often (by virtue of the self-transition marked 1).
Various work has been done on the translation of LTL to BA to reduce the number of states in the resulting BA and to speed up the process of the BA generation.This paper compares three LTL to BA translators (along with the SPIN model checker) in the number of states in the BA generated from those LTL formulas for patterns and scopes.
(i) Temporal Message Parlor (TMP) [11] is the work of Kousha Etessami at Lucent Technologies.
(ii) LTL2BA [10] is the work of Denis Oddoux and Paul Gastin at the University of Paris 7, France.
(iii) LTL2NBA [12] is the work of Carsten Fritz of the Department of Computer Science at Christian-Albrechts University.

Prospec
The Property Specification tool (Prospec) [5][6][7] builds on the Specification Patterns System (SPS) [8,9] by facilitating the identification of SPS patterns and scopes as well as validation of specifications.SPS defines patterns and scopes to assist the practitioner in formally specifying software properties.Patterns capture the expertise of developers by describing solutions to recurrent problems [17].Each pattern describes the structure of specific behavior, defines the pattern's relationship with other patterns, and defines the scope over which the property holds.
The main patterns defined by SPS are universality, absence, existence, precedence, and response.Universality P states that property P is true at every point of the execution; absence P states that P is never true during the execution; existence P states that P is true at some point in the execution; precedence (T, P) states that P holds before T holds; response (P, T) states that if P holds, then T must hold at a future state.Response properties represent a temporal relation called cause-effect between two propositions.Prospec displays traces of computation to illustrate the subtle issues that exist within the different patterns and scopes, and it displays a decision tree to guide the user through a series of decisions in selecting the appropriate pattern and/or scope.Given a computation represented as a sequence of states, and a finite set of events E, a trace of computation is a list indicating, for each moment of time t, which events from the set E occur at t. Figure 2 shows the Prospec window for selecting a pattern and the traces of computation that are given to elucidate each pattern.Prospec enhances the definition of patterns and scope characteristics provided in the SPS website [18] by explicitly defining the relationships among the proposition that define a pattern and/or a scope and the boundaries defined by each scope.Tables 1 and 2 give those characteristics for pattern and scope, respectively, as they appear in the Prospec tool.These are the characteristics that were used by Salamah et al. [19] to verify the correctness of the LTL formulas for patterns and scopes.Prospec extends SPS by introducing a classification for defining sequential and concurrent behavior.This is accomplished by including composite propositions (CPs) as shown in Figure 3. Section 4 discusses composite propositions in more detail.While Prospec builds on SPS in defining the mapping of patterns and scopes into LTL, it makes some changes to those LTL formulas for patterns and scopes defined in SPS.(Comparing the new formulas in Section 4 with the original SPS formulas showed that the new formulas were at least as efficient in all cases with the exception of the case of the Response pattern within the After L Until R scope in which SPS formula produced one fewer state in the never-claim as produced by LTL2BA, LTL2NBA, and TMP).Salamah et al. [19] provide a listing of those modifications and the justification behind the changes.Table 3 presents Prospec's LTL mappings for each pattern and scope combination.These formulas along with the ones defined in Section 3 are the ones being compared in this paper.
Note that Prospec added the definition of strict precedence, which is not available in SPS.This pattern describes the situation where S strictly precedes P, where S and P are events or conditions.Unlike the regular precedence pattern, S and P cannot hold at the same state in this pattern.Use of Strict Precedence enforces that S and P cannot hold at the same state.

New Pattern Formulas
The goal of the work presented by this paper is to improve the efficiency of the LTL specifications generated by Prospec.The efficiency is measured by the number of states in the BA corresponding to the negation of LTL specification.The BAs were produced using the SPIN model checker Version 4.2.7, and the LTL to BA translation tools LTL2BA, LTL2NBA, and the Temporal Message Parlor (TMP), all of which are available at a website maintained by Carsten Fritz [20].In order to reduce the number of states in the BA, our goal is to reduce the number of temporal operators within each formula.We were able to achieve this in 17 out of 30 formulas originally defined by Prospec.Table 4 lists the new improved formulas, and Table 5 lists the results of the comparison between Prospec's original formulas and the new ones.In all the cases where we were able to reduce the number of temporal operators, the BAs generated by SPIN contained fewer states.Only in the case of the Response pattern with an After L Until R scope did the new formula generate more states when used by the three BA generators.All the translation tools produced BAs with the same number of states for each new formula except in the case of the strict precedence with the after L until R scope.In this case, the generated BAs by LTL2BA, TMP, and LTL2NBA produced one fewer state than the one generated by SPIN.This is significant, as it allows SPIN users to use the new formulas without having to use the other translators to produce neverclaims that have to be inserted into the Promela code.

Equivalence of LTL
Formulas.An approach to demonstrating the equivalence of two LTL formulas is to compare the languages of the BAs generated from them.If the languages are identical, then the two LTL formulas are equivalent.To show this, we show that the first language is a subset of the second, and that the second is a subset of the first.
Given two LTL formulas F 1 and F 2 , let Label each transition in δ 1 and δ 2 with the The universality property is also known as safety or invariant (T) Precedes (P) (1) T holds before P holds, where T and P are events or conditions (2) T may hold several times before P holds (3) P does not hold before T holds (4) P may hold at the same state as T (5) If T holds, then P may or may not hold (6) If T holds, then T may or may not hold when P holds (7) The precedence property represents a cause-effect relation, where T denotes a cause and P denotes an effect (8) There is no effect P without a cause T (9) T precedes P is also known as T before P (T) Strictly Precedes (P) (1) T holds before P holds, where T and P are events or conditions (2) T may hold several times before P holds (3) P does not hold before T holds (4) P does not hold at the same state at which T holds (5) If T holds, then P may or may not hold (6) If T holds, then T does not hold when P holds (7) The precedence property represents a cause-effect relation, where T denotes a cause and P denotes an effect (8) There is no effect P without a cause T (9) T precedes P is also known as T before P (T) Responds to (P) (1) P must be followed by T, where P and T are events or conditions (2) Some T follows each time that P holds (3) The same state at which T holds may follow two or more states at which P holds (4) T may hold at the same state as P holds (5) If T holds, then P may or may not hold at a previous state (6) The response property represents a cause-effect relation, where P denotes a cause and T denotes an effect (7) If cause P holds, then at some future state effect T holds (8) T responds to P is also knows as T follows P names of the propositions that are true in the state entered by the transition.Let Σ be the union of all the transition labels in B 1 and B 2 .Let L 1 be the language accepted by B 1 and let L 2 be the language accepted by B 2 .To show that F 1 and F 2 are equivalent, we show that (Since L 1 ∩ ¬L 2 is empty, ¬L 2 must not contain any element of L 1 .Since L 1 and L 2 are both subsets of Σ * , L 2 must contain every element of L 1 .Thus, L 1 ⊂ L 2 .Similarly, L 2 ⊂ L 1 .Thus, L 2 ≡ L 1 .B 1 and B 2 are equivalent if they accept the same language, thus B 1 ≡ B 2 , and F 1 ≡ F 2 .)Given two formulas F P and F N , where F P is the original Prospec formula and F N is the new formula, we used LTL2BA to generate a BA 1 for (F P ∧ ¬F N ) and a BA 2 for (¬F P ∧ F N ).To assert that F P ≡ F N we have to check that BA 1 and BA 2 are both empty.To do this we developed a simple computer tool that checks the emptiness of a BA.

Tool for Checking Emptiness.
By definition a BA is empty if it does not contain a reachable accepting state that is visited infinitely often [3].The LTL Validation Tool is designed to ensure that a given LTL formula is valid (i.e., its BA contains at least one reachable accepting state that is visited infinitely often).In this work, the tool is used to prove the equivalence of two formulas.As discussed above we show equivalence of two LTL formulas F P and F N by checking that resulting BAs for (F P ∧¬F N ) and (¬F P ∧ F N ) are both empty.
This validation tool makes use of LTL2BA's Java interface (JLTL2BA) to translate the formulas (F P ∧ ¬F N ) and

Global
(1) The scope denotes the entire computation (2) The scope includes all the states in the computation (3) The interval defined by the scope occurs once in a computation Before R (1) The scope denotes a subsequence of states or events (an interval) that begins with the start of computation and ends with the state or event immediately preceding the event or state at which R holds for first time in the computation (2) The interval does not include the state or event associated with R (3) The interval defined by the scope occurs once in a computation (4) One or more events (conditions) may be associated with R; a condition is a proposition and an event is a change in value of the proposition from one state to the next After L (1) The scope denotes a subsequence of states or events (an interval) that begins with the first event or state at which L holds and ends with termination of computation (2) The interval includes the state or event associated with L (3) The interval defined by the scope occurs once in a computation (4) One or more events (conditions) may be associated with L; a condition is a proposition and an event is a change in value of the proposition from one state to the next Between L and R (1) The scope denotes a subsequence of states or events (an interval) that begins when L holds and ends with the state or event immediately preceding the event or state at which R holds (2) Event or condition L must hold and, at a different event or state in the future, R must hold (3) The interval includes the state or event associated with L (4) The interval does not include the state or event associated with R (5) The interval defined by the scope may occur more than once in a computation (6) Multiple intervals may be defined within an interval when L holds more than once before R holds (7) One or more events (conditions) may be associated with L and R The scope denotes a subsequence of states or events (an interval) that begins when L holds and ends either with the state or event immediately preceding the event or state at which R holds, or begins when L holds and ends with the termination of computation (2) The interval includes the state or event associated with L (3) The interval does not include the state or event associated with R (4) The interval may repeat during a computation (5) If L holds and R does not hold, the interval ends with termination of a computation (6) The interval defined by the scope may occur more than once in a computation (7) Multiple intervals may be defined within an interval when L holds more than once before R holds (8) One or more events (conditions) may be associated with L and R (¬F P ∧ F N ) into the corresponding BAs.Once the BAs are available, the tool tries to assert that there are no reachable accepting states that are visited infinitely often.This is done by first finding all states reachable from every given state, then by linking these together to form cycles.Should the tool find a single acceptance cycle, that is, an acceptance state which is within a cycle then we declare that the BA is not empty.
Figure 4 shows the never-claim generated by the LTL Validation tool (through interfacing with LTL2BA) for the LTL formula "[]p → q" and the result generated by the tool to check for the emptiness of the BA (never-claim).Obviously the BA for this formula is not empty, and as a result the tool states that the formula is Valid (i.e., there is a reachable acceptance state that is within a cycle).Figure 5, on the other hand, shows the never-claim and the tool's result for the formula (¬

([]((l ∧ ¬r) → (([]p) ∨ (pUr))))) ∧ ([]((l ∧ ¬r) → (¬((p ∧ ¬r)U((¬p) ∧ ¬r))))
).This formula is the result of ANDing the negation of Prospec's original LTL formula for Universality of P within the After L Until R scope with the new LTL formula for the same pattern/scope combination.The result returned by the tool specify that there is no reachable acceptance state that is within a cycle (i.e., the BA is empty).Figure 6 shows the graph of the neverclaim in Figure 5.
Similarly, we used the LTL Validation tool to generate the BA for the LTL formula of ANDing Prospec's original LTL formula for Universality of P within the After L Until R scope with the negation of new LTL formula for the same pattern/scope combination.Figure 7 shows the graph Figure 4: LTL validation tool's output for the formula []p → q.

¬((¬R)U(P ∧(¬R)∧(([]((¬T)∧¬R))∨((¬T)UR))))))
Strict Precedence In our work we performed the above mentioned procedure for all the new and original formulas in Tables 3  and 4, and the results showed in every case that the  new formula is semantically equivalent to the original one.

Impact on the Use of CP
Mondragon et al. [7,21] introduced composite propositions (CPs) classes to define the structure of multiple propositions to capture sequential and concurrent behavior.The work provided a CP taxonomy that can be used in the property elicitation and specification process.The taxonomy guides practitioners in formally specifying properties, illuminating the subtleties associated with multiple events and conditions.When relations have not been carefully analyzed, CP classes can expose incompleteness or ambiguities.CP classes defined as conditions are used to describe concurrency, and those defined as events are used to describe activation or synchronization of processes or actions.Table 6 presents the semantics of the CP classes in LTL.negation of this formula produces a BA with (i) 6 states using SPIN, (ii) 5 states using LTL2NBA and TMP, (iii) 9 states using LTL2BA.
The previous example shows that although the difference in the number of states generated by the original LTL formulas in Table 3 and those in Table 4 might seem negligible, this difference becomes more significant when using the notion of CP classes to specify properties.
To further prove this point, Table 7 provides a sample comparison of the original and new formulas when some propositions are replaced by certain CP classes.The table shows the number of states generated by SPIN, LTL2NBA, TMP, and LTL2BA for formulas of patterns and scopes using CP.Note that these values were generated running the tools on the negated formulas for the specified pattern and scope.Old indicates Prospec's original formula, and New indicates the new formula.In Table 7 only one of the propositions was replaced by a CP class at a time.In generating this sample, we only used three of the CP classes: Parallel E , Eventual C , and Strict Eventual C .We used these CP classes in replacing one of the propositions in four of the pattern/scope combinations; Absence of P After L, Existence of P After L, universality of P After L, and Q Responds to P After L. The choice of the CP classes and the pattern/scope combinations was based on the fact that direct substitution of the CP classes into the formulas for these pattern/scope formulas was possible.The CP class replacing a proposition is indicated by the subscript attached to the proposition.The number in the subscript refers to the number of the CP class in Table 6.Each CP class was comprised of two or three propositions.The goal was to include three propositions in each CP class; however in some cases some translation tools (mostly TMP and SPIN) could not generate BAs for the old Prospec formulas with CP classes containing three propositions.Those cases where CP classes were made of only two propositions are indicated with the symbol( * ).

Discussion
Tools that assist in the generation of formal specifications in LTL are important to the model checking community as they relieve the user from the burden of writing specifications in a language that is hard to read and write.Without the help of tools such as Prospec, the user might create faulty specifications.These tools must generate specifications that correspond to the intent of the user.Prospec was demonstrated to provide such support [19].It is also important that these tools generate efficient formulas, since one of the main challenges of model checking is the state explosion problem.The smaller the size of the automata an LTL formula generates, the less likely that this problem will occur.Although this might not appear significant in the basic pattern-scope formulas as generated originally by Prospec, an example and a sample comparison given in the previous section show the effect on the number of states generated when using less efficient formulas as the base formulas when incorporating CP classes.The sample comparison also shows that in some cases, some translation tools could not generate BAs for the old Prospec formulas in which one of the propositions was replaced with CP classes containing three propositions.
The new formulas provided by this work generate BAs with fewer states in almost all pattern/scope combinations regardless of LTL to BA translator used.In addition, the BAs of the new formulas generated by SPIN seem to always be comparable to those generated by the other more efficient translators.This is significant to SPIN users, since those users do not need to use different LTL to BA translators and manually insert the resulting never-claim into the Promela code.
Another result of this work is that we are able to provide the user with more than one LTL mapping to the same pattern-scope combination.In some cases we can provide the user with three LTL formulas (considering the formulas provided by SPS) for a specific pattern and scope (Absence of P Before R, e.g.).This, along with the detailed descriptions of patterns and scopes (such as timelines) provided by the Prospec tool, enhances a user's understanding of LTL and can be used as an educational tool.Table 8 shows the formulas generated using the original Prospec formulas while Table 9 provides those generated using the new formulas.

Final Initial a b 1 Figure 1 :
Figure 1: BA for "a ∪ b".

Table 1 :
Summary of characteristics for patterns in Prospec.Event or condition P does not hold within the states defined by the scope of interest (2) The absence property is also known as alarm

Table 2 :
Summary of characteristics for scopes in Prospec.

Table 3 :
Prospec's original LTL formulas for pattern and scope.

Table 5 :
Comparison results 1.This BA obviously does not contain a cycle that passes through an accepting state.The only accepting state in the BA is accept-S3.Although this state is reachable from the initial state, it is not visited infinitely often (i.e., there is no cycle that contains this state).As expected, the LTL Validation tool returned the message "There's no reachable acceptance cycle within this BA".Since both the BAs for ANDing the negation of Prospec's original LTL with the new LTL formula and for ANDing Prospec's original LTL formula with the negation of the new LTL formula are both empty, we conclude that both formulas are equivalent.

Table 6 :
CP semantics in LTL (subscripts C and E stand for condition and event, resp.).