interactive state-space analysis of concurrent systems · pdf fileinteractive state-space...

IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. SE-13, NO. 10, OCTOBER 1987

Interactive State-Space Analysis of ConcurrentSystems

E. TIMOTHY MORGAN AND RAMI R. RAZOUK, MEMBER, IEEE

Abstract-The introduction of concurrency into programs has addedto the complexity of the software design process. This is most evidentin the design of communications protocols where concurrency is inher-ent to the behavior of the system. The complexity exhibited by suchsoftware systems makes more evident the need for computer-aidedtools for automatically analyzing behavior.

The Distributed Systems project at UCI has been developing tech-niques and tools, based on Petri nets, which support the design andevaluation of concurrent software systems. Techniques based on con-structing reachability graphs that represent projections and selectionsof complete state-spaces have been developed. This paper focuses at-tention on the computer-aided analysis of these graphs for the purposeof proving correctness of the modeled system. The application of theanalysis technique to evaluating simulation results for correctness isdiscussed. The tool which supports this analysis (the reachability graphanalyzer, RGA) is also described. This tool provides mechanisms forproving general system properties (e.g., deadlock-freeness) as well assystem-specific properties. The tool is sufficiently general to allow auser to apply complex user-defined analysis algorithms to reachabilitygraphs. The alternating-bit protocol, with a bounded channel, is usedto demonstrate the power of the tool and to point to future extensions.

Index Terms-Assertions, communications protocols, computer-aided design, concurrent programs, correctness, Petri net, reachabil-ity graph, software design.

I. INTRODUCTIONW,tITH the increased use of distributed processing in

v a wide range of applications, a need exists for tech-niques which can be used to assist in evaluating the cor-rectness of concurrent software and hardware. A varietyof novel specification and verification approaches arebeing investigated ranging from highly abstract and math-ematical approaches (e.g., temporal logic [7], [24]) to ap-proaches which closely mirror and restrict implementa-tions (e.g., algorithmic specifications [27]). All thetechniques in question are based on some formal modelof computation and, in order to be used effectively, mustbe supported by automated tools.

In recent years, the Petri net model [16] has been ex-tended in a variety of ways and used to model wide rangesof hardware/software systems. Extended Petri net modelsare particularly interesting since they support verification

Manuscript received April 30, 1985. The work of R. R. Razouk wassupported in part by the Microelectronics Innovation and Computer Re-search Opportunities (MICRO) program cosponsored by Hughes AircraftCorporation. The work of E. T. Morgan was supported in part by the Na-tional Science Foundation under Grant DCR 84-06756.

The authors are with the Department of Information and Computer Sci-ence, University of California, Irvine, CA 92717.

IEEE Log Number 8716567.

of correctness [9], [28], [2], [22] and evaluation of per-formance [25], [13], [10], [18], [30], [20], [21], [8]. It isthis versatility which motivates the paper's focus on Petrinets.

Verification can be generally viewed as requiring rea-soning about the complete state-space of a system. Forexample, proving deadlock-freeness requires reasoningabout the possibility of reaching a state in which no fur-ther useful action is possible. Verifying the "safety" ofa system requires reasoning about the possibility of reach-ing states which are deemed unsafe. Any verification at-tempt requires a clear specification of what constitutes"correct" behavior. A proof of correctness is then thetask of reasoning about states (or sequences of states) andevents (or sequences of events) to show that they are con-sistent with the specified desirable behavior.Reasoning about a concurrent system's state-space is a

difficult task. The most efficient approach is reasoning,byinduction [9]. A correctness proof requires proving thatthe initial state meets the required behavior and that everytransition (event) in the system preserves that desired be-havior. While some invariants can be derived automati-cally [11], in general the modeler formulates the invariantand attempts to prove it. Some automation of the proofscan be done. Invariants can be very useful in verifyingconstant properties of the state-space but cannot be usedto verify properties relating to sequences of states andevents. Those latter properties (such as deadlock-free-ness) must be verified using the notion of a "homingstate" [9].An alternative approach is to reason about the complete

state-space by constructing and then analyzing a finite (andhopefully small) representation of the complete state-space. Several approaches exist which allow for construc-tion of such finite representations:

1) Projections can be performed to preserve some as-pects of the behavior of a system while ignoring others.A projection involves aggregating states based on someaggregation criterion. For example, a control projectionaggregates states with identical control states, ignoring thedata state and timing information. In Petri net models,analyzing only the control portion of a net can yield sucha control projection. In Taylor's work [29] such projec-tions are performed by focusing on concurrency states(states in which tasks synchronize and communicate). Ifa projection is performed carefully so as to preserve thebehavior which is being analyzed (e.g., control flow), then

0098-5589/87/1000-1080$01.00 © 1987 IEEE

1080

MORGAN AND RAZOUK: STATE-SPACE ANALYSIS OF CONCURRENT SYSTEMS

analyzing the smaller state-space can yield results whichare known to apply to the complete state-space. In mostcases such analyses yield results which indicate potentialproblems in the real system. In some sense such analysesaccount for the "worst-case." Past work on Petri nets inthis area has focused on proving general properties suchas deadlock-freeness by relying on Petri net propertiessuch as liveness and boundedness [17]. System-specificproperties are usually verified by manual examination ofthe state space [19].

2) Reductions are transformations which can be ap-

plied on the model of a system to yield a smaller model(and therefore one with a smaller state-space). Results forreduction must be carefully constructed to guarantee thatthey preserve the behavior being analyzed. An exampleof such reductions is the reduction procedure defined forUCLA graphs [6]. This reduction procedure is guaranteedto preserve deadlocks (and all terminal states) while sig-nificantly reducing the size of the state-space.

3) Selections can be performed on a state-space by fo-cusing attention on a selected portion of the state-space.For example, simulation experiments focus on some se-

lected paths through the complete system state-space.Such paths are (it is hoped) representative of the behaviorof the complete system. The thoroughness of a simulationexperiment can be quantified by the fraction of the com-

plete state space that it traverses. Analysis of such se-

lected subgraphs cannot be used to "prove" propertiesabout the complete state-space. However, such an anal-ysis can increase confidence in the correctness of the sys-

tem.Regardless of how finite state-spaces are constructed,

they can be viewed as reachability graphs. Nodes in thesegraphs represent states of the system while arcs represent,state transitions. Analysis of such graphs can be very use-

ful but is difficult: Typically, reachability analysis toolssupport a set of fixed built-in analyses which can be ap-

plied to all models [4]. Such a narrow view of "correct-ness" is of limited use when a need exists to verify theconsistency between a model and some higher level spec-

ification. This paper addresses this deficiency by present-ing a tool which can be used to analyze reachability graphs(partial or complete) of models to determine if the modelof the system is consistent with some higher-level speci-fication. The novelty in this work centers on a language(first order predicate calculus) and an interpreter whichallow a designer to give formal specifications of generalcorrectness properties (e.g., deadlock-freeness) as well as

