<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Archiving and Interchange DTD v1.0 20120330//EN" "JATS-archivearticle1.dtd">
<article xmlns:xlink="http://www.w3.org/1999/xlink">
  <front>
    <journal-meta />
    <article-meta>
      <contrib-group>
        <contrib contrib-type="author">
          <string-name>Jörg Desel</string-name>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <aff id="aff0">
          <label>0</label>
          <institution>FernUniversität in Hagen</institution>
          ,
          <country country="DE">Germany</country>
        </aff>
      </contrib-group>
      <abstract>
        <p>The most common composition mechanism for Petri nets synchronizes transitions of two nets by merging them: Two transitions are merged into one whose pre-set places consists of all pre-set places of the two transitions in their respective nets, and accordingly for the post-set places. This approach seems appropriate in applications where components are permanently connected, and therefore their models can be composed. However, it becomes very complex and even unsuitable when dealing with dynamically changing connection relations. This short paper introduces a diferent and novel composition mechanism tailored for dynamic composition of Petri nets. We will call it interaction. The core idea is that when Petri net components interact, corresponding (interacting) transitions are merged, as is the case for composition, but the original transitions are preserved and available for further interactions. Petri net components that are interpreted as parts of larger nets are called Petri net modules. We distinguish between internal and external transitions of Petri net modules, whereby only external transitions are capable of interaction. While the potential behavior of a module considers all transitions, the behavior of a closed Petri net, which does not provide for any further interaction, is limited to the internal transitions. The approach is defined and illustrated using the examples of a vending machine and of sets of chameleons, which can only change their color cooperatively.</p>
      </abstract>
      <kwd-group>
        <kwd>eol&gt;Petri net composition</kwd>
        <kwd>Petri net modules</kwd>
        <kwd>interaction</kwd>
        <kwd>chameleons</kwd>
      </kwd-group>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>1. Introduction</title>
      <p>
        An introductory lecture on Petri nets often begins with Petri net models of vending machines, see e.g.
[
        <xref ref-type="bibr" rid="ref1 ref2">1, 2</xref>
        ]. An example (from the Petri Net Course at the Petri Net Conference) is shown in Figure 1. This
example can explain a lot:
• There is a left hand component that describes the physical flow of goods and thus the physical
part of a vending machine. This modeling is based on place/transition nets; the number of tokens
in a place indicates how many goods are located at that position.
• The right hand component models the internal logic of the automaton, represented by an
elementary net system. Places of this component are therefore to be interpreted as conditions that can
either be true or false.
• The example shows that both Petri net components, although they have diferent Petri net types,
can be merged at the common transition “dispense item”. The composed Petri net represents the
overall behavior of the vending machine.
• The example was also created to represent alternatives (between “accept coin” and “reject coin”)
and little concurrency (for example between “refill” and “accept coin”) in one figure.
• Considering the transitions “dispense item” separately in both components, both of them model
an activity of the (hardware or software) system, that cannot occur without each other in the
modeled composed system: No item can be dispensed without accepted money, and each signal
“dispense item” should be accompanied by an actual dispense.
• There are further transitions of this Petri net that represent activities that also require an external
partner. For example, one would not expect the system to insert a coin into itself. Therefore, one
would need to merge this transition with a transition from a customer model. However, it also
item available
      </p>
      <p>ready for insertion
refill
dispense item</p>
      <p>holding coin
reject coin</p>
      <p>insert coin
empty
ready to dispense
accept coin
makes sense to abstract from this interaction, as long as it is taken into account that the system
cannot perform this activity on its own. The same applies to some other transitions, for example
“refill”. We will call such transitions external.
• For other activities, the responsibility lies solely with the modeled system. After a coin has been
inserted, one can expect that the system proceeds without further interaction – the corresponding
transitions “accept coin” and “reject coin” are said to be internal. Notice that the alternative
between these two transitions is also considered internal. Although the criterion for coin
acceptance is missing in the model and both transitions appear to occur randomly upon activation, the
missing model of a coin acceptor is nevertheless internal.</p>
      <p>Since nearly every modeled system has some relations to the outside world which is not in the focus of
the model, a Petri net is usually just a model of a system component that is connected to potential other
component models, but only this section of the overall model is shown. One could therefore assume
that the transition “insert coin” is merged in a larger model with a transition of another Petri net – the
model of a customer. However, this is not entirely true: While the two components of the vending
machine model cooperate closely with each other, this is not the case when connecting to a model of a
customer inserting a coin. A model composition would ensure that this would be the only customer
forever – no other customer could dock to the “insert coin” transition, which is not the desired behavior.
Instead, we need a dynamic composition where, in a single run (describing, for example, the behavior
of a day), multiple customers use the machine, and thus multiple customer models can merge with the
same transition of the model. The aim of this contribution is to develop and define such a compositional
approach, which we will call interaction.</p>
    </sec>
    <sec id="sec-2">
      <title>2. The Chameleon Game</title>
      <p>
        As the title of this paper suggests, we will not use the vending machine as running example, but
chameleons. The chameleon game, originally found in [
        <xref ref-type="bibr" rid="ref3">3</xref>
        ] and [
        <xref ref-type="bibr" rid="ref4">4</xref>
        ], was modeled and analysed with
Petri nets in [
        <xref ref-type="bibr" rid="ref5">5</xref>
        ].
      </p>
      <p>Some chameleons live quite happily in a large terrarium. There are  red,  blue, and 
green ones. These chameleons have a strange property: whenever two chameleons of
diferent colors meet, both take on the third color. For example, when a blue and a green
chameleon meet, they both turn red. And when a red and a green chameleon meet, they
both turn blue.</p>
      <p>
        In [
        <xref ref-type="bibr" rid="ref5">5</xref>
        ] termination and deadlock properties were studied, based on the respective initial numbers
of red, blue and green chameleons. Now we want to model chameleons adequately to describe their
behavior. Let us first provide a correct model for one chameleon:
      </p>
      <p>As Figure 2 shows, a chameleon in a certain color can change to both other colors, resulting in a Petri
net with three places (conditions) and six transitions. However, the rule of the chameleon game tells us
that a chameleon cannot change color unless it contacts another chameleon. So, this model represents a
single chameleon in some context, and all its transitions need to synchronize with transitions of other
model components. We call all these transitions external. The Petri net is said to be a Petri net module
(or open Petri net).</p>
      <p>br
blue
rb</p>
      <p>gr
red
bg
gb</p>
      <p>Now let us look at a model for two chameleons, built by composing two of the above modules. Since
every color change of one chameleon (say  → ) corresponds to exactly one change of the other
chameleon (here  → ), there is a one-to-one match between the respective sets of transitions.
The resulting net is shown in Figure 3.</p>
      <p>red1
green1</p>
      <p>blue1</p>
      <p>In this model, all transitions are internal because they cannot be composed with anything else. The
net is a closed Petri net, which describes the complete behavior of two chameleons, provided that both
will never contact a third one. We do not call this model a Petri net module because it cannot engage in
any composition. However, its behavior is a bit boring: Either both chameleons have the same color and
therefore no transition is enabled, or they have diferent colors (as depicted in the figure) and exactly
one transition is enabled, the occurrence of which leads to a deadlock.</p>
      <p>Next, we construct a model of two chameleons, which is extendable, i.e. we model two chameleons
which can interact as the ones modeled in Figure 3, but can also encounter further chameleons. For
this, the first composition of two chameleon models should not “consume” all transitions (making them
internal), because this interaction may occur only once, and then the same transition should be able to
synchronize with another transition. This consideration leads to a new composition operator, called
interaction which is illustrated in the following figures:</p>
      <p>If an external transition 1 of a Petri net module 1 interacts with an external transition 2 of a Petri
net module 2, then the resulting Petri net will have all the net elements and arcs of the nets 1 and
2 (in particular, 1 and 2 are still external transitions), and additionally a new internal transition 
satisfying ∙  = ∙ 1 ∪ ∙ 2 and ∙ = ∙1 ∪ ∙2.</p>
      <p>Merging two chameleon models by this interaction results in the Petri net shown in Figure 6. This
is another open Petri net, i.e., a Petri net module with external transitions. The reader might argue
that this Petri net interaction results in a Petri net with undesirable behavior: The internal transitions
represent steps that are legal according to the rules of the chameleon game, whereas the external
transitions represent illegal behavior, at least if the composed net is considered the nfial result. So
we distinguish the potential behavior of a Petri net module given an arbitrary environment (external
behavior) from the behavior of a Petri net which only uses its internal transitions (internal behavior).
The internal behavior of the Petri net module shown in Figure 6 equals the behavior of the net of Figure
3. It represents the behavior of two chameleons which are the only ones, whereas the external behavior
represents their potential behavior in a context.
red2
e
e
e
e
e
e
blue1
i
i
i
i
i
i
Definition. A Petri net module is a Petri net  = (,  , , 0) with a set   ⊆  of external
transitions. If   ̸= ∅ then we call the module open Petri net, otherwise closed Petri net.</p>
      <p>Assume two Petri net modules 1 and 2 with disjoint sets of elements and a relation  ⊆ 1 × 2.
Their interaction 1 ∘ 2 is defined by the unions of places, transitions, arcs, markings (viewed as
relations), plus additional transitions (, ) for each pair (, ) in . For each (, ) ∈  and each arc
(, ) of 1 or (, ) of 2 we add an arc (, (, )), and for each arc (, ) of 1 or (, ) of 2 we
add an arc ((, ), ). The set of external transitions of 1 ∘ 2 is the union of external transitions of
the component nets, i.e., the new transitions are internal.</p>
      <p>Lemma 1. Petri net module composition is commutative, i.e. 1 ∘  2 = 2 ∘ − 1 1, where ∘  denotes
interaction with respect to relation .</p>
      <p>Petri net module composition is associative, i.e. (1 ∘ 1 2) ∘ 2 3 = 1 ∘ 1 (2 ∘ 2 3).</p>
      <p>
        These rules follow immediately from the definition of Petri net module interaction. Notice that these
properties are not trivial when it comes to a syntactical representation of the relation , as discussed in
detail in the HERAKLIT approach [
        <xref ref-type="bibr" rid="ref6">6</xref>
        ].
      </p>
      <p>By associativity, repeated use of the interaction operator allows to build arbitrarily large net modules.
Since we assume disjoint nets in the definition, we must take care to add always “new” net modules,
although these might be copies of the same pattern. This is the case for the chameleon example – each
chameleon model needs new names for places and transitions. Instead of this assumption, we could
have shifted disjointness into the construction: if nets are not disjoint, then the operator distinguishes
the elements of the components before performing the actual composition. This allows to specify large
nets syntactically by e.g.  ∘  ∘  ∘  ∘  or even  5.</p>
      <p>
        Interaction of net modules allows to specify sets of modules that can interact arbitrarily, just in the
sense of [
        <xref ref-type="bibr" rid="ref7">7</xref>
        ], but it is also possible to restrict to possible interactions. For example, we might be interested
in modeling chameleons 0, 1, . . . , − 1 such that chameleon  can only interact with chameleons
− 1(mod ) and +1(mod ), that is, chameleons arranged on a circle.
      </p>
    </sec>
    <sec id="sec-3">
      <title>3. Behavior of interacting Petri net modules</title>
      <p>What is the “natural” behavior of a Petri net module? For the vending machine, one would consider
