Using TAME to Prove Invariants of Automata Models: Two ... - CiteSeerX

Using TAME to Prove Invariants of Automata Models: Two Case Studies  To be presented at FMSP '00, Portland, OR, August 24-25, 2000

Myla Archer

Constance Heitmeyer

Elvinia Riccobene

Naval Research Laboratory Code 5546 Washington, DC 20375

Naval Research Laboratory Code 5546 Washington, DC 20375

[email protected]

[email protected]

Dipartimento di Matematica e Informatica Universita` di Catania Viale A. Doria 6, I-95125 Catania, Italy

[email protected] ABSTRACT

TAME is a special-purpose interface to PVS designed to support developers of software systems in proving properties of automata models. One of TAME's major goals is to allow a software developer who has basic knowledge of standard logic, and can do hand proofs, to use PVS to represent and to prove properties about an automaton model without rst becoming a PVS expert. A second goal is for a human to be able to read and understand the content of saved TAME proofs without running them through the PVS proof checker. A third goal is to make proving properties of automata with TAME less costly in human time than proving such properties using PVS directly. Recent work by Romijn and Devillers et al., based on the I/O automata model, has provided the basis for two case studies on how well TAME achieves these goals. Romijn speci ed the RPC-Memory Problem and its solution, while Devillers et al. speci ed a tree identify protocol. Hand proofs of speci cation properties were provided by the authors. In addition, Devillers et al. used PVS directly to mechanize the speci cations and proofs of the tree identify protocol. In one case study, the third author, a new TAME user with no previous PVS experience, used TAME to create PVS speci cations of the I/O automata presented by Romijn and Devillers et al. and to check the hand proofs of invariant properties. The PVS speci cations and proofs of Devillers et al. provide the basis for the other case study, which compares the TAME approach to an alternate approach which uses PVS directly. Keywords

Software engineering, software requirements analysis, formal methods, veri cation, theorem proving.

This research is funded by the Oce of Naval Research.

1. INTRODUCTION

Several authors [25, 8, 9, 7] have found that the PVS speci cation language and similar strongly typed, higher-order logic languages are well suited to the formalization of system speci cations. All report that appropriately structured PVS speci cations can be understood by practitioners, such as design engineers and requirements analysts. Yet, a number of barriers exist to more widespread industrial use of formal techniques such as PVS. Although Miller notes in [25] that engineers at Collins Aviation learned to use PVS, the authors of each of [25, 8, 9, 10] concede that in general practitioners themselves may be unwilling or unable to create formal speci cations or to perform analysis of the speci cations using the PVS proof checker. Further, Butler et al. [8] observe that one barrier to transferring formal methods technology to industry is that: Training the industrial experts to use the formal techniques, especially to develop skill in veri cation, [is costly]. The high cost of training industrial experts is not the sole barrier to more general use of PVS (or other theorem proving systems) to formalize and to prove properties of speci cations. For a given system, a user must discover an appropriate representation in the language of the theorem prover. Formal proofs of system properties will be in uenced by the details of the representation, the particular reasoning steps available in the theorem prover, and the manner in which the properties are formalized. The eort required therefore is substantial even for those who have mastered the use of the theorem prover. Moreover, direct use of any general theorem prover can encourage users to adapt both speci cations and proofs to the needs of the prover rather than to the conventions associated with the problem domain. As a result, practitioners may nd it dicult to relate the formalization of their system and formal proofs of its properties to their understanding of the system behavior and their beliefs as to why it has certain properties. We agree with Butler et al. [8] when they state that: [T]he formal methods researchers must be willing to adapt their methods to the problem domain rather than ght to change the existing methodologies to conform to their needs. TAME (Timed Automata Modeling Environment) [3, 5, 6, 2] is a specialized interface to PVS that is intended to re-

move, or at least reduce, the barriers to more general use of PVS in verifying automata models. It supports the creation of PVS descriptions of three dierent automata models: Lynch-Vaandrager (LV) timed automata [23], I/O automata [21], and the automata model that underlies SCR speci cations [16]. Further, TAME supports formulating properties of these automata in standard logic and proving the properties using reasoning \natural" to humans. A major goal of TAME is to improve on the direct support that PVS provides for specifying, and proving properties of, automata. To make PVS speci cations of automata easy to create from automaton descriptions, TAME provides templates for specifying automata. To make PVS proofs of properties of automata easy to create, TAME provides PVS strategies which support the kinds of proof steps normally found in hand proofs of invariant properties of automata. In particular, TAME is intended to support straightforward construction of a mechanized proof of an invariant property from a high level hand proof that expresses an application expert's explanation of why the property should hold. In recent work by Romijn [28, 27] and Devillers et al. [12, 11], example systems to be implemented in software were speci ed and veri ed using the I/O automata model. This work, together with the availability of a volunteer TAME user with no previous PVS experience (the third author), gave us an opportunity to evaluate the extent to which TAME has achieved its goals. Both [28] and [12] provide descriptions of I/O automata and formulations of their properties. References [27] and [11] provide hand proofs of most of the properties in [28] and [12] in varying degrees of detail. Thus, the third author had several example speci cations and proofs to which she could apply TAME. In addition, reference [12] describes the PVS speci cation and proofs for one application, an I/O automaton called TIP , with a pointer to the actual speci cation and proofs on the web. This gave us the opportunity to compare the use of TAME with the more direct use of PVS on one particular problem. Section 2 of this paper provides a high level description of TAME, its templates, and its strategies. Section 3 then compares the PVS approach to speci cation and proof for TIP [12] to the TAME approach to the same problem. (Although this case study was done after the study of TIP by the third author discussed in Section 4, we describe it rst because it clari es the dierence between using PVS through TAME and using PVS directly.) Section 4 describes the experience of the third author in applying TAME to the examples of references [28, 27, 12, 11], with particular attention to 1) the time and eort required and 2) the adequacy of the TAME proof steps for mechanizing the proofs of invariants. Section 5 discusses the results of Sections 3 and 4 and describes some improvements in TAME that resulted from the case study in Section 4. Finally, Section 6 describes related work, and Section 7 presents our conclusions. 2. TAME

For software developers in industry, model checking is often viewed as more practical than theorem proving for establishing properties of software systems. While clearly an important technique for developing correct software systems, model checking does not solve all of a software developer's problems. For example, although model checking is often described as automatic and therefore requiring less exper-

tise from the user, the user, due to the state explosion problem, must typically model check an abstraction of a given system rather than the full system. Finding the appropriate abstraction often requires user ingenuity and creativity. Even when abstraction is used, state explosion can prevent a model checker from running to completion, and thus from establishing the correctness of a property. Moreover, in speci cations involving parameters, model checking alone can only check correctness for speci c (usually small), rather than arbitrary, values of the parameters. The protocols from [28] and [12] involve both parameters and another feature| complex data types|problematic for a model checker. Thus, for the veri cation of these and similar examples, theorem proving is necessary. TAME is intended to reduce the human eort associated with mechanical theorem proving using PVS. To achieve this, TAME provides an interface to PVS [3, 5, 6, 2]. This interface consists of a set of templates for specifying automata, a set of standard theories, and a set of standard PVS strategies. Below, we provide an overview of the templates, theories, and strategies, and how they are related. We also discuss the major goals which have guided the design of the TAME strategies. TAME Templates. TAME currently provides templates for each of the three classes of automata mentioned in Section 1: LV timed automata, I/O automata, and SCR automata. Each template provides a standard structure for de ning an automaton. Because LV timed automata are essentially I/O automata with time added, the template originally designed for specifying LV timed automata was easily adapted to specifying I/O automata. To de ne an automaton of either of these two classes, the user provides the information indicated in Figure 1. iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii c c c Template Part User Fills In Remarks ic iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii c c c c c actions c Declarations of c The nondefault cases of the c ic iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii c non-time-passage actions c actions datatype c c MMTstates c Type of the “basic state” c Usually a record type c ciiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii c representing the state variables c c c c c c c OKstate? c An arbitrary state predicate c Default is true c ic iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii c restricting the set of states c c c enabled_specific c Preconditions for all the c enabled_specific(a) = c ciiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii c non-time-passage actions c specific precondition of action a c c c c c c trans c Effects of all the actions c trans(a,s) = state reached c ic iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii c c from state s by action a c c start c State predicate defining the c Preferred forms: s = ... or c c c initial states c s = (# basic := basic(s) c c c c WITH ... c c c c c ... #) ic iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii c c c c const_facts c Predicate describing relations c Optional c cciiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii cc assumed among the constants cc cc

Figure 1: Information in the TAME template

Speci cations of I/O automata in the style used by Devillers et al. [12] and Romijn [28] (see Appendix A for an example) can be easily translated into TAME speci cations. The de nitions of the actions of the I/O automaton provide the names and argument types needed for their TAME declarations, preconditions and eects. The de nitions of the state variables and their types in the I/O automaton speci cation provide the information needed to de ne the type of the basic state as well as any needed auxiliary type de nitions in the TAME speci cation. The initial state information for the I/O automaton is translated into the initial state predicate start of the TAME speci cation. Finally, any constants and predicates relating constants de ned for the I/O automaton can be represented in the TAME speci ca-

tion using constant declarations and the axiom const facts. TAME does not provide automated support for composing automata or reasoning directly about an automaton de ned as a composition. However, when an I/O automaton is de ned as the composition of two or more other I/O automata (this happens with some of the automata in [28]), the user can combine the information extracted from the individual automaton descriptions to produce a single TAME speci cation in a (usually) straightforward way.

TAME Proof Steps. The standard strategies of TAME

are designed to support mechanical reasoning about automata using proof steps that mimic human proof steps. These strategies are based on type and name conventions enforced by the templates, the TAME standard theories, and additional special de nitions, auxiliary local theories, and local strategies that can be generated from a particular template instantiation. For example, lemmas in the standard theory machine support the induction strategy AUTO INDUCT (see Figure 2). The auxiliary local theories contain lemmas used to support rewriting and forward chaining needed in \obvious" reasoning about the particular application. Reference [2] lists the TAME user strategies useful for I/O and LV automata, and describes their eects. These strategies implement proof steps typically used in hand proofs of automaton properties. Hand proofs of invariant properties typically contain only proof steps from a limited set. Figure 2 lists the most common proof steps used in invariant proofs and names the TAME strategies that implement them. TAME strategies also exist for several steps needed less frequently than those listed in Figure 2. iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii ciiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii c c c Proof Step TAME Strategy Remarks c c c c c Break down into base case and c AUTO_INDUCT c For starting an c c induction (i.e., action) cases, and c c induction proof c cido c c standard first steps of each case iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiic c c c c Appeal to precondition of an APPLY_SPECIFIC_PRECOND Used when needed c c c c ciaction c c in induction cases c iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii c Apply the inductive hypothesis c APPLY_IND_HYP c Used when needed c c c c c c to argument(s) other than the c c in induction cases; c skolem constant(s) ci(default) c c needs argument(s) c iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii c Perform the standard initial steps c DIRECT_PROOF c For starting a c c c c c the direct proof of an invariant c iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii ciin c non-induction proof c c Apply an auxiliary invariant c APPLY_INV_LEMMA c Used in any proof; c c lemma c c needs argument(s) c ciiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii c c c c Break down into cases based c SUPPOSE c Used in any proof; c cion c c a predicate needs boolean argument iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiic c c c c c Apply “obvious” reasoning, e.g., c TRY_SIMP c Used for “it is now c equational, datatype c cipropositional, c obvious” in any proof c iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii c Use a fact from the mathematical c APPLY_LEMMA c Used in any proof; c c c c c for a state variable type citheory iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii c c needs argument(s) c

Figure 2: Common steps for invariant proofs and their TAME strategies1 Major Goals of the TAME Proof Steps. One major goal of the TAME proof steps is to save the user from much of the tedium typical of proofs done directly in PVS. One technique for achieving this (used in almost all of the TAME strategies) is to incorporate repeated patterns of steps. Several repeated patterns are incorporated into the TAME strategy AUTO INDUCT. In some cases, a repeated pattern becomes a single proof step. For example, the TAME strategy called APPLY INV LEMMA, with the appropriate arguments, introduces the desired invariant lemma, instantiates it, expands the invariant, and dis1 Here and below, a name in bold capital letters denotes a TAME strategy.

charges the reachability condition that is the hypothesis of the lemma. Another technique TAME uses to eliminate tedium is to automate certain inferences which are \obvious" to humans but which, in PVS, require detailed user guidance together with knowledge of the behavior and some of the more obscure proof steps of the PVS prover. Several such inferences relate to the PVS DATATYPE construct. For example, if con and des are a corresponding constructordestructor pair in a datatype A, it is obvious to a human that con(des(a)) = a whenever a is a \con" value of A. To establish this needed fact in a proof, the PVS user must apply the PVS step APPLY-EXTENSIONALITY. Establishing other simple facts about data types can require the PVS steps REPLACE and CASE to do explicit substitution and judicious case splitting. The auxiliary local theories that can be generated from a template instantiation provide the conditional rewrite rules and lemmas used by the TAME strategy TRY SIMP to make such inferences automatic. A second major goal of the TAME proof steps is to make saved PVS proofs understandable by humans without executing them in PVS. Saved TAME proofs have a clear structure, with the meanings of the proof branches indicated by comments automatically generated by TAME. The meanings of the individual TAME proof steps can be inferred from their names and arguments. In verbose mode, TAME prints extended comments showing the exact facts introduced, so that the reader of a proof does not need to look up particular lemmas, preconditions, etc. (Sections 3 and 5 contain example TAME proofs.) Finally, the TAME proof steps are designed to give users improved feedback from PVS in the course of a proof, through appropriate labels on formulae that indicate their origin, and hence their signi cance. For example, the strategy AUTO INDUCT labels formulae in subgoals corresponding to induction cases according to whether they come from the precondition, inductive hypothesis, or inductive conclusion, or express the fact that the prestate or poststate of an induction step is reachable. When the TAME step SUPPOSE is applied to an assertion argument P, the current subgoal will be split into two subgoals, one with the hypothesis P labeled Suppose and the other with the hypothesis not(P) labeled Suppose not.2 Facts introduced with APPLY INV LEMMA or APPLY LEMMA will be given a label lemma derived from the name of the lemma. In later subgoals, the descendants of a labeled formula retain the labels of their parent and are thus useful in indicating the reason for the presence of new formulae. The ability to label formulae, a recent new feature of PVS, is important in the execution of, as well as the feedback from, the TAME strategies. 3. FIRST CASE STUDY

Reference [12] describes the direct use of PVS to mechanize the proofs of properties of an automaton called TIP, a tree identify protocol. Below, we contrast the TAME approach with the direct PVS approach, drawing from the third author's results from applying of TAME to TIP. For brevity, 2 Technically, because PVS does not allow negative formulae to appear at the top level of a sequent, the hypothesis \not(P)" in the \Suppose not" subgoal will appear as \P" in the \wrong half" of the sequent (assuming P itself is not a negation).

hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh

To prove: For every reachable state s, for every edge e, length(mq(e,s))

: : :

3232 3231 3231 324 3241 325

>;
; < >

: : :

: :

: :

3233 : : :

3242 33

>;
;


>

I4

^ e 6 f ) init v _ child e _ child f

Assume a = C KN OW N (v), v 2 V . s j= I4 . Take arbitrary f; g; v such that target(f ) = target(g ) = v ^ g 6= f . . s j= init(v ) _ child[f ] _ child[g] . . Case distinction on v = v . . Assume v = v . . . s j= child[f ] _ child[g ] . . . t j= child[f ] _ child[g ] . . . t j= init(v ) _ child[f ] _ child[g ] . . Assume :(v = v) . . . s j= init(v ) _ child[f ] _ child[g ] . . . t j= init(v ) _ child[f ] _ child[g ] . . t j= init(v ) _ child[f ] _ child[g] . t j= I4 3

>;

>

Figure 7: Complete TAME proof (verbose) of < >

:

>

>

: : :

32

I4

>

: : :

=

( )

[ ]

[ ]

(by IH)

0

0

0

0

0

0

0

(pre. C KNOWN (v ) and f; g 2 to(v)) (e. C KNOWN (v ) does not change child ) (by ) (e. C KNOWN (v ) does not change child or init [v ] by ) (def. I4 ) 0

Figure 8: Nontrivial branch of Lamport-style proof of 4 I

f

g

>

g




to v

I

5.2 Explaining TAME Proofs

child(e,prestate) ∨ child(f,prestate) ∨ e = f by appealing to the specific precondition of children_known(childV_action) in the state prestate. Instantiating the second part of this precondition with e_theorem and f_theorem, the remainder of the proof in this case is now obvious. e_theorem and f_theorem belong to the subtype The fact that tov(childV_action) of the type Edges is also obvious. The proof in the case v_theorem =/ childV_action is obvious. hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh