<!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>Preface</string-name>
        </contrib>
      </contrib-group>
      <pub-date>
        <year>2011</year>
      </pub-date>
      <fpage>59</fpage>
      <lpage>100</lpage>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>Didier Buchs (PC chair SUMo)</title>
    </sec>
    <sec id="sec-2">
      <title>Hanna Klaudel and Franck Pommereau (PC chairs CompoNet)</title>
      <p>Conference Organization
SUMo Programme Committee</p>
    </sec>
    <sec id="sec-3">
      <title>Beatrice Berard (France)</title>
    </sec>
    <sec id="sec-4">
      <title>Dragan Bosnacki (The Netherlands)</title>
    </sec>
    <sec id="sec-5">
      <title>Ivana Cerna (Czech Republic)</title>
    </sec>
    <sec id="sec-6">
      <title>Gianfranco Ciardo (USA)</title>
    </sec>
    <sec id="sec-7">
      <title>Jean-Michel Couvreur (France)</title>
    </sec>
    <sec id="sec-8">
      <title>Martin Franzle (Germany)</title>
    </sec>
    <sec id="sec-9">
      <title>Giuliana Franchescinis (Italy)</title>
    </sec>
    <sec id="sec-10">
      <title>Monika Heiner (Germany)</title>
    </sec>
    <sec id="sec-11">
      <title>Tommi Junttila (Finland)</title>
    </sec>
    <sec id="sec-12">
      <title>Kais Klai (France)</title>
    </sec>
    <sec id="sec-13">
      <title>Olga Kouchnarenko (France)</title>
    </sec>
    <sec id="sec-14">
      <title>Marta Kwiatkowska (UK)</title>
      <p>External Reviewers</p>
    </sec>
    <sec id="sec-15">
      <title>Edmundo Lopez (University of Geneva)</title>
    </sec>
    <sec id="sec-16">
      <title>Charles Lakos (Australia)</title>
    </sec>
    <sec id="sec-17">
      <title>Isabella Mastroeni (Italia)</title>
    </sec>
    <sec id="sec-18">
      <title>Emmanuel Paviot-Adet (France)</title>
    </sec>
    <sec id="sec-19">
      <title>Wojciech Penczek (Poland)</title>
    </sec>
    <sec id="sec-20">
      <title>Denis Poitrenaud (France)</title>
    </sec>
    <sec id="sec-21">
      <title>Olivier Roux (France)</title>
    </sec>
    <sec id="sec-22">
      <title>Alexander Serebrenik (Netherland)</title>
    </sec>
    <sec id="sec-23">
      <title>Jeremy Spronston (Italy)</title>
    </sec>
    <sec id="sec-24">
      <title>Yann Thierry-Mieg (France)</title>
    </sec>
    <sec id="sec-25">
      <title>Bow-Yaw Wang (Taiwan)</title>
    </sec>
    <sec id="sec-26">
      <title>Karsten Wolf (Germany)</title>
      <p>CompoNet Programme Committee</p>
    </sec>
    <sec id="sec-27">
      <title>Eike Best (Germany)</title>
    </sec>
    <sec id="sec-28">
      <title>Didier Buchs (Switzerland)</title>
    </sec>
    <sec id="sec-29">
      <title>Gianfranco Ciardo (USA)</title>
    </sec>
    <sec id="sec-30">
      <title>Raymond Devillers (Belgium)</title>
    </sec>
    <sec id="sec-31">
      <title>Berndt Muller (Farwer) (UK)</title>
    </sec>
    <sec id="sec-32">
      <title>Alain Finkel (France)</title>
    </sec>
    <sec id="sec-33">
      <title>David de Frutos-Escrig (Spain)</title>
    </sec>
    <sec id="sec-34">
      <title>Ryszard Janicki (Canada)</title>
    </sec>
    <sec id="sec-35">
      <title>Ekkart Kindler (Denmark)</title>
    </sec>
    <sec id="sec-36">
      <title>Jetty Kleijn (The Netherlands)</title>
    </sec>
    <sec id="sec-37">
      <title>Charles Lakos (Australia)</title>
    </sec>
    <sec id="sec-38">
      <title>Johan Lilius (Finland)</title>
    </sec>
    <sec id="sec-39">
      <title>Daniel Moldt (Germany)</title>
    </sec>
    <sec id="sec-40">
      <title>Elisabeth Pelz (France)</title>
    </sec>
    <sec id="sec-41">
      <title>Laure Petrucci (France)</title>
    </sec>
    <sec id="sec-42">
      <title>Wolfgang Reisig (Germany)</title>
    </sec>
    <sec id="sec-43">
      <title>Natalia Sidorova (The Netherlands)</title>
    </sec>
    <sec id="sec-44">
      <title>Alex Yakovlev (UK)</title>
    </sec>
    <sec id="sec-45">
      <title>S ren Christensen (Denmark)</title>
    </sec>
    <sec id="sec-46">
      <title>Karsten Wolf (Germany)</title>
      <sec id="sec-46-1">
        <title>Session 1. CompoNet</title>
        <p>Distributed Veri cation of Modular Systems : : : : : : : : : : : : : : : : : : : : : : : : : :</p>
        <p>Mohand Cherif Boukala, Laure Petrucci
Compositional Analysis of Discrete Time Petri nets : : : : : : : : : : : : : : : : : : :
Yann Thierry-Mieg, Beatrice Berard, Fabrice Kordon, Didier Lime,
Olivier H. Roux
On the modularity in Petri Nets of Active Resources : : : : : : : : : : : : : : : : : :</p>
        <p>Vladimir A. Bashkin</p>
      </sec>
      <sec id="sec-46-2">
        <title>Session 2. SUMo</title>
        <p>Optimising the compilation of Petri net models : : : : : : : : : : : : : : : : : : : : : : :</p>
        <p>Lukasz Fronc, Franck Pommereau
Generalized Buchi Automata versus Testing Automata for Model Checking 65</p>
        <p>Ala Eddine Ben Salem, Alexandre Duret-Lutz, Fabrice Kordon
When Gra ti Brings Order : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
Alban Linard, Didier Buchs
81
1
17
33
49
Distributed Verification of Modular Systems</p>
        <p>M.C. Boukala1 and L. Petrucci2</p>
        <sec id="sec-46-2-1">
          <title>1 LSI, Computer Science department, USTHB</title>
          <p>BP 32 El-Alia Algiers, ALGERIA
boukala@lsi-usthb.dz</p>
        </sec>
        <sec id="sec-46-2-2">
          <title>2 LIPN, CNRS UMR 7030, Université Paris XIII</title>
          <p>99, avenue Jean-Baptiste Clément</p>
          <p>F-93430 Villetaneuse, FRANCE</p>
          <p>Laure.Petrucci@lipn.univ-paris13.fr
Abstract. The use of distributed or parallel processing gained interest
in the recent years to fight the state space explosion problem. Many
industrial systems are described with large models, and the state space
being even larger, it does not fit completely into the memory of a single
computer.</p>
          <p>To avoid the high space requirement, several reduction techniques have
been proposed: modular verification, partial order reductions,
symmetries, using symbolic or compact representations like BDDs.</p>
          <p>Another way to alleviate the state space explosion problem is to use
modular analysis, which takes advantage of the modular structure of a
system specification, particularly for systems where the modules exhibit
strong cohesion and weak coupling.</p>
          <p>In this paper, we propose to combine distributed processing and
modular analysis to perform verification of basic behavioural properties such
as reachability, deadlock states, liveness, and home states and their
distributed analysis for modular systems. Each module is assigned to a
process which explores independently the internal activity of the
module, allowing a significant reduction in the size of the state space rather
than in an interleaved fashion.</p>
          <p>Keywords: Modular systems, distributed verification, modular analysis,
Petri nets.
1</p>
          <p>Introduction
Systems developed nowadays are both more and more complex and critical.
When addressing the design of such systems, it is necessary to ensure reliability,
by verifying the system properties. The main approach to verification consists
in the generation and analysis of the state space. Some properties such as
reachability or deadlocks can be verified on-the-fly, and only require information on
states reachable from the initial marking. On the contrary, liveness and home
states are elaborate properties which require a full generation of the state space
including not only nodes but also arcs. Even for small models, the size of the
state space may be too huge to fit in the memory of a single computer.</p>
          <p>To cope with the state space explosion problem, several reduction techniques
have been proposed: on-the-fly verification checks properties during the state
space construction; sweep-line construction [Sch04] considers a progress
measure, and discards states that will not be encountered further in the
construction; modular verification [LP04]; partial order reductions [Val92,NG97];
symmetries [AHI98,CFJ93]; using symbolic or compact representations like BDDs
and Kronecker algebra.</p>
          <p>Recently, several studies addressed distributed verification, many of them
focussing on distributed LTL model-checking [BBS01,BO03,LS99,BP07]. These
works are mainly based on the partionning of the state space.</p>
          <p>The performances of distributed verification depends on several criteria, e.g.
load balancing of the partitioned state space, but also, more importantly, on
a good partitioning. Therefore, choosing an adequate hash function to assign
nodes to processors is important.</p>
          <p>In [LP04] the modular analysis approach examines in isolation the local
behaviour of each subsystem, and then separately considers the synchronisation
between the subsystems. In this fashion, exploring the many possible
interleavings of activity of the subsystems is avoided, thus reducing the state space.</p>
          <p>In this work, we propose to combine modular analysis and distributed
processing to improve consequently the systems verification. We focus on checking
usual properties such as reachability, liveness and home states.</p>
          <p>The paper is organised as follows. We assume the reader is familiar with basic
Petri nets notions. Hence, we recall in Section 2 only the modular concepts, i.e.
Modular Petri nets and Modular State Spaces. In section 3, we introduce
algorithms based on distributed modular construction of the state space. In section 4
distributed verification of various properties is presented. These algorithms have
been implemented in a prototype tool and experimental results are presented in
section 5. Finally, section 6 concludes the paper.
2</p>
          <p>Modular Petri Nets
In this paper, we consider only modules synchronised through shared transitions
as in [LP04].
2.1</p>
          <p>Definition of Modular Petri Nets
