Verication of Reactive Systems. Using DisCo and PVS. Pertti Kellomaki. Tampere University of Technology. Finland

Transcription

1 Verication of Reactive Systems Using DisCo and PVS Pertti Kellomaki Tampere University of Technology Software Systems Laboratory Finland Abstract. We have provided mechanical verication support for the DisCo language. DisCo is an object oriented specication language for the specication of reactive systems. The paper has two main contributions. The rst one is a mapping of object oriented specications to the PVS theorem prover, where their invariant properties can be mechanically veried. The second one is the systematic use of the theorem prover together with the animation facility of the DisCo environment when strengthening invariants. 1 Introduction This work was done in the DisCo project, whose aim is to develop a methodology and associated tools for the specication of reactive systems. The work on the specication language and the tools has been described elsewhere [1, 14, 15], so we will only introduce them briey here. Since the DisCo language has a well dened semantics, it is possible to reason formally about DisCo specications. This paper describes how invariant properties are veried using the PVS [18] theorem prover. Figure 1 gives an overview of the system. The user rst constructs a specication in the DisCo language. The specication can be examined using the animation tool, which can also be used to validate the specication against the informal requirements. Once the user is satised that the specication captures the requirements, formal verication can be used to increase condence in the specication. During verication we sometimes need to nd a stronger invariant that implies the invariant we want to verify. We use the theorem prover together with the animation tool for systematically strengthening invariants. The main contributions of this paper are the mapping of object oriented specications to the PVS logic, and the use of the theorem prover and the animation tool together for systematically strengthening invariants. We use a familiar example, the alternating bit protocol, to give a avor of what DisCo specications look like and how they are mapped to the logic of the theorem prover. The rest of the paper is structured as follows. Section 2 reviews some related work. Section 3 introduces the DisCo specication language using the alternating bit protocol as an example. Section 4 gives our formalization of TLA in PVS, and Section 5 describes the mapping of DisCo constructs to this

2 DisCo specication? compiler? animation - PVS specication - PVS? proof Fig. 1. The DisCo specication environment logic. Section 6 illustrates how invariants are proved, and Section 7 draws some conclusions and outlines future work. 2 Related Work Theorem provers have been applied to reasoning on action systems by Langbacka and von Wright [17, 19], who have formalized Temporal Logic of Actions (TLA) using the HOL [11] theorem prover. Engberg [9] has implemented a mechanical verication system for TLA using the LP [10] verication system. Our system is not intended to be a general purpose TLA prover, but we use a PVS formalization of TLA as the target logic. Chou [8] describes a general framework for reasoning about distributed algorithms with the HOL theorem prover. Properties of programs are veried by verifying the properties of their more abstract counterparts, and using a mapping between concrete and abstract programs. Agerholm [2] describes an experiment where existing specications written in VDM-SL were translated by hand to the PVS logic. The Unity [7] logic has been formalized using a variety of theorem provers [3, 6, 13] The main dierence between these and our work is that we deal with object oriented specications, where the number of variables is potentially innite. Also, we have implemented an automatic translation from the specication language to the logic of the theorem prover. 3 DisCo The DisCo specication language is based on the joint action approach of Back and Kurki-Suonio [4, 5]. A joint action system consists of a set of objects, and a set of actions. Whenever the guard of an action is true for some combination of participating objects, the action can be executed for them. The execution of

3 an action is atomic, and parallelism is modeled using nondeterministic choice of actions. The meaning of a DisCo specication is the set of execution sequences it allows. Rather than presenting all the details of the DisCo specication language, we show how a familiar example is specied using it. We do not use the language support for stepwise renement DisCo, but rather give the specication as a monolithic whole. In specications of realistic size, stepwise renement would be used, however. For brevity, we do not give the full specication here, just some representative parts of it. Figure 2 illustrates the specication in the DisCo animation tool. Fig. 2. Specication in the DisCo animation tool 3.1 The Alternating Bit Protocol We now briey outline the version of the alternating bit protocol we use as an example. The protocol ensures correct delivery of messages over an unreliable channel, which may lose messages but not corrupt them. In our version, there are two channels. The sender places messages on a message channel which the receiver can read, and the receiver places acknowledgments on an acknowledgment channel which the sender can read.