system-specific properties in a way which can be easilyunderstood and which can be automatically verified. Inaddition to formal correctness proofs the tool can be usedto evaluate simulation results and to "debug" the systembeing modeled and its model by providing the designerwith convenient ways of focusing attention on portions ofthe state-space. The tool in question (the ReachabilityGraph Analyzer, or RGA [14], [15]) is part of a largersuite of tools (P-NUT, Petri Net UTilities) being devel-oped at UCI by the Distributed Systems Project [23].

In Section II of the paper, Petri nets are briefly re-viewed. The usefulness of reachability graphs and theirlimitations are also discussed. Section III describes someof the most primitive capabilities of RGA. The diningphilosophers problem is used as a reference example.Section IV delves into the more advanced features ofRGAwhich make it extensible and flexible. Section V presentsa model of the alternating-bit protocol with boundedchannels and demonstrates some of the flexibility of RGAin analyzing such complex reachability graphs.

II. PETRI NETS AND REACHABILITY GRAPHSPetri nets [16] are bipartate, directed graphs whose

nodes are transitions and places. The arcs of the graphdenote those places which are inputs to the transitions andthose which are outputs. Associated with each place is anumber of tokens; a marking is an assignment of zero ormore tokens to each place in the net. A transition is con-sidered to be enabled when there is at least one token oneach of its input places.The execution of a net involves choosing an enabled

transition nondeterministically and firing it. Firing in-volves removing a token from each input place and place-ing one on each of the transition's output places. The fir-ing operation is considered to be an instantaneous andindivisible operation, and no two transitions may firesimultaneously. If the number of output places is not equalto the number of input places, then the total number oftokens in the net changes (the net is not conservative).When there is more than one token on the graph, there isa possibility of concurrent execution. However, not everytoken represents a separate process; some may be usedonly for synchronization and resource control.The paragraphs above describe the simplest form of

Petri net. Practical use of the model requires a variety ofextensions which simplify the construction of largermodels and increase the modeling power of the model. Inorder to support modeling time-dependent behavior, a va-riety of time extensions have been proposed. Timed Petrinets [20] support fixed enabling and firing times. TimePetri nets [12] support ranges of time delays. GeneralizedStochastic Petri nets [10] support exponentially distrib-uted firing times. Other common extensions include da-ta dependent predicates and actions associated with tran-sitions in the net [3]. These extensions permit details ofdata manipulation to be modeled without obscuring thebasic control flow modeled by the Petri net.The state of a net can be characterized by the distribu-

tion of tokens on places (the marking), by the set of en-abled and firing transitions (for Timed Petri nets) and bythe values of all the data variables. The construction ofthe complete state space of a fully-interpreted Petri net isunrealistic. However, by focusing attention on some com-ponents of the state of the net it is possible to easily con-struct projections. For example, if all timing informationand all predicates and actions are omitted, then the stateof the net simply consists of the marking of the net. Thusa firing of a transition, which can result in a change in the

1081


distribution of tokens, represents a change in the state ofthe net. A marking /' is said to be immediately reachablefrom a marking it if firing some enabled transition resultsin changing the marking from A to i'. The reflexive tran-sitive closure of the immediately reachable relationshipdefines the reachability set, the set of all markings whichcan be reached from ,. If timing information is retained,then the state of a net consists of the marking as well asthe set of enabled and firing transitions [20].

Projections do not always yield finite reachabilitygraphs. A reachability graph obtained from an ordinaryPetri net (a control projection) will be infinite if any placecan acquire an unbounded number of tokens. Varioustechniques exist for handling this case in formal analysisof Petri nets [16], but these techniques will not be dis-cussed here, as the analyzer being described handles onlyfinite graphs. Typically, problems which would be ana-lyzed with this tool, such as communications protocols,have by design only a finite number of states. For thosecases where the number of states is infinite, portions ofthe state space must be selected and analyzed. In P-NUTthis is currently accomplished by running simulation ex-periments from which finite partial reachability graphs areconstructed.Once a reachability graph (complete or otherwise) is

constructed, it can be used in a number of ways to verifyproperties of the Petri net. If the graph being analyzed iscomplete, then the analysis is a proof of correctness. Ifthe graph is incomplete, then the analysis can only servethe purpose of increasing confidence. Among the prop-erties which can be analyzed are boundedness, safeness,and liveness. The maximum number of tokens on anyplace can be determined by examining each state of thegraph. If this bound is 1 for all places, then the net is safe,and if the total number of tokens on all places in each stateis a constant, the net is conservative. If every state has atleast one successor state, then the net is deadlock-free. Atransition is dead in some marking if no sequence of tran-sition firings exists which can enable it. If there- existssuch a sequence, however, the transition is said to be po-tentiallyfirable. A transition is live if it is potentially fir-able in all reachable markings. By examining the arcs ofthe graph, it is possible to determine if a transition is liveand the set of all states which can reach or can be reachedfrom a particular state. These properties of the net(boundedness, liveness, etc.) are important because prop-erties of the system being modeled can be inferred fromthem. For example, liveness implies that the system isdeadlock-free.The next two sections of the paper present the capabil-

ities of the analyzer. The approach taken in the imple-mentation of this tool is based on an understanding of theneed for flexible and expandable tools. Other implemen-tations of reachability graph builders [4] have tended tohave a set of built-in algorithms which can be used toverify some known general properties (e.g., deadlock-freeness). In this tool, more general mechanisms are madeavailable to the user instead of specific functions which

solve only certain predefined problems. Arbitrarily com-plex algorithms can be synthesized from the simple basiccapabilities of the analyzer. Should some algorithms proveparticularly useful, the analyzer can then be enhanced toprovide them as built-ins.

III. BASIC CAPABILITIESThe RGA system functions on two levels. First, it al-

lows the user to specify propositions and predicates [26]over a universe of discourse consisting of places and tran-sitions in a Petri net, and states and arcs in its reachabilitygraph. Variables in the propositions may be bound by as-signment or by universal or existential quantification.RGA is further augmented with primitives which give itthe capabilities of a simple programming language.The intended use of RGA is to verify interesting prop-

erties about the system being modeled. Since all systembehavior is encoded in the state of the system, it is criticalfor such a tool to allow the user to express system prop-erties as predicates on places and states. To this end, RGAprovides the user with the ability to refer to four built-insets: the set of places in the net P, the set of transitionsT, the set of reachable states S, the set of arcs in thereachability graph A. Places are referred to by theirnames, while states are referred to by their number (#0 isthe initial state).

A. Arithmetic and Boolean ExpressionsArithmetic expressions follow the conventions of most

modern programming languages, with operations such as+,-, *, and /, using parentheses to override the normaloperator precedence. The operands of these operators areexpressions whose values are integers or reals. Places inthe net are evaluated as the number of tokens on that place,in the context of some state written in parentheses afterthe place name. Places may also be evaluated as booleansin situations where Boolean values are expected. Table Ishows the set of predefined integer-valued primitive func-tions. Real-valued primitive functions are listed in TableII. The types of the arguments of these functions, such asarcs and transitions, are explained below.As with other expressions, Boolean expressions are built

up from constants, infix operators, predefined functionsand user-defined functions. The Boolean constants are thereserved words true and false.The infix Boolean operators are the conventional arith-

metic comparison tests, <, <=, >, > =, =, and !=.The equal and not equal tests may be applied to any datatypes, while the other operators are restricted to integerand real expressions. Some other infix Boolean operatorsapply to Boolean expressions: implies, iff, and, and or.Both the and and or operators are "short-circuit" oper-ators which evaluate the lefthand operand first and thenevaluate the righthand operand only if necessary. The pre-fix unary operator not may be used to negate a logicalexpression. There is only one primitive function whichreturns a Boolean value, shown in Table III.

1082


TABLE IINTEGER-VALUED PRIMITIVE FUNCTIONS

int (float) The expression float is evaluated and rounded to an integer.tokens (state) The total number of tokens on all places in a specified state. An

alternate way of writing this function is to put the state withinvertical bars, as an absolute value. For example, 1#11.

marked(state) Returns the number of places in the argument state which haveat least one token on them. If marked(s)=tokens(s) then thestate s is safe.

nsucc (state) Returns the number arcs going out of the argument state.

npred(state) Returns the number of arcs going into the indicated state.

card(s) Returns the number of elements of a set a.

TABLE IIREAL-VALUED PRIMITIVE FUNCTIONS

float (int)

enable-time (trans)

f iring_t ime (trans)

prob (trans)

atime (a)

aprob (a)

Converts the integer expression int to a floating point value.

Returns the enabling time for a transition trans. Zero isreturned for untimed Petri nets.

Returns the firing time for a transition trans. Zero is returnedfor untimed Petri nets.

Returns the probability of a transition trans as a floatingpoint value. Returns 0.0 for untimed Petri nets.

Returns the time associated with an arc a in a timed reach-ability graph as a floating point value. Returns 0.0 withuntimed nets.

Returns the probability associated with an arc a in a timedreachability graph as a floating point value. Returns 0.0 withuntimed nets.

TABLE IIIBOOLEAN-VALUED PRIMITIVE FUNCTION

in(item, a) The in function takes two arguments, an item of any type, anda set of items s. It returns true if the item is an element of theindicated set, and false otherwise.

B. State, Place, Transition, and Arc ExpressionsStates of the reachability graph and transitions in the

net are numbered. Particular states can be referenced usinga # symbol followed by the number of the state. Transi-tions are similarly referenced using a dollar sign and thetransition number. They may also be given symbolicnames in the Petri net. Places are referred to through theidentifiers defined in the original Petri net.

Arcs between nodes in a reachability graph model statetransitions which result from transitions firing. These arcs

may be referred to as a quadruple of the source and des-tination states and the lists, or sequences, of transistionswhich begin and finish firing with this state change. Foruntimed Petri nets, the first list will contain the one tran-sition which fired, and the second list will be empty. Forexample, [#0, #10, <<$9>>, <<>>] wouldbethe arc from state #0 to state #10 firing transition $9.Table IV shows the primitive functions which return theseparate components of an arc.

Below are some examples of the types of expressionswhich can be constructed with the capabilities describedup to this point:

1) nsucc(s) > 0: This expression will be true if states has one or more successors. Such an expression can be

TABLE IVSTATE AND TRANSITION-VALUED PRIMITIVE FUNCTIONS

src (a) Returns the source state of a.

dest (a) Returns the destination state of a.tbegin (a) Returns the list of transitions which begin firing with arc a.tend(a) Returns the list of transitions which finish firing with arc a.

used to detect if s is deadlocked or is a proper terminalstate.

2) in(s, S') & marked(s) != 0: This expression istrue if state s is a member of set of states S' and thatthere is at least one marked place in s.

3) tokens(s) = tokens(#O): This tests whether astate s contains the same number of tokens as the initialstate. If all states satisfy this predicate, the net is said tobe conservative.

C. Set and Sequence ExpressionThe set operations are the single most powerful feature

of the language. Sets are composed of any legal data types,including other sets; all the elements of a set must be ofthe same type. A- single set is either a set variable, a setconstant, or a set-valued function. Sequences, or lists, aresimilar to sets, but duplicate elements are allowed, andthe sequence is maintained in the order in which the ele-ments are added.A set constant is written as a list of expressions (which

need not be constants) within curly braces { }. For ex-ample, the set consisting of states 1, 5-10, and 12 can bewritten

{#1, #5. . #10, #1 2}

Sequence constants are similar, using the symbols < <and > > to delimit the list.Another powerful way of specifying a set is the subset

construct. It allows elements to be selected from a setusing any Boolean expression as the selection criterion.The subset construct is written

{id in set-expression boolean-expression}

This construct creates a set of all elements in a given setset-expression which satisfy the property specified in theboolean-expression. Table V lists the primitive functionswhich return sets or sequences. Table VI lists those func-tions which are used to manipulate sets and sequences.Two of the language's most important operators are

forall and exists, the universal and existential quanti-fiers. They allow traversal through sets, evaluating aBoolean expression for each element of the set. Their syn-tax is the same, so only that of forall will be given:

forall id in set [boolean-expression]

This expression is evaluated as follows. The set is eval-uated once and only once, and the id is then loopedthrough the elements of this set one at a time. For eachvalue of the id, the boolean-expression is evaluated. If forall values, this expression evaluates to true, then the

1083


TABLE VSET-VALUED PRIMITIVE FUNCTIONS

ain(state) Returns the set of arcs whose destination state is the indi-cated state.

aout (state) Returns the set of arcs whose source state is the indicatedstate.

succ (state) The succ function returns the (possibly empty) set of im-mediate successor states in the reachability graph of thespecified state.

pred(state) The pred function it returns the set of immediate prede-cessor states of the specified state.

allsucc (state) Returns the set of all the successors of the indicated state,and recursively, all their successors.

allpred(state) Returns the set of all the predecessors of the indicatedstate, and recursively, all their predecessors.

input_places(trans) Returns the set of input places for a particular transitiontrans.

output-places(trans) Returns the set of output places for a particular transitiontrans.

TABLE VISET-MANIPULATION FUNCTIONS

union(sl, s2) The union function takes two sets or sequences sl and s2as its arguments. This function returns the set union of thetwo sets, or the concatenation of the two sequences in theorder given. The infix plus operator (+) may be written inplace of the union function.

intersectionCsl, s2) This function is similar to the union function, but it re-turns the set intersection of its two arguments which mustboth be sets. The two arguments must both be sets of thesame type, or at least one must be the empty set.

setdiff (sl, s2) The setdiff command takes two sets or sequences andreturns a copy of sl minus any elements it has in commonwith s2. The setdiff function may be written using theinfix minus (-) operator.

setop(fune, set) The setop operator applies the function func, which mustbe a monadic function, to each element of the set. Theresults of the function executions are unioned into the re-sulting set, which is returned as the value of the setopfunction. The function fune may return values which areeither individual elements or sets of elements; it may beeither a user-defined function or one of the predefined func-tions succ, pred, ain, aout. card, marked. nsucc,npred. src. dest, trans. allpred, allsucc. show-state. conflict_set, atime, aprob, probability.capacity, float, int, enable-time., firing_time.input-places. and output-places.

set(sequence) The sequence will be converted to a set of the same type,eliminating duplicate elements.

ret(s, trans) Returns a sequence of the remaining enabling time(s) fora transition trans within the context of a state s. Foruntimed reachability graphs, or when no enablings of thetransition exist in the state, an empty sequence is returned.

rft(s, trans) Returns a sequence of the remaining firing time(s) for atransition trans within the context of a state s. For un-timed reachability graphs, or when no instances of firingsof the transition exist in the state, an empty sequence isreturned.

whole expression returns that value. But if the expressionever evaluates to false, then execution of the loop ishalted immediately and the forall expression returnsfalse.The exists expression is similar to forall, but with the

logical tests reversed. It continues to evaluate the Booleanexpression until it exhausts all the elements of the set or

until the expression evaluates to true. If the set is ex-

hausted, then exists returns false, and otherwise, true.Some examples of the set traversal operators follow:

1) forall s in S [nsucc(s) > 01: This predicate is trueif the net is deadlock-free.

2) forall s in S [forall p in P [p(s) <= 11]: Thisexpression is true if all the places in the net are safe (1-bounded) in all states.

3) exists sin S [philosopher eating 1 (s) > 0]: Inthe context of the dining philosopher example (discussedbelow), this predicate determines if it is possible for phi-losopher 1 to eat. It should be noted that this predicatedoes not in any way guarantee that philosopher 1 will evereat.

D. A Simple ExampleNow a short example is used to demonstrate some of

the capabilities of the analyzer. The dining philosophersproblem will be used because it is widely understood. Fig.1 shows the Petri net representation of one philosopher inthe dining philosophers problem. The equivalent textualrepresentation of the Petri net for the problem with threephilosophers is shown in Fig. 2. Using the P-NUT tools,this representation is converted into a canonical represen-tation of the same net from which the reachability graphis built. The reachability graph is then read by RGA sothat the analysis can be performed.

Fig. 3 shows a sample run of the analyzer on the phi-losophers problem. The line numbers at the left have beenadded for reference purposes. In line 1, the user asks howmany states there are in the reachability graph by deter-mining the cardinality of the set of all states S. There are26 states.On line 3, the user asks if the net is deadlock-free (that

each state has at least one successor). RGA responds withfalse, that there is at least one deadlocked state. The userthen asks on line 5 for the set of all states s which haveno successors. The response is a set containing one state,#21. On line 7, the user asks for a symbolic display ofstate #21, with the result shown on lines 8 and 9. Thenames are the names of the places as defined in the orig-inal Petri net, which each have one token (more than onetoken would have been indicated by a token count).

In lines 10 and 12, the user determines if the net is safe,using two different methods. Line 10 uses the strict defi-nition of net safety, while the expression on line 12 takesadvantage of two built-in functions. Both expressionsevaluate to true, indicating that the net is safe. Theexpression in line 12 is computed many times faster thanthat on line 10 because it avoids the doubly nested loopsby using built-in functions and precomputed values.

All of the above tests apply equally to any net whichmight be analyzed with RGA; that is, they test for generalproperties. Next, some specific properties of the diningphilosophers problems are analyzed. In line 14, the userasks if it is possible for philosopher 1 to eat, and the sys-tem responds true. The user then asks for the set of allstates in which the philospher is eating, and RGA re-sponds with a set of three states. Finally, on line 18, theuser verifies a property of the net which should be true,that the maximum number of philosophers eating in any

1084


Fig. 1. Petri net for dining philosopher i.

* Dining philosophers problem with n=3 philosophers.

for -3 {for iO to n-I {philosophere-thinkingEi], forks.free[i] -> philosopher..i.orkti], forks-buuyti]philosophers._thinkingEi], forks.Jfree(i+1) X ml -> philosopher-l.fork[i],

forks.busyt(i+1) % n]philosopher_l_forkti], forku.free(i] -> philosopher-eating[i]. forks..busy[i]philosopher-l.forkti], forks.free [(ii) X n] -> philosopher.eating[i),

forks.busy[(i+1) X n]philosopheroeating[i], forks_busy ti].

forks.busyE(i+1) X ml -> philosophers.thinkingti], forks-.free[i].forks.free[ti+1) X n]

<philosopherstthinkingEi], forks_free [i)>

Fig. 2. Dining philosophers problem for three philosophers symbolic formof Petri net.

1 >card(S)2 263 >forall s in S tnsucc(s) > 0]4 false5 >{s in S unsucc(s) = 0)6 {#21}7 >showstate(#21)8 philosopher-l-forkO philosopher_l_fiorkl philosopher-lfork2 forks..busyO9 forks_busyl forks-busy210 >forall s in S tforall p in P tp(s) < 1]]i1 true12 >forall s in S [marked(s) tokens(s)]13 true14 >exists s in S fphilosopher-eatingl(s) > 011s true16 >{s in S philosopher_eatingl(s) > 0)17 (#14, #23, #24118 >forall s in S [philooopher-eatingO(s) + philosopher-eatingl(s) +19 philosopher-eating2(s) < 3/2]20 true

Fig. 3. Analysis of dining philosophers problem.

1085


state must be less than or equal to the number of philos-ophers divided by the number of forks needed by a phi-losopher to eat. If this expression did not evaluate to true,then an error in the specification of the net would be in-dicated. In this case, since integer division is used, 3/2is truncated to 1, and therefore no two philosophers canever be eating simultaneously. In general, Ln/2j phi-losophers can eat simultaneously when there are n diningphilosophers.

IV. ADVANCED CAPABILITIESThe features of RGA described above allow a designer

to traverse the graph interactively and to prove someproperties about the net. It may be possible, in some cases,for a designer to develop an algorithm to perform morecomplex analyses of the graph. It is therefore desirable tohave the tool be able to execute user-defined algorithmsbuilt from the primitive capabilities outlined earlier.RGA allows any value to be assigned to an identifier

using the assignment operator (:=), which assigns thevalue of the expression on its right to the identifier on itsleft. In addition, it returns that value as a result. The se-quence of expressions a = 1 and a'= a + 1 wouldassign the identifier a the integer value 2. Then theexpression

a := {s in S nsucc(s) = O}

would assign to a the set of all deadlocked states. Eachidentifier represents a < value, type > pair, so its type aswell as its value can vary dynamically.

It is possible to assign to an identifier an expression,rather than the value of the expression, using the "::="operator, thus defining a function. The syntax used to de-fine a function is

id (formal-parameters) [local-variables] = expression

The formal-parameters and local-variables are lists ofidentifiers separated with commas. If either of these listsis empty, then the corresponding parentheses or bracketsare omitted. The function invocation mechanism in RGAprovides for dynamic scoping of identifiers, as in Lisp.Also as in pure Lisp, recursion is' often the primary mech-anism for specifying interation.

In order to make user-defined functions sufficientlypowerful, two special expressions are included in the RGAlanguage: expression lists and conditional expressions.The semicolon (;) infix operator evaluates the expressionon its left and discards it, then it evaluates and returns theexpression on its right. It is an associative operator, sothe expression "1;2;3" evaluates to the integer 3. Intui-tively, it provides for sequential execution of expressionsmuch like the execution of statements in conventionalprogramming languages. The if expression is used forconditional expression evaluation. It can take two differ-ent forms:

if boolean-expression then expression fiif boolean-expression then expression] else

expression2 fi

EMPTYSET

can-reach (s) :: cr {} EMPTYSET, {s})

cr(frontier, tried, canreachset)tnfrontierlif frontier = EMPTYSET \

then canreachset \else nfrontier := EMPTYSET; \

tried := union (tried, frontier); \forall s in frontier \

tnfrontier := union(nfrontier,pred(s)); \canreachset :- union (canreachset, pred(s));true ]; \

cr(setdiff(nfrontier, tried), tried, canreachset) \fi

Fig. 4. A small user-defined function.

The type and value returned by the if expression dependson what expression, if any, is executed.

Fig. 4 shows a user-defined function, can reach. Itconstructs the set of states which can reach a particularstate s; thus it is the same as the primitive operationalipred except that the constructed set will contain theinitial state. It has been found empirically that the primi-tive function allpred is about 2.5 times faster than thisuser-defined version.The "\" symbols in the figure are used to indicate that

the end of a line is not the end of the function definition.'The can reach function invokes a recursive function crwhich does the actual work. Cr takes three arguments, afrontier of states which should be tried next, the set ofstates already tested, and the states which have alreadybeen found to be able to reach the starting state. If thereare no more states in the frontier, then cr returns the setcanreachset since nothing more can be added to that set.Otherwise, it adds the frontier set to the set of states whichhave been tried, and constructs the new frontier nfrontieras the set of predecessors of the states in the current fron-tier. Then cr is called recursively, removing any statesfrom the new frontier which have already been tried.

V. AN EXTENSIVE EXAMPLEA. The Alternating-Bit ProtocolA larger example is now presented which makes use of

some of the more sophisticated features of RGA. The ex-ample used is the- alternating-bit protocol [1], with mes-sage and acknowledgment queues of length two. In thisprotocol, there are two communicating entities, a senderand a receiver. The sender sends message packets to thereceiver over an unreliable medium, with a flag bit at-tached to each message. This flag is either a zero or one,alternating from one message to the next. The receiversends acknowledgment packets back to the sender whichhave the same flag bit as the message packet being ac-knowledged. If the receiver receives a packet with whatit considers a bad flag, it still sends an acknowledgmentpacket containing the flag received, which then serves asa negative acknowledgment to the sender. The receiverthen drops the bad packet.Upon receiving a good packet, however, the receiver

alternates its flag to be ready to receive the next packet

1086


from the sender. The sender alternates its flag and trans-mits its next message receiving a valid acknowledgmentpacket. It uses timeouts and negative acknowledgmentsto detertnine when it should stop waiting for an acknowl-edgment and retransmit its current message.

Fig. 5 shows a Petri net representing a high-level de-scription of the alternating-bit protocol, using places torepresent the overall system state. For brevity, the globalstate of the system will be referred to by two digits, thefirst being the sender's flag, and the second being the re-ceiver's flag. The system stays in state 00 until a messageis successfully received by the receiver, and it then entersstate 01. When the acknowledgment is correctly receivedby the sender, the system enters state 11; the sender hasnow alternated its flag, and its attempting to send the nextmessage. When that message is correctly received, thesystem enters state 10, and after its acknowledgment isreceiVed by the sender, the system returns to state 00. Thetransitions labeled "Bad Message" and "Bad Ack"model timeouts and actions taken upon receipt of packetswith bad flags. No other transitions should be possible ina correct implementation of the protocol. This net thusserves as a high-level specification of the protocol againstwhich the model may be tested.

B. Petri Net Model of the Alternating-Bit ProtocolFigs. 6-8 show the textual representation of a detailed

Petri net model of the alternating-bit protocol. Some ofthe transitions are given symbolic names, correspondingto the names of the transitions and places in Fig. 5, be-tween pairs of":" characters for use during analysis. Thequeues or messages being sent, and for the acknowledg-ments returning, are modeled as circular queues. Bothqueues are of length two in this model. The reachabilitygraph built from this Petri net has 1752 states.The sender, shown in Fig. 6, can be in one of four

states: Sready, waitack, ackO, or ackl. Thesend flagO and send flag1 places indicate the stateof the sender's flag. If there is no room in the messagequeue when the sender is ready to send, then the senderwill block until a slot becomes free. Once it has sent amessage, it enters the waitack state to await the ac-knowledgment message from the receiver. Since Petri netsare incapable of representing time, the sender can retrans-mit its last message at any time when it is waiting for anacknowledgment and there are no acknowledgments in thequeue.The receiver, Fig. 7, is in one of four states, Rready,

acking, readO, and read1. When Rready, the receiverwaits until a message appears in the message queue fromthe sender. When a message comes in, it verifies that theflag bit on the message corresponds to the type of messageexpected (rcv_flagO or rcv_flag 1 ). If the flags match,an acknowledgment is sent with the same flag bit, and thereceiver's flag is reversed in preparation for the next mes-sage. Otherwise, if the flag bits do not match, the receiversends an acknowledgement with a flag bit indicating thetype of message it received, giving the sender a negativeacknowledgment.

Bad sendO sendO BadMessage rvO ecvl Ack

MessageOReceived

Ackl t m AckOReceived Received

Bad se 1 se I if BadAck rev rev Message

MessagelReceived

Fig. 5. Meta level Petri net for alternating-bit protocol.

Fig. 8 shows the model of transmission line noise andthe initial state of the Petri net. This model of the alter-nating-bit protocol assumes that there is some probabilitythat line noise will destroy messages or acknowledg-ments, but messages are never distorted (delivered withchanged flags). There are therefore some transitions whichcan absorb messages or acknowledgments before they arereceived, simply dropping the packets. In the initial state,the sender is ready to send a message with flag bit 0, thereceiver is ready to receive a message with flag bit 0, andboth the message and acknowledgment queues are empty.

C. Verification of the ModelWe have found that RGA can be useful in verifying that

a Petri Net model of a system is correct as well as in ana-lyzing the system being modeled. Our understanding ofthe alternating-bit protocol and our model of it allows usto state several properties this model should exhibit if itis correct:

1) The model should be safe since each place is usedas a Boolean flag.

2) The sum of the tokens on Sready, waitack, ackO,and ack1 will be 1 for all states since these are mutuallyexclusive conditions. Send_flagO and send_flag 1 arealso mutually exclusive.

3) The sum of the tokens on Rready, acking, readO,and read 1 should be 1 for all states. This also verifiesthat readO and read1 are mutually exclusive.

4) The sum of rcv flagO and rcv flag 1 should be1 for all states, verifying that the receiver expects onlyone type of message at any one time.

5) For each slot in the each queue, at most one flag bitshould be set. For instance, msgO 0 and msg 1 0should be mutually exclusive. In states where neither areset, then that slot should be available (e.g.,slotO empty). A slot should not be both available andfilled (e.g., slotO empty and slotO filled are mu-tually exclusive).

6) The system should behave as described by Fig. 5.Arcs should not exist between the states other than thoseshown. The transitions which loop from each of the sys-tem states should be fired only when a message or ac-knowledgment has not been received successfully. To getfrom state 00 to state 11, or state 11 to state 00, exactlyone good message should have been received by the re-

1087


/* Sender sends msg */Sready, sendtflagO, slotO.empty, lastO -> msgO_O, lastl, slotO_filled,

send.flagO, waitackSready, send.flagl, slotO-empty, lastO -> msgl_O, lastl, slotO_filled,

senddflagi, waitackSready, send.flagO, slotl_empty, lasti -> msgO_l, lastO, slotl_filled,

send_flagO, waitackSready, send_flagl, slotl_empty, lasti -> msgl_1, lastO, sloti_filled,

send-flagl, waitack

/* Sender dequeues an acknowledgement packet. */waitack, first_ackO, filled_ackO, ack_msgO_0 -> first.ackl, ack slotO.empty,

ackOwaitack, first_ackO, filled_ackO, ack_msgi_O -> first_acki, ack_slotO.empty,

ackiwaitack, first_ackl, filled_ackl, ack_msgO_l -> first_ackO, ack.slotI.empty,

ackOwaitack, first.acki, filled_acki, ack_msgil -> first_ackO, ack.sloti_empty,

acki

/* Good ack - alternate bit and send next message */:ackO.received: ackO, send_flagO -> send_flagi, Sready:acki_received: acki, send.flagl -> send.flagO, Sready

/* Bad ack - ignore it and let timeout take care of retransmitting msg */:bad_ackO: ackO, sendjflagi -> send.flagl, waitack:bad_acki: acki, sendcflagO -> send_flagO, waitack

/* Timeout (if no acknowledgements av;ilable) and retransmit last msg */waitack, first-ackO, ack.slotO....mpty -> Sready, first.ackO, ack-slotO.emptywaitack, first-ackl, ack.slotliempty -? Sready, first-acki, ack_slotl_empty

Fig. 6. Alternating bit protocol-sender model.

/* Receiver dequeues msg */Rready, slotO_filled, firstO, msgO_O -? readO, firsti, slotO-emptyRready, slotO_filled, firstO, msgLO -> readl, firsti, slotO_emptyRready, slotl_filled, firstl, msgO_l -> readO, firstO, sloti.emptyRready, slotl_filled, firpti, msglli -> readi, firstO, slotilempty

/* Receiver verifies received msg matches rcvyflag */:messageO-received: readO, rcv-flagO -> rcv_flagi, acking, msgO /* Good msg */:messagel-received: readi, rcv-flagi -> rcvjflagO, acking, msgI:bad-messagel: readO, rcv-flagl -> rcv_flagi, acking, msgO /* Bad msg */:bad_message2: readl, rcvjflagO -> rcv_flagO, acking, msgi

/* Receiver sends an acknowledgement with flag - flag received */acking, msgO, ack-slotO-empty, last_ackO -> Rready, ack_msgO_O, last.acki,

filled-ackOacking, msgi, ack-slotO.empty, last_ackO -> Rready, ack_msgl_O, last_acki,

filled_ackOacking, megO, ack_slotl_empty, last-ackl -> Rready, ack-msgO-1, last-ackO,

filled_ackiacking, msgl, ack.slotl.empty, last_ackl -> Rready, ack_msgl_l, last_ackO,

filled-acki

Fig. 7. Alternating bit protocol-receiver model.

/* Discard messages at random from both queues */slotOjfilled, firstO, msgO_O -> slotO_empty, firstislotO-filled, firstO, msgl_O -> slotO_empty, firstieloti_filled, firsti, msgO_l -> slotl_empty, firstOslotl_filled, firstl, msglli -> slotl_empty, firstO

filled-ackO, first_ackO, ack_msgO_O -> ack_slotO_empty, first_ackifilled_ackO, first_ackO, ack_msglO -> ack_slotO_empty, first_ackifilled_ackl, first_acki, ack_msgO._ -> ack_sloti_empty, first_ackOfilled-ackl, first_acki, ack_msgl_ -> ack-slotl_empty, first_ackO

/* INITIAL CONDITIONS */<Sready, sen&dflagO, Rready, rcv-flagO, slotO_empty, slotl-empty,ack_.slotO_empty, ack.slotiempty, lastO, last_ackO, firstO, first.ackO>

Fig. 8. Alternating bit protocol-line noise and initial state.

1088


/* Test for safeness */is-safe : forall a in S [tokens(s) = marked(s)]

/* Test for consistency of the sender */sender-consistent ::= forall s in S [USready + waitack + ackO + acki = 1) & \

(send.flagO + send_flagl = 1) J

/* Test receiver properties */rcvr-consistent ::- forall s in S [(Rready + acking + readO + readl - 1) & \

(rcv.flagO + rcv-flagi = 1) ]

/* Test consistency of the message and acknowledgement queues */qs-consistent ::= \

forall s in S [slotO_filled + slotO_empty = 1 & \slotl.filled + slotl_empty = 1 & \filled_ackO + ack.slotO-empty = I & \filled_acki + ack.slotl-empty = 1] & \

forall s in S [(msgO.O + msgi.O=O iff slotO_empty) & \(msgO.l + msgl_l=O iff slotl_empty) & \(ack_msgO_O + ack.msgl-O=O iff ack_slotO_empty) &\(ack-msgO-l + ack_msgl_l=O iff ack.slotl.empty)]&\

forall s in S [msgO-O + msgi.O < 1 & msgO-l + msgil_ <= I & \ack-msgO.O + ack.msgL_O <= 1 & ack.msgO.l + ack-msgi-J <= 1]

Fig. 9. Verification of alternating-bit protocol model.

ceiver, and one good acknowledgment received by thesender.

Properties 1-5 can be seen as properties which are usedto verify that the model behaves in a way which is con--sistent with our intent. Property 6 verifies that it behavesas a correct alternating-bit protocol according to the spec-ification in Fig. 5.

Fig. 9 shows the RGA functions used to verify that theseproperties hold for this model. The test for net safeness isthat used in the dining philosophers example. The sen-der_consistent function tests that waitack and Sreadyare mutually exclusive, and that the sender is always inone of those two states or in the intermediate state of de-ciding whether it has received a valid acknowledgment(ackO or ack1 ). It then tests that for those states whichhave a token of send_flagO or send flag 1, there arenever tokens on both places at once.The receiver is consistent if it is waiting to read, has

read a packet with a zero or one flag, or it is sending anacknowledgment with a zero or one flag. These states areall mutually exclusive. The receiver must in any state beprepared for the next packet read to have a specific flagvalue, so rcv flagO(s) + rcv_flag 1 (s) must also be 1for all states s. The rcvr consistent function tests forall of these conditions simultaneously.The sender and acknowledgment queues are in consis-

tent states if the slots are always filled or empty, there isnot a message in a slot if and only if the slot is empty,and there is never more then one message type in any slot.These conditions are tested by function qs_consistent.

Finally, we wish to show that the system exhibits theoverall flow described in Fig. 5. Part of this analysis isshown in Fig. 10. It shows that arcs leaving place 00 inFig. 5 go either back to place 00, or they go to place 10.The variables SORO and SOR1 are the mutually-exclu-sive subsets of all states of the system based on the mark-ing of the send flagO, rcv flagO, and rcv flaglplaces. They represent the 00 and 01 places in Fig. 5. The

set aout SORO is assigned the set of arcs leaving theSORO states. The first forall loop verifies that the des-tination states of all these arcs are in one of the two sets.The second loop checks that all of the arcs which movethe system into the 01 place involve firing of the transitionnamed "messageO received," which is fired onlywhen the receiver model receives a message and verifiesthat its flag bit matches the expected value.

Similar analysis verifies the relationships betweenplaces 10 and 11, 11 and 10, and 10 and 00. For brevity,the complete analysis is omitted here. The model there-fore exhibits the behavior expected of the alternating-bitprotocol. In going from state 00 to state 11, or from state11 to state 00, exactly one message and one acknowledg-ment are successfully sent and received.

VI. ONGOING WORKTimed Petri nets [20], [21] are extensions to Petri

nets which are valuable for modeling communicationsprotocols and for performance analysis. The use of RGAto analyze timed reachability graphs produced from timedPetri nets is currently being investigated. Some additionalprimitive functions, described above, have been added al-ready: ret, rft, enable time, firing_time, etc. Intimed Petri nets, it is possible for more than one transitionto begin firing simultaneously, or even for the same tran-sition to be firing concurrently with itself. Since any statechange can therefore be caused by a transition's begin-ning or finishing firing, arcs in the graph must be repre-sented as the quadruples described above.One of the problems with reachability analysis is that a

representation of the complete state space of the systemmust be constructed. Even when projections are used thisconstruction is time-consuming for large systems. Formany Petri nets finite projections cannot be built, pre-cluding the use of RGA to analyze their behavior. Onesolution to this problem is the use of simulation, which isin essence exploration of a selected portion of the state

1089


>S{#0. .#1751}>card(A)5184>SORO := {s in S | send_flagO & rcv..flagO}; card(SORO)436>SOR1 : {s in S send_flagO & rcv.flagl}; card(SORI)440>aout_SORO 5 setop(aout, SORO); card(aout_SORO)1304>forall a in aout_SORO [in(dest(a), SORO) in(dest(a). SORi)]truetrans(a)[tseq] ::= tseq : tbegin(a); tseq(O)ok>forall a in aout_SORO [in(dest(a), SORI) if f (trans(a) - messageO-received)]true

Fig. 10. Verification of overall model behavior.

space. Another advantage of simulation is that statisticalinformation about the performance of the system may becalculated from the results of a simulated execution, an-swering such questions as "What percentage of the timedoes the system spend waiting for the use of some sharedresource?". A tool has been built which can simulate theexecution of timed or untimed Petri nets. Other tools canbe used to compute the statistics or to filter the simulator'soutput to limit execution traces to only those places andtransitions of interest. Finally, an execution trace may beconverted by another tool into a partial reachability graphwhich may then be analyzed using RGA. The potential ofusing RGA to evaluate simulation results is great, but thepractical utility of this approach is still being explored.

Another area of ongoing research is in adding branch-ing-time temporal operators to RGA similar to those de-scribed in [5]. These operators allow one to ask the sys-tem if a specified predicate will be true in some or all ofthe successor states of a given state. A simple example ofthe utility of such functions is starvation: one might askif, from some state of interest, a certain resource musteventually become available to a waiting process, or if theprocess must wait forever. The latest version of RGA in-cludes branching-time temporal logic operators.

VII. CONCLUSIONThe reachability graph analyzer described herein allows

many system-independent and system-specific propertiesof concurrent systems modeled using Petri nets to be ver-ified. The tool provides primitives from which complexuser-defined propositions can be constructed about thestates of the reachability graph. RGA then mechanicallyverifies the propositions for a particular graph. Often,carefully constructed functions can be used to avoid brute-force approaches to verifying system properties, leadingto significant time savings with large graphs.

Other tools are needed to aid in the automatic genera-tion and analysis of Petri nets. RGA is only one of a suiteof tools currently being developed for this purpose at UCI.Other tools include Petri net editors, optimizers, anima-tors, and simulators, and reachability and decision graphbuilders and printers. The tools are being designed to in-tercQnnect easily, allowing the greatest possible flexibil-

ity in the design and analysis of concurrent systems ex-pressed as Petri nets.

ACKNOWLEDGMENTSome earlier results of this work appeared as "Com-

puter-Aided Analysis of Concurrent Systems in Proc. IFIPWorkshop on Protocol Specification, Verification, andTesting (Amsterdam, The Netherlands: North-Holland,1985).

REFERENCES[1] K. A. Bartlett, R. A. Scantlebury, and P. T. Wilkinson, "Note on

reliable full-duplex transmission over half-duplex links," Commun.ACM, vol. 12, no. 5, pp. 260-262-, May 1969.

[2] G. Berthelot and R. Terrat, "Petri net theory for the correctness ofprotocols," in Proc. IFIP Workshop Protocol Specification, Verifi-cation, and Testing, C. A. Sunshine, Ed. Amsterdam, The Neth-erlands: North-Holland, May 1982, pp. 325-342.

[3] M. Diaz, "Modeling and analysis of communication and cooperationprotocols using Petri net based models," in Proc. IFIP WorkshopProtocol Specification, Verification, and Testing, C. Sunshine, Ed.Amsterdam, The Netherlands: North-Holland, 1983.

[4] G. Estrin, R. S. Fenchel, R. R. Razouk, and M. K. Vernon, "SARA(System ARchitects Apprentice): Modeling, analysis, and simulationsupport for design of concurrent systems," IEEE Trans. SoftwareEng., vol. SE-12, pp. 293-311, Feb. 1986.

[5] J. C. Fernandez, J. L. Richier, and J. Voiron, "Verification of pro-tocol specifications using the Cesar system," in Proc. IFIP WorkshopProtocol Specification, Verification, and Testing, June 1985.

[6] K. Gostelow, V. G. Cerf, G. Estrin, and S. Volansky, "Proper ter-mination of flow of control in programs involving concurrent pro-cesses," SIGPLAN Notices, vol. 7, no. 11, 1972.

[7] B. Hailpern and S. Owicki, "Verifying network protocols using tem-poral logic," in Proc. Trends and Applications Symp., 1980, Com-puter Network Protocols, National Bureau of Standards, Gaithers-burg, MD, May 1980.

[8] M. Holliday and M. Vernon, "A generalized timed Petri net modelfor performance analysis of pipelined architectures," in Proc. Int.Workshop Timed Petri Nets, Torino, Italy, July 1985.

[9] R. M. Keller, "Formal verification of parallel programs," Commun.ACM, vol. 19, no. 7, pp. 371-384, July 1976.

[10] M. A. Marsan, G. Conte, and G. Balbo, "A class of generalizedstochastic Petri nets for the performance evaluation of multiprocessorsystems," ACM Trans. Comput. Syst., vol. 2, no. 2, pp. 93-122,1984.

[11] J. Martinez and M. Silva, "A simple and fast algorithm to obtain allinvariants of a generalized Petri net," in Proc. Second EuropeanWorkshop Application and Theory of Petri Nets, C. Girault and W.Reisig, Eds. New York: Springer-Verlag, 1982, pp. 301-310.

[12] P. Merlin and D. Farber, "A methodology for the design and imple-mentation of communications protocols," IEEE Trans. Commun., vol.COM-24, no. 6, June 1976.

[13] M. Molloy, "Performance modeling using stochastic Petri nets,"IEEE Trans. Comput., vol. C-3 1, pp. 913-917, Sept. 1982.

1090


114] E. T. Morgan, "RGA users manual," Dep. Inform. Comput. Sci.,Univ. California, Irvine, Tech. Rep. 243, Dec. 1984.

[15] E. T. Morgan and R. R. Razouk, "Computer-aided analysis of con-current systems," in Proc. IFIP Workshop Protocol Specification,Verification, and Testing, Amsterdam, The Netherlands: North-Hol-land, 1985.

[16] J. L. Peterson, Petri Net Theory and the Modeling of Systems. En-glewood Cliffs, NJ: Prentice-Hall, 1981.

[17] J. Postel, "Graph modeling of computer communications protocols,"in Proc. 5th Texas Conf. Computing Systems, Austin, TX, Oct. 1976,pp. 66-77.

[18] C. V. Ramamoorthy and G. S. Ho, "Performance evaluation of asyn-chronous concurrency systems using Petri nets," IEEE Trans. Soft-ware Eng., vol. SE-6, pp. 440-449, Sept. 1980.

[19] R. R. Razouk and G. Estrin, "Modeling and verification of commu-nication protocols: The X.21 interface," IEEE Trans. Comput., vol.C-29, pp. 1038-1052, Dec. 1980.

[20] R. R. Razouk and C. V. Phelps, "Performance analysis using timedPetri nets," in Proc. IFIP Workshop Protocol Specification, Verifi-cation, and Tesing, Y. Yemini, R. Strom, and S. Yemini, Eds. pp.Amsterdam, The Netherlands: North-Holland, June, 1984, pp. 561-576.

[21] R. R. Razouk, "The derivation of performance expressions for com-munication protocols from timed Petri nets," Comput. Commun. Rev.,vol. 14, no. 2, pp. 210-217, 1984.

[22] -, "A guided tour of P-NUT (Release 2.1)," Dep. Inform. Com-put. Sci., Univ. California, Irvine, Tech. Rep. 86-05, Mar. 1986.

[23] R. R. Razouk and M. T. Rose, "Verifying partial correctness of con-current software using contour/transition nets," in Proc. 19th Int.Hawaii Conf Syst. Sci., Jan. 1986, pp. 734-743.

[24] K. Sabnani and M. Schwartz, "Verification of a multidestination pro-tocol using temporal logic," in Proc. IFIP Workshop Protocol Spec-ification, Verification, and Testing, C. A. Sunshine, Ed. Amster-dam, The Netherlands: North-Holland, 1982.

[25] J. Sifakis, "Petri nets for performance evaluation," in MeasuringModeling, and Evaluating Computer Systems, H. Beilner and E. Ge-lenbe, Eds. Amsterdam, The Netherlands: North-Holland, 1977, pp.75-93.

[26] D. M. Stanat and D. F. McAllister, Discrete Mathematics in Com-puter Science. Englewood Cliffs, NJ: Prentice-Hall, 1977.

[27] C. A. Sunshine, "Formal techniques for protocol specification andverification," Computer, pp. 20-27, Sept. 1979.

[28] F. J. W. Symons, "Verification of communication protocols usingnumerical Petri nets," Australian Telecommun Res., vol. 14, no. 1,pp. 34-38, 1980.

[29] R. N. Taylor, "A general-purpose algorithm for analyzing concurrentprograms," Commun. ACM, vol. 26, no. 5, pp. 362-376, May 1983.

[30] W. M. Zuberek, "Time Petri nets and preliminary performance eval-uation," in Proc. 7th Annu. Symp. Comput Architecture, 1980, pp.88-96.

E. Timothy Morgan was born in Chattanooga,X~X llTN,in 1959. He received the B.S. degree in phys-

ics and computer science from Vanderbilt Univer-- sity, Nashville, TN, in 1980, and the M.S. degree

in computer science from the University of Cali-fornia, Irvine, in 1982.

Presently he is a doctoral candidate in com-puter science at the University of California, Ir-vine. His interests include modeling and verifi-cation of concurrent software, computer type-setting, graphics, and networking, multiprecision

arithmetic, compilers, and operating systems.Mr. Morgan is a member of Phi Beta Kappa, Sigma Pi Sigma, and the

Association for Computing Machinery.

W _ Rami R. Razouk (M'81) was born in Cairo,m>_, Egypt, in 1953. He received the B.S. degree in

engineering, and the M.S. and Ph.D. degrees incomputer science from the University of Califor-nia, Los Angeles, in 1975 and 1980, respectively.

-. _As a doctoral student he led the SARA group, un-

der the direction of Dr. Gerald Estrin, from 1977to 1980.X Presently he is an Assistant Professor of Infor-

mation and Computer Science at the University ofCalifornia, Irvine. His research interests include

simulation, verification, modeling, and communications protocols.Dr. Razouk is a member of Tau Beta Pi, Phi Beta Kappa, and the As-

sociation for Computing Machinery.

1091

interactive state-space analysis of concurrent systems · pdf fileinteractive state-space...

Documents