Definition 1 (Modular Petri net). A modular Petri net is a pair MN =
(S, TF ), satisfying:
1. S is a finite set of modules such that:
– Each module, s ∈ S, is a Petri net: s = (Ps, Ts, Ws, M0s ).
– The sets of nodes corresponding to different modules are pair-wise
disjoint:
∀s1, s2 ∈ S : [s1 6= s2 ⇒ (Ps1 ∪ Ts1 ) ∩ (Ps2 ∪ Ts2 ) = ∅].
– P = S Ps and T = S Ts are the sets of all places and all transitions
s∈S s∈S
of all modules.
2. TF ⊆ 2T is a finite set of non-empty transition fusion sets.</p>
          <p>In the following, TF also denotes Stf ∈TF tf . We now introduce transition
groups.</p>
          <p>Definition 2 (transition group). A transition group tg ⊆ T consists of either
a single non-fused transition t ∈ T \ TF or all members of a transition fusion
set tf ∈ TF .</p>
          <p>The set of transition groups is denoted by TG.</p>
          <p>A transition can be a member of several transition groups as it can be
synchronised with different transitions (a sub-action of several more complex
actions). Hence, a transition group corresponds to a synchronised action. Note
that all transition groups have at least one element.</p>
          <p>Next, we extend the arc weight function W to transition groups, i.e. ∀p ∈
P, ∀tg ∈ TG :</p>
          <p>W (p, tg) = P W (p, t),
t∈tg</p>
          <p>W (tg, p) = P W (t, p).</p>
          <p>t∈tg
Markings of modular Petri nets are defined as markings of Petri nets, over the
set P of all places of all modules. The restriction of a marking M to a module
s is denoted by Ms. The enabling and occurrence rules of a modular Petri net
can now be expressed.</p>
          <p>Definition 3 (Transition group enabledness). A transition group tg is
