1080
IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. SE-13, NO. 10, OCTOBER 1987
Interactive State-Space Analysis
Systems
E. TIMOTHY MORGAN
AND
of
Concurrent
RAMI R. RAZOUK, MEMBER,
Abstract-The introduction of concurrency into programs has added
to the complexity of the software design process. This is most evident
in the design of communications protocols where concurrency is inherent to the behavior of the system. The complexity exhibited by such
software systems makes more evident the need for computer-aided
tools for automatically analyzing behavior.
The Distributed Systems project at UCI has been developing techniques and tools, based on Petri nets, which support the design and
evaluation of concurrent software systems. Techniques based on constructing reachability graphs that represent projections and selections
of complete state-spaces have been developed. This paper focuses attention on the computer-aided analysis of these graphs for the purpose
of proving correctness of the modeled system. The application of the
analysis technique to evaluating simulation results for correctness is
discussed. The tool which supports this analysis (the reachability graph
analyzer, RGA) is also described. This tool provides mechanisms for
proving general system properties (e.g., deadlock-freeness) as well as
system-specific properties. The tool is sufficiently general to allow a
user to apply complex user-defined analysis algorithms to reachability
graphs. The alternating-bit protocol, with a bounded channel, is used
to demonstrate the power of the tool and to point to future extensions.
IEEE
of correctness [9], [28], [2], [22] and evaluation of performance [25], [13], [10], [18], [30], [20], [21], [8]. It is
this versatility which motivates the paper's focus on Petri
nets.
Verification can be generally viewed as requiring reasoning about the complete state-space of a system. For
example, proving deadlock-freeness requires reasoning
about the possibility of reaching a state in which no further useful action is possible. Verifying the "safety" of
a system requires reasoning about the possibility of reaching states which are deemed unsafe. Any verification attempt requires a clear specification of what constitutes
"correct" behavior. A proof of correctness is then the
task of reasoning about states (or sequences of states) and
events (or sequences of events) to show that they are consistent with the specified desirable behavior.
Reasoning about a concurrent system's state-space is a
difficult task. The most efficient approach is reasoning,by
Index Terms-Assertions, communications protocols, computer- induction [9]. A correctness proof requires proving that
aided design, concurrent programs, correctness, Petri net, reachabil- the initial state meets the required behavior and that every
ity graph, software design.
transition (event) in the system preserves that desired behavior. While some invariants can be derived automatiI. INTRODUCTION
cally [11], in general the modeler formulates the invariant
W,tITH the increased use of distributed processing in and attempts to prove it. Some automation of the proofs
v a wide range of applications, a need exists for tech- can be done. Invariants can be very useful in verifying
niques which can be used to assist in evaluating the cor- constant properties of the state-space but cannot be used
rectness of concurrent software and hardware. A variety to verify properties relating to sequences of states and
of novel specification and verification approaches are events. Those latter properties (such as deadlock-freebeing investigated ranging from highly abstract and math- ness) must be verified using the notion of a "homing
ematical approaches (e.g., temporal logic [7], [24]) to ap- state" [9].
An alternative approach is to reason about the complete
proaches which closely mirror and restrict implementations (e.g., algorithmic specifications [27]). All the state-space by constructing and then analyzing a finite (and
techniques in question are based on some formal model hopefully small) representation of the complete stateof computation and, in order to be used effectively, must space. Several approaches exist which allow for construction of such finite representations:
be supported by automated tools.
1) Projections can be performed to preserve some asIn recent years, the Petri net model [16] has been extended in a variety of ways and used to model wide ranges pects of the behavior of a system while ignoring others.
of hardware/software systems. Extended Petri net models A projection involves aggregating states based on some
are particularly interesting since they support verification aggregation criterion. For example, a control projection
aggregates states with identical control states, ignoring the
data state and timing information. In Petri net models,
Manuscript received April 30, 1985. The work of R. R. Razouk was analyzing only the control portion of a net can yield such
supported in part by the Microelectronics Innovation and Computer Research Opportunities (MICRO) program cosponsored by Hughes Aircraft a control projection. In Taylor's work [29] such projecCorporation. The work of E. T. Morgan was supported in part by the Na- tions are performed by focusing on concurrency states
tional Science Foundation under Grant DCR 84-06756.
(states in which tasks synchronize and communicate). If
The authors are with the Department of Information and Computer Scia
projection is performed carefully so as to preserve the
ence, University of California, Irvine, CA 92717.
IEEE Log Number 8716567.
behavior which is being analyzed (e.g., control flow), then
0098-5589/87/1000-1080$01.00 © 1987 IEEE
MORGAN AND RAZOUK: STATE-SPACE ANALYSIS OF CONCURRENT SYSTEMS
1081
In Section II of the paper, Petri nets are briefly reanalyzing the smaller state-space can yield results which
viewed. The usefulness of reachability graphs and their
are known to apply to the complete state-space. In most
limitations are also discussed. Section III describes some
cases such analyses yield results which indicate potential
problems in the real system. In some sense such analyses of the most primitive capabilities of RGA. The dining
account for the "worst-case." Past work on Petri nets in philosophers problem is used as a reference example.
this area has focused on proving general properties such Section IV delves into the more advanced features of RGA
which make it extensible and flexible. Section V presents
as deadlock-freeness by relying on Petri net properties
such as liveness and boundedness [17]. System-specific a model of the alternating-bit protocol with bounded
properties are usually verified by manual examination of channels and demonstrates some of the flexibility of RGA
in analyzing such complex reachability graphs.
the state space [19].
2) Reductions are transformations which can be apII. PETRI NETS AND REACHABILITY GRAPHS
plied on the model of a system to yield a smaller model
Petri nets [16] are bipartate, directed graphs whose
(and therefore one with a smaller state-space). Results for
reduction must be carefully constructed to guarantee that nodes are transitions and places. The arcs of the graph
they preserve the behavior being analyzed. An example denote those places which are inputs to the transitions and
of such reductions is the reduction procedure defined for those which are outputs. Associated with each place is a
UCLA graphs [6]. This reduction procedure is guaranteed number of tokens; a marking is an assignment of zero or
to preserve deadlocks (and all terminal states) while sig- more tokens to each place in the net. A transition is considered to be enabled when there is at least one token on
nificantly reducing the size of the state-space.
of its input places.
each
3) Selections can be performed on a state-space by foThe
execution of a net involves choosing an enabled
cusing attention on a selected portion of the state-space.
nondeterministically and firing it. Firing intransition
For example, simulation experiments focus on some sea token from each input place and placeremoving
volves
lected paths through the complete system state-space.
of
on
each
the transition's output places. The firone
ing
Such paths are (it is hoped) representative of the behavior
to be an instantaneous and
is
considered
operation
ing
of the complete system. The thoroughness of a simulation
no
two transitions may fire
and
operation,
indivisible
of
the
comexperiment can be quantified by the fraction
of
If
the
number
output places is not equal
simultaneously.
such
seof
Analysis
it
traverses.
that
state
space
plete
then
the total number of
of
places,
input
to
the
number
properties
"prove"
to
be
used
lected subgraphs cannot
not conservative).
net
is
tokens
in
the
net
changes
(the
an
analHowever,
such
about the complete state-space.
on
the graph, there is
one
token
there
is
more
than
When
of
the
sysin
the
correctness
increase
confidence
ysis can
a possibility of concurrent execution. However, not every
tem.
Regardless of how finite state-spaces are constructed, token represents a separate process; some may be used
they can be viewed as reachability graphs. Nodes in these only for synchronization and resource control.
The paragraphs above describe the simplest form of
graphs represent states of the system while arcs represent,
state transitions. Analysis of such graphs can be very use- Petri net. Practical use of the model requires a variety of
ful but is difficult: Typically, reachability analysis tools extensions which simplify the construction of larger
support a set of fixed built-in analyses which can be ap- models and increase the modeling power of the model. In
plied to all models [4]. Such a narrow view of "correct- order to support modeling time-dependent behavior, a vaness" is of limited use when a need exists to verify the riety of time extensions have been proposed. Timed Petri
consistency between a model and some higher level spec- nets [20] support fixed enabling and firing times. Time
ification. This paper addresses this deficiency by present- Petri nets [12] support ranges of time delays. Generalized
ing a tool which can be used to analyze reachability graphs Stochastic Petri nets [10] support exponentially distrib(partial or complete) of models to determine if the model uted firing times. Other common extensions include daof the system is consistent with some higher-level speci- ta dependent predicates and actions associated with tranfication. The novelty in this work centers on a language sitions in the net [3]. These extensions permit details of
(first order predicate calculus) and an interpreter which data manipulation to be modeled without obscuring the
allow a designer to give formal specifications of general basic control flow modeled by the Petri net.
The state of a net can be characterized by the distribucorrectness properties (e.g., deadlock-freeness) as well as
system-specific properties in a way which can be easily tion of tokens on places (the marking), by the set of enunderstood and which can be automatically verified. In abled and firing transitions (for Timed Petri nets) and by
addition to formal correctness proofs the tool can be used the values of all the data variables. The construction of
to evaluate simulation results and to "debug" the system the complete state space of a fully-interpreted Petri net is
being modeled and its model by providing the designer unrealistic. However, by focusing attention on some comwith convenient ways of focusing attention on portions of ponents of the state of the net it is possible to easily conthe state-space. The tool in question (the Reachability struct projections. For example, if all timing information
Graph Analyzer, or RGA [14], [15]) is part of a larger and all predicates and actions are omitted, then the state
suite of tools (P-NUT, Petri Net UTilities) being devel- of the net simply consists of the marking of the net. Thus
a firing of a transition, which can result in a change in the
oped at UCI by the Distributed Systems Project [23].
1082
IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. SE-13, NO.
distribution of tokens, represents a change in the state of
the net. A marking /' is said to be immediately reachable
from a marking it if firing some enabled transition results
in changing the marking from A to i'. The reflexive transitive closure of the immediately reachable relationship
defines the reachability set, the set of all markings which
can be reached from ,. If timing information is retained,
then the state of a net consists of the marking as well as
the set of enabled and firing transitions [20].
Projections do not always yield finite reachability
graphs. A reachability graph obtained from an ordinary
Petri net (a control projection) will be infinite if any place
can acquire an unbounded number of tokens. Various
techniques exist for handling this case in formal analysis
of Petri nets [16], but these techniques will not be discussed here, as the analyzer being described handles only
finite graphs. Typically, problems which would be analyzed with this tool, such as communications protocols,
have by design only a finite number of states. For those
cases where the number of states is infinite, portions of
the state space must be selected and analyzed. In P-NUT
this is currently accomplished by running simulation experiments from which finite partial reachability graphs are
constructed.
Once a reachability graph (complete or otherwise) is
constructed, it can be used in a number of ways to verify
properties of the Petri net. If the graph being analyzed is
complete, then the analysis is a proof of correctness. If
the graph is incomplete, then the analysis can only serve
the purpose of increasing confidence. Among the properties which can be analyzed are boundedness, safeness,
and liveness. The maximum number of tokens on any
place can be determined by examining each state of the
graph. 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 state
is a constant, the net is conservative. If every state has at
least one successor state, then the net is deadlock-free. A
transition is dead in some marking if no sequence of transition firings exists which can enable it. If there- exists
such a sequence, however, the transition is said to be potentiallyfirable. A transition is live if it is potentially firable in all reachable markings. By examining the arcs of
the graph, it is possible to determine if a transition is live
and the set of all states which can reach or can be reached
from a particular state. These properties of the net
(boundedness, liveness, etc.) are important because properties of the system being modeled can be inferred from
them. For example, liveness implies that the system is
deadlock-free.
The next two sections of the paper present the capabilities of the analyzer. The approach taken in the implementation of this tool is based on an understanding of the
need for flexible and expandable tools. Other implementations of reachability graph builders [4] have tended to
have a set of built-in algorithms which can be used to
verify some known general properties (e.g., deadlockfreeness). In this tool, more general mechanisms are made
available to the user instead of specific functions which
10, OCTOBER 1987
solve only certain predefined problems. Arbitrarily complex algorithms can be synthesized from the simple basic
capabilities of the analyzer. Should some algorithms prove
particularly useful, the analyzer can then be enhanced to
provide them as built-ins.
III. BASIC CAPABILITIES
The RGA system functions on two levels. First, it allows the user to specify propositions and predicates [26]
over a universe of discourse consisting of places and transitions in a Petri net, and states and arcs in its reachability
graph. Variables in the propositions may be bound by assignment or by universal or existential quantification.
RGA is further augmented with primitives which give it
the capabilities of a simple programming language.
The intended use of RGA is to verify interesting properties about the system being modeled. Since all system
behavior is encoded in the state of the system, it is critical
for such a tool to allow the user to express system properties as predicates on places and states. To this end, RGA
provides the user with the ability to refer to four built-in
sets: the set of places in the net P, the set of transitions
T, the set of reachable states S, the set of arcs in the
reachability graph A. Places are referred to by their
names, while states are referred to by their number (#0 is
the initial state).
A. Arithmetic and Boolean Expressions
Arithmetic expressions follow the conventions of most
modern programming languages, with operations such as
+,-, *, and /, using parentheses to override the normal
operator precedence. The operands of these operators are
expressions whose values are integers or reals. Places in
the net are evaluated as the number of tokens on that place,
in the context of some state written in parentheses after
the place name. Places may also be evaluated as booleans
in situations where Boolean values are expected. Table I
shows the set of predefined integer-valued primitive functions. Real-valued primitive functions are listed in Table
II. The types of the arguments of these functions, such as
arcs and transitions, are explained below.
As with other expressions, Boolean expressions are built
up from constants, infix operators, predefined functions
and user-defined functions. The Boolean constants are the
reserved words true and false.
The infix Boolean operators are the conventional arithmetic comparison tests, <, <=, >, > =, =, and !=.
The equal and not equal tests may be applied to any data
types, while the other operators are restricted to integer
and real expressions. Some other infix Boolean operators
apply to Boolean expressions: implies, iff, and, and or.
Both the and and or operators are "short-circuit" operators which evaluate the lefthand operand first and then
evaluate the righthand operand only if necessary. The prefix unary operator not may be used to negate a logical
expression. There is only one primitive function which
returns a Boolean value, shown in Table III.
1083
MORGAN AND RAZOUK: STATE-SPACE ANALYSIS OF CONCURRENT SYSTEMS
TABLE IV
STATE AND TRANSITION-VALUED PRIMITIVE FUNCTIONS
TABLE I
INTEGER-VALUED PRIMITIVE FUNCTIONS
int (float)
tokens (state)
marked(state)
nsucc (state)
npred(state)
card(s)
The expression float is evaluated and rounded to an integer.
The total number of tokens on all places in a specified state. An
alternate way of writing this function is to put the state within
vertical bars, as an absolute value. For example, 1#11.
Returns the number of places in the argument state which have
at least one token on them. If marked(s)=tokens(s) then the
state s is safe.
Returns the number arcs going out of the argument state.
Returns the number of arcs going into the indicated state.
Returns the number of elements of a set a.
TABLE II
REAL-VALUED PRIMITIVE FUNCTIONS
Converts the integer expression int to a floating point value.
enable-time (trans) Returns the enabling time for a transition trans. Zero is
float (int)
returned for untimed Petri nets.
f iring_t ime (trans) Returns the firing time for a transition trans. Zero is returned
for untimed Petri nets.
Returns the probability of a transition trans as a floating
prob (trans)
point value. Returns 0.0 for untimed Petri nets.
Returns the time associated with an arc a in a timed reachatime (a)
ability graph as a floating point value. Returns 0.0 with
untimed nets.
Returns the probability associated with an arc a in a timed
aprob (a)
reachability graph as a floating point value. Returns 0.0 with
untimed nets.
src (a)
dest (a)
tbegin (a)
tend(a)
Returns the source state of a.
Returns the destination state of a.
Returns the list of transitions which begin firing with arc a.
Returns the list of transitions which finish firing with arc a.
used to detect if s is deadlocked or is a proper terminal
state.
2) in(s, S') & marked(s) != 0: This expression is
true if state s is a member of set of states S' and that
there is at least one marked place in s.
3) tokens(s) = tokens(#O): This tests whether a
state s contains the same number of tokens as the initial
state. If all states satisfy this predicate, the net is said to
be conservative.
C. Set and Sequence Expression
The 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 of
the same type. A- single set is either a set variable, a set
constant, or a set-valued function. Sequences, or lists, are
similar to sets, but duplicate elements are allowed, and
the sequence is maintained in the order in which the elements are added.
TABLE III
A set constant is written as a list of expressions (which
BOOLEAN-VALUED PRIMITIVE FUNCTION
need not be constants) within curly braces { }. For example, the set consisting of states 1, 5-10, and 12 can be
The in function takes two arguments, an item of any type, and
in(item, a)
a set of items s. It returns true if the item is an element of the
written
indicated set, and false otherwise.
{#1, #5. . #1 0, #1 2}
Sequence constants are similar, using the symbols < <
B. State, Place, Transition, and Arc Expressions
and > > to delimit the list.
Another powerful way of specifying a set is the subset
States of the reachability graph and transitions in the
be
referenced
numbered.
Particular
states
can
construct.
It allows elements to be selected from a set
net are
using
using
any
Boolean
expression as the selection criterion.
#
number
of
the
Transistate.
a
symbol followed by the
The
subset
the
construct
is written
tions are similarly referenced using a dollar sign and
be
number.
also
transition
They may
given symbolic
{id in set-expression boolean-expression}
names in the Petri net. Places are referred to through the
This construct creates a set of all elements in a given set
identifiers defined in the original Petri net.
Arcs between nodes in a reachability graph model state set-expression which satisfy the property specified in the
transitions which result from transitions firing. These arcs boolean-expression. Table V lists the primitive functions
which return sets or sequences. Table VI lists those funcmay be referred to as a quadruple of the source and destination states and the lists, or sequences, of transistions tions which are used to manipulate sets and sequences.
Two of the language's most important operators are
which begin and finish firing with this state change. For
untimed Petri nets, the first list will contain the one tran- forall and exists, the universal and existential quantisition which fired, and the second list will be empty. For fiers. They allow traversal through sets, evaluating a
example, [#0, #10, <<$9>>, <<>>] wouldbe Boolean expression for each element of the set. Their synthe arc from state #0 to state #10 firing transition $9. tax is the same, so only that of forall will be given:
Table IV shows the primitive functions which return the
forall id in set [boolean-expression]
separate components of an arc.
This expression is evaluated as follows. The set is evalBelow are some examples of the types of expressions
which can be constructed with the capabilities described uated once and only once, and the id is then looped
through the elements of this set one at a time. For each
up to this point:
1) nsucc(s) > 0: This expression will be true if state value of the id, the boolean-expression is evaluated. If for
s has one or more successors. Such an expression can be all values, this expression evaluates to true, then the
IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. SE-13, NO. 10, OCTOBER 1987
1084
TABLE V
SET-VALUED PRIMITIVE FUNCTIONS
Returns the set of arcs whose destination state is the indicated state.
Returns the set of arcs whose source state is the indicated
aout (state)
state.
The succ function returns the (possibly empty) set of imsucc (state)
mediate successor states in the reachability graph of the
specified state.
The pred function it returns the set of immediate predepred(state)
cessor states of the specified state.
Returns the set of all the successors of the indicated state,
allsucc (state)
and recursively, all their successors.
Returns the set of all the predecessors of the indicated
allpred(state)
state, and recursively, all their predecessors.
input_places(trans) Returns the set of input places for a particular transition
trans.
output-places(trans) Returns the set of output places for a particular transition
trans.
ain(state)
TABLE VI
SET-MANIPULATION FUNCTIONS
The union function takes two sets or sequences sl and s2
as its arguments. This function returns the set union of the
two sets, or the concatenation of the two sequences in the
order given. The infix plus operator (+) may be written in
place of the union function.
intersectionCsl, s2) This function is similar to the union function, but it returns the set intersection of its two arguments which must
both be sets. The two arguments must both be sets of the
same type, or at least one must be the empty set.
setdiff (sl, s2)
The setdiff command takes two sets or sequences and
returns a copy of sl minus any elements it has in common
with s2. The setdiff function may be written using the
infix minus (-) operator.
The setop operator applies the function func, which must
setop(fune, set)
be a monadic function, to each element of the set. The
results of the function executions are unioned into the resulting set, which is returned as the value of the setop
function. The function fune may return values which are
either individual elements or sets of elements; it may be
either a user-defined function or one of the predefined functions succ, pred, ain, aout. card, marked. nsucc,
npred. src. dest, trans. allpred, allsucc. showstate. conflict_set, atime, aprob, probability.
capacity, float, int, enable-time., f iring_time.
input-places. and output-places.
The sequence will be converted to a set of the same type,
set(sequence)
eliminating duplicate elements.
ret (s, trans)
Returns a sequence of the remaining enabling time(s) for
a transition trans within the context of a state s. For
untimed reachability graphs, or when no enablings of the
transition exist in the state, an empty sequence is returned.
rft (s, trans)
Returns a sequence of the remaining firing time(s) for a
transition trans within the context of a state s. For untimed reachability graphs, or when no instances of firings
of the transition exist in the state, an empty sequence is
returned.
union(sl, s2)
whole expression returns that value. But if the expression
ever evaluates to false, then execution of the loop is
halted immediately and the forall expression returns
false.
The exists expression is similar to forall, but with the
logical tests reversed. It continues to evaluate the Boolean
expression 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 true
if the net is deadlock-free.
2) forall s in S [forall p in P [p(s) <= 11]: This
expression is true if all the places in the net are safe (1bounded) in all states.
3) exists sin S [philosopher eating 1 (s) > 0]: In
the context of the dining philosopher example (discussed
below), this predicate determines if it is possible for philosopher 1 to eat. It should be noted that this predicate
does not in any way guarantee that philosopher 1 will ever
eat.
D. A Simple Example
Now a short example is used to demonstrate some of
the capabilities of the analyzer. The dining philosophers
problem will be used because it is widely understood. Fig.
1 shows the Petri net representation of one philosopher in
the dining philosophers problem. The equivalent textual
representation of the Petri net for the problem with three
philosophers is shown in Fig. 2. Using the P-NUT tools,
this representation is converted into a canonical representation of the same net from which the reachability graph
is built. The reachability graph is then read by RGA so
that the analysis can be performed.
Fig. 3 shows a sample run of the analyzer on the philosophers problem. The line numbers at the left have been
added for reference purposes. In line 1, the user asks how
many states there are in the reachability graph by determining the cardinality of the set of all states S. There are
26 states.
On line 3, the user asks if the net is deadlock-free (that
each state has at least one successor). RGA responds with
false, that there is at least one deadlocked state. The user
then asks on line 5 for the set of all states s which have
no successors. The response is a set containing one state,
#21. On line 7, the user asks for a symbolic display of
state #21, with the result shown on lines 8 and 9. The
names are the names of the places as defined in the original Petri net, which each have one token (more than one
token 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 definition of net safety, while the expression on line 12 takes
advantage of two built-in functions. Both expressions
evaluate to true, indicating that the net is safe. The
expression in line 12 is computed many times faster than
that on line 10 because it avoids the doubly nested loops
by using built-in functions and precomputed values.
All of the above tests apply equally to any net which
might be analyzed with RGA; that is, they test for general
properties. Next, some specific properties of the dining
philosophers problems are analyzed. In line 14, the user
asks if it is possible for philosopher 1 to eat, and the system responds true. The user then asks for the set of all
states in which the philospher is eating, and RGA responds with a set of three states. Finally, on line 18, the
user verifies a property of the net which should be true,
that the maximum number of philosophers eating in any
1085
MORGAN AND RAZOUK: STATE-SPACE ANALYSIS OF CONCURRENT SYSTEMS
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 form
of Petri net.
1 >card(S)
2
3
4
5
6
7
8
9
10
i1
26
>forall s in S tnsucc(s)
false
>{s in S
{#21}
nsucc(s)
u
>
0]
= 0)
>showstate(#21)
philosopher-l-forkO philosopher_l_fiorkl philosopher-lfork2
forks_busyl f orks-busy2
>forall s in S tforall p in P tp(s) < 1]]
forks..busyO
true
12 >forall s in S [marked(s)
tokens(s)]
13 true
14 >exists s in S fphilosopher-eatingl(s) > 01
1s
true
16 >{s in S philosopher_eatingl(s) > 0)
17 (#14, #23, #241
18 >forall s in S [philooopher-eatingO(s) +
19 philosopher-eating2(s) < 3/2]
20 true
philosopher-eatingl(s)
Fig. 3. Analysis of dining philosophers problem.
+
1086
IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. SE-13, NO. 10, OCTOBER 1987
state must be less than or equal to the number of philosophers divided by the number of forks needed by a philosopher to eat. If this expression did not evaluate to true,
then an error in the specification of the net would be indicated. In this case, since integer division is used, 3/2
is truncated to 1, and therefore no two philosophers can
ever be eating simultaneously. In general, Ln/2j philosophers can eat simultaneously when there are n dining
philosophers.
IV. ADVANCED CAPABILITIES
The features of RGA described above allow a designer
to traverse the graph interactively and to prove some
properties about the net. It may be possible, in some cases,
for a designer to develop an algorithm to perform more
complex analyses of the graph. It is therefore desirable to
have the tool be able to execute user-defined algorithms
built from the primitive capabilities outlined earlier.
RGA allows any value to be assigned to an identifier
using the assignment operator (:=), which assigns the
value of the expression on its right to the identifier on its
left. In addition, it returns that value as a result. The sequence of expressions a = 1 and a'= a + 1 would
assign the identifier a the integer value 2. Then the
EMPTYSET
can-reach (s)
::
cr
{} EMPTYSET, {s})
cr(frontier, tried, canreachset)tnfrontierl
if frontier EMPTYSET \
then canreachset \
else nfrontier := EMPTYSET; \
tried := union (tried, frontier); \
forall s in frontier \
=
tnfrontier
:=
canreachset
fi
union(nfrontier,pred(s));
:- union
\
(canreachset, pred(s));
true ]; \
cr(setdiff(nfrontier, tried), tried, canreachset) \
Fig. 4. A small user-defined function.
The type and value returned by the if expression depends
on what expression, if any, is executed.
Fig. 4 shows a user-defined function, can reach. It
constructs the set of states which can reach a particular
state s; thus it is the same as the primitive operation
alipred except that the constructed set will contain the
initial state. It has been found empirically that the primitive function allpred is about 2.5 times faster than this
user-defined version.
The "\" symbols in the figure are used to indicate that
expression
the end of a line is not the end of the function definition.'
The can reach function invokes a recursive function cr
a := {s in S nsucc(s) = O}
the actual work. Cr takes three arguments, a
which
would assign to a the set of all deadlocked states. Each frontierdoes
which should be tried next, the set of
of
states
identifier represents a < value, type > pair, so its type as states already tested,
and the states which have already
well as its value can vary dynamically.
been
to
be
to reach the starting state. If there
found
able
It is possible to assign to an identifier an expression, are no more states in the frontier, then cr returns the set
rather than the value of the expression, using the "::="
since nothing more can be added to that set.
operator, thus defining a function. The syntax used to de- canreachset
it adds the frontier set to the set of states which
Otherwise,
fine a function is
have been tried, and constructs the new frontier nfrontier
id (formal-parameters) [local-variables] = expression as the set of predecessors of the states in the current fronThen cr is called recursively, removing any states
The formal-parameters and local-variables are lists of tier.
from
the new frontier which have already been tried.
identifiers separated with commas. If either of these lists
is empty, then the corresponding parentheses or brackets
V. AN EXTENSIVE EXAMPLE
are omitted. The function invocation mechanism in RGA
provides for dynamic scoping of identifiers, as in Lisp. A. The Alternating-Bit Protocol
A larger example is now presented which makes use of
Also as in pure Lisp, recursion is' often the primary mechof the more sophisticated features of RGA. The exsome
anism for specifying interation.
In order to make user-defined functions sufficiently ample used is the- alternating-bit protocol [1], with mespowerful, two special expressions are included in the RGA sage and acknowledgment queues of length two. In this
language: expression lists and conditional expressions. protocol, there are two communicating entities, a sender
The semicolon (;) infix operator evaluates the expression and a receiver. The sender sends message packets to the
on its left and discards it, then it evaluates and returns the receiver over an unreliable medium, with a flag bit atexpression on its right. It is an associative operator, so tached to each message. This flag is either a zero or one,
the expression "1;2;3" evaluates to the integer 3. Intui- alternating from one message to the next. The receiver
tively, it provides for sequential execution of expressions sends acknowledgment packets back to the sender which
much like the execution of statements in conventional have the same flag bit as the message packet being acprogramming languages. The if expression is used for knowledged. If the receiver receives a packet with what
conditional expression evaluation. It can take two differ- it considers a bad flag, it still sends an acknowledgment
packet containing the flag received, which then serves as
ent forms:
a negative acknowledgment to the sender. The receiver
if boolean-expression then expression fi
then drops the bad packet.
if boolean-expression then expression] else
Upon receiving a good packet, however, the receiver
alternates its flag to be ready to receive the next packet
expression2 fi
MORGAN AND RAZOUK: STATE-SPACE ANALYSIS OF CONCURRENT SYSTEMS
from the sender. The sender alternates its flag and transmits its next message receiving a valid acknowledgment
packet. It uses timeouts and negative acknowledgments
to detertnine when it should stop waiting for an acknowledgment and retransmit its current message.
Fig. 5 shows a Petri net representing a high-level description of the alternating-bit protocol, using places to
represent the overall system state. For brevity, the global
state of the system will be referred to by two digits, the
first being the sender's flag, and the second being the receiver's flag. The system stays in state 00 until a message
is successfully received by the receiver, and it then enters
state 01. When the acknowledgment is correctly received
by the sender, the system enters state 11; the sender has
now alternated its flag, and its attempting to send the next
message. When that message is correctly received, the
system enters state 10, and after its acknowledgment is
receiVed by the sender, the system returns to state 00. The
transitions labeled "Bad Message" and "Bad Ack"
model timeouts and actions taken upon receipt of packets
with bad flags. No other transitions should be possible in
a correct implementation of the protocol. This net thus
serves as a high-level specification of the protocol against
which the model may be tested.
B. Petri Net Model of the Alternating-Bit Protocol
Figs. 6-8 show the textual representation of a detailed
Petri net model of the alternating-bit protocol. Some of
the transitions are given symbolic names, corresponding
to the names of the transitions and places in Fig. 5, between pairs of":" characters for use during analysis. The
queues or messages being sent, and for the acknowledgments returning, are modeled as circular queues. Both
queues are of length two in this model. The reachability
graph 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. The
send flagO and send flag1 places indicate the state
of the sender's flag. If there is no room in the message
queue when the sender is ready to send, then the sender
will block until a slot becomes free. Once it has sent a
message, it enters the waitack state to await the acknowledgment message from the receiver. Since Petri nets
are incapable of representing time, the sender can retransmit its last message at any time when it is waiting for an
acknowledgment and there are no acknowledgments in the
queue.
The receiver, Fig. 7, is in one of four states, Rready,
acking, readO, and read1. When Rready, the receiver
waits until a message appears in the message queue from
the sender. When a message comes in, it verifies that the
flag bit on the message corresponds to the type of message
expected (rcv_flagO or rcv_flag 1 ). If the flags match,
an acknowledgment is sent with the same flag bit, and the
receiver's flag is reversed in preparation for the next message. Otherwise, if the flag bits do not match, the receiver
sends an acknowledgement with a flag bit indicating the
type of message it received, giving the sender a negative
acknowledgment.
Bad
Message
1087
sendO
sendO
ecvl
rvO
Bad
Ack
MessageO
Received
Ackl t
Received
Bad
Ack
m
se
AckO
Received
1
se
rev
I
if
rev
Bad
Message
Messagel
Received
Fig. 5. Meta level Petri net for alternating-bit protocol.
Fig. 8 shows the model of transmission line noise and
the initial state of the Petri net. This model of the alternating-bit protocol assumes that there is some probability
that line noise will destroy messages or acknowledgments, but messages are never distorted (delivered with
changed flags). There are therefore some transitions which
can absorb messages or acknowledgments before they are
received, simply dropping the packets. In the initial state,
the sender is ready to send a message with flag bit 0, the
receiver is ready to receive a message with flag bit 0, and
both the message and acknowledgment queues are empty.
C. Verification of the Model
We have found that RGA can be useful in verifying that
a Petri Net model of a system is correct as well as in analyzing the system being modeled. Our understanding of
the alternating-bit protocol and our model of it allows us
to state several properties this model should exhibit if it
is correct:
1) The model should be safe since each place is used
as a Boolean flag.
2) The sum of the tokens on Sready, waitack, ackO,
and ack1 will be 1 for all states since these are mutually
exclusive conditions. Send_f lagO and send_f lag 1 are
also mutually exclusive.
3) The sum of the tokens on Rready, acking, readO,
and read 1 should be 1 for all states. This also verifies
that readO and read1 are mutually exclusive.
4) The sum of rcv flagO and rcv flag 1 should be
1 for all states, verifying that the receiver expects only
one type of message at any one time.
5) For each slot in the each queue, at most one flag bit
should be set. For instance, msgO 0 and msg 1 0
should be mutually exclusive. In states where neither are
set, then that slot should be available (e.g.,
slotO empty). A slot should not be both available and
filled (e.g., slotO empty and slotO filled are mutually exclusive).
6) The system should behave as described by Fig. 5.
Arcs should not exist between the states other than those
shown. The transitions which loop from each of the system states should be fired only when a message or acknowledgment has not been received successfully. To get
from state 00 to state 11, or state 11 to state 00, exactly
one good message should have been received by the re-
IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. SE-13, NO. 10, OCTOBER 1987
1088
/* Sender sends msg */
Sready, sendtflagO, slotO.empty, lastO
send.flagO, waitack
Sready, send.flagl, slotO-empty, lastO
senddflagi, waitack
Sready, send.flagO, slotl_empty, lasti
send_flagO, waitack
Sready, send_flagl, slotl_empty, lasti
send-flagl, waitack
-> msgO_O, lastl, slotO_filled,
-> msgl_O, lastl, slotO_filled,
-> msgO_l, lastO, slotl_filled,
-> msgl_1, lastO, sloti_filled,
/* Sender dequeues an acknowledgement packet. */
waitack, first_ackO, filled_ackO, ack_msgO_0 -> first.ackl,
ackO
waitack, first_ackO, filled_ackO, ack_msgi_O -> first_acki,
acki
waitack, first_ackl, filled_ackl, ack_msgO_l -> first_ackO,
ackO
waitack, first.acki, filled_acki, ack_msgil -> first_ackO,
acki
ack slotO.empty,
ack_slotO.empty,
ack.slotI.empty,
ack.sloti_empty,
/* Good ack - alternate bit and send next message */
:ackO.received: ackO, send_flagO -> send_flagi, Sready
:acki_received: acki, send.flagl -> send.flagO, Sready
- ignore it and let timeout take care of retransmitting msg */
:bad_ackO: ackO, sendjflagi -> send.flagl, waitack
:bad_acki: acki, sendcflagO -> send_flagO, waitack
/* Bad ack
/* Timeout (if no acknowledgements av;ilable) and retransmit last msg */
waitack, first-ackO, ack.slotO....mpty -> Sready, first.ackO, ack-slotO.empty
waitack, first-ackl, ack.slotliempty -? Sready, first-acki, ack_slotl_empty
Fig. 6. Alternating bit protocol-sender model.
/* Receiver dequeues msg */
Rready, slotO_filled, firstO,
Rready, slotO_filled, firstO,
Rready, slotl_filled, firstl,
Rready, slotl_filled, firpti,
msgO_O
msgLO
msgO_l
msglli
-? readO, firsti,
-> readl, firsti,
-> readO, firstO,
-> readi, firstO,
/* Receiver verifies received msg matches rcvyflag
:messageO-received: readO, rcv-flagO -> rcv_flagi,
:messagel-received: readi, rcv-flagi -> rcvjflagO,
readO, rcv-flagl -> rcv_flagi,
:bad-messagel:
readl, rcvjflagO -> rcv_flagO,
:bad_message2:
slotO-empty
slotO_empty
sloti.empty
slotilempty
*/
acking,
acking,
acking,
acking,
msgO /* Good msg */
msgI
msgO /* Bad msg */
msgi
/* Receiver sends an acknowledgement with flag - flag received */
acking, msgO, ack-slotO-empty, last_ackO -> Rready, ack_msgO_O, last.acki,
filled-ackO
acking, msgi, ack-slotO.empty, last_ackO -> Rready, ack_msgl_O, last_acki,
filled_ackO
acking, megO, ack_slotl_empty, last-ackl -> Rready, ack-msgO-1, last-ackO,
filled_acki
acking, 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, firsti
slotO-filled, firstO, msgl_O -> slotO_empty, firsti
eloti_filled, firsti, msgO_l -> slotl_empty, firstO
slotl_filled, firstl, msglli -> slotl_empty, firstO
filled-ackO, first_ackO, ack_msgO_O -> ack_slotO_empty, first_acki
filled_ackO, first_ackO, ack_msglO -> ack_slotO_empty, first_acki
filled_ackl, first_acki, ack_msgO._ -> ack_sloti_empty, first_ackO
filled-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.
MORGAN AND RAZOUK: STATE-SPACE ANALYSIS OF CONCURRENT SYSTEMS
/* Test for safeness */
forall a in S [tokens(s)
is-safe :
=
1089
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 */
::- forall s in S [(Rready + acking + readO + readl - 1) & \
(rcv.flagO + rcv-flagi = 1) ]
rcvr-consistent
/* 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 the
sender.
Properties 1-5 can be seen as properties which are used
to verify that the model behaves in a way which is con-sistent with our intent. Property 6 verifies that it behaves
as a correct alternating-bit protocol according to the specification in Fig. 5.
Fig. 9 shows the RGA functions used to verify that these
properties hold for this model. The test for net safeness is
that used in the dining philosophers example. The sender_consistent function tests that waitack and Sready
are mutually exclusive, and that the sender is always in
one of those two states or in the intermediate state of deciding whether it has received a valid acknowledgment
(ackO or ack1 ). It then tests that for those states which
have a token of send_flagO or send flag 1, there are
never 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 an
acknowledgment with a zero or one flag. These states are
all mutually exclusive. The receiver must in any state be
prepared for the next packet read to have a specific flag
value, so rcv flagO(s) + rcv_flag 1 (s) must also be 1
for all states s. The rcvr consistent function tests for
all of these conditions simultaneously.
The sender and acknowledgment queues are in consistent states if the slots are always filled or empty, there is
not 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 the
overall flow described in Fig. 5. Part of this analysis is
shown in Fig. 10. It shows that arcs leaving place 00 in
Fig. 5 go either back to place 00, or they go to place 10.
The variables SORO and SOR1 are the mutually-exclusive subsets of all states of the system based on the marking of the send flagO, rcv flagO, and rcv flagl
places. They represent the 00 and 01 places in Fig. 5. The
set aout SORO is assigned the set of arcs leaving the
SORO states. The first forall loop verifies that the destination states of all these arcs are in one of the two sets.
The second loop checks that all of the arcs which move
the system into the 01 place involve firing of the transition
named "messageO received," which is fired only
when the receiver model receives a message and verifies
that its flag bit matches the expected value.
Similar analysis verifies the relationships between
places 10 and 11, 11 and 10, and 10 and 00. For brevity,
the complete analysis is omitted here. The model therefore exhibits the behavior expected of the alternating-bit
protocol. In going from state 00 to state 1 1, or from state
1 1 to state 00, exactly one message and one acknowledgment are successfully sent and received.
VI. ONGOING WORK
Timed Petri nets [20], [21] are extensions to Petri
nets which are valuable for modeling communications
protocols and for performance analysis. The use of RGA
to analyze timed reachability graphs produced from timed
Petri nets is currently being investigated. Some additional
primitive functions, described above, have been added already: ret, rft, enable time, firing_time, etc. In
timed Petri nets, it is possible for more than one transition
to begin firing simultaneously, or even for the same transition to be firing concurrently with itself. Since any state
change can therefore be caused by a transition's beginning or finishing firing, arcs in the graph must be represented as the quadruples described above.
One of the problems with reachability analysis is that a
representation of the complete state space of the system
must be constructed. Even when projections are used this
construction is time-consuming for large systems. For
many Petri nets finite projections cannot be built, precluding the use of RGA to analyze their behavior. One
solution to this problem is the use of simulation, which is
in essence exploration of a selected portion of the state
IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. SE-13, NO. 10, OCTOBER 1987
1090
>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
in(dest(a). SORi)]
>forall a in aout_SORO [in(dest(a), SORO)
true
trans(a)[tseq]
::=
tseq
:
tbegin(a); tseq(O)
ok
>forall a in aout_SORO [in(dest(a), SORI) if f (trans(a)
true
-
messageO-received)]
Fig. 10. Verification of overall model behavior.
space. Another advantage of simulation is that statistical ity in the design and analysis of concurrent systems exinformation about the performance of the system may be pressed as Petri nets.
calculated from the results of a simulated execution, anACKNOWLEDGMENT
swering such questions as "What percentage of the time
Some earlier results of this work appeared as "Comdoes the system spend waiting for the use of some shared
resource?". A tool has been built which can simulate the puter-Aided Analysis of Concurrent Systems in Proc. IFIP
execution of timed or untimed Petri nets. Other tools can Workshop on Protocol Specification, Verification, and
be used to compute the statistics or to filter the simulator's Testing (Amsterdam, The Netherlands: North-Holland,
output to limit execution traces to only those places and 1985).
transitions of interest. Finally, an execution trace may be
REFERENCES
converted by another tool into a partial reachability graph
A. Bartlett, R. A. Scantlebury, and P. T. Wilkinson, "Note on
which may then be analyzed using RGA. The potential of [1] K.
reliable full-duplex transmission over half-duplex links," Commun.
using RGA to evaluate simulation results is great, but the
ACM, vol. 12, no. 5, pp. 260-262-, May 1969.
[2] G. Berthelot and R. Terrat, "Petri net theory for the correctness of
practical utility of this approach is still being explored.
protocols," in Proc. IFIP Workshop Protocol Specification, VerifiAnother area of ongoing research is in adding branchcation, and Testing, C. A. Sunshine, Ed. Amsterdam, The Nething-time temporal operators to RGA similar to those deerlands: North-Holland, May 1982, pp. 325-342.
scribed in [5]. These operators allow one to ask the sys- [3] M. Diaz, "Modeling and analysis of communication and cooperation
protocols using Petri net based models," in Proc. IFIP Workshop
tem if a specified predicate will be true in some or all of
Protocol Specification, Verification, and Testing, C. Sunshine, Ed.
the successor states of a given state. A simple example of
Amsterdam, The Netherlands: North-Holland, 1983.
the utility of such functions is starvation: one might ask [4] G. Estrin, R. S. Fenchel, R. R. Razouk, and M. K. Vernon, "SARA
(System ARchitects Apprentice): Modeling, analysis, and simulation
if, from some state of interest, a certain resource must
for design of concurrent systems," IEEE Trans. Software
support
eventually become available to a waiting process, or if the
Eng., vol. SE-12, pp. 293-311, Feb. 1986.
[5] J. C. Fernandez, J. L. Richier, and J. Voiron, "Verification of proprocess must wait forever. The latest version of RGA intocol specifications using the Cesar system," in Proc. IFIP Workshop
cludes branching-time temporal logic operators.
Protocol Specification, Verification, and Testing, June 1985.
VII. CONCLUSION
The reachability graph analyzer described herein allows
many system-independent and system-specific properties
of concurrent systems modeled using Petri nets to be verified. The tool provides primitives from which complex
user-defined propositions can be constructed about the
states of the reachability graph. RGA then mechanically
verifies the propositions for a particular graph. Often,
carefully constructed functions can be used to avoid bruteforce approaches to verifying system properties, leading
to significant time savings with large graphs.
Other tools are needed to aid in the automatic generation and analysis of Petri nets. RGA is only one of a suite
of tools currently being developed for this purpose at UCI.
Other tools include Petri net editors, optimizers, animators, and simulators, and reachability and decision graph
builders and printers. The tools are being designed to intercQnnect easily, allowing the greatest possible flexibil-
[6] K. Gostelow, V. G. Cerf, G. Estrin, and S. Volansky, "Proper termination of flow of control in programs involving concurrent processes," SIGPLAN Notices, vol. 7, no. 11, 1972.
[7] B. Hailpern and S. Owicki, "Verifying network protocols using temporal logic," in Proc. Trends and Applications Symp., 1980, Computer Network Protocols, National Bureau of Standards, Gaithersburg, MD, May 1980.
[8] M. Holliday and M. Vernon, "A generalized timed Petri net model
for 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 generalized
stochastic Petri nets for the performance evaluation of multiprocessor
systems," 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 all
invariants of a generalized Petri net," in Proc. Second European
Workshop 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 implementation 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.
1091
MORGAN AND RAZOUK: STATE-SPACE ANALYSIS OF CONCURRENT SYSTEMS
users manual," Dep. Inform. Comput. Sci.,
Univ. California, Irvine, Tech. Rep. 243, Dec. 1984.
E. T. Morgan and R. R. Razouk, "Computer-aided analysis of concurrent systems," in Proc. IFIP Workshop Protocol Specification,
Verification, and Testing, Amsterdam, The Netherlands: North-Holland, 1985.
J. L. Peterson, Petri Net Theory and the Modeling of Systems. Englewood Cliffs, NJ: Prentice-Hall, 1981.
J. Postel, "Graph modeling of computer communications protocols,"
in Proc. 5th Texas Conf. Computing Systems, Austin, TX, Oct. 1976,
pp. 66-77.
C. V. Ramamoorthy and G. S. Ho, "Performance evaluation of asynchronous concurrency systems using Petri nets," IEEE Trans. Software Eng., vol. SE-6, pp. 440-449, Sept. 1980.
R. R. Razouk and G. Estrin, "Modeling and verification of communication protocols: The X.21 interface," IEEE Trans. Comput., vol.
C-29, pp. 1038-1052, Dec. 1980.
R. R. Razouk and C. V. Phelps, "Performance analysis using timed
Petri nets," in Proc. IFIP Workshop Protocol Specification, Verification, and Tesing, Y. Yemini, R. Strom, and S. Yemini, Eds. pp.
Amsterdam, The Netherlands: North-Holland, June, 1984, pp. 561576.
R. R. Razouk, "The derivation of performance expressions for communication protocols from timed Petri nets," Comput. Commun. Rev.,
vol. 14, no. 2, pp. 210-217, 1984.
-, "A guided tour of P-NUT (Release 2.1)," Dep. Inform. Comput. Sci., Univ. California, Irvine, Tech. Rep. 86-05, Mar. 1986.
R. R. Razouk and M. T. Rose, "Verifying partial correctness of concurrent software using contour/transition nets," in Proc. 19th Int.
Hawaii Conf Syst. Sci., Jan. 1986, pp. 734-743.
K. Sabnani and M. Schwartz, "Verification of a multidestination protocol using temporal logic," in Proc. IFIP Workshop Protocol Specification, Verification, and Testing, C. A. Sunshine, Ed. Amsterdam, The Netherlands: North-Holland, 1982.
J. Sifakis, "Petri nets for performance evaluation," in Measuring
Modeling, and Evaluating Computer Systems, H. Beilner and E. Gelenbe, Eds. Amsterdam, The Netherlands: North-Holland, 1977, pp.
75-93.
D. M. Stanat and D. F. McAllister, Discrete Mathematics in Computer Science. Englewood Cliffs, NJ: Prentice-Hall, 1977.
C. A. Sunshine, "Formal techniques for protocol specification and
verification," Computer, pp. 20-27, Sept. 1979.
114] E. T. Morgan, "RGA
[15]
[16]
[17]
[18]
[19]
[20]
[21]
[22]
[23]
[24]
[25]
[26]
[27]
[28] F. J. W. Symons, "Verification of communication protocols using
numerical Petri nets," Australian Telecommun Res., vol. 14, no. 1,
pp. 34-38, 1980.
[29] R. N. Taylor, "A general-purpose algorithm for analyzing concurrent
programs," Commun. ACM, vol. 26, no. 5, pp. 362-376, May 1983.
[30] W. M. Zuberek, "Time Petri nets and preliminary performance evaluation," in Proc. 7th Annu. Symp. Comput Architecture, 1980, pp.
88-96.
E. Timothy Morgan was born in Chattanooga,
l in 1959. He received the B.S. degree in physlTN,
X~X
ics and computer science from Vanderbilt University, Nashville, TN, in 1980, and the M.S. degree
in computer science from the University of California, Irvine, in 1982.
Presently he is a doctoral candidate in computer science at the University of California, Irvine. His interests include modeling and verification of concurrent software, computer typesetting, 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.
-
Rami R. Razouk (M'81) was born in Cairo,
Egypt, in 1953. He received the B.S. degree in
engineering, and the M.S. and Ph.D. degrees in
computer science from the University of California, Los Angeles, in 1975 and 1980, respectively.
a doctoral student he led the SARA group, un_As
der the direction of Dr. Gerald Estrin, from 1977
W _
_,
m>
-.
to 1980.
X
Presently he is an Assistant Professor of Information and Computer Science at the University of
California, 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 Association for Computing Machinery.