4 Both the sender and the receiver maintain one bit of additional information, which is transmitted in the messages and acknowledgments to the other party. In the initial state, the values of the bits are the same in the receiver and in the sender, and there are no messages nor acknowledgments in transit. When the sender wants to send a message, it stores the message on the message channel along with its bit, and enters a state indicating that it is expecting an acknowledgment. In this state it can then repeatedly send the message, until an acknowledgment with the same bit is received. When the acknowledgment is received, the sender inverts its bit, and enters a state where no acknowledgments are pending. The receiver repeatedly sends acknowledgments with the negation of its bit. When it reads a message with a bit equal to its own bit, it receives the message and negates its own bit. It then continues to send acknowledgments with the new value of the bit. 3.2 Specication of the Alternating Bit Protocol in DisCo We rst give a denition for the data channel. It has a single top level state indicating whether the channel contains a valid message. A message consists of the alternating bit and some data to be sent. class data channel is state *invalid, valid; extend valid by data : integer; bit : boolean; end; end; DisCo objects have a hierarchical state structure similar to Statecharts [12]. The extend clause declares the variables data and bit to reside within the state valid. When a data channel enters the state invalid, the variables become inactive. The asterisk in front of invalid indicates that it is the default state. The denition of ack channel is similar, so it is omitted here. A class denition describes the structure of the objects belonging to the class. There can be any number of objects, even innitely many. An implementation of a specication xes the number of objects of each class. Animation also requires a specic instance of the specication. Figure 2 shows an instance of the specication consisting of one object of each class. The class sender is dened next. It has two constant attributes in ch and out ch, which are references to channels. The history variable sent messages is used when formulating the main invariant about ordering of messages. The denition for class receiver is similar, so it is omitted here.

5 class sender(in ch : ack channel := null; out ch : data channel := null) is state *ready, waiting ack; last sent : integer; bit : boolean; sent messages : sequence integer; end; A number of assertions about the structure of the system are needed. They give the necessary conditions an implementation needs to fulll in order for the veried invariants to hold. These assertions are also initial conditions for the system. Some representative assertions are listed below. assert data receiver exists is 8 d : data channel :: 9 r : receiver :: r.in ch = d; assert well connected is 8 r : receiver :: 8 s : sender :: (s.out ch = r.in ch) = (s.in ch = r.out ch); assert unique ack sender is 8 r, rr : receiver :: r.out ch = rr.out ch => rr = r; The assertions sender data exists, receiver data exists, sender ack exists, receiver ack exists, and unique data sender, are omitted, as they are similar to those presented. For completeness, we also give here the assertions corresponding to the invariants we want to verify. The rst one relates the bits at the sender and receiver and the channels to each other, and the second one states that the protocol preserves message ordering. We return to these assertions in Section 6 when discussing verication. assert channel bits is 8 s : sender; r : receiver; data : data channel; ack : ack channel :: (s.out ch = data ^ data = r.in ch ^ s.in ch = ack ^ ack = r.out ch) => ((s.bit = r.bit => (ack.invalid or ack.valid.bit = : s.bit)) ^ (s.bit 6= r.bit) => (data.invalid or data.valid.bit = s.bit)); assert delivered messages is 8 s : sender; r : receiver :: (s.out ch = r.in ch ^ s.in ch = r.out ch) => (s.sent messages = r.received messages) _ (<s.last sent> & s.sent messages = r.received messages);