enabled in a marking M , denoted by M [tgi, iff:</p>
          <p>∀p ∈ P : W (p, tg) 6 M (p)
When a transition group tg is enabled in a marking M1, it may occur, changing
the marking M1 to another marking M2, defined by:</p>
          <p>∀p ∈ P : M2(p) = (M1(p) − W (p, tg)) + W (tg, p).</p>
          <p>Example: The (full) state space for the modular Petri net of figure 1 is shown
in figure 2. Note that the initial state is shown as A1B1C1, thus indicating that
place A1 is marked with a token in module A, place B1 is marked with a token
in module B, and place C1 is marked with a token in module C. In this initial
state, only transition F1 is enabled, its occurrence leading to state A2B2C1.</p>
          <p>When considering the modular state space, as well as checking properties of
the system, we will use Strongly Connected Components. The set of all strongly
connected components is denoted by SCC. For a node v and a component c ∈
SCC we use v ∈ c to denote that v is one of the nodes in c. A similar notation
is used for arcs. We use vc to denote the component to which v belongs.
A1
F1
A2
F3
tB
A3
tA</p>
          <p>C1
F2</p>
          <p>C2</p>
          <p>Modular State Spaces
In the definition of modular state spaces, we denote the set of states reachable
from M by occurrences of local (non-fused) transitions only, in all the individual
modules, by [[M i.</p>
          <p>The notation with a subscript s means the restriction to module s, e.g. [M is
is the set of all nodes reachable from the global marking M by occurrences of
transitions in module s only.</p>
          <p>We use M [[σiiM 0 to denote that M 0 is reachable from M by a sequence
σ ∈ (T \ T F )∗T F of internal transitions followed by a fused transition. In the
definition of modular state spaces we need a compact notation to capture the
states reachable from M in all the individual modules. It turns out that we can
use a product of SCCs of the individual modules to express this representative
node: for any reachable marking M , we use M c to denote the product (or tuple)
of Strongly Connected Components (SCCs) Msc of the individual modules:
∀M ∈ [M0i : M c =</p>
          <p>YMsc.
s∈S
The definition of a modular state space consists of two parts: the state spaces of
the individual modules and the synchronisation graph.</p>
          <p>Definition 4 (Modular state space). Let MN = (S, TF ) be a modular Petri
net with the initial marking M0. The modular state space of MN is a pair
MSS = ((SS s)s∈S , SG), where:
1. SS s = (Vs, As) is the local state space of module s:
(a) Vs = S [vis
v∈VSG</p>
          <p>A2B3C2
F3
(b) As = {(M1, t, M2) ∈ Vs × (T \ TF )s × Vs | M1[tiM2}
2. SG = (VSG, ASG) is the synchronisation graph of MN :
(a) VSG = [[M0iic
(b) ASG = {(M1c, (M∪M10c,0ctf ), M2c) ∈ VSG × ([M0ic × TF ) × VSG | M10 ∈ [[M1i ∧</p>
          <p>M10 [tf iM2}</p>
          <p>A detailed explanation of the definition is given in [LP04]:
(1) The definition of the state space graphs of the modules is a generalization of
the usual definition of state spaces.</p>
          <p>(1a) The set of nodes of the state space graph of a module contains all states
locally reachable from any node of the synchronisation graph.</p>
          <p>(1b) Likewise the arcs of the state space graph of a module correspond to all
enabled internal transitions of the module.
(2) Each node of the synchronisation graph is labelled by a M c and is a
representative for all the nodes reachable from M by occurrences of local transitions
only, i.e. [[M i. The synchronisation graph contains the information on the nodes
reachable by occurrences of fused transitions.</p>
          <p>(2a) The nodes of the synchronisation graph represent all markings reachable
from another marking by a sequence of internal transitions followed by a fused
transition. The initial node is also represented.</p>
          <p>(2b) The arcs of the synchronisation graph represent all occurrences of fused
transitions.</p>
          <p>The state space graphs of the modules contain only local information, i.e.
the markings of the module and the arcs corresponding to local transitions but
not the arcs corresponding to fused transitions. All the information concerning
these is stored in the synchronisation graph.</p>
          <p>The nodes of the synchronisation graph represent all markings reachable
from another marking by a sequence of internal transitions followed by a fused
transition. The initial node is also represented.</p>
          <p>The arcs of the synchronisation graph represent all occurrences of fused
transitions. Each arc is labelled by the corresponding fired transition and by the
SCCs of the markings which enabled this transition. But only the SCCs of the
participating modules do appear.</p>
          <p>Example: The modular state space for the modular Petri net of figure 1 is shown
in figure 3. Note that there is a local state space for each module, as well as a
synchronisation graph which captures the occurrence of fused transitions. We do
not distinguish between nodes and SCCs since, in this case, all SCCs consist of
a single node (which is seldom the case in practice).</p>
          <p>Module A</p>
          <p>Module B</p>
          <p>Module C</p>
          <p>Synch. Graph
A1
A2</p>
          <p>A3</p>
          <p>B1
B2
B3
tB</p>
          <p>C1
C2</p>
          <p>A1B1C1</p>
          <p>Although sketches of algorithms were introduced in [LP04], we give here the
description of the distributed algorithms for the construction of the state space
and for the verification of the reachability, dead markings, liveness, and home
states properties.
3</p>
          <p>Distributed Construction of the Modular State Space
Several works have developed distributed tools generating and exploring the
state space on a cluster of workstations. Partitioning the set of states over the
different stations is done using a hash function [GMS01,KP04,AAC87,LP04].
This approach can handle larger state spaces but still remains limited.</p>
          <p>Here, we consider a different approach based on modularity to achieve a
distributed construction of the state space and the verification of various properties.</p>
          <p>In this approach we also used two types of processes. They consist in a
coordinator process and N worker processes, one worker process for each module,
as in [KP04].</p>
          <p>The coordinator constructs the synchronisation graph, coordinates the
different worker processes and determines the termination of the modular state space
construction, while every worker generates the local state space of the module
it is assigned by firing only internal transitions.</p>
          <p>The coordinator process starts by sending the initial marking M0s restricted
to module s to each worker process, and waits for receiving the states enabling
fused transitions from the workers processes.</p>
          <p>Algorithm 1: Internal State Space Generation()
24
25 end
forall the tf ∈ TF s.t. M [tf i do
/* M enables a fused transition tf */</p>
          <p>TFWaiting ← TFWaiting ∪ {(M, tf )};</p>
          <p>Waitings ← Waitings \ {M }
if TFWaiting = ∅ then</p>
          <p>EndOfGeneration = true
else
while TFWaiting 6= ∅ do</p>
          <p>Choose (M, tf ) ∈ TFWaiting s.t. M [tf iM 0
Waitings ← Waitings ∪ {M 0}
TW .label = M c
TW .AncSCC = AncSCC (M )
TW .tr = tf
TW .SuccSCC = M 0c
Send (Sender = s, Dest = Coordinator, Type = SynchTrans,</p>
          <p>Content = TW )</p>
          <p>Send (Sender = s, Dest = Coordinator, Type = END_GENERATION)</p>
          <p>When a worker process s receives the initial marking, it adds it to the sets
Vs and W aitings, that correspond respectively to the set of local markings and
the set of markings which are visited but not explored yet. The worker process
then invokes algorithm 1 to generate the internal state space of the module it is
assigned. Function Add (M ) adds the marking M to both sets Vs and W aitings
if it is not already in Vs.</p>
          <p>The workers send enabled fused transitions to the coordinator process.
Actually, the message sent to the coordinator not only contains the fused transition tf
but also the SCC number M c of the marking enabling tf , and the SCC number
of its predecessor marking in the synchronisation graph (in a field AncSCC ).</p>
          <p>The communications are asynchronous. Thus, when receiving a message,
the coordinator and worker processes are preempted and a handler function
MessageHandler() is invoked. Algorithm 2 describes the actions performed by
the coordinator when it receives a fused transition from the worker process s.</p>
          <p>The parts handling other messages are not detailed. They concern the
algorithm termination (and is similar to the termination in [KP04]), as well as the
analysis messages introduced in section 4.</p>
          <p>First, the coordinator creates the initial node v0 = M0c ∈ VSG. When a
fused transition tf is received from a process s, the successors of a node v =
(v1, v2, . . . vN ) ∈ VSG are computed as follows:
– we consider the set PM of the modules (processes) participating in the
synchronisation of the fused transition tf ;
– we construct the sets:
• Wpm corresponding to the fused transition tf received earlier from other
processes;
• Ws corresponding to the fused transition received from process s;
• Wnp contains • for modules not participating in the synchronisation;
– for all possible combinations, the successor nodes in the synchronisation
graph are calculated.</p>
          <p>The successor states thus computed are sent to the worker processes for an
additional round of internal state space generation.
4</p>
          <p>Properties
A major issue is the analysis of concurrent systems properties. The
reachability graph is the basic model on which most verifications are built. Behavioural
properties, which depend on initial marking, and the reachability graph are often
used to perform such analysis.</p>
          <p>In this work we focus on basic behavioural properties: reachability, deadlocks,
liveness, home state and their distributed analysis.
4.1</p>
          <p>Reachability
The reachability problem for Petri nets consists in proving that a given marking
M is in [M0i. This property is often used to check whether a faulty state M
is reachable, e.g. an elevator moving while the door is open. It is convenient to
look for erroneous states.
Algorithm 2: Message Handler()
1 begin
.
.</p>
          <p>.
2 if Message.Type = SynchTrans then</p>
          <p>/* message received contains an enabled fused transition */
3 tf = Message.Content.tr
4 s = Message.Sender
5 PM = {i s.t. tf ∈ Ti}</p>
          <p>/* PM: modules participating in the synchronisation of tf */
6 foreach v = (v1c, v2c, · · · , vNc ) ∈ VSG do
7 foreach pm ∈ PM and pm 6= s do
8 Wpm = {w ∈ SGWaitingpm s.t.
9 (w.AncSCC = vpcm) ∧ (w.tr = tf )}</p>
          <p>/* Wpm: markings enabling tf , with vpm as ancestor */
Ws = {Message.Content}
foreach C = (c1, c2, · · · , cN ) s.t. ∀i ∈ PM , ci ∈ Wi do
v0 = (v0c1, v0c2, · · · , v0cN ) where:</p>
          <p>∀i ∈ PM , v0ic = ci.SuccSCC and ∀i 6∈ PM , v0ic = vic
Add (v0)
AddArc (v, (C , ft), v0)
foreach pm ∈ PM do</p>
          <p>Send (Sender = Coordinator, Dest = pm, Type = NEW_NODE,</p>
          <p>Content = vp0m)
SGWaitings = SGWaitings ∪ Message.Content</p>
          <p>In some applications, one may be interested in the markings of a subset of
places and not care about the others places in the net. This leads to a submarking
reachability problem.</p>
          <p>Reachability is known to be decidable. For modular systems, determining
whether a given state M is reachable from the initial marking can be done in
a parallel way: each worker process s searches through its local state space Vs.
Then, if one of the worker processes does not find Ms in its local state space
Vs, marking M is not reachable. Otherwise i.e. (∀s ∈ {1..N } Ms ∈ Vs), all
the workers send the ancestor SCCs of Ms to the coordinator. The coordinator
stores the SCCs received from each worker s and checks whether there exists a
combination of these in the set of nodes of the synchronisation graph VSG.
4.2</p>
          <p>Deadlocks
The algorithm used to find dead markings in a modular state space is based on
the following proposition:
Proposition 1 (Deadlocks).</p>
          <p>M ∈ [M0i is a deadlock ⇔ [ ∀s ∈ S : (M s)c ∈ T erm(SCCs) ∩ T rivial(SCCs))
∧(∀(v1, (M1c, tf ), v2) ∈ ASG : M1c 6= M c)]</p>
          <p>Each worker process s searches in its local state space for the local dead
markings which consist in trivial terminal SCCs. If there exists a worker process
without such a node, the module assigned to this worker always allows a local
behaviour. Hence, the system is deadlock-free. Otherwise, every worker process
sends the SCCs corresponding to the locally dead markings to the coordinator
process.</p>
          <p>The coordinator process stores the SCCs received from the workers. It then
checks each combination of such markings: if it labels an arc in the
synchronisation graph, the corresponding fused transition is enabled and the marking is
not a deadlock. Otherwise, if the marking is effectively reachable, then it is a
deadlock.
4.3</p>
          <p>Liveness
To verify whether a transition t is live or not, two cases are distinguished: if t
is a fused transition (t ∈ TF ), or t is an internal transition. The verification is
based on the following proposition.</p>
          <p>Proposition 2 (Liveness).
1. A transition tf ∈ TF is live ⇔</p>
          <p>[∀scc ∈ Term(SCCSG) : tf ∈ Trans(scc)]
∧ [∀v ∈ VSG : ∀M ∈ [[vi :(∀s ∈ S : Msc ∈ Term(SCCs))</p>
          <p>⇒ ∃(v, (M1, tf 0), v2) ∈ ASG : M1 ∈ [[M i].
2. A transition t ∈ Ts is live ⇔</p>
          <p>[∀scc ∈ Term(SCCSG) : ∃v ∈ scc : t ∈ Trans([vsis)]
∧ [∀v ∈ VSG : ∀M ∈ [[vi : (Msc ∈ Term(SCCs))</p>
          <p>⇒ (t ∈ T rans(Msc) ∨ ∃(v, (M1, tf ), v2) ∈ ASG : M1 ∈ [[M i))].</p>
          <p>To check if a fused transition tf is live, the coordinator checks if there exists
a terminal SCC in the synchronisation graph which does not contain transition
tf , in which case transition tf is not live. Otherwise, for each node v ∈ VSG
of the synchronisation graph, the coordinator sends vs to the worker process s
and waits to receive the terminal SCCs reachable from vs in module s. Then,
it checks whether the combinations of the terminal SCCs label fused transitions
are in SG, considering only the modules participating in the synchronisation of
this fused transition. If this is not the case, tf is not live.</p>
          <p>When transition t is an internal transition of module s, the worker process s
detects the terminal SCCs which do not enable t, that may invalidate liveness.
For each node v ∈ VSG of the synchronisation graph, the coordinator sends vs
to the worker process s. The worker processes check whether these problematic
SCCs are reachable from vs, and send them to the coordinator. The coordinator
checks if there exists a combination that does not label a fused transition, in
which case transition t is not live.
The verification of whether a reachable state MH is a home state or not is based
on the following proposition.</p>
          <p>Proposition 3 (Home state).</p>
          <p>A state MH ∈ [M0i is a home state ⇔</p>
          <p>[∀scc ∈ Term(SCCSG) : ∃v ∈ scc : MH ∈ [[vi]
∧ [∀v ∈ VSG : ∀M ∈ [[vi : (∀s ∈ S : Msc ∈ Term(SCCs))</p>
          <p>⇒ MH ∈ [[M i ∨ ∃(v, (M1, tf , M2), v2) ∈ ASG : M1 ∈ [[M i].</p>
          <p>To check such a property, we first check whether the state MH is reachable
from all nodes of the synchronisation graph. Then, for every node v of the
synchronisation graph, the coordinator asks the worker processes for the terminal
SCCs reachable from v by firing internal transitions only. The coordinator checks
then that all combinations label an arc, or correspond to the SCC containing
MH . Otherwise MH is not a home state.
5</p>
          <p>Implementation and experiments
The previous algorithms were implemented within a prototype tool. The tests
were carried on a cluster composed of 12 stations (Pentium IV with 512 Mbytes
of memory), one of them is assigned to the coordinator process while the others
run the worker processes.</p>
          <p>In this section, we give the results obtained for the dining philosophers
problem and Automated Guided Vehicles (AGV) problem, and draw conclusions.
5.1</p>
          <p>The dining philosophers problem
The distributed generation based on partitioning the state space over a cluster
of stations, allows for handling large size problems. In [BP07], the philosophers
problem was handled with various sizes (see Table 1).
But this approach is still limited. The total number of exchanged messages
is very high, due to the amount of cross arcs.</p>
          <p>In the distributed modular based approach, the original Petri net is split into
a Modular Petri net with N modules and each module, which can contain m
philosophers, is assigned to a worker process. Philosopher i of module l shares its
forks with the philosophers i − 1 and i + 1 of the same module for 2 ≤ i ≤ m − 1.
Philosophers 1 in module l and m in module (l − 1) mod N + 1 also share a fork.</p>
          <p>The nature of the Petri net gives 4 SCCs in each module graph. The
synchronisation graph size is 2N nodes and N.2N arcs. For a problem with 100
philosophers, if we consider 10 modules with 10 philosophers each, we obtain
1,024 nodes and 10,240 arcs in the synchronisation graph, 233 nodes and 1,132
arcs in each local graph. The reachability graph size for the original problem is
greater than 7 × 1020 nodes and 7 × 1022 arcs.</p>
          <p>In Table 2, we give the modular state space sizes for the philosophers problem
considering 10 philosophers per module each time. The average of CPU times of
the coordinator is also given.</p>
          <p>The CPU time of the workers is generally equal to 0.04 s (for 10 philosophers
per module). Thus, in the first cases the global CPU time corresponds to the
local state space generation, the synchronisation graph generation CPU time is
less then 0.01 s. In the last cases the synchronisation graph generation spends
more time since its size became larger.</p>
          <p>Various tests were performed for reachability, liveness and home state
properties, with the philosophers problem of 10 modules with 10 philosophers in each
one, the experimental results are given in the table 3.</p>
          <p>For reachability, we considered three cases: in the first, the marking is not
reachable in some modules; in the second, the marking is reachable in the
modules but not reachable as a global marking; and in the third case, the marking
is reachable. The number of exchanged messages is the same and correspond to
messages sent by the coordinator to the worker processes to transmit the
marking to check (10 messages) and to the answers of the workers (10 messages).
The liveness and home state verifications are performed with a relatively large
number of exchanged messages: since all transitions are live, the coordinator
must obtain the terminal SCCs reachable from each node of the synchronisation
graph. When the coordinator moves from a node to its successor in the
synchronisation graph, it transmits messages only to the workers corresponding to the
changed components to have their terminal SCCs. This allows for minimising
the number of messages transmitted by the coordinator.</p>
          <p>Automated Guided Vehicles
The Automated Guided Vehicles (AGVs) problem has been solved by means of
Modular State Spaces in [LP04]. The problem is that of a factory floor which
consists of three workstations which operate on parts, two input and one output
stations, and five AGVs which move parts from one station to another.</p>
          <p>The 5 AGVs example is loosely coupled. Therefore, much interleaving is
avoided when building the modular state space and this leads to very good
results. This model has 30,965,760 states (see [LP04]). However, with
modular analysis we obtain only 900 states with 2,687 arcs. The analysis based on
modular distribution gives also good results as shown in table 4.</p>
          <p>CPU Time (sec) Mess Nb
In this paper, we proposed steps towards distributed modular analysis of Petri
net models, based on the construction framework of [LP04]. Using these
algorithms, it is possible to verify standard Petri nets properties, such as reachability,
deadlocks, home states and liveness, in a distributed manner.</p>
          <p>The main advantage of such an approach is the possibility to consider very
large systems with several modules, sharing transitions, and assign them among a
set of machines, thus limiting the drawbacks of the state space explosion problem.</p>
          <p>Each machine (process) generates only the state space of the module it is
assigned. The synchronisation graph provides the global knowledge of the
behaviour of the system.</p>
          <p>Moreover, it is also possible to check properties using the distributed
modular state space directly, i.e. without unfolding to the ordinary state space. When
designing algorithms there is often a trade-off between time and space
complexity. For state space analysis it is attractive to have a rather fast way to decide
properties, but the state space explosion problem makes it absolutely necessary
to minimise memory usage.</p>
          <p>Experiments were performed on a cluster of 12 stations. Both the AGVs,
and the philosophers problems were considered, with different sizes. The results
obtained for the generation of the modular state space were very interesting
and allow for checking properties of very large systems. Future work will
extend properties verification to temporal logic properties. Further experiments
on larger case studies are also necessary for a better assessment of the benefits
of this approach.
Proceedings of CompoNet and SUMo 2011</p>
          <p>80
When Graffiti Brings Order?</p>
          <p>Alban Linard and Didier Buchs
Université de Genève, Centre Universitaire d’Informatique</p>
          <p>7 route de Drize, 1227 Carouge, Suisse
Abstract. Most researchers use Petri nets as a formal notation with
mathematically defined semantics. Their graphical part is usually only
seen as a notation, that does not carry semantics.</p>
          <p>Contrary to this tradition, we show in this article that, when created by a
human, there is inherent semantics in the positions of places, transitions
and arcs. We propose to use the full definition of Petri nets: whereas they
have been deteriorated to their mathematically defined part only, their
graphical information should be considered in their definition.
1
Graphical information of Petri nets usually does not appear in their formal
definitions. For instance, Figure 1 presents the traditional graphical Petri net
representation of two dining philosophers, a textual, and a mathematical
representation of the same Petri net. In research, we almost always consider them as
equivalent. The graphical representation is used by the modeler, or for figures in
articles, the textual representation is an example of input format for a tool, and
the mathematical representation is used for scientific publications.</p>
          <p>
            Are all these representations really equivalent? When we ask researchers in
Petri nets, they often believe it. But their equivalence is only an assumption,
it might thus be false. Why do people strive to maintain layouts in the model
transformation field, for instance in [
            <xref ref-type="bibr" rid="ref1 ref25">1</xref>
            ]? Our doubts for Petri nets are exposed
in Dialogue 1, through a fictional dialogue between two elements of a Petri net:
master transition: Why does graphical information of Petri nets disappear in their
formal definitions?
placehopper: Because graphical information has no semantics.
master transition: If there is no semantics in graphical information, why are Petri
nets represented graphically?
placehopper: Because it helps the modelers to write and understand the models.
master transition: But how does graphical information help the modelers if it has
no semantics?
          </p>
          <p>Dialogue 1: Question of Placehopper</p>
          <p>Throughout this article, we propose to investigate the problem raised by
Master Transition, by extracting semantics from the graphical part of Petri
?Thanks to Matteo Risoldi for proposing this title.
Left0</p>
          <p>Right0
Think0
Eat0
Eat1</p>
          <p>Think1
Fork0</p>
          <p>Right1</p>
          <p>Left1</p>
          <p>Places</p>
          <p>Think0, Think1 = 1
Fork0 , Fork1 = 1
Left0, Right0, Eat0 = 0</p>
          <p>Left1, Right1, Eat1 = 0
Transitions</p>
          <p>Think0 + Fork0 ! Left0</p>
          <p>Think0 + Fork1 ! Right0
Fork1 Left0 + Fork1 ! Eat0</p>
          <p>Right0 + Fork0 ! Eat0
Eat0 ! Fork0 + Fork1 + Think0
Think1 + Fork1 ! Left1
Think1 + Fork0 ! Right1
Left1 + Fork0 ! Eat1
Right1 + Fork1 ! Eat1</p>
          <p>Eat1 ! Fork0 + Fork1 + Think1
PN = hP;TAi</p>
          <p>P =
(Think0;Left0;Right0;Eat0;Fork0)</p>
          <p>Think1;Left1;Right1;Eat1;Fork1
T = (r0;s0;t0;u0;v0)
r1;s1;t1;u1;v1
kT L0 tghR0 taE0 rkoF0 ikhnT1 fteL1 itghR1 taE1 rkoF1
0
ihn fte i
kT L0 tghR0 taE0 rkoF0 ikhnT1 fteL1 itghR1 taE1 rkoF1
0
ihn fte i
Fig.1: Graphical, textual and mathematical representations of a Petri net
nets. This semantics is unclear, as it depends on the modeler and the model.
Thus, we check that the extracted semantics can be useful to improve model
checking performance of the Petri nets.</p>
          <p>Section 2 presents the methodology of this work: how semantics extracted
from the graphical information is used to improve model checking performance.
Then we propose to use alignments of places and transitions in Section 3. As
this only information is not always sufficient to improve model checking
performance, we also propose to use graphical distances in Section 3. Then we propose
in Section 4 to use surfaces delimited by arcs, for models with no alignments.
The approach is generalized to colored Petri nets in Section 5. As we cannot
give semantics to graphical information of all models, two counter-examples are
provided in Section 6. Section 7 discusses about when and how graphical
information can be used, before conclusion in Section 8.
2</p>
          <p>
            How do we assess the quality of semantics extracted
from graphical information?
The Software Modeling and Verification Group has developed the Algebraic
Petri Net Analyzer (AlPiNA) [
            <xref ref-type="bibr" rid="ref2 ref26">2</xref>
            ], a model checker for Algebraic Petri nets.
For efficient state space computation, this tool is based on Decision Diagrams
(DDs) [
            <xref ref-type="bibr" rid="ref27 ref28 ref3 ref4">3,4</xref>
            ]. In this approach, a Decision Diagram, which is a particular kind of
Directed Acyclic Graph, represents the state space. A node in the graph, called
“variable”, represents the marking of each color for each place. When using DDs,
the efficiency highly depends on the variable order in the graph [
            <xref ref-type="bibr" rid="ref29 ref5">5</xref>
            ].
          </p>
          <p>
            By default, AlPiNA has rather good computation times [
            <xref ref-type="bibr" rid="ref30 ref6">6</xref>
            ], but its efficiency
can be improved by orders of magnitude when the user provides “clustering”
information, to group related variables. It is given in a textual notation. For
instance, Listing 1 shows a clustering for the Philosophers model1. Variables for
the black token in places Think0 .. Eat0 are put in the same cluster (group of
variables) c0. The same applies for in Think1 .. Eat1, put in cluster c1.
          </p>
          <p>Clusters c0 , c1 ;
Rules
c l u s t e r o f
in Think0 , Left0 , Right0 , Fork0 , Eat0
i s c0 ;
c l u s t e r o f
in Think1 , Left1 , Right1 , Fork1 , Eat1
i s c1 ;
c0 &lt; c1 ;</p>
          <p>Listing 1: Example of clustering</p>
          <p>
            Several articles already give heuristics to infer variable orders from Petri
nets [
            <xref ref-type="bibr" rid="ref31 ref7">7</xref>
            ]. Clustering is less precise, as it only defines groups of variables, and
1 This is not the exact syntax used in AlPiNA, but a very near one.
groups order. It does not define the order of variables within each group.
However, AlPiNA also allows to define an order over places.
          </p>
          <p>In this article, we propose to use the graphical information of Petri nets to
define the clustering, together with ordering of the variables in the clusters. We
try to group together tokens and places that belong to the same process.</p>
          <p>
            To assess the inferred clustering, we check if it improves the model checker
performances. Instead of using AlPiNA, we use PNXDD [
            <xref ref-type="bibr" rid="ref32 ref8">8</xref>
            ]. It is another Decision
Diagram-based model checker that provides several clustering and ordering
algorithms, contrary to AlPiNA. By using it, we can easily compare our approach
with these algorithms. Because they are simpler, we begin our experiments with
Place/Transition Petri nets and then use a Symmetric Petri net.
          </p>
          <p>All the examples in this article are taken from the Model Checking Contest of
the SUMo 2011 workshop. Choosing models that were not created by our group
allows us to avoid a possible bias that may be introduced if we had too much
knowledge about the models.</p>
          <p>For each model, we compare the efficiency of our graphical clustering and
ordering with fully random ones (500 random clusterings and orderings for each
clustering proposed in this article). This benchmark shows the experimental
probability of obtaining clustering and ordering with the same efficiency. Then
we compare our graphical clustering and ordering with all the algorithms
implemented in PNXDD. It shows how we perform against several existing algorithms.</p>
          <p>
            The results are not intended to show that our approach is more efficient
than other ordering algorithms, for instance those used by [
            <xref ref-type="bibr" rid="ref33 ref9">9</xref>
            ]. We provide them
primarily to assess how much semantics is put in the graphical information of
Petri nets, and also to assess if the semantics we extract makes sense. Therefor,
we propose throughout this article informal ways to extract semantics from the
graphical representation of Petri nets, instead of well defined algorithms.
          </p>
          <p>We provide a VirtualBox image of the tools and scripts used
in the benchmarks at http://smv.unige.ch/members/dr-alban-linard/
sumo2011-when-graffiti-brings-order-image (use login/pass: sumo2011
for the Linux session).
3</p>
          <p>Using alignment of places and transitions
We start the exploration of usual graphical semantics in Petri nets with the
Flexible Manufacturing System (FMS) model. It is a Place/Transition Petri net
represented in Figure 2. Initial marking is not shown as it is irrelevant in our
approach. Note that this model is parameterized by its initial marking. The full
model is presented in the SUMo 2011 workshop.</p>
          <p>Even with absolutely no knowledge of the modeled system, it is obvious
that the PN has vertically aligned places and transitions, linked by arcs in the
alignment. Alignment, either vertical or horizontal, is one usual way for the
modelers to show graphically the processes. Figure 2a shows the four vertical
(a) Aligned places and transitions
(b) With places added to nearest group</p>
          <p>Fig. 2: Flexible Manufacturing System
alignments of places and transitions, and one horizontal alignment. Thus,
maximal non-overlapping chains of consecutive and aligned places and transitions
define groups. All the places of each group can be put in a same cluster. From
this example, we can state Assumption 1:
Assumption 1 Aligned places and transitions may correspond to a process.
3.2 Alignment with graphical distance</p>
          <p>After applying Assumption 1, some places do not belong to any group.
Usually, the modelers use them either to represent shared data or for local data.
In Figure 2a, the horizontal alignment shows a shared data. The remaining
marked places are each near the middle of a cluster, and thus are likely to
represent local data. On the contrary, the remaining unmarked places are found at
the extremity of the clusters, and thus they can either represent the processes or
local data. So, after defining the groups, we extend them using Assumption 2:
Assumption 2 Local data of a process is more likely to be near its process.</p>
          <p>Figure 2b shows the result of application of Assumption 2 to the groups
of Figure 2a. Each place is added to the nearest group it is related to, where
nearest means graphical distance. For instance, the unmarked places are added
to the vertical groups instead of the horizontal one, because they are linked to
transitions aligned with the vertical clusters.</p>
          <p>We also define ordering of the places inside the clusters and ordering of the
clusters. Inside each cluster, the places are ordered from top to bottom or from
left to right. The local data places are put randomly before or after the nearest
process place. To order the clusters, we also chose graphical distance. In the FMS
model, and are next to each other. is far from all other
clusters, but its nearest neighbor is . As is between and
, we get the following order for the clusters:
&lt;
&lt;
&lt;
&lt;</p>
          <p>
            The results of the benchmarks for the FMS 50, i.e., with initial marking
parameter set to 50. All random clusters and orders were too slow, and thus could
not finish computation. Graphical clustering and ordering gives better results
than all algorithms implemented in PNXDD. We give only the number of the
algorithm, instead of its name, for a concise diagram. The corresponding algorithm
names are found in [
            <xref ref-type="bibr" rid="ref33 ref9">9</xref>
            ] and in the documentation of the tool [
            <xref ref-type="bibr" rid="ref32 ref8">8</xref>
            ].
0
4
Using surfaces
state space generation time (linear scale)
Unlike the fms model, the kanban model shown in Figure 3 contains almost no
alignments. The modeler has used different graphical semantics for this model.
          </p>
          <p>For the human eye, the kanban model is composed of four components, each
one with four places. All components have rather similar shapes. They differ by
some arcs and also by a symmetry. Detecting these small differences is not a
trivial task.</p>
          <p>The components are visible because the arcs draw the shapes of the
components. For instance, the modeler used arcs with two inflexion points where he
could have drawn a direct arc. From this example, we can deduce Assumption 3:
Assumption 3 Arcs may draw shapes, the surface of which may contain related
places.</p>
          <p>We investigate different ways to use the shapes. First, Figure 3a identifies
three different components in the model. Each one is found by searching maximal
surfaces in the graphical Petri net. When two surfaces are linked by a place, they
are merged, as one place can only belong to one cluster.</p>
          <p>The maximal surfaces approach can lead to huge clusters. The worst case
is when the whole Petri net is enclosed by arcs, and thus all its places are in
the same cluster. We thus propose a second way to search surfaces. Instead of
identifying maximal surfaces, we can use minimal surfaces. They are defined
(a) Maximal surfaces
(b) Minimal surfaces
(c) Minimal connected surfaces
with nearest remaining places</p>
          <p>Fig. 3: Kanban System
as the surfaces that do not enclose another surface. Figures 3b and 3c show the
Kanban model with minimal surfaces. In Figure 3b, the choice of minimal surfaces
to consider leads to four clusters, whereas in Figure 3c another choice leads to
three clusters. As the surfaces that touch the same place must be merged, we
have to choose either Figure 3b or Figure 3c. Otherwise, the three surfaces in the
middle block are merged, and the clustering is equivalent to the one of Figure 3a.</p>
          <p>We compare Figure 3a and Figure 3b in the benchmarks. Places are ordered
inside the clusters by following the boundaries of minimal surfaces. Clusters are
ordered by graphical proximity, giving the clusters below:
&lt;
&lt;</p>
          <p>&lt;
&lt;
&lt;
(Figure 3a)
(Figure 3b)</p>
          <p>The results of the benchmarks for the Kanban model are given below. All
random clusters and orders were again too slow, and thus could not finish
computation. The same applies to some algorithms of PNXDD (1,2,6,12,21). Whereas
graphical clustering shows a small improvement over existing algorithms for the
FMS model, it gives here huge improvements over algorithms in PNXDD.</p>
          <p>Extension to colored Petri nets
The Shared Memory model of the SUMo 2011 workshop is given in Figure 4.
It is a Symmetric Petri net, which is a particular kind of colored Petri net. Of
course, our approach can be extended to the unfolded Place/Transition Petri net
equivalent to a colored Petri net, when this equivalence exists. But the unfolding
must then generate positions (possibly in three or more dimensions) to avoid
superposition of unfolded places and transitions.</p>
          <p>Without unfolding, we can still in some cases use graphical information to
define clusters. Clusters for colored Petri nets are groups of unfolded places, i.e.,
places together with colors. Two policies can coexist:
– Grouping in the same cluster all colors for one place,
– Distributing in its own cluster each color for one place.</p>
          <p>The first policy works usually well for places representing shared data, whereas
the second one leads usually to good results for places representing processes or
data local to a process. Assumptions 4 and 5 describe these two policies.
Assumption 4 One place related to other places using different variables may
represent a shared data.</p>
          <p>Assumption 5 Several places related to each other using the same variable, or
equal ones, may represent a process.</p>
          <p>In the Shared Memory model, both Assumption 1 and Assumption 3 can be
applied, as we find both aligned places and transitions and surfaces.
5.1 Using surfaces</p>
          <p>To consider surfaces, we use Assumption 3. Its clustering is given in Figure 4a.
We divided the model in four minimal surfaces. As there are places common to
several surfaces, we obtain two groups. All places (a; b; c; e) in the group
have the same domain, except one (e) that is not colored (shown using ).
We create one cluster for each color 1 , 2 , 3 , or 4 , as shown in Listing 2. Place e
can only belong to one cluster, as its domain is the black token . Thus, we also
create its own separate cluster.</p>
          <p>Clusters c , c1 , c2 , c3 , c4 ;
Rules
c l u s t e r o f in e i s c ;
c l u s t e r o f 1 in a; b; c i s c1 ;
c l u s t e r o f 2 in a; b; c i s c2 ;
c l u s t e r o f 3 in a; b; c i s c3 ;
c l u s t e r o f 4 in a; b; c i s c4 ;</p>
          <p>Listing 2: Clustering using surfaces for places a; b; c; e</p>
          <p>The group contains two places: d and f . Place f has domain
f 1 ; 2 ; 3 ; 4 g, whereas the domain of the place d is a couple of colors. For each
color, we create one cluster. Listing 3 completes Listing 2 with the new clusters.
(a) Minimal surfaces and Identity, with nearest Identity
y
y
x
c
x
x 6= m x; m</p>
          <p>x; y
c
x
x x 6= m x; m</p>
          <p>x; y
m
m
m
m
m
m
x
x
1 2
3 4
1 2
3 4
f
d
e
f
d
e
(b) Alignment and Identity, with nearest Identity</p>
          <p>Fig. 4: Shared Memory
Each token in place f is put in the cluster of its color. In place d, each token is
a couple of colors. We have to choose which component of the couple
predominates. Here, there is no obvious choice, so we choose the first element. Thus all
tokens in place d are put in the cluster of the color of the first component.</p>
          <p>Clusters d1 , d2 , d3 , d4 ;
Rules
c l u s t e r of 1 in f i s d1 ;
c l u s t e r of 2 in f i s d2 ;
c l u s t e r of 3 in f i s d3 ;
c l u s t e r of 4 in f i s d4 ;
c l u s t e r of f 1 g f 1 , 2 , 3 , 4 g in d i s d1 ;
c l u s t e r of f 2 g f 1 , 2 , 3 , 4 g in d i s d2 ;
c l u s t e r of f 3 g f 1 , 2 , 3 , 4 g in d i s d3 ;
c l u s t e r of f 4 g f 1 , 2 , 3 , 4 g in d i s d4 ;
c &lt; c1 &lt; d1 &lt; c2 &lt; d2 &lt; c3 &lt; d3 &lt; c4 &lt; d4 ;</p>
          <p>Listing 3: Clustering using surfaces for places d; f
5.2</p>
          <p>Using alignments</p>
          <p>Using Assumption 1 gives a totally different result. It is shown in Figure 4b.
Listing 4 shows the clustering obtained using Assumption 1.</p>
          <p>We first identify aligned places and transitions: places b; c; d belong to one
group. Places b and c have the same colored domain, whereas the tokens of
place d are couples of colors.</p>
          <p>We then try to add to the group what seems local data or part of the
processes. All places a; f; e are near the group. Place a is linked to the group using
only variable x. This clearly shows that an identity is passed along the arcs. So,
this place is added to the group.</p>
          <p>Place e contains black tokens. Because of this domain, it cannot be added in
the clusters of colors, so we create its own cluster, as in Listing 2.</p>
          <p>The last place is f . The variables that relate this place to d are used in the
second part of the couple, whereas the variables that relate d to the places in
its group are in the first part. So, f probably represents a shared data. We thus
put place f in its own cluster, for all colors.</p>
          <p>Clusters c , c1 , c2 , c3 , c4 , f;
Rules
c l u s t e r of in e i s c;
c l u s t e r of 1 in a; b; c i s c1 ;
c l u s t e r of 2 in a; b; c i s c2 ;
c l u s t e r of 3 in a; b; c i s c3 ;
c l u s t e r of 4 in a; b; c i s c4 ;
c l u s t e r of 1 in f i s f;
c l u s t e r of 2 in f i s f;
c l u s t e r of 3 in f i s f;
c l u s t e r of 4 in f i s f;
c l u s t e r of f 1 g f 1 , 2 , 3 , 4 g in d i s c1 ;
c l u s t e r of f 2 g f 1 , 2 , 3 , 4 g in d i s c2 ;
c l u s t e r of f 3 g f 1 , 2 , 3 , 4 g in d i s c3 ;
c l u s t e r of f 4 g f 1 , 2 , 3 , 4 g in d i s c4 ;
c &lt; c1 &lt; c2 &lt; c3 &lt; c4 &lt; f;</p>
          <p>Listing 4: Clustering using alignment</p>
          <p>Figure 4b shows the result of this analysis. Note that for each color 1 , 2 , 3 ,
or 4 , we create a cluster that contains all the highlighted places for this color
only. For place d, each cluster contains all possible colors for the second part of
the Cartesian product.</p>
          <p>We compare both clusterings below. For this third model, the state space
generation could not finish using some algorithms of PNXDD (2,12,21). Graphical
clustering and ordering is still better than all algorithms implemented in PNXDD.
As for other models, none of the random clusterings could finish.
il()rca4gaphb il()rcga4aaph )(6xnpdd ()1xpndd ,()811xpndd )(13xpndd
random
pnxdd(2,12,21)
0
state space generation time (linear scale)</p>
          <p>When we fail at understanding the model
The Model Checking Contest of SUMo 2011 workshop uses seven models, three of
which are Place/Transition Petri nets and the four others Symmetric Petri nets.
In this article, we provide clustering for Flexible Manufacturing System, Kanban
and Shared Memory. Two models are not discussed: Philosophers and Token Ring.
The Philosophers model has been studied a lot for use with Decision Diagrams.
Before writing this article, we already knew that the best order is when each
philosopher and its left (or right) fork is put in its own cluster. Because of this
knowledge, trying to find graphical information would be biased. The Token Ring
model does not contain enough places (1) and transitions (2).</p>
          <p>The two remaining models are MAPK (Figure 5) and Peterson’s algorithm
(Figure 6). For them, we did not find how to give semantics to the graphical
information. Note that these two models are considered as hard to understand
by humans. This might be an explanation: because their modelers could not
find a good disposition of places and transitions, we cannot give semantics to
graphical information, and thus the models are hard to understand.
7</p>
          <p>Discussion on the approach
We propose in this article to extract semantics from the graphical part of a Petri
net. It works on some models, but does not work on some others. Moreover,
all people do not always agree on how to identify the processes in the Petri
net. This approach is thus fragile. We provide in this section some remarks on
its applicability, and on other techniques that could be used along graphical
information to improve clustering.</p>
          <p>This approach depends on the school of modeling.</p>
          <p>Depending on where we have studied, and where we work, we may not create
models in the same way. The most obvious difference is putting aligned processes
horizontally or vertically. But some people can also prefer to show processes using
surfaces instead of alignments. We should investigate which representations are
used, and where they are modeled.</p>
          <p>
            A side effect is that every Petri net should define an author and the
institutes where the author has studied and workse Using this information, giving
semantics to graphical information could be enhanced. The “author” field is
already present in the Petri Net Markup Language [
            <xref ref-type="bibr" rid="ref10 ref34">10</xref>
            ], but there is currently no
traceability of the author’s institutions, nor of the school of modeling for this
Petri net.
          </p>
          <p>Graphical information cannot be processed easily</p>
          <p>
            The Petri Net Markup Language handles absolute positions for the Petri net
elements (places, transitions, labels. . . ). The problem with absolute positioning
is that analysis of the graphical information is not easy. Some other positioning
schemes exist. For instance, TikZ [
            <xref ref-type="bibr" rid="ref11 ref35">11</xref>
            ] provides a way to define a position relative
to another one (above, below, . . . ). Such positions can be processed more easily.
7.3
          </p>
          <p>Labels can also be used to detect components.</p>
          <p>We use only graphical information on Place/Transition Petri nets in this
article. For Symmetric Petri nets, we also use domains and variables on the arcs.
Another interesting information to compute clustering is the labels of places
and transitions. In Place/Transition Petri nets, they are often composed of a
textual prefix, a textual suffix, and some numbers in the middle. These numbers
correspond to colors in an equivalent colored Petri nets. Extracting the naming
patterns of places can greatly enhance the clustering.</p>
          <p>This approach may be redundant with graph analysis.</p>
          <p>
            Ordering the Decision Diagrams used during the model checking of a Petri
net has been explored for a long time. We can cite again [
            <xref ref-type="bibr" rid="ref31 ref7">7</xref>
            ], which is a survey
of existing algorithms.
          </p>
          <p>Instead of using the graphical information, they are usually based on the
graph structure of the Petri net. These techniques, from the structural analysis
field, can lead to very good results. Note that combining them with graphical
information and naming analysis is often possible.</p>
          <p>
            First, traps and siphons [
            <xref ref-type="bibr" rid="ref12 ref36">12</xref>
            ] are a way to detect components, and thus
clusters. They can be computed efficiently, for instance in [
            <xref ref-type="bibr" rid="ref13 ref37">13</xref>
            ]. Invariants are another
way to define clusters, but they show both processes and data. A good point is
that they can even be computed in colored Petri net [
            <xref ref-type="bibr" rid="ref14 ref38">14</xref>
            ].
8
Throughout this article, we show Petri nets from the Model Checking Contest
of SUMo 2011 workshop. For each one, we try to understand how their modelers
put semantics in their graphical information. Whereas we cannot identify such
information in some models (MAPK and Peterson’s algorithm), it provides really
good results for the others.
          </p>
          <p>We extract semantics from several kinds of graphical information: the
alignment of places and transition, the graphical proximity of places and groups, and
the surfaces delimited by arcs. This semantics is used to define clustering and
ordering of the places and tokens.</p>
          <p>For all these examples, we use the graphical information to improve symbolic
model checking of the Petri net. To do so, we extract clustering and ordering
from the graphical part of each model. Using them, we compare the time taken to
generate the state space with several clustering and ordering algorithms
implemented in PNXDD, and with fully random clusters and orders. In all models where
graphical clustering could be defined, we obtain improvements over PNXDD. No
random clusters and orders could run in the time and memory limits, which
shows that the semantics extracted from graphical information makes sense.</p>
          <p>At the beginning of this work, we were only hoping to obtain improvements
over some of the algorithms in PNXDD. Prior the benchmarks, we did no selection
of the models, and of the inferred graphical semantics. Thus, the good results
seem promising.</p>
          <p>From these examples, two conclusions arise: (1) in education, Petri nets are
always introduced as a graphical formalism. In research, they have been
deteriorated into a mathematical only formalism, by losing graphical information; (2)
graphical information in Petri nets has semantics, but unclear one.</p>
          <p>We believe that, contrary to their usual presentation in scientific publications,
Petri nets are truly a graphical formalism, and their mathematical representation
is only a projection.</p>
          <p>Further work should identify more graphical semantics, and the cases in
which they apply. We may not be able to create algorithms to extract always
semantics from graphical information. But when it is possible, a study with fully
automatic algorithms should check that the inferred semantics can be used with
no user knowledge of the models.</p>
          <p>References</p>
          <p>K 9 K
ER 1k R 1</p>
          <p>E 2</p>
          <p>k
6
3
e
s
a 6
h
P</p>
          <p>P
K
R
E
8
2
k
P
P
K
E
M
6
1
k
2
e
s 3
a 1
h k
P
4</p>
          <p>K
5
2 R 6
k E 2</p>
          <p>k
K 0
R 3</p>
          <p>k
E
3
e
s
a
h
P
_
P
P
3
e
s
a
h
P
_
P
P
P
K
E
M
_</p>
          <p>4
2 1
se k
a
h
P
_
P
P
K
E
M
2
e 7
M
8
1
k
7
2
k
9
2
k
0
2
k
5
1
k
2
2
k
4
2
k</p>
          <p>P
P
K
R
E</p>
          <p>P
P
K
E
M
_
P
K
R
E
3
2
k
P
f 9
a k
R
_</p>
          <p>K
7 E
k M</p>
          <p>P
K
E 0</p>
          <p>1
M k
8
k
1
e
s
a 6
h
P 4</p>
          <p>k
P 1</p>
          <p>k
T
sG 2
a
2
1
k
1
1
k
P
f
a
R
1
e
s
a
h
P
_
P
f
a
R
T
G
s
a</p>
          <p>P
f
a
R
_
P
K
E
M
6
k
f
a 2
R k
R
_ 3
fa k
R
e
d
a
k
s
a
k
e
s
a
n
i
k
n
i
e
t
o
r
p
d
e
t
a
v
i
t
c
a
n
e
g
o
t
i
g
i</p>
          <p>F
CLASS
Process is 0..N;
Tour is 0..N-1;
Bool is [T, F];
DOMAIN
ProcTour is &lt;Process, Tour&gt;;
TourProc is &lt;Tour, Process&gt;;
ProcTourProc is &lt;Process, Tour, Process&gt;;
ProcBool is &lt;Process, Bool&gt;;
VAR
i in Process;
k in Process;
j in Tour;
WantSection
&lt;Process.all, F&gt;</p>
          <p>ProcBool
&lt;i, T&gt;</p>
          <p>&lt;i, F&gt;
&lt;i, j&gt;</p>
          <p>&lt;i, j, k&gt;
ContinueLoop
&lt;i, 0&gt;</p>
          <p>Process
Ask
&lt;i, j&gt;
UpdateTurn
&lt;i, j&gt;</p>
          <p>TestTurn</p>
          <p>ProcTour
&lt;j, i&gt;
&lt;j, i&gt;
&lt;j, i&gt;
&lt;j, k&gt;</p>
          <p>Turn
TourProc
&lt;Tour.all, 0&gt;
TurnDiff</p>
          <p>&lt;i, j&gt;
[i&lt;&gt;k]</p>
          <p>&lt;i, j&gt;
&lt;i, j&gt;
ProgressTurn</p>
          <p>AccessCS
CS</p>
          <p>Process</p>
          <p>EndLoop
&lt;Process.all&gt;
AskForSection
ProcTour</p>
          <p>&lt;i, j&gt;
&lt;i, j, 0&gt;
TurnEqual</p>
          <p>BeginLoop
ProcTourProc
&lt;i, j , i&gt;
Identity</p>
          <p>&lt;i, j , i&gt;
&lt;i, j ,k&gt;
&lt;i, j, k++1&gt;
&lt;i, j, k&gt;
&lt;i, j++1&gt;</p>
          <p>&lt;i, j&gt;
Loop
[k &lt;&gt; N]
&lt;i, j, N&gt;
&lt;i, T&gt;</p>
          <p>&lt;i, F&gt;</p>
          <p>Fig. 6: Peterson’s algorithm
Author Index</p>
          <p>B
D
F
K
L
P
R
T</p>
          <p>Bashkin, Vladimir A.</p>
          <p>Berard, Beatrice
Ben Salem, Ala Eddine
Boukala, Mohand Cherif
Buchs, Didier
Duret-Lutz, Alexandre
Fronc, Lukasz
Kordon, Fabrice
Lime, Didier
Linard, Alban
Petrucci, Laure
Pommereau, Franck
Roux, Olivier H.</p>
          <p>Thierry-Mieg, Yann
33
17
65
1
81
1
49</p>
        </sec>
      </sec>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          1.
          <string-name>
            <given-names>G.</given-names>
            <surname>Ciardo</surname>
          </string-name>
          , G. Lüttgen, and
          <string-name>
            <given-names>R.</given-names>
            <surname>Siminiceanu</surname>
          </string-name>
          .
          <article-title>Efficient symbolic state-space construction for asynchronous systems</article-title>
          .
          <source>In Proc. of ICATPN'00</source>
          , vol.
          <source>1825 of LNCS</source>
          , pp.
          <fpage>103</fpage>
          -
          <lpage>122</lpage>
          . Springer.
        </mixed-citation>
      </ref>
      <ref id="ref2">
        <mixed-citation>
          2. J. Cichon´,
          <string-name>
            <given-names>A.</given-names>
            <surname>Czubak</surname>
          </string-name>
          ,
          <article-title>and</article-title>
          <string-name>
            <given-names>A.</given-names>
            <surname>Jasin</surname>
          </string-name>
          <article-title>´ski. Minimal Büchi automata for certain classes of LTL formulas</article-title>
          .
          <source>In Proc. of DEPCOS'09</source>
          , pp.
          <fpage>17</fpage>
          -
          <lpage>24</lpage>
          . IEEE Computer Society.
        </mixed-citation>
      </ref>
      <ref id="ref3">
        <mixed-citation>
          3.
          <string-name>
            <surname>J.-M. Couvreur</surname>
          </string-name>
          .
          <article-title>On-the-fly verification of temporal logic</article-title>
          .
          <source>In Proc. of FM'99</source>
          , vol.
          <volume>1708</volume>
          of LNCS, pp.
          <fpage>253</fpage>
          -
          <lpage>271</lpage>
          . Springer.
        </mixed-citation>
      </ref>
      <ref id="ref4">
        <mixed-citation>
          4.
          <string-name>
            <surname>J.-M. Couvreur</surname>
          </string-name>
          .
          <article-title>Un point de vue symbolique sur la logique temporelle linéaire</article-title>
          .
          <source>In Actes du Colloque LaCIM</source>
          <year>2000</year>
          , vol.
          <volume>27</volume>
          of Publications du LaCIM, pp.
          <fpage>131</fpage>
          -
          <lpage>140</lpage>
          . Université du Québec à Montréal, Aug.
          <year>2000</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref5">
        <mixed-citation>
          5.
          <string-name>
            <surname>J.-M. Couvreur</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          <string-name>
            <surname>Duret-Lutz</surname>
            , and
            <given-names>D.</given-names>
          </string-name>
          <string-name>
            <surname>Poitrenaud</surname>
          </string-name>
          .
          <article-title>On-the-fly emptiness checks for generalized Büchi automata</article-title>
          .
          <source>In Proc. of SPIN'05</source>
          , vol.
          <volume>3639</volume>
          of LNCS, pp.
          <fpage>143</fpage>
          -
          <lpage>158</lpage>
          . Springer.
        </mixed-citation>
      </ref>
      <ref id="ref6">
        <mixed-citation>
          6.
          <string-name>
            <given-names>J.</given-names>
            <surname>Dallien</surname>
          </string-name>
          and W. MacCaull.
          <article-title>Automated recognition of stutter-invariant LTL formulas</article-title>
          .
          <source>Atlantic Electronic Journal of Mathematics</source>
          , (
          <volume>1</volume>
          ):
          <fpage>56</fpage>
          -
          <lpage>74</lpage>
          ,
          <year>2006</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref7">
        <mixed-citation>
          7.
          <string-name>
            <given-names>A.</given-names>
            <surname>Duret-Lutz</surname>
          </string-name>
          and
          <string-name>
            <given-names>D.</given-names>
            <surname>Poitrenaud</surname>
          </string-name>
          .
          <article-title>SPOT: an extensible model checking library using transition-based generalized Büchi automata</article-title>
          .
          <source>In Proc. of MASCOTS'04</source>
          , pp.
          <fpage>76</fpage>
          -
          <lpage>83</lpage>
          . IEEE Computer Society Press.
        </mixed-citation>
      </ref>
      <ref id="ref8">
        <mixed-citation>
          8.
          <string-name>
            <given-names>J.</given-names>
            <surname>Geldenhuys</surname>
          </string-name>
          and
          <string-name>
            <given-names>H.</given-names>
            <surname>Hansen</surname>
          </string-name>
          .
          <article-title>Larger automata and less work for LTL model checking</article-title>
          .
          <source>In Proc. of SPIN'06</source>
          , vol.
          <volume>3925</volume>
          of LNCS, pp.
          <fpage>53</fpage>
          -
          <lpage>70</lpage>
          . Springer.
        </mixed-citation>
      </ref>
      <ref id="ref9">
        <mixed-citation>
          9.
          <string-name>
            <given-names>J.</given-names>
            <surname>Geldenhuys</surname>
          </string-name>
          and
          <string-name>
            <given-names>A.</given-names>
            <surname>Valmari</surname>
          </string-name>
          .
          <article-title>Tarjan's algorithm makes on-the-fly LTL verification more efficient</article-title>
          .
          <source>In Proc. of TACAS'04</source>
          , vol.
          <volume>2988</volume>
          of LNCS, pp.
          <fpage>205</fpage>
          -
          <lpage>219</lpage>
          . Springer.
        </mixed-citation>
      </ref>
      <ref id="ref10">
        <mixed-citation>
          10.
          <string-name>
            <given-names>D.</given-names>
            <surname>Giannakopoulou</surname>
          </string-name>
          and
          <string-name>
            <given-names>F.</given-names>
            <surname>Lerda</surname>
          </string-name>
          .
          <article-title>From states to transitions: Improving translation of LTL formulae to Büchi automata</article-title>
          .
          <source>In Proc. of FORTE'02</source>
          , vol.
          <volume>2529</volume>
          of LNCS, pp.
          <fpage>308</fpage>
          -
          <lpage>326</lpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref11">
        <mixed-citation>
          11. H.
          <string-name>
            <surname>Hansen</surname>
            ,
            <given-names>W.</given-names>
          </string-name>
          <string-name>
            <surname>Penczek</surname>
          </string-name>
          ,
          <article-title>and</article-title>
          <string-name>
            <given-names>A.</given-names>
            <surname>Valmari</surname>
          </string-name>
          .
          <article-title>Stuttering-insensitive automata for on-the-fly detection of livelock properties</article-title>
          .
          <source>In Proc. of FMICS'02</source>
          , vol.
          <volume>66</volume>
          (
          <issue>2</issue>
          ) of Electronic Notes in Theoretical Computer Science. Elsevier.
        </mixed-citation>
      </ref>
      <ref id="ref12">
        <mixed-citation>
          12.
          <string-name>
            <surname>M. Heiner</surname>
            ,
            <given-names>D.</given-names>
          </string-name>
          <string-name>
            <surname>Gilbert</surname>
            , and
            <given-names>R.</given-names>
          </string-name>
          <string-name>
            <surname>Donaldson</surname>
          </string-name>
          .
          <article-title>Petri nets for systems and synthetic biology</article-title>
          .
          <source>In Proc. of SFM'08</source>
          , vol.
          <volume>5016</volume>
          of LNCS, pp.
          <fpage>215</fpage>
          -
          <lpage>264</lpage>
          . Springer.
        </mixed-citation>
      </ref>
      <ref id="ref13">
        <mixed-citation>
          13.
          <string-name>
            <surname>J. Hugues</surname>
            ,
            <given-names>Y.</given-names>
          </string-name>
          <string-name>
            <surname>Thierry-Mieg</surname>
            ,
            <given-names>F.</given-names>
          </string-name>
          <string-name>
            <surname>Kordon</surname>
            ,
            <given-names>L.</given-names>
          </string-name>
          <string-name>
            <surname>Pautet</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          <string-name>
            <surname>Barrir</surname>
            , and
            <given-names>T.</given-names>
          </string-name>
          <string-name>
            <surname>Vergnaud</surname>
          </string-name>
          .
          <article-title>On the formal verification of middleware behavioral properties</article-title>
          .
          <source>In Proc. of FMICS'04</source>
          , vol.
          <volume>133</volume>
          of Electronic Notes in Theoretical Computer Science, pp.
          <fpage>139</fpage>
          -
          <lpage>157</lpage>
          . Elsevier.
        </mixed-citation>
      </ref>
      <ref id="ref14">
        <mixed-citation>
          14.
          <string-name>
            <given-names>C.</given-names>
            <surname>Löding</surname>
          </string-name>
          .
          <article-title>Efficient minimization of deterministic weak w-automata</article-title>
          .
          <source>Information Processing Letters</source>
          ,
          <volume>79</volume>
          (
          <issue>3</issue>
          ):
          <fpage>105</fpage>
          -
          <lpage>109</lpage>
          ,
          <year>2001</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref15">
        <mixed-citation>
          15.
          <string-name>
            <given-names>S.</given-names>
            <surname>Miyano</surname>
          </string-name>
          and
          <string-name>
            <given-names>T.</given-names>
            <surname>Hayashi</surname>
          </string-name>
          .
          <article-title>Alternating finite automata on w-words</article-title>
          .
          <source>Theoretical Computer Science</source>
          ,
          <volume>32</volume>
          :
          <fpage>321</fpage>
          -
          <lpage>330</lpage>
          ,
          <year>1984</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref16">
        <mixed-citation>
          16. MoVe/LRDE. The Spot home page: http://spot.lip6.fr,
          <year>2011</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref17">
        <mixed-citation>
          17.
          <string-name>
            <given-names>R.</given-names>
            <surname>Pelánek</surname>
          </string-name>
          .
          <article-title>Properties of state spaces and their applications</article-title>
          .
          <source>International Journal on Software Tools for Technology Transfer (STTT)</source>
          ,
          <volume>10</volume>
          (
          <issue>5</issue>
          ):
          <fpage>443</fpage>
          -
          <lpage>454</lpage>
          ,
          <year>2008</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref18">
        <mixed-citation>
          18. I. Pyarali,
          <string-name>
            <given-names>M.</given-names>
            <surname>Spivak</surname>
          </string-name>
          ,
          <string-name>
            <given-names>R.</given-names>
            <surname>Cytron</surname>
          </string-name>
          , and
          <string-name>
            <given-names>D. C.</given-names>
            <surname>Schmidt</surname>
          </string-name>
          .
          <article-title>Evaluating and optimizing thread pool strategies for RT-CORBA</article-title>
          .
          <source>In Proc. of LCTES'00</source>
          , pp.
          <fpage>214</fpage>
          -
          <lpage>222</lpage>
          . ACM.
        </mixed-citation>
      </ref>
      <ref id="ref19">
        <mixed-citation>
          19.
          <string-name>
            <surname>K. Y. Rozier</surname>
            and
            <given-names>M. Y.</given-names>
          </string-name>
          <string-name>
            <surname>Vardi</surname>
          </string-name>
          .
          <article-title>LTL satisfiability checking</article-title>
          .
          <source>In Proc. of SPIN'07</source>
          , vol.
          <volume>4595</volume>
          of LNCS, pp.
          <fpage>149</fpage>
          -
          <lpage>167</lpage>
          . Springer.
        </mixed-citation>
      </ref>
      <ref id="ref20">
        <mixed-citation>
          20.
          <string-name>
            <given-names>S.</given-names>
            <surname>Schwoon</surname>
          </string-name>
          and
          <string-name>
            <given-names>J.</given-names>
            <surname>Esparza</surname>
          </string-name>
          .
          <article-title>A note on on-the-fly verification algorithms</article-title>
          .
          <source>In Proc. of TACAS'05</source>
          , vol.
          <volume>3440</volume>
          of LNCS. Springer.
        </mixed-citation>
      </ref>
      <ref id="ref21">
        <mixed-citation>
          21.
          <string-name>
            <given-names>R.</given-names>
            <surname>Sebastiani</surname>
          </string-name>
          and
          <string-name>
            <given-names>S.</given-names>
            <surname>Tonetta</surname>
          </string-name>
          .
          <article-title>"more deterministic" vs. "smaller" Büchi automata for efficient LTL model checking</article-title>
          .
          <source>In Proc. of CHARME'03</source>
          , vol.
          <volume>2860</volume>
          of LNCS, pp.
          <fpage>126</fpage>
          -
          <lpage>140</lpage>
          . Springer.
        </mixed-citation>
      </ref>
      <ref id="ref22">
        <mixed-citation>
          22.
          <string-name>
            <given-names>H.</given-names>
            <surname>Tauriainen</surname>
          </string-name>
          . Automata and
          <article-title>Linear Temporal Logic: Translation with Transition-based Acceptance</article-title>
          .
          <source>PhD thesis</source>
          , Helsinki University of Technology, Espoo, Finland, Sept.
          <year>2006</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref23">
        <mixed-citation>
          23.
          <string-name>
            <given-names>M. Y.</given-names>
            <surname>Vardi</surname>
          </string-name>
          .
          <article-title>An automata-theoretic approach to linear temporal logic</article-title>
          .
          <source>In Proc. of Banff '94</source>
          , vol.
          <volume>1043</volume>
          of LNCS, pp.
          <fpage>238</fpage>
          -
          <lpage>266</lpage>
          . Springer.
        </mixed-citation>
      </ref>
      <ref id="ref24">
        <mixed-citation>
          <article-title>0 state space generation time (linear scale)</article-title>
        </mixed-citation>
      </ref>
      <ref id="ref25">
        <mixed-citation>
          1.
          <string-name>
            <surname>Sun</surname>
            ,
            <given-names>Y.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Gray</surname>
            ,
            <given-names>J.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Langer</surname>
            ,
            <given-names>P.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Wimmer</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>White</surname>
            ,
            <given-names>J.:</given-names>
          </string-name>
          <article-title>A WYSIWYG Approach for Configuring Model Layout using Model Transformations</article-title>
          . In: DSM'10: Workshop on Domain-Specific Modeling @ Splash. (
          <year>2010</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref26">
        <mixed-citation>
          2. SMV Group:
          <article-title>Algebraic Petri Nets Analyzer (</article-title>
          <year>2010</year>
          ) http://alpina.unige.ch.
        </mixed-citation>
      </ref>
      <ref id="ref27">
        <mixed-citation>
          3.
          <string-name>
            <surname>Bryant</surname>
          </string-name>
          , R.E.:
          <article-title>Graph-Based Algorithms for Boolean Function Manipulation</article-title>
          .
          <source>IEEE Transactions on Computers</source>
          <volume>35</volume>
          (
          <issue>8</issue>
          ) (
          <year>1986</year>
          )
          <fpage>677</fpage>
          -
          <lpage>691</lpage>
        </mixed-citation>
      </ref>
      <ref id="ref28">
        <mixed-citation>
          4.
          <string-name>
            <surname>Couvreur</surname>
            ,
            <given-names>J.M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Encrenaz</surname>
            ,
            <given-names>E.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Paviot-Adet</surname>
            ,
            <given-names>E.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Poitrenaud</surname>
            ,
            <given-names>D.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Wacrenier</surname>
            ,
            <given-names>P.A.</given-names>
          </string-name>
          :
          <article-title>Data Decision Diagrams for Petri Net analysis</article-title>
          .
          <source>In: ICATPN '02: 23rd International Conference on Applications and Theory of Petri Nets</source>
          . (
          <year>2002</year>
          )
          <fpage>101</fpage>
          -
          <lpage>120</lpage>
        </mixed-citation>
      </ref>
      <ref id="ref29">
        <mixed-citation>
          5.
          <string-name>
            <surname>Bollig</surname>
            ,
            <given-names>B.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Wegener</surname>
            ,
            <given-names>I.</given-names>
          </string-name>
          :
          <article-title>Improving the variable ordering of obdds is np-complete</article-title>
          .
          <source>IEEE Transactions on Computers</source>
          <volume>45</volume>
          (
          <issue>9</issue>
          ) (
          <year>1996</year>
          )
          <fpage>993</fpage>
          -
          <lpage>1002</lpage>
        </mixed-citation>
      </ref>
      <ref id="ref30">
        <mixed-citation>
          6.
          <string-name>
            <surname>Buchs</surname>
            ,
            <given-names>D.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Hostettler</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Marechal</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Risoldi</surname>
            ,
            <given-names>M.:</given-names>
          </string-name>
          <article-title>AlPiNA: A symbolic model checker</article-title>
          .
          <source>In: Petri Nets '10: International Conference on Theory and Applications</source>
          of Petri nets. (
          <year>2010</year>
          )
          <fpage>287</fpage>
          -
          <lpage>296</lpage>
        </mixed-citation>
      </ref>
      <ref id="ref31">
        <mixed-citation>
          7.
          <string-name>
            <surname>Rice</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Kulhari</surname>
            ,
            <given-names>S.:</given-names>
          </string-name>
          <article-title>A survey of static variable ordering heuristics for efficient BDD/MDD construction</article-title>
          .
          <source>Technical report</source>
          , UC riverside (
          <year>2008</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref32">
        <mixed-citation>
          8.
          <string-name>
            <surname>Hong</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Paviot-Adet</surname>
            ,
            <given-names>E.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Kordon</surname>
            ,
            <given-names>F.: PNXDD</given-names>
          </string-name>
          <string-name>
            <surname>Model</surname>
          </string-name>
          Checkers - https://srcdev.lip6. fr/trac/research/neoppod/ https://srcdev.lip6. fr/trac/research/NEOPPOD/.
        </mixed-citation>
      </ref>
      <ref id="ref33">
        <mixed-citation>
          9.
          <string-name>
            <surname>Hong</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Kordon</surname>
            ,
            <given-names>F.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Paviot-Adet</surname>
            ,
            <given-names>E.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Evangelista</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          :
          <article-title>Computing a Hierarchical Static Order for Decision Diagram-Based Representation from</article-title>
          P/T Nets.
          <article-title>ToPNoC: Transactions on Petri Nets and Other Models of Concurrency (submitted) (</article-title>
          <year>2010</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref34">
        <mixed-citation>
          10.
          <string-name>
            <surname>Hillah</surname>
            ,
            <given-names>L.M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Kindler</surname>
            ,
            <given-names>E.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Kordon</surname>
            ,
            <given-names>F.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Petrucci</surname>
            ,
            <given-names>L.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Trèves</surname>
          </string-name>
          , N.:
          <article-title>A primer on the Petri Net Markup Language and ISO/IEC 15909-2</article-title>
          .
          <source>Petri Net Newsletter</source>
          <volume>76</volume>
          (
          <year>2009</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref35">
        <mixed-citation>
          11.
          <string-name>
            <surname>Tantau</surname>
            ,
            <given-names>T.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Feuersaenger</surname>
            ,
            <given-names>C.</given-names>
          </string-name>
          : TikZ ist kein Zeichenprogramm http://www.ctan.org/tex-archive/graphics/pgf/.
        </mixed-citation>
      </ref>
      <ref id="ref36">
        <mixed-citation>
          12.
          <string-name>
            <surname>Murata</surname>
            ,
            <given-names>T.</given-names>
          </string-name>
          :
          <article-title>Petri nets: Properties, analysis and applications</article-title>
          .
          <source>Proceedings of the IEEE 77(4)</source>
          (
          <year>1989</year>
          )
          <fpage>541</fpage>
          -
          <lpage>580</lpage>
        </mixed-citation>
      </ref>
      <ref id="ref37">
        <mixed-citation>
          13.
          <string-name>
            <surname>Barkaoui</surname>
            ,
            <given-names>K.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Lemaire</surname>
            ,
            <given-names>B.</given-names>
          </string-name>
          :
          <article-title>An Effective Characterization of Minimal Deadlocks and Traps in Petri nets Based on Graph Theory</article-title>
          .
          <source>In: 10th Int. Conf. on Application and Theory of Petri Nets ICATPN'89. (January</source>
          <year>1989</year>
          )
          <fpage>1</fpage>
          -
          <lpage>21</lpage>
        </mixed-citation>
      </ref>
      <ref id="ref38">
        <mixed-citation>
          14.
          <string-name>
            <surname>Couvreur</surname>
            ,
            <given-names>J.M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Haddad</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Peyre</surname>
            ,
            <given-names>J.F.</given-names>
          </string-name>
          :
          <article-title>Computation of generative families of positive semi-flows in two types of coloured nets</article-title>
          .
          <source>International Conference on Theory and Applications of Petri Nets</source>
          (
          <year>1991</year>
          )
        </mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>