external transitions as first-class citizens of the game: the usual considerations include “insert coin”
etc. In contrast, for the chameleons, one would not consider chameleons that change color without
partner. So, it makes sense to consider both ways natural and to distinguish “internal behavior” (without
external transitions) from “external behavior” (with external transitions).</p>
      <p>Definition. Given a Petri net module, its internal Petri net is given by the Petri net of the module
without external transitions (and incoming and outgoing arcs).</p>
      <p>The external behavior of a Petri net module is the behavior of its Petri net.</p>
      <p>The internal behavior of a Petri net module is the behavior of its internal Petri net.</p>
      <p>
        We are interested in the external behavior of the vending machine model, but in the internal behavior
of a model of the chameleon game. What about other examples? Consider a workflow Petri net model of
a process as defined by van der Aalst [
        <xref ref-type="bibr" rid="ref8">8</xref>
        ], which has a unique (initially marked) initial place and a unique
ifnal place. Add an additional external transition that moves a token from the final place to the initial
place. Then the internal behavior is the behavior of the workflow net itself, representing the behavior
of the modeled process. Soundness is a behavioral property defined for internal behavior. External
behavior also allows the occurrence of the “feedback transition”, which represents the environment of
the process in a very abstract way. This external behavior makes it clear that a process should not be
executed only once. Ideally, the Petri net (with the additional external transition) is live and bounded.
      </p>
      <p>Typical behavioral properties such as liveness or deadlock-freeness refer to the definition of the
behavior of a net. But do they refer to internal or to external behavior? We consider this question for
deadlock-freeness in the sequel, but these considerations can be transferred to other properties like
liveness as well.</p>
      <p>A Petri net can run into a deadlock when it can reach a marking that does not enable any transition.
A deadlock-free Petri net has no reachable deadlocks. To transfer this property to Petri net modules,
we need to make two decisions, each with two possibilities: Should reachability refer to internal or
external behavior, i.e. should we consider markings only reachable by occurrence sequences of internal
transitions? And should the deadlock property (no transition enabled) refer to all transitions or to
internal transitions only? So we have four options. We will show that all of them can be meaningful,
depending on the system modeled.</p>
      <p>• For the vending machine example, the state in which the machine is waiting for a customer
would not be considered an undesired deadlock, even though the machine stops. For this example,
reachability and deadlock refer to external behavior. Generally, this case refers to reactive models
with interface.
• In the chameleon game, a deadlock occurs when all chameleons have the same color. Here both
reachability and deadlock refer to internal behavior. Generally, this is the case when the system
is fully modeled.
• For the model of a database system, one would include possible user interactions (external
transitions) as part of behavior, but expect that the system never stops and waits for user input
(deadlocked with respect to internal transitions). This case is typical for models where interaction
is interruption.
• Finally, it might be desirable that a system cannot get stuck before the first user interaction. Then
we consider reachability w.r.t. internal behavior and expect that for any reachable state either an
internal or an external activity is possible. This property is relevant for the initialization phase of
systems where interaction is possible but not mandatory.</p>
    </sec>
    <sec id="sec-4">
      <title>4. Conclusion</title>
      <p>We introduced the concept of interaction of Petri net modules and distinguished it from traditional
