On the Automatic Verification of Non-Standard Measures of Consistency

Consistency between a process and its specification expressed in CSP is typically presented as a refinement check. Within the traces model consistency is measured by examining only the traces of the systems, whilst in the finer stable failures model the possibility of subsequently refusing a combination of events is also taken into consideration. 
 
The contribution of this paper is to identify and motivate the need for alternative measures of consistency, and to present and prove the soundness and completeness of general techniques for automatically verifying such consistencies. We achieve this by masking all failures information other than that associated with the measure in question. 
 
More concretely, we describe methods for automatically checking: that a process can refuse a given set of events after any trace only if its specification can refuse the same set of events after the same trace; that a process might deadlock after any trace only if its specification might also deadlock after the same trace; and that a process might after any trace refuse a given number of events of a particular class only if its specification might also refuse the same set after the same trace.


INTRODUCTION
Refinement is a standard technique that is used to ascertain whether or not a model of a system is in some way consistent with, or satisfies a property captured by, its specification.The measure of consistency depends on the language used and often on the choice of semantic model.Process algebras such as CSP [1,2] and CCS [3,4] can be used to model concurrent systems as can modal logics [5,6,7] and Petri nets [8].
In the process algebra CSP a typical refinement check is of the form SPEC P for process P and specification SPEC.Non-trivial problems are generally verified using the the model-checker FDR [9,10].FDR checks that all behaviours of process P are possible behaviours of specification SPEC.The class of behaviours taken into consideration is determined by the choice of semantic model: the traces model [2] simply records all possible traces, or sequences of interaction whereas the stable failures model [2] records also the potential to refuse sets of events after each such trace.
The purpose of this paper is to identify and motivate the need for alternative measures of consistency between a process and its specification, and to present (and prove the correctness of) techniques for using existing tools to automatically verify such consistencies.We restrict ourselves to measures that are finer than the traces model but courser than the stable failures model; we achieve our goal by masking all failures information other than that associated with the measure in question.

Example 1
The implementation of a pantomime horse 2 is modelled in the self-explanatory UML [11] state diagram in Figure 1  If we are are working in the context of the traces model then the answer is "Yes": every possible sequence of interaction of the implementation is a possible sequence of interaction of the specification.However if we consider full failures information then the answer is "No": the implementation could initially refuse to go backwards whilst the specification could not.
But perhaps neither of these is the correct measure.It might be that in this instance our measure of consistency should be "Can the implementation refuse to move only when the specification can also refuse to move?"In other words, can the implementation refuse both fwd and bkwd only when the specification could refuse both these events?If that is our measure then the answer is "Yes": the implementation is consistent with the specification.

2
The intention of this paper is to provide general techniques for verifying that a process can exhibit a particular behaviour only when its specification could exhibit the same behaviour.The particular behaviours that concern us are: the refusal of a given combination of events; the potential to deadlock; the refusal of a given number of events; and the refusal of a given number of events from a specificied set or class.
The paper begins with a brief introduction to the syntax of CSP, identifying the standard operators that we will be using throughout the rest of the paper.We follow this by a discussion of Roscoe's traces and stable failures models.
In Section 3 we present a general technique for verifying automatically whether or not a process can refuse a particular set of events only when its specification can.As well as proving the soundness and completeness of this technique, we discuss practical applications of such a measure of consistency, observing that the results presented in this section could be used to verify automatically (assuming the correct translation to CSP) that the implementation of the pantomime horse as defined in Example 1 is consistent with its specification.Sections 4, 5 and 6 adopt a structure similar to Section 3: we identify a potential application for the measure of consistency under consideration; and we prove formally how consistency within this context might be automatically verified.These proofs apply arguments similar to those used in Theorem 1 of Section 3 and are therefore included in the appendix rather than the main body of the paper.
The measure of consistency with which we are concerned in Section 4 is that a process might deadlock after some trace only when its specification might deadlock after the same trace.In Section 5 we are concerned only with failures in which the cardinality of the refusal set is at least a specified value.And in Section 6 we are concerned only with failures in which the refusal is a subset of a given set and is of at least a specified size.
We conclude the paper in Section 7 with a discussion of related work.

OVERVIEW OF CSP
In this section we give a brief overview of the syntax and semantics for CSP, as defined by Roscoe [2], that we will be using throughout the rest of the paper.

Syntax
The process algebra CSP can be used to model systems such as networks, protocols and machines.Furthermore, simple components may be combined to create complex composite entities.A CSP process is a pattern of communication that describes the behaviour of a system.Behaviour is described in terms of events or synchronous atomic communications, marking points in the evolution of the system.The simplest process is Stop.It will not perform any events and marks the end of a pattern of communication.By contrast, the process div represents a divergent process, which performs unboundedly many internal events and never reaches a stable state.
For any event a and process P, the process a → P is willing to communicate event a and, if that event occurs, will subsequently behave as P. If A is a set of events, then ?a : A → P a represents the process that is willing to communicate any event from A; if event a ∈ A, which can be thought of as an input, is performed, subsequent behaviour is that of P a .
CSP has two choice operators: P Q and P 2 Q respectively represent the internal (or non-deterministic) choice and external choice between processes P and Q.In addition, there are indexed version of these operators: process i : I | p(i) • P i represents an indexed internal choice between the processes P i where i ranges over those members of I such that p(i) holds.
Given processes P and Q and sets of events A and B (their respective interfaces), the process P A B Q denotes the parallel combination of P and Q.In such a parallel combination, a process can perform only those events that are in its interface and its cooperation is required if such an event is to occur; hence the processes synchronise on events in the intersection of their interfaces.By contrast, P ||| Q represents an interleaving of P and Q, i.e. a parallel composition with no synchronisation.
The process P Q represents a process that initially acts like P, but at any point, P can be interrupted and control passed to Q.If P is a process and R a relation over events, then P [[R]] represents the process that can perform an event b whenever P could perform an event a such that a R b.If P is a process and A a set of events, then the process P \ A behaves as P except that events from A are hidden (or made internal) so cannot be observed and do not require the cooperation of any other process.
For later convenience we define also Offer (A) = ?a: A → div, the process that offers the events from A and then diverges, and ;, the non-deterministic interrupt operator defined as follows: P ; Q ≡ P (P Q).These were introduced in [12].

Semantics
Given Σ, the set of all possible events, a trace describes a sequence of interaction and is an element of the type Σ * .A failure is an element of the type Σ * × P Σ; the first component is a trace and the second a refusal set; the refusal set is a set of events that might collectively be refused from a stable state (i.e.where no internal activity is possible) reached after the given trace.
Roscoe's stable failures model represents each process P by a pair in which the first component is a set of traces and the second a set of failures.The semantics of a process P is given by the pair (traces(P), failures(P)) where the functions traces and failures must satisfy the following healthiness conditions: Condition (T1) states that the empty trace is a possible trace of every process and condition (T2) states that the set of traces of any process is prefix-closed.Condition (F1) ensures consistency between failure and trace information whilst condition (F2) states that the set of refusal sets for every possible trace is subset closed.Finally, condition (F3) states that events that cannot be performed in a particular state may be added to a corresponding refusal set.
The functions traces and failures satisfy the following equations 3 3 In the equations for P ||| Q, the notation tr P ||| tr Q represents all ways of interleaving the traces tr P and tr Q ; see [2].Similarly, the notation tr X represents trace tr restricted to those events in set X .
If R is a relation over events, then R * is the corresponding lifted relation over traces, and Note that the version of the interrupt operator presented here is not that implemented in FDR.The version presented here can, however, be modelled in FDR as follows: Interrupt(P,Q) = (P /\ (i->Q)) \ {i} for some fresh event i.
Finally, observe that div has no stable failures, because it never reaches a stable state, and that P Q has no failures corresponding to P, because in such states it can be interrupted at any point, so never stabilises.
On the Automatic Verification of Non-Standard Measures of Consistency Given these definitions, refinement and equivalence in the traces and stable failures models can be defined as follows:

REFUSAL OF A SPECIFIC SET OF EVENTS
In this section we present an automatable refinement check that will identify whether or not there is some trace after which a process can refuse a specified set of events but after which its specification could not. 4

Practical application
A test of the form described above will be useful whenever we have a system in which we are concerned about the availability of at least one of a given class of operations, although which operation is actually performed does not concern us.
Suppose for instance that a service provider has a collection of processors indexed by some set I. The acceptance and completion of a job by processor i are respectively modelled by events acceptJob.iand completeJob.i.An initial specification might be of the following form: To maximise efficiency, the service provider decides to incorporate a scheduler into the system when it comes to the actual implementation.The scheduler's role is to allocate jobs to processors.How it makes its decisions is not important for the purpose of this example.The final implementation is modelled as follows:

ServiceProviderSpec.
We are concerned not with which processor performs which job, but that the implementation cannot block the acceptance of a job where the specification would not.We need to verify that the following predicate holds: and hence need the result presented in Theorem 1 below.

Automatic verification
The following predicate captures that there is no trace of process P after which it can refuse the set of events A, but after which its specification SPEC cannot refuse that same set: ( To verify automatically whether or not this is the case, we must reduce the problem to an equivalent one expressed in terms of refinement within the established semantic models.We must retain failures information when the refusal set is A, and mask all other failures information.
Provided SPEC is trace-refined by P we can achieve this by: • Preserving the trace information of both P and SPEC; • Removing all trace-refusal pairs (tr , X ) where X ⊆ A from the failures sets of both P and SPEC.• Flooding the failures sets of both P and SPEC with all trace-refusal pairs (tr , X ) where tr ∈ traces(P) and X ⊂ A; and If the resulting processes are P and SPEC , then Equation (1) will hold precisely when P F SPEC .
Removing failures can be achieved by interleaving with a suitable process-in this case a process in which every event outside A is initially available.Flooding with additional failures at each trace can be achieved by non-deterministically allowing interruption by a suitable processin this case a process which can refuse every strict subset of A.
In Theorem 1 below we prove our desired result for an arbitrary non-empty set A.
Theorem 1 For any process P defined over finite set of events Σ, and with specification SPEC such that SPEC T P, and for any given set of events A = ∅, Equation 1 is satisfied precisely when Proof First observe that, by definition of ||| and Offer , for any process Q, Furthermore, since A = ∅, Hence, by definition of , we deduce that for any On the Automatic Verification of Non-Standard Measures of Consistency We are now equipped with the necessary building blocks to complete our proof.

POTENTIAL DEADLOCK
In this section we present a technique for determining automatically whether a process could reach a state of deadlock after a particular sequence of interaction, whilst, after the same sequence of interaction, its specification could not.This is a special case of the previous section, taking A to be the whole of Σ.

Practical application
A means of automatically verifying whether one system can deadlock when another would not is necessary whenever we are designing a system that might reach a deadlocked state but should do so only under certain conditions: for instance after reporting an error or successfully completing a task.
Consider an inference tool that can make a variety of deductive steps depending on its current knowledge.The specification might permit any possible deductive step from any given state whilst, for efficiency reasons, the implementation might prioritise techniques: all possible deductive steps of one class must be completed before any deductive steps of another class may be performed.We see that every possible trace of the implementation must be a possible trace of the specification, but are not concerned that the implementation will have more refusals than the specification.Our concern is that whenever the implementation can make no more deductive steps and hence deadlocks, the specification might also deadlock.We need to verify that and hence need the result presented in Theorem 2 below.

Automatic verification
The following predicate captures that there is no trace of process P after which it can deadlock, but its specification SPEC cannot: In order to ascertain automatically whether this is or is not the case, we must equivalently express the above predicate in terms of refinement checks within established semantic models.To achieve this we must flood the failures sets of both P and SPEC with all trace refusal pairs (tr , X ) such that tr is a trace of the process and X is a strict subset of Σ.As we show in Theorem 2 below, a corollary to Theorem 1 taking A to be the whole of Σ, this can be done by non-deterministically interrupting with an appropriate process.
Theorem 2 For any process P defined over finite set of events Σ and with specification SPEC such that SPEC T P, there is no trace of P after which it might deadlock but after which SPEC will not deadlock precisely when

REFUSAL OF A GIVEN NUMBER OF EVENTS
In this section we present a technique for determining automatically whether, for any given integer N > 0, a process could refuse any set of N or more events after a particular sequence of interaction, whilst, after the same sequence of interaction, its specification could not.

Practical application
Verifying that a set of at least N events can be refused by a process only when its specification could also refuse those events is of particular interest when we are considering support or safety systems, systems that under usual circumstances require a built-in margin for error.
A large office has an indexed set of E emergency exits.The Health and Safety Division of the company are required to do an annual check to verify that, provided a fire does not simultaneously On the Automatic Verification of Non-Standard Measures of Consistency break out in more than F places, there are at least R escape routes.Equivalently, no more than E − R exits can be blocked unless a fire has broken out in more than F places.
Suppose that a process Layout models the current layout of the building along with access to exits, and that Fires is a process that non-deterministically chooses to block certain routes.The Health and Safety executives construct a process Scenario = (Layout Routes Fires) \ Routes that determines which exits are accessible given the current layout and the non-deterministic blocking of routes by Fires.They then construct a process that specifies that if fewer than F fires have broken out, then all exits are accessible (the parameter fs ⊆ Fire represents the set of fires that have broken out): Since they are only interested in cases where more than E − R exits are blocked (and fire events are never refused by SafetySpec), they need to verify that the following condition is met: The result presented in Theorem 3 would facilitate such a check.

Automatic verification
For any strictly positive integer N, the following predicate captures that process P can refuse a set of at least N events only when SPEC can refuse the same set of events: We can perform this check using existing tools by masking all failures information where the cardinality of the refusal set is strictly less than N. We do this by using the non-deterministic interrupt operator to flood both sides with all such failures.The proof is included in the appendix.Theorem 3 For any process P defined over finite set of events Σ and with specification SPEC such that SPEC T P, and for any strictly positive integer N, there is no trace of P after which it might refuse a set X such that #X ≥ N but after which SPEC will not refuse X precisely when

REFUSAL OF A GIVEN NUMBER OF EVENTS OF A SPECIFIC CLASS
In this section we present a technique for determining automatically whether or not, for some strictly positive integer N, a process could refuse a set of N or more events from a particular set or class, whilst its specification could not, after the same sequence of interaction, refuse that same set of events.

Potential application
A means of automatically verifying whether one system can refuse at least a certain number of events of a given class when another could not is of particular interest when we are modelling distributed systems involving the parallel combination or interleaving of an indexed collection of identical components.
Suppose that a company is running the software for a large safety-critical distributed system comprising a dynamic network of R indexed nodes.The requirements imposed on the company state that (modulo an agreed latency period after any node crashes) the central monitor must always be able to communicate with at least k nodes.The ability of the central monitor to be able to communicate with node i ∈ R is modelled by the event inContact.i.
Suppose that the process Network below satisfies the necessary constraints:

Nodes.
The company now decides, for whatever reason, to update its nodes:

UpdatedNodes
but then needs to verify that the new system can communicate with at least k of its processors at least as often as the old system could.They need to verify that whenever the new system can refuse N = R − K + 1 or more inContact events the old system could also have refused these events.They need to verify that We prove in Theorem 4 below how such a verification might be performed automatically using existing tools.

Automatic verification
Given set of events A ⊆ Σ and integer N > 0, the following predicate captures that there is no trace of process P after which it can refuse a subset of A of size N or greater but its specification SPEC cannot: To verify automatically whether or not this is the case, we must reduce the problem to one expressed in terms of refinement within the established models.We must retain failures information when the refusal set is a subset of A of cardinality N or more, and we must mask all other failures information: we remove all failures in which the refusal set is not a subset of A and we flood the failures sets of both P and SPEC with all trace refusal pairs (tr , X ) such that tr is a trace of the process and X is a subset of Σ of size strictly less than N.
As we show in Theorem 4 below, this can be done through a combination of interleaving and non-deterministically interrupting with the appropriate processes.The proof is included in the appendix.
Theorem 4 For any process P defined over finite set of events Σ and with specification SPEC such that SPEC T P, for any strictly positive integer N and for any given set of events A = ∅, P can refuse a set of N events from A only if SPEC can precisely when

DISCUSSION
In this paper we have considered various non-standard measures for determining whether a process modelled in CSP is consistent with its specification, presenting motivating examples in which the full strength of the stable failures model is too prescriptive but traces model not prescriptive enough.
The first situation we considered was one is which we were concerned only about the potential refusal of a particular set of events: we wished to verify that a process could refuse a fixed set of events after any trace only if its specification could refuse the same set after the same trace.The criterion for consistency in our second model was that a process might deadlock after any trace only if its specification might also deadlock after the same trace.Our third measure was to ascertain whether a process could refuse a set of at least N events when its specification could not.And the final situation we considered was one in which we were concerned about the potential to refuse N or more events from a given set.
For each measure we identifed various problem domains in which the proposed measure of consistency would be useful and appropriate.Furthermore, in each case we explored in greater detail a particular example within one of these domains.We expressed the predicate defining consistency for each measure in terms of refinement checks within the traces model and the stable failures model, thereby enabling automatic verification of consistency using existing tools.Finally, we proved formally the soundness and completeness of each of these results.
The work presented here has built upon and developed the very abstract ideas presented in [12].There we identified a family, in fact a complete lattice, of failures models each recording all trace information and some failures information.The amount of failures information recorded in each model was determined by its associated predicate on refusal sets.In this paper we have taken a further step, considering practical applications of some of these models and presenting explicitly their associated refinement checks.
An interesting corollary of a result in that paper is that the preorders corresponding to the measures of consistency in Sections 4 and 5 are precongruences with respect to all the CSP operators except for parallel composition; while the preorders corresponding to the measures of consistency in Sections 3 and 6 are precongruences with respect to all the CSP operators except for parallel composition and hiding.In other words, for any CSP context F ( ) built using CSP operators other than (respectively) parallel composition or parallel composition and hiding, if P satisfies the condition then so does F (P).This allows a degree of compositional reasoning.
In [14], Roscoe considers which predicates R over the semantics of processes can be captured as refinement checks.He shows that all predicates that are closed under the metric topology can be captured as refinement checks.He gives simplified refinement checks in the cases that R is refinement-closed (i.e.such that if P satisfies R and P Q then Q satisfies R) and/or distributive (i.e.such that if each process in the set S satisfies R, then so does S).However, his refinement checks are not, in general, finite-state, and so cannot be automated using a tool such as FDR.
It is interesting to observe that the techniques for verifying consistency presented in this paper are not unique: other operators and combinations could be used to mask the unwanted failures.Indeed, as observed in Section 3, Roscoe has come up with an alternative method for determining whether a process can refuse a set of events A only when its specification could refuse the same set of events [13].His work arose from a problem posed by Reed and Sinclair following on from [15] in which their predicate "is as live as" could be verified using techniques similar to those presented in Section 3.

Roscoe's technique is as follows. Let e /
∈ Σ be a fresh event, and let R A be the renaming relation that maps each element a of A to both itself and e, and is otherwise the identity function.Let CheckAll A (Q) can perform any trace of Q, but can also perform an e when Q can do an event from A, after which it must stop.After any trace it can refuse anything except for e; it can refuse e only when Q can refuse the whole of A. Hence the requirement that P refuses A only when SPEC refuses A can be captured by the following refinement check: This check and the one introduced in Section 3 take comparable times.The Sixth International Workshop in Formal Methods (IWFM'03)