“What Is a Petri Net?”
Informal Answers for the Informed Reader
J¨org Desel and Gabriel Juh´as
Katholische Universit¨at Eichst¨att
Lehrstuhl f¨ur Angewandte Informatik
85071 Eichst¨att, Germany
{joerg.desel,gabriel.juhas}@ku-eichstaett.de
Abstract. The increasing number of Petri net variants naturally leads
to the question whether the term “Petri net” is more than a common
name for very different concepts. This contribution tries to identify as-
pects common to all or at least to most Petri nets. It concentrates on
those features where Petri nets significantly differ from other modeling
languages, i.e. we ask where the use of Petri nets leads to advantages
compared to other languages. Different techniques that are usually com-
prised under the header “analysis” are distinguished with respect to the
analysis aim. Finally, the role of Petri nets in the development of dis-
tributed systems is discussed.
1 Introduction
What is a Petri net? Very often, the thesis of Carl Adam Petri [23] written in
the early sixties is cited as the origin of Petri nets. However, Petri did of course
not use his own name for defining a class of nets. Moreover, this fundamental
work does not contain a definition of those nets that have been called Petri nets
later on. In fact, there are hundreds of different definitions and extensions in
the literature on Petri nets since then. Most authors did not mean to define
something completely new when coming up with a new definition. They use the
term “Petri net” to express that the basic concept of a notion is the one of Petri
nets, no matter how this notion is formulated mathematically or which extensions
of standard definitions are used. In this contribution we try to identify central
aspects of this basic concept of Petri nets. In other words, we aim at providing
characteristics of Petri nets that are common to all existing and future variants.
It should be clear that this can only be done in a very subjective manner. So we
like to place the following disclaimer at the very beginning of the paper: We do
not consider our list of important aspects of Petri nets complete, and for each
aspect claimed to be common to all Petri net variants there might exist very
reasonable exceptions.
This paper is not an introduction to Petri net theory. Instead, we assume
that the readers have some knowledge about Petri nets and preferably even
know different Petri net classes. For an overview of Petri net theory we refer to
the proceedings of the previous advanced course on Petri nets [25,26]. The other
H. Ehrig et al. (Eds.): Unifying Petri Nets, LNCS 2128, pp. 1–25, 2001.
c
Springer-Verlag Berlin Heidelberg 2001
2J¨org Desel and Gabriel Juh´as
contributions in this book should also be helpful, although the present paper is
meant to be an introductory note to this book. In particular, the work of the
“Forschergruppe Petrinetz-Technologie”, represented by the papers [35,17,13,36],
show how different variants of Petri nets can be subsumed and structured in a
unified framework.
There are also examples of modeling notions which do not carry “Petri net”
in the name but apparently stem from Petri nets. Among these notions are event-
driven process chains (EPCs) [31] (originally called “Ereignisgesteuerte Prozess-
ketten” in German), a standard notion for modeling business processes in the
framework of the “ARIS-Toolset”. The first publications on this model explictly
refer to Petri nets. Still, the central idea is the one of Petri nets although there
are some significant differences. Another example is given by activity diagrams,
a language within the Unified Modeling Language (UML). These diagrams more
or less look like Petri nets and have an interpretation which is very similar to
Petri nets but have some additional features such as “swim lanes”, associating
each diagram element to an object. Although people from the UML community
insist that activity diagrams have nothing to do with Petri nets, there already
exist a number of publications establishing close connections between these two
languages [14,18]. Actually, Petri nets are suggested for a formal semantics of ac-
tivity diagrams – this notion has evolved to a standard without having any fixed
semantics by now. So this paper is about Petri nets and those related formalisms
which are based on the same concepts as Petri nets.
Many papers defining or using Petri nets emphasize the following charac-
teristics of the model; Petri nets are a graphical notion and at the same time
a precise mathematical notion. So we take it that these two properties are the
most important ones and we devote the following two sections to them. The next
important characteristics of Petri nets is described by their executability, their
semantics, their behavior or the like. Whereas it seems that the first two charac-
teristic features do not rise any dissension, there is no common agreement what
the semantics of a Petri net should look like, i.e., what the behavior of a Petri
net formally is. We split the consideration on behavior in two parts; behavior
is constituted by the occurrence rule – which defines under which conditions a
transition is enabled and what happens when it occurs – and by derived for-
mal descriptions of the entire behavior, given by the set of occurrence sequences,
partially ordered runs or any kind of trees or graphs representing all runs of a
net. These parts constitute the topics of sections four and five. Analysis of Petri
nets is the next important subject, addressed in section six. This term comprises
many different concepts; analysis by simulation, by employing structural prop-
erties of the net, or by analysis of the exhibited behavior of a net. We distinguish
between analysis techniques that automatically provide useful information for a
given net (like deadlock-freedom), techniques that automatically verify a given
property (like mutual exclusion) and techniques that help in manually proving
the correctness of a net with respect to a given specification. The last section
is concerned with topics that are not explicitly addressed in most other papers
on Petri nets. Each Petri net is a model of a system, if it is not just a counter-
“What Is a Petri Net?” Informal Answers for the Informed Reader 3
example or an illustration of a proof. There are many different languages for
modeling systems, most of them not comparable with Petri nets (consider, e.g.,
models of the architecture, models of the data structure etc.). Therefore we have
to be more precise; a Petri net models the behavioral aspects of a system. The
same can be said about differential equations. So we should add that the behav-
ior is constituted by discrete events. Again, there are more prominent languages
for this task, namely the variety of automata models. The core issue of Petri nets
is that they model behavioral aspects of distributed systems, i.e., systems with
components that are locally separated and communicate which each other. Sur-
prisingly, neither components nor any notion of locality appears with the usual
definition of a Petri net. The section on distributed systems discusses aspects of
this gap.
Each section header is an answer to the question raised at the beginning of
the paper.
2 A Graphical Notation
Most modeling languages have graphical notations, and this has good reasons.
Models are used as a means to specify concepts and ideas, and to communicate
them between humans. Nearly everybody would use some kind of graphics to
express his or her understanding of a system, even without using any explicit
modeling language. We asked our first semester students to give a model of the
enrollment procedure of our university. The result was a very interesting vari-
ety of models emphasizing surprisingly many different aspects of the procedure.
All these models were supported by graphics. It does not need psychological
research to state that graphics employing two dimensions allow for a better un-
derstanding of complex structures than one-dimensional text. Since specification
of systems and communication of models are the main applications of Petri nets
in practice, understandability for humans is among the most crucial quality cri-
teria for modeling languages. Petri nets have a nice graphical representation
using only very few different types of elements, which is a good basis for an easy
understandability of a model and for the learnability of the language. These two
criteria for modeling languages belong to the most important ones recognized in
the “Guidelines of Modeling” [3].
Many modeling languages are supported by graphics that possibly abstracts
from some details of a model. Petri nets are not only supported by graphics but
each Petri net is a special annotated graph. One could argue that the annotations
of a Petri net are as essential as the graphics. In fact, for some high-level Petri
net classes it is possible to represent any model equivalently by a trivial net
structure, putting all the information about the model into the annotations of
a single place, a single transition and the connecting arcs [32]. In general, often
one has to trade off between specification by graphical means and specification
by textual means in the annotations. It is a typical feature of Petri nets that the
semantics of textual annotations can be given in terms of nets, i.e. of graphs.
As an example, consider the low-level unfolding of a high-level Petri net [32]. In
4J¨org Desel and Gabriel Juh´as
D
C
B
A
a
b
c
d
e
Fig. 1. A picture of a Petri net
this sense, annotations can be viewed as shortcuts for more complex graphical
representations, employing, e.g., symmetries of a net. Hence it is justified to
claim that a Petri net is a graph.
In the previous paragraphs we confused mathematical graphs with graphi-
cal notations. So what is a Petri net, a mathematical object representing the
components of a graph or a picture? It is important to notice that by definition
the way a net is drawn does not carry any semantic information. This is dif-
ferent for languages such as SADT [28] where it makes an important difference
whether an arc touches a node at its right, left, upper or lower side. Also the
relative position of Petri net nodes carries no formal information. However, the
topology of a drawn Petri net is important from a pragmatic perspective. The
modeler might place the elements representing a single system component on a
cycle if this helps to understand the net. In this case, additional knowledge about
the model and its relation to the system is put in the picture. Alternatively, a
tool can calculate a nice way to draw a net; then the figure carries information
about the net itself and about some analysis results. So a Petri net picture can
be more than a mathematically defined graph. The difference is irrelevant for
analysis tools. But it is significant when the net is used as a means for human
communication. Even simple models can be drawn in a spaghetti style such that
this picture does not help much (compare for example two pictures of the same
Petri net in Figures 1 and 2). The topology of a net drawing is an important
topic in the context of interchange standards for Petri nets [20]. The exchange
information of a picture might contain information about the relative position
of the nodes, about their shape etc.
It is often emphasized that Petri nets are bipartite graphs, because each di-
rected arc either leads from a place to a transition or from a transition to a place.
This is not exactly true; Petri nets are more than that. In bipartite graphs the
two sets of nodes play a symmetric role whereas places and transitions are dual
concepts. Exchanging places and transitions leads to a completely different net.
The existence of places and transitions and their distinction, is one of the fun-
damental ingredients of Petri nets. Therefore this formalism is neither primarily
based on actions (like data flow diagrams), represented by transitions, nor is it
primarily based on states (like automata), represented by places. Instead, the
“What Is a Petri Net?” Informal Answers for the Informed Reader 5
D
C
B
A
a
b
c
d
e
Fig. 2. Another picture of the Petri net from Figure 1
mutual interplay of local activities and local states constitutes the basic compo-
nents of each net, as will be discussed later in more detail. The equal footing of
actions and states is reflected in nets by the definition of places and transitions
on the same level. So the following definition is the most common answer to the
question “What is a Petri net?”
The usual definition of a “core” Petri net
A Petri net is a directed graph with two kinds of nodes,
interpreted as places and transitions,
such that no arc connects two nodes of the same kind.
Places of a Petri net are usually represented by round graphical objects (cir-
cles or ellipses), and transitions by rectangular objects (boxes or squares), as
shown in Figures 1 and 2. There is a standard arc type between vertices of differ-
ent type representing the flow relation, as shown in the figures. This convention
makes it easy to guarantee a rough understanding of any Petri net without ad-
ditional legend. One of the main advantages of the Unified Modeling Language
(UML, see [30]) is that it unifies the shape of vertices and arcs in its diagrams
that have been used in a contradictory way in different languages before. Like-
wise, the consistent use of graphical symbols for Petri net objects is one of the
main reasons for the worldwide and long standing success of Petri nets. When-
ever someone acquainted with Petri nets is confronted with a new variant, the
general interpretation of places and transitions does not have to be explained
and gives no rise to misunderstandings. So Petri nets play the role of a “Unified
Process Language” since a long time.
Sometimes the use of only circles and squares is considered a disadvantage.
Instead of circles or squares, special symbols representing the actual type of
the represented system component can be used. Branches at transitions or at
places can be substituted by special branching nodes. These variants are – among
others – implemented in many commercial Petri net tools. The vendors claim
that the readability of their models is improved by the graphical extensions.
This might sometimes be true, but there is the danger of inconsistency between
different products. Moreover, an increasing number of features leads to an in-
creasing number of modeling errors. Someone only familiar with such a specific
application-dependent notion can not understand an example net given in an-
other proprietary notation. However, as long as additional graphical notions have
