Journal ArticleIn a companion paper in these proceedings [6], we introduced the CCS notation and explained how to write  specifications succinctly in CCS using the composition operator. In this paper we explain how one may associate a process logic with CCS and use it to resolve deadlock, safety, liveness, and fairness properties of specifications by static testing

Liu, Ying

Stevens, Kenneth

English

The University of Utah: J. Willard Marriott Digital Library

TESTING THE CONSEQUENCES OF SPECIFICATIONS IN MODAL Jl Ying Liu, John Aldwinckle, Graham Birtwistle, Ken Stevens, Department of Computer Science, University of Calgary, Canada. Abstract In a companion paper in these proceedings [6], we in-troduced the CCS notation and explained how to write specifications succinctly in CCS using the composition op-erator. In this paper we explain how one may associate a process logic with CCS and use it to resolve deadlock, safety, liveness, and fairness properties of specifications by static testing. 1 Introduction Specifications tell us what a system should do - not how it does it. They are thus simpler and shorter than im-plementation descriptions. Since equivalent descriptions share exactly the same properties, it pays to investigate properties of a system by testing its specification rather than testing its implementation. In this paper we couple a process logic to CCS and show how to test for such properties as deadlock, safety, liveness and fairness. See [5, section 2, pages 177-387] for a very readable and full account. [1] gives the intuition and background to minimum and maximum fix points. [7] is an excellent account of process logics and CCS. Ms Liu's thesis [4] applies these techniques to asynchronous hardware. 2 HML - Hennessy-Milner logic Labelled transition systems. The processes of CCS generate labeled transition systems of the form ( P, A, T) where • P is a non-empty set of agents • A is a set of input actions (a) and output actions (a) • T are the transition relations for each a (or a) E A. E.g. given the system which describes a two place buffer, Bo d~ put.Bl Bl d~ put.B2 B2 d~ then P {Bo,Bl ,B2 } A {put, get} T {Bo put -+ B l , Bl put -+ B 2, Bl get '-+ Bo, B2 ~ Bd HML. The syntax of HML formulae is: A ::= T 1 -,A 1 A /\ A 1< a > A 1 [alA with interpretation: • T is the constant true formula • -,A is a negated formula • A /\ A is a conjunction • modalised terms: <a> A is read as "A holds after some a action" [a] A is read as "A holds after all a actions" We derive F, v, =>, =, ... from the basic operators. Notice that [ land <> are duals of each other since < a > A = -,[a]-,A - only one need be defined as a primitive. Since the formulae are parameterised by the action set, each transition system has its own associated HML. Satisfaction over HML. For a given fixed transition system, we now define when a process E E P satisfies the property A (written E F= A): 1 E F= T 2 E F= -,A 3 E F= A/\B 4 E F= <a> A 5 E [a] A with interpretation VE iff E ~ A iff E F= A and E F= B iff 3 E' E P, a E A. E ~ E' and E' F= A iff 'v' E' E P, a E A. E ~ E' => E' F= A 1. Every process in P satisfies property T 2. A process has property -,A when it fails to have prop-erty A 3. A process has property A /\ B when it has property A and it has property B 4. A process satisfies <a> A if there exists one a action whose resulting process has property A CCECE/CCGEI '93 0-7803-1443-3/93 $3.00 © 1993 IEEE 987 57.3 988 5. A process satisfies [aJ A if after every performance of an a action all the resulting processes have property A Example: 2 place buffer 1. Bo 1= <put> T the buffer can add an item in Bo 2. Bo 1= ~«get> T) the buffer cannot remove an item from Bo 3. B1 1= <get> T 1\ <put> T B1 can both remove and add an item 4. B2 1= <get> T 1\ ~«put> T) B2 can remove an item, but can not add an item and more notation. We make HML more convenient to use by allowing the following notational extensions: H d~ all actions A [-k,l,mJ d;;j all actions except k,l,m in A <a,b,c> S d~ <a> S V <b> S V <c> S [a,b,cJ S d,;/ [a] S 1\ [b] S 1\ [c] S In particular E 1= [a] F E 1= <a> T E 1= [-] F E 1= <-> T E cannot do an a move E can do an a move E is deadlocked E is live E 1= <a> T 1\ [-a] F E can only do an a 3 Recursive agents All interesting agents are recursive. Our buffer has the property that once in state B1 all we can do is either a put followed by a get, or a get followed by a put, and then we are back in state B1 again. I.e. we can keep on doing this forever. An obvious notation in which to express this infinite behaviour is: B1 = «get> <put> V <put> <get> )B1 Such a fix point equation may have no solutions (e.g. X = ~ X) or several solutions. There will always be at least one solution provided that each fix point variable is within the scope of an even number of negations. From now on, we assume that all our modal formulae pass this simple syntactic test. Satisfaction via sets of states. We associate with a property the set of states satisfying it: II A II II T II II F II II ~A II II A 1\ B II d!..! set of all states satisfying A true of all states = P true of no state = 0 P -II A II IIA II n II B II II <a> A II d~ true iff it is possible to do an a and move to a state enjoying A II [aJ A II ~ true iff however we do an a we move to a state enjoying A TRUE if we cannot do an a Example: 2 place buffer (cont) Here are some satisfaction relations over the 2 place buffer Property p Set of states with p II T { Bo, B1, B2 } II <->T {Bo,B1 ,B2 } II <get> T { Bo, B1 } II <put> T { B 1 , B2 } II <get>TI\[-get]F { Bo } II <get>TI\<-put>T { B1 } II <put> T 1\ [-put] F { B2 } II H F {} II F { } Min and max fix poin s. In general when we look for the fix points of a formula several sets of states might be solutions. And since there may be several solutions, key questions to ask are: how do we find them? are there any of special interest? If we wish to find all the fix points, we could test all the possible combinations from the empty set, the sets of singletons, two states at a time, ... , all the way up to P. It turns out that the fix points form a lattice and that the "least" and "largest" of solutions are not only unique, but they also have interesting physical interpretations and fast algorithms. The minimum (least) fixpoint includes only what is nec-essarily true. It expresses liveness: e.g. a must eventually happen. It is found by iteration: we start from the empty set of states and include what must be there. The maximum (largest) fix point includes everything except that which is necessarily false. It expresses safety: e.g. a holds everywhere. It is found by iteration: start with all possible states and pare out those found wanting. Raw modal 1-1. Modal 1-1 extends HML with fix points: A H M L I min(X.A) I max(X.A) where X is a fix point variable. min and max are dual operations - only one need be defined as a primitive. Unfortunately properties written in raw modal 1-1 are rather hard to read. As an example, a test for the absence of deadlock is: max(X. < - > T 1\ [-]X) It expresses the set of states X which can themselves make a move « - > T) and from which all moves ([ -]) takes us to a member of the set of states X which can ... Thus, no member of this set of states is incapable of making a move. Since this is a relatively simple test, it doesn't take much imagination to to realise that complicated proper-ties can be very hard to for humans to interpret. The same game has been played for many years by temporal logicians who have come up with a few basic operators that may he composed. Amongst these are AL WAY S needs all states on all paths as witnesses PAT H needs all states on a single path to be witnesses POSSIBLE needs only a single state on a single path as a witness EV ENTU ALLY needs a single witness on all paths and modal I-' is powerful enough to express them all: max(X.P /\ [-]X) ALWAYS max(X.P/\ < - > X) PATH min(X.P V [-]X) EV ENTU ALLY min(X.PV < - > X) POSSI BLE These operators are easier to understand, and we use them rather than raw modal tJ. 4 Property testing in modal J-l DEADLOCK means that a system may reach a state in which it cannot make a move (is stuck). For any system SYS, absence of deadlock may be expressed as: SYS F ALWAYS <-> T read as "in every state (ALWAYS), it is possible to make a move «-> T)", or by its dual SYS F ...,(POSSIBLE H F) read as "it is not true that there exists a path to a state (POSSIBLE) in which every move is impossible ([-] F)". FAIRNESS means that a system can not "spin" forever without enabling some particular input or output ac-tion. For any system SYS, and for a particular action a, this may be expressed as: SYS F ALWAYS..., PATH..., <a> T read as "from every state (ALWAYS) there does not exist a path (..., PATH) to a state where action a is never enabled (..., <a> T)" or by its dual SYS F ALWAYS EVENTUALLY <a> T which reads as "from every state (ALWAYS) for each path (EVENTUALLY) there is a state in which a is enabled «a> T)". SAFETY tests to see that bad things cannot happen. Safety tests must be tailored to the system at hand. For the two place buffer, we may want to check that it is never possible to output three times without doing an input. Bo F ALWAYS [get][get][get]F read as "in every state (ALWAYS) it is not possible to perform three consecutive get actions ([get] [get] [get] F) . LIVENESS tests to see that good things may happen (e.g. each request may be accepted) For any system SYS, and a particular action a, live ness of action a may be expressed as: Bo F ALWAYS POSSIBLE <a> T read as "from every state (ALWAYS) there exists a path (POSSIBLE) to some state where action a is enabled «a> T)". Fairness can be seen as a stronger form of liveness. 5 CSM: Dill et. al's memory In this section we put it all together using a recently published example. [3], Dill et. al describe (but do not specify) a FIFO storage management control system using Petri nets. wr wa din CSM cr dout Co e;:r This CSM has to deal with two types of request: 1. WRITE which claims a storage location and then puts data read from din into it 2. CLEAR which emits the "next" data item (when one is available) on dout and then frees that location The implementation they have in mind uses a circu-lar buffer as basic storage. The storage is guarded by a controller which prevents din and dout occurring to-gether (mutual exclusion), and also refuses writes when the buffer is full and refuses clears when the buffer is empty. This specification is given shape by considering W (write) and C (clear) agents running in parallel. W d;J wr.din.wa.W E d;J cr.dout.ca.E CSM d;J (W I E) \ {timing constraints} We now define a counter which is used to keep track of the number of used slots in the system. Every time a slot is given out it counts up and every time a slot is returned it counts down. Since we need to be able to test the state of the counter before actual accesses are made, the counter maintains a number of flags: f (full) and nf (notfull); and e (empty) and ne (notempty). Here we use a 3-counter - a counter of arbitrary size is defined in the same manner, Notice that this counter fails with a signal on err should we attempt to up a full count or down an empty count. C3 d;J down.C2 + up.err.O + f.C3 + ne.C3 C2 d;J down.C1 + up.C3 + nf,C2 + ne.C2 C1 d;J down.Co + up.C2 + nf,C1 + ne.C1 Co d;J down.err.O + up.C1 + nf.Co + e.Co Our second approximation to the specification is: W d!.l wr.nf.up.din.wa.W E d;J cr.ne.dout.down.ca.E Co as above CSM (W I E I Co IS) \ {down, up, f, nf, e, ne} 989 990 in which W tests the Hag nf to ensure a slot before claim-ing it with an up and reading in the data, and E tests the Hag ne to ensure data is there before writing it out and then returning the slot with a down. Our last step is to ensure that data inputs and out-puts are mutually exclusive. All we need add is an extra semaphore: W d;J wr.nf.gS.up.din.pS. wa. W E d;J cr.ne.gS.dout.down.pS.ca.E Co d;! as above S d;! gS.pS.S CSM d;J (W I E I Co I S) \ {down, up, f,nf, e, ne,gS,pS} Dill et. al state the desirability of testing the speci-fication for mutual exclusion on data input and output and ensuring that data cannot be input when SM is full and output when SM is empty. The Concurrency Work Bench (CWB) [2] has a fully automatic model checker, which makes these and other more searching questions trivial to ask: • Is it always possible to make some move? i.e. no deadlock. CSM F ALWAYS <->T • No bus data contention, i.e. it is never possible to both input and output. CSM F ALWAYS ...,«<din>T /\ <dout>T) • we can neither overflow nor underflow the stack. CSM F ...,(POSSIBLE <err>T) • is" din" a live transition? CSM F ALWAYS POSSIBLE <din>T • is the system "fair" on din? CSM F ALWAYS EVENTUALLY <din>T • is the input protocol respected? i.e. no din without a wr; no wa without a din; no wa without a wr CSM F CYCLE wr din /\ CYCLE din tVa /\ CYCLE wr tVa where we introduce a new operator called CYCLE: CYCLE a b d;J max(X.tb]F /\ [-a]X /\ [a](max(Y. [a]F /\ [-b]Y /\ [b]X») This describes the set of states X where no b action is possible, and any action other than a will take us back into this set of states, and an a action will take us to a set of states Y where, no a action is possible, and any action other than a b will take us back into this set of states, and a b action will take us back into the set of states X where ... In essence, it ensures that action a always preceeds action b which always preceeds action a which ... 6 • is the output protocol respected? i.e. no dout with-out a cr; no CO without a dout; and no ca without a cr. CSM F CYCLEcrdout /\ CYCLE dout ca /\ CYCLE cr ca Conclusions If specifications for circuits are written in a formal speci-fication language such as CCS, it is possible to automat-ically and mechanically check properties of the specifica-tion using the modal IJ-logic. These methods are comple-mentary, as CCS uses an operational description of circuit behaviour, while the ModallJ logic describes properties of specifications independently from their implementation. For details of how to specify complex systems in CCS see the companion paper in these proceedings [6]. 7 Acknowledgements This research is supported by Equipment and Operat-ing Grants from CMC and NSERC, studentships from Hewlett Packard (KS) and The Alberta Microelectronic Centre (YL), and AGT/SEED (JA). References [1] J. Aldwinckle, R. Nagarajan, and G. Birtwistle. An introduction to Modal Logic and its Applications on the Concurrency Workbench. Technical Report, Computer Science Department, University of Calgary, 1991. [2] Rance Cleaveland, Joachim Parrow, and Bernhard Steffen. The concurrency workbench: A semantics-based tool for the verification fo concurrent systems. A C M Transactions on Programming Languages and Systems, 15(1),1993. [3] D. Dill, S. Nowick, and C. Sproull. Specification and automatic verification of self-timed queues. Formal Methods in Systems Design, 1(1 ):30-60, 1992. [4] Y. Liu. Reasoning about asynchronous designs in CCS. MSc Thesis, Department of Electrical and Com-puter Engineering, University of Calgary, 1992. [5] Z. Manna and A. Pnueli. The Temporal Logic of Re-active Systems: specification. Springer-Verlag, New York, 1992. [6] K. Stevens, J. Aldwinckle, G. Birtwistle, and Y. Lin. Designing parallel specifications in CCS. In Proceed-ings of Canadian Conference on Electrical and Com-puter Engineering, Vancouver, 1993. [7] C. Stirling. Modal and Temporal Logics for Processes. Tech Report ECS-LFCS-92-221, Laboratory for the Foundations of Computer Science, Computer Science, University of Edinburgh, 1992. 

Testing the consequences of specifications in modal µ

https://collections.lib.utah.edu/dl_files/2e/5a/2e5a3f429554dc4a99ab85771a81ca18b74f522d.pdf

Testing the consequences of specifications in modal µ

Abstract

Similar works

Full text

Available Versions

The University of Utah: J. Willard Marriott Digital Library