composition. The distinction requires a distinction between internal and external transitions and
between internal and external behavior. The examples illustrated that modeling with Petri nets does not
simply involve drawing standalone Petri nets and observing their behavior, but that the modeled system,
and thus also its model, is usually embedded in an environment. The interfaces to this environment play
a crucial role in interpreting the model and defining its properties. A learner must therefore practice
from the beginning to consider system interfaces and their role with regard to the model.</p>
    </sec>
    <sec id="sec-5">
      <title>Declaration on Generative AI</title>
      <p>The authors have not employed any Generative AI tools.</p>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          [1]
          <string-name>
            <given-names>J.</given-names>
            <surname>Desel</surname>
          </string-name>
          ,
          <string-name>
            <given-names>J.</given-names>
            <surname>Esparza</surname>
          </string-name>
          , Free choice Petri nets, Cambridge University Press, USA,
          <year>1995</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref2">
        <mixed-citation>
          [2]
          <string-name>
            <given-names>W.</given-names>
            <surname>Reisig</surname>
          </string-name>
          ,
          <article-title>Elements of distributed algorithms: modeling and analysis with Petri nets</article-title>
          , Springer,
          <year>1998</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref3">
        <mixed-citation>
          [3]
          <string-name>
            <given-names>H.</given-names>
            <surname>Dambeck</surname>
          </string-name>
          ,
          <string-name>
            <given-names>M.</given-names>
            <surname>Niestedt</surname>
          </string-name>
          , Verwirrspiel im Terrarium, https://www.spiegel.de/karriere/verwirrspielim-terrarium
          <article-title>-raetsel-der-woche-</article-title>
          <string-name>
            <surname>a-</surname>
          </string-name>
          404e0560
          <string-name>
            <surname>-</surname>
          </string-name>
          ca83
          <string-name>
            <surname>-</surname>
          </string-name>
          418c
          <source>-a5f3-8acfa3167d3d</source>
          ,
          <year>2021</year>
          . Accessed:
          <fpage>2022</fpage>
          - 03-01.
        </mixed-citation>
      </ref>
      <ref id="ref4">
        <mixed-citation>
          [4]
          <string-name>
            <given-names>A.</given-names>
            <surname>Beutelspacher</surname>
          </string-name>
          , Das Geheimnis der zwölften Münze: Neue mathematische Knobeleien,
          <string-name>
            <given-names>C.H.</given-names>
            <surname>Beck</surname>
          </string-name>
          ,
          <year>2021</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref5">
        <mixed-citation>
          [5]
          <string-name>
            <given-names>J.</given-names>
            <surname>Desel</surname>
          </string-name>
          ,
          <article-title>The chameleon game</article-title>
          , in: M.
          <string-name>
            <surname>Köhler-Bussmeier</surname>
            ,
            <given-names>D.</given-names>
          </string-name>
          <string-name>
            <surname>Moldt</surname>
          </string-name>
          , H. Rölke (Eds.),
          <source>Petri Nets and Software Engineering</source>
          <year>2022</year>
          , volume
          <volume>3170</volume>
          <source>of CEUR Workshop Proceedings</source>
          ,
          <year>2022</year>
          , pp.
          <fpage>202</fpage>
          -
          <lpage>210</lpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref6">
        <mixed-citation>
          [6]
          <string-name>
            <given-names>P.</given-names>
            <surname>Fettke</surname>
          </string-name>
          , W. Reisig, Understanding the Digital World - Modeling
          <string-name>
            <surname>with</surname>
            <given-names>HERAKLIT</given-names>
          </string-name>
          , Springer,
          <year>2024</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref7">
        <mixed-citation>
          [7]
          <string-name>
            <given-names>G.</given-names>
            <surname>Berry</surname>
          </string-name>
          ,
          <string-name>
            <surname>G. Boudol,</surname>
          </string-name>
          <article-title>The chemical abstract machine</article-title>
          ,
          <source>Theoretical Computer Science</source>
          <volume>96</volume>
          (
          <year>1992</year>
          )
          <fpage>217</fpage>
          -
          <lpage>248</lpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref8">
        <mixed-citation>
          [8]
          <string-name>
            <surname>W. M. P. van der Aalst</surname>
          </string-name>
          ,
          <article-title>Verification of workflow nets</article-title>
          , in: P. Azéma, G. Balbo (Eds.),
          <source>Application and Theory of Petri Nets</source>
          <year>1997</year>
          , volume
          <volume>1248</volume>
          of Lecture Notes in Computer Science, Springer,
          <year>1997</year>
          , pp.
          <fpage>407</fpage>
          -
          <lpage>426</lpage>
          .
        </mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>