6 We next give the actions objects can participate in. The actions send and resend move a message from the sender to the data channel. The message to be sent in the send action is modeled as an action parameter, which receives an arbitrary integer value each time the action is executed. The message is stored in last sent for subsequent use in the action resend. The action resend is similar to send, and is omitted here. action send(m : integer) by s : sender; ch : data channel is when s.out ch = ch ^ s.ready do!s.waiting ack; { { state transition to state waiting ack s.last sent := m;!ch.valid; ch.valid.data := m; ch.valid.bit := s.bit; end; A message is received if its bit matches the bit of the receiver. Receiving a message removes it from the channel. The received message is appended to the sequence of received messages, and the alternating bit at the receiver is negated. action receive message by r : receiver; ch : data channel is when r.in ch = ch ^ ch.valid ^ ch.valid.bit = r.bit do r.bit := : r.bit; r.received messages := <ch.data> & r.received messages;!ch.invalid; end; The actions acknowledge and receive ack are similar to the actionssend and receive message. The actions lose message and lose ack lose the contents of a channel by entering the state invalid. We omit these actions here for brevity. 4 Temporal Logic In this section, we give a formalization of a temporal logic in the PVS logic. The logic is essentially Lamport's Temporal Logic of Actions, even though there are some dierences to the description of TLA in [16]. This is the logic to which the syntactic forms of the DisCo language are mapped to. We start by formalizing state, which is simply an uninterpreted abstract data type in our formalization: state : TYPE

7 Behaviors are sequences of states, so they are formalized as such: behavior: TYPE = [nat -> state] The types for temporal formulas, actions, and state predicates are the expected mappings temporal_formula : TYPE = [behavior -> bool] state_predicate : TYPE = [state -> bool] action : TYPE = [state,state -> bool] We represent terminating computations as nonterminating computations by repeating the last state. For this a stuttering step is needed. stutter(a : action) : action = LAMBDA (unprimed, primed : state) : A(unprimed, primed) or primed = unprimed In order to be able to use actions and state predicates as temporal formulas, we introduce lifting functions, which are declared as conversions to PVS. Whenever an action or a state predicate is encountered in a context requiring a temporal formula, it is automatically converted by PVS using these conversions. statepred2temporal((p: state_predicate)): temporal_formula = LAMBDA (b: behavior): P(b(0)) action2temporal((a: action)): temporal_formula = LAMBDA (b: behavior): A(b(0), b(1)) We next dene the temporal operator [] for a temporal formula F and behavior b: []((F: temporal_formula), (b: behavior)): bool = FORALL (n: nat): F(suffix(b, n)) We are now ready to dene what an invariant is. A state predicate P is an invariant for a system with initial condition I and actions A under some assumptions i [](P,b) holds for all behaviors b satisfying the assumptions and the initial condition, and consisting only of A steps or stuttering steps. invariant((p: state_predicate), (assumptions: bool), (I: state_predicate), (A: action)): bool = FORALL (b: behavior): assumptions AND I(b(0)) AND [](stutter(a),b) => [](P,b) We derive theorems corresponding to the inference rules of TLA. These theorems can then be used in invariant proofs. The theorem invariant rule is the standard technique for establishing invariants: show that the predicate holds in the initial state, and that none of the actions can invalidate it. The second theorem, invariant intro rule, allows us to introduce previously established

8 invariants as assumptions in a proof. Both of these are straightforward to prove. invariant_rule: THEOREM FORALL (P: state_predicate, assumptions: bool, I: state_predicate, A: action): (FORALL (b: behavior): NOT (I(b(0)) AND [](stutter(a),b)) OR ((assumptions AND I(b(0)) => P(b(0))) AND FORALL (n: nat): assumptions AND P(b(n)) AND A(b(n), b(n + 1)) => P(b(n + 1)))) => invariant(p, assumptions, I, A) invariant_intro_rule: THEOREM FORALL (assumptions: bool, P: state_predicate, I: state_predicate, A: action): invariant(p, assumptions, I, A) => FORALL (b: behavior): assumptions AND I(b(0)) AND [](stutter(a),b) => FORALL (n: nat): P(b(n)) It is often convenient to derive a stronger invariant implying the invariant we want to prove, and prove the stronger invariant. The invariant implication rule allows for this. invariant_implication_rule: THEOREM FORALL (assumptions: bool, Pstrong: state_predicate, Pweak: state_predicate, I: state_predicate, A: action): invariant(pstrong, assumptions, I, A) AND (FORALL (b: behavior, n: nat): assumptions and Pstrong(b(n)) => Pweak(b(n))) => invariant(pweak, assumptions, I, A) 5 Mapping DisCo to PVS In this section we describe the mapping of DisCo constructs to PVS using the specication in the previous section as an example. 5.1 Classes A DisCo class is represented as a record type in the PVS logic. Each of the components of the DisCo class gives rise to one or more elements in the record

9 type. For example, the the class sender maps to the type sender: TYPE FROM [# in_ch: objid, out_ch: objid, last_sent: [state -> int], bit: [state -> bool], sent_messages: [state -> list[int]], ready: [state -> bool], waiting_ack: [state -> bool], ref: objid #] There are two kinds of components in a class: parameters and variables. Parameters are constant components which do not change their values in actions, so they are represented as elements of the corresponding type. The eld in ch is an example of a parameter. Variables change their values in actions, so they are represented as functions from state to the appropriate type. The eld bit is an example of a variable. A DisCo state is an anonymous nite state machine. We represent a DisCo state as a collection of boolean variables. The elds ready and waiting ack correspond to a state in the DisCo class. The hierarchical structure of DisCo states is not preserved in the PVS representation. Parameters and variables embedded within states are converted to top level components by prexing them with the names of the enclosing state items. For example, the variable valid.bit is mapped to valid bit in the PVS representation. 5.2 Expressions Mapping DisCo expressions to PVS is straightforward. DisCo constants map to PVS constants, DisCo operators map to PVS operators, etc. References to parameters and variables within objects use the accessor functions PVS creates for a record type. Let s be an object of class sender. The reference s.in ch maps to in ch(s), since in ch is a parameter. The reference s.bit maps to bit(s)(state). References to DisCo states expand to references to the corresponding collections of boolean variables. 5.3 Assertions As was mentioned in Section 3, there are two kinds of assertions. The rst is exemplied by data receiver exists: assert data receiver exists is 8 d : data channel :: 9 r : receiver :: r.in ch = d; The assertion only refers to constant attributes of objects, so it cannot be invalidated by actions. There is thus no need to prove it as an invariant. We map these state-independent assertions to boolean formulas, which are taken as assumptions when doing verication. The assertion data receiver exists maps to

10 data_receiver_exists: bool = (FORALL (d: data_channel): (EXISTS (r: receiver): in_ch(r) = ref(d))) Assertions that can be invalidated by actions are mapped to boolean functions of state. For example, the assertion delivered messages maps to PVS as follows. delivered_messages_body((r: receiver), (s: sender), (other: state)): bool = ((out_ch(s) = in_ch(r)) AND (in_ch(s) = out_ch(r))) IMPLIES ((sent_messages(s)(other) = received_messages(r)(other)) OR ((append((: last_sent(s)(other) :), sent_messages(s)(other))) = received_messages(r)(other))) delivered_messages((other: state)): bool = (FORALL (s: sender): (FORALL (r: receiver): delivered_messages_body(r, s, other))) State-dependent assertions give rise to proof obligations. For each assertion, the following theorem is generated. assertion_is_invariant : THEOREM invariant(init, ACTIONS, assertion) The predicate INIT is the conjunct of all initial conditions and assertions, and ACTIONS is the conjunct of the actions. The bulk of the work involved in verifying an invariant goes into establishing that none of the actions can invalidate the invariant. It is often the case that most of the actions preserve the invariant almost trivially, and that only a handful of actions need special consideration. We produce a lemma action preserves assertion for each action-assertion pair. These lemmas together imply assertion is invariant, and help to modularize the proof. 5.4 Actions An action is a relation between two states, so we map it to a boolean function of states. A DisCo action only gives the changes that take place, leaving implicit what is left unchanged. The PVS counterpart needs to spell out the new values also for the unchanged parts of the state. Figure 3 gives the mapping of the action send to PVS. Parameters and participants map to existentially quantied variables. We give the guard as a separate function, since this is sometimes convenient when doing the verication. The body of an action consists of a sequence of assignments and state transitions, which are individually mapped to the corresponding PVS formulas. Assignments in DisCo map to equalities in PVS, with the left hand side mapping

11 send_guard((ch: data_channel), (s: sender), (m: int), (other: state)): bool = (out_ch(s) = ref(ch)) AND ready(s)(other) AND NOT waiting_ack(s)(other) send((unprimed, primed: state)): bool = (EXISTS (ch: data_channel, s: sender, m: int): (send_guard(ch, s, m, unprimed)) AND (((ready(s)(primed) = FALSE) AND ((waiting_ack(s)(primed) = TRUE) AND ((last_sent(s)(primed) = (m)) AND ((invalid(ch)(primed) = FALSE) AND ((valid(ch)(primed) = TRUE) AND ((valid_data(ch)(primed) = (m)) AND (valid_bit(ch)(primed) = (bit(s)(unprimed))))))))) AND (((FORALL (other: data_channel): ((other) /= (ch)) IMPLIES ((invalid(other)(primed) = (invalid(other)(unprimed))) AND ((valid(other)(primed) = (valid(other)(unprimed))) AND ((valid_data(other)(primed) = (valid_data(other)(unprimed))) AND (valid_bit(other)(primed) = (valid_bit(other)(unprimed)))))))) AND (((FORALL (other: sender): ((other) /= (s)) IMPLIES (last_sent(other)(primed) = (last_sent(other)(unprimed))))) AND ((FORALL (other: sender): ((other) /= (s)) IMPLIES ((ready(other)(primed) = (ready(other)(unprimed))) AND (waiting_ack(other)(primed) = (waiting_ack(other)(unprimed)))))))))) AND (h invalid, valid, and valid bit unchanged in ack channeli AND (h bit unchanged in receiveri AND (h received messages unchanged in receiveri AND (h bit unchanged in senderi AND h sent messages unchanged in senderi)))) Fig. 3. Mapping of the action send to PVS. to a reference in the primed state. State transitions map to assignments to the corresponding boolean variables in a similar fashion as references to state items map to references to boolean variables. 6 Verication of Invariants We set out to verify two invariants. The rst one is a simple invariant about how the bits of the sender, the receiver and the channels are related. The second one

12 concerns the messages that have been delivered over the channel. 6.1 Channel bits Observing how the values of the alternating bits are related, we produce an invariant candidate. As such the invariant is not very interesting, but it illustrates how we systematically strengthen invariant candidates using the animation tool. The proposed invariant is assert channel bits is 8 s : sender; r : receiver; data : data channel; ack : ack channel :: (s.out ch = data ^ data = r.in ch ^ s.in ch = ack ^ ack = r.out ch) => ((s.bit = r.bit => (ack.invalid or ack.valid.bit = : s.bit)) ^ (s.bit 6= r.bit) => (data.invalid or data.valid.bit = s.bit)); The attempted proof of channel bits leaves us with four subproofs that cannot be completed. The rst one is presented in Figure 4. Analyzing the subproof reveals that it represents a state where the bits are equal to one at both the sender and receiver, and an acknowledgment with the alternating bit equal to one is on transit (formulas -10, -11, and -13 in the sequent). Informal reasoning and suggests that this is not a reachable state of the system. Simulation with the DisCo animation tool also indicate this, so we strengthen channel bits with the conjunct not(s.bit ^ r.bit ^ ack.valid.bit). [-1] ss = s [-2] ack = ch [-3] ASSUMPTIONS [-4] INIT(b!1(0)) [-5] [] action2temporal(actions) [-6] (out_ch(s) = ref(data)) [-7] (ref(data) = in_ch(r)) [-8] (in_ch(s) = ref(ch)) [-9] (ref(ch) = out_ch(r)) f-10g bit(s)(s!1) f-11g bit(r)(s!1) f-12g valid(ch)(s!1) f-13g valid_bit(ch)(s!1) f-14g valid(data)(s!1) f-15g valid_bit(data)(s!1) f1g invalid(ch)(s!1) Fig. 4. An unresolved subproof from the proof of channel bits

13 Similar analysis of the three other subproofs reveals that they also represent nonreachable states. One represents exactly the same state as the rst one, and the two remaining ones represent an identical situation except that the common value of the bit is zero. The next invariant candidate is thus channel bits strengthened with conjuncts that exclude the nonreachable states: assert channel bits aux is 8 s : sender; r : receiver; data : data channel; ack : ack channel :: (s.out ch = data ^ data = r.in ch ^ s.in ch = ack ^ ack = r.out ch) => ((s.bit = r.bit => (ack.invalid or (not s.bit) = ack.valid.bit)) ^ (s.bit 6= r.bit => (data.invalid or data.valid.bit = s.bit)) ^ not(s.bit ^ r.bit ^ ack.valid.bit) ^ not((not s.bit) ^ (not r.bit) ^ (not ack.valid.bit))); We give here an outline of the proof of the lemma send preserves channel bits aux, which establishes that action send does not invalidate channel bits. Figure 5 shows the outline of the proof. (send_preserves_channel_bits_aux) (bddsimp) (hide 4-5) (bddsimp) (bddsimp) (propax) (assumptions...) (propax) (propax) (ground) Fig. 5. Outline of proof of send preserves channel bits aux The DisCo to PVS translation produces a custom proof script for automating the routine parts of an invariant proof. When the generated script is applied, it yields four subproofs. Three of these are resolved by using bdd simplication. The second subproof describes a situation where two senders are connected to the same data channel. This violates the assumption unique data sender, so we need to introduce it and the assumption sender unique reference suitably instantiated. With this additional information in the sequent, the PVS decision procedures can complete the proof. The other subproofs are similar to this one. Most branches are automatically proved by the PVS decision procedures, while some branches require suitable instances of the assumptions to be brought into the sequent.

14 The original assertion channel bits can now be proved by applying the invariant implication rule. 6.2 Delivered messages The second invariant establishes that the sequence of sent messages is a sux of the sequence of received messages. We cannot formulate this directly in DisCo, but the following assertion immediately implies it. assert delivered messages is 8 s : sender; r : receiver :: (s.out ch = r.in ch ^ s.in ch = r.out ch) => (s.sent messages = r.received messages) _ (<s.last sent> & s.sent messages = r.received messages); As was the case with channel bits, this invariant is not strong enough to be proved alone. We use the same technique of recognizing subproofs representing nonreachable states using the animation tool to produce a stronger version of the invariant. Somewhat arbitrarily, we separate some of the strengthening conjuncts to separate assertions. The strengthened delivered messages is assert delivered messages aux is 8 s : sender; r : receiver; ack : ack channel :: (s.out ch = r.in ch ^ s.in ch = ack ^ ack = r.out ch) => ((s.sent messages = r.received messages) _ (<s.last sent> & s.sent messages = r.received messages)) ^ not(s.bit = ack.valid.bit ^ s.sent messages = r.received messages) ^ not(s.bit 6= r.bit ^ s.sent messages = r.received messages) ^ not(s.bit = r.bit ^ s.sent messages 6= r.received messages); In addition to this, two auxiliary invariants are introduced: data not corrupted and ready bits. The rst one guarantees that once a message is placed on a data channel, its contents are not changed unless the bit is changed, too. The second introduces constraints on the values of the bits when the sender is in state ready. 7 Conclusions We have implemented a mechanized chain from DisCo specications to the logic of the PVS prover. This can be used for formal verication of invariant properties of DisCo specications. The main contributions of the paper are the mapping of an object oriented specication language to the PVS logic, and the use of the theorem prover together with the animation tool systematically to strengthen invariants.

15 7.1 Experiences on Verication The DisCo specication of the alternating bit protocol does not describe a single instance of a sender{receiver pair and the associated channels, but rather a world of senders, receivers, and channels. The class denitions for sender and receiver state that they can be connected to channels, but do not imply any particular structure. The structure needs to be given explicitly using assertions. Most of the subgoals not resolved by the PVS decision procedures have to do with this generality of the DisCo specication. For example, when the prover constructs a subproof corresponding the situation where two senders are connected to the same data channel, we need to refer to the appropriate assumptions in order to resolve the subproof. In practise this means expanding denitions and instantiating the resulting quantied formulas with appropriate values. Installing all the assumptions as automatic rewrites is not feasible, because that would make the search space for PVS decision procedures too large. Verifying a typical DisCo specication involves mostly reasoning about state machines, for which the PVS decision procedures are quite eective. Once a strong enough invariant has been found, it is thus usually not a problem to prove it. The main problem is how to nd the invariant. We use the failed subproofs together with the DisCo animation tool for systematic strengthening of invariants. We analyze the subproof to see if it represents an unreachable state, using simulation with the animation tool to augment informal reasoning. Once we are convinced that we have identied an unreachable state characterized by some assignment a of values to variables, we strengthen the invariant with the conjunct :a. It is quite often the case that the original invariant describes some intuitively understandable property of the system, but the strengthening conjuncts are not immediately obvious. It is thus easy to make mistakes with the strengthening conjuncts, which leads to wasted verication eorts. We are planning to use nite state methods as a quick check for the strengthened invariants before attempting a proof with PVS. The examples we have tried so far suggest that verication can be done with a reasonable amount of eort. It is dicult to estimate how much work has gone into the verication of the alternating bit protocol, as the tools have been under constant development, but we estimate that specifying and verifying a similar case would be a matter of a few weeks. 7.2 Future Work The PVS logic has proved to be exible enough to express the semantics of DisCo in a natural way. It would be interesting to compare how some other theorem provers using higher order logic would fare in this respect. So far we have concentrated on invariants, but we are planning eventually to extend this work to the verication of liveness properties. Invariant proofs have been attempted rst, because automatic support can be provided for them. Also, liveness proofs often need supporting invariants.

16 References 1. The DisCo home page Sten Agerholm. Translating specications in VDM-SL to PVS. In J. von Wright, T. Grundy, and J. Harrison, editors, Proceedings of the 9th International Conference on Theorem Proving in Higher Order Logics, volume 1125 of Lecture Notes in Computer Science, pages 1{16. Springer-Verlag, F. Andersen, K. D. Petersen, and J. S. Petterson. Program verication using HOL- UNITY. In J. J. Joyce and C.-J.H Seger, editors, International Workshop on Higher Order Logic and its Applications, volume 780 of Lecture Notes in Computer Science, pages 1{16, R. J. R. Back and R Kurki-Suonio. Distributed cooperation with action systems. ACM Transactions on Programming Languages and Systems, 10(4):513{554, October R. J. R. Back and R. Kurki-Suonio. Decentralization of process nets with a centralized control. Distributed Computing, (3):73{87, N. Brown and D. Mery. A proof environment for concurrent programs. In FME'93: Industrial Strength Formal Methods, volume 670 of Lecture Notes in Computer Science, pages 196{215, K. M. Chandy and J. Misra. Parallel Program Design: A Foundation. Addison- Wesley, Ching-Tsun Chou. Mechanical verication of distributed algorithms in higherorder logic. The Computer Journal, 38(1), Urban Engberg, Peter Grnning, and Leslie Lamport. Mechanical verication of concurrent systems with TLA. In G. v. Bochmann and D. K. Probst, editors, Computer Aided Verication { Fourth International Workshop. CAV'92. Montreal, Canada. June 29 - July 1, volume 663 of Lecture Notes in Computer Science. Springer Verlag, Stephen J. Garland and John V. Guttag. An overview of LP, the Larch prover. In Proceedings of the Third International Conference on Rewriting Techniques and Applications, volume 335 of Lecture Notes in Computer Science. Springer Verlag, Michael J. C. Gordon. HOL: A proof generating system for higher-order logic. In Graham Birtwistle and P. A. Subrahmanyam, editors, VLSI Specication, Verication and Synthesis, pages 73{128. Boston Kluwer Academic Publishers, David Harel. Statecharts: A visual formalism for complex systems. Science of Computer Programming, 8(3):231{274, jun Barbara Heyd and Pierre Cregut. A modular coding of UNITY in COQ. In J. von Wright, T. Grundy, and J. Harrison, editors, Proceedings of the 9th International Conference on Theorem Proving in Higher Order Logics, volume 1125 of Lecture Notes in Computer Science, pages 251{266, Hannu-Matti Jarvinen. The Design of a Specication Language for Reactive Systems. PhD thesis, Tampere University of Technology, Reino Kurki-Suonio, Hannu-Matti Jarvinen, Markku Sakkinen, and Kari Systa. Object-oriented specication of reactive systems. In Proceedings of the 12th International Conference on Software Engineering, pages 63{71. IEEE Computer Society Press, Leslie Lamport. The temporal logic of actions. ACM Transactions on Programming Languages and Systems, 16(3):872{923, May 1994.

17 17. Thomas Langbacka. A HOL formalization of the temporal logic of actions. volume 859 of Lecture Notes in Computer Science. Springer Verlag, S. Owre, J. M. Rushby, and N. Shankar. PVS: A prototype verication system. In Deepak Kapur, editor, 11th International Conference on Automated Deduction, volume 607 of Lecture Notes in Articial Intelligence, pages 748{752. Springer Verlag, J. von Wright and T. Langbacka. Using a theorem prover for reasoning about concurrent algorithms. In G. v. Bochmann and D. K. Probst, editors, Computer Aided Verication { Fourth International Workshop. CAV'92. Montreal, Canada. June 29 - July 1, volume 663 of Lecture Notes in Computer Science. Springer Verlag, This article was processed using the LATEX macro package with LLNCS style