Transactions on petri nets and other models of concurrency XI

Journal Subline
LNCS 9930

Jörg Desel · Jetty Kleijn
Guest Editors

Transactions on

Petri Nets
and Other Models
of Concurrency XI
Maciej Koutny
Editor-in-Chief

123


Lecture Notes in Computer Science
Commenced Publication in 1973
Founding and Former Series Editors:
Gerhard Goos, Juris Hartmanis, and Jan van Leeuwen

Editorial Board
David Hutchison
Lancaster University, Lancaster, UK
Takeo Kanade
Carnegie Mellon University, Pittsburgh, PA, USA
Josef Kittler
University of Surrey, Guildford, UK
Jon M. Kleinberg
Cornell University, Ithaca, NY, USA

Friedemann Mattern
ETH Zurich, Zurich, Switzerland
John C. Mitchell
Stanford University, Stanford, CA, USA
Moni Naor
Weizmann Institute of Science, Rehovot, Israel
C. Pandu Rangan
Indian Institute of Technology, Madras, India
Bernhard Steffen
TU Dortmund University, Dortmund, Germany
Demetri Terzopoulos
University of California, Los Angeles, CA, USA
Doug Tygar
University of California, Berkeley, CA, USA
Gerhard Weikum
Max Planck Institute for Informatics, Saarbrücken, Germany

9930


More information about this series at />

Maciej Koutny Jörg Desel
Jetty Kleijn (Eds.)
•

Transactions on
Petri Nets
and Other Models
of Concurrency XI

123


Editor-in-Chief
Maciej Koutny
Newcastle University
Newcastle upon Tyne
UK
Guest Editors
Jörg Desel
FernUniversität in Hagen
Hagen
Germany

Jetty Kleijn
Leiden University
Leiden
The Netherlands

ISSN 0302-9743
ISSN 1611-3349 (electronic)
Lecture Notes in Computer Science
ISBN 978-3-662-53400-7
ISBN 978-3-662-53401-4 (eBook)
DOI 10.1007/978-3-662-53401-4
Library of Congress Control Number: 2016950374
© Springer-Verlag Berlin Heidelberg 2016
This work is subject to copyright. All rights are reserved by the Publisher, whether the whole or part of the
material is concerned, specifically the rights of translation, reprinting, reuse of illustrations, recitation,

broadcasting, reproduction on microfilms or in any other physical way, and transmission or information
storage and retrieval, electronic adaptation, computer software, or by similar or dissimilar methodology now
known or hereafter developed.
The use of general descriptive names, registered names, trademarks, service marks, etc. in this publication
does not imply, even in the absence of a specific statement, that such names are exempt from the relevant
protective laws and regulations and therefore free for general use.
The publisher, the authors and the editors are safe to assume that the advice and information in this book are
believed to be true and accurate at the date of publication. Neither the publisher nor the authors or the editors
give a warranty, express or implied, with respect to the material contained herein or for any errors or
omissions that may have been made.
Printed on acid-free paper
This Springer imprint is published by Springer Nature
The registered company is Springer-Verlag GmbH Berlin Heidelberg


Preface by Editor-in-Chief

The 11th Issue of LNCS Transactions on Petri Nets and Other Models of Concurrency
(ToPNoC) contains revised and extended versions of a selection of the best papers from
the workshops held at the 36th International Conference on Application and Theory of
Petri Nets and Concurrency (Petri Nets 2015, Brussels, Belgium, June 22–26, 2015)
and the 15th International Conference on Application of Concurrency to System
Design (ACSD 2015, Brussels, Belgium, June 22–26, 2015). It also contains one paper
submitted directly to ToPNoC.
I would like to thank the two guest editors of this special issue: Jörg Desel and Jetty
Kleijn. Moreover, I would like to thank all the authors, reviewers, and organizers of the
Petri Nets 2015 and ACSD 2015 satellite workshops, without whom this issue of
ToPNoC would not have been possible.
July 2016

Maciej Koutny


LNCS Transactions on Petri Nets and Other Models
of Concurrency: Aims and Scope

ToPNoC aims to publish papers from all areas of Petri nets and other models of
concurrency ranging from theoretical work to tool support and industrial applications.
The foundations of Petri nets were laid by the pioneering work of Carl Adam Petri and
his colleagues in the early 1960s. Since then, a huge volume of material has been
developed and published in journals and books as well as presented at workshops and
conferences.
The annual International Conference on Application and Theory of Petri Nets and
Concurrency started in 1980. The International Petri Net Bibliography maintained by
the Petri Net Newsletter contains over 10,000 entries, and the International Petri Net
Mailing List has close to 2,000 subscribers. For more information on the International
Petri Net community, see: />All issues of ToPNoC are LNCS volumes. Hence they appear in all main libraries
and are also accessible on SpringerLink (electronically). It is possible to subscribe to
ToPNoC without subscribing to the rest of the LNCS series.
ToPNoC contains:
• Revised versions of a selection of the best papers from workshops and tutorials
concerned with Petri nets and concurrency
• Special issues related to particular subareas (similar to those published in the
Advances in Petri Nets series)
• Other papers invited for publication in ToPNoC
• Papers submitted directly to ToPNoC by their authors
Like all other journals, ToPNoC has an Editorial Board, which is responsible for the
quality of the journal. The members of the board assist in the reviewing of papers
submitted or invited for publication in ToPNoC. Moreover, they may make recommendations concerning collections of papers for special issues. The Editorial Board
consists of prominent researchers within the Petri net community and in related fields.

Topics
The topics covered include system design and verification using nets; analysis and
synthesis, structure and behavior of nets; relationships between net theory and other
approaches; causality/partial order theory of concurrency; net-based semantical, logical, and algebraic calculi; symbolic net representation (graphical or textual); computer
tools for nets; experience with using nets, case studies; educational issues related to
nets; higher-level net models; timed and stochastic nets; and standardization of nets.
Applications of nets to: biological systems; defence systems; e-commerce and
trading; embedded systems; environmental systems; flexible manufacturing systems;


VIII

LNCS Transactions on Petri Nets and Other Models of Concurrency

hardware structures; health and medical systems; office automation; operations
research; performance evaluation; programming languages; protocols and networks;
railway networks; real-time systems; supervisory control; telecommunications; cyber
physical systems; and workflow.
For more information about ToPNoC see: />
Submission of Manuscripts
Manuscripts should follow LNCS formatting guidelines, and should be submitted as
PDF or zipped PostScript files to All queries should be addressed
to the same e-mail address.


LNCS Transactions on Petri Nets and Other Models
of Concurrency: Editorial Board

Editor-in-Chief

Maciej Koutny

Newcastle University, UK

Associate Editors
Grzegorz Rozenberg
Susanna Donatelli
Jetty Kleijn
Wil van der Aalst

Leiden University, The Netherlands
University of Turin, Italy
Leiden University, The Netherlands
Eindhoven University of Technology, The Netherlands

Editorial Board
Didier Buchs
Gianfranco Ciardo
José-Manuel Colom
Jörg Desel
Michel Diaz
Hartmut Ehrig
Jorge C.A. de Figueiredo
Luis Gomes
Serge Haddad
Xudong He
Kunihiko Hiraishi
Gabriel Juhas
Lars M. Kristensen
Charles Lakos

Johan Lilius
Chuang Lin
Satoru Miyano
Madhavan Mukund
Wojciech Penczek
Laure Petrucci
Lucia Pomello
Wolfgang Reisig
Manuel Silva
P.S. Thiagarajan
Glynn Winskel
Karsten Wolf
Alex Yakovlev

University of Geneva, Switzerland
Iowa State University, USA
University of Zaragoza, Spain
FernUniversität in Hagen, Germany
LAAS – CNRS, France
Technical University of Berlin, Germany
Federal University of Campina Grande, Brazil
Universidade Nova de Lisboa, Portugal
ENS Cachan, France
Florida International University, USA
JAIST, Japan
Slovak University of Technology, Slovak Republic
Bergen University College, Norway
University of Adelaide, Australia
Åbo Akademi, Finland
Tsinghua University, China

University of Tokyo, Japan
Chennai Mathematical Institute, India
ICS PAS, Poland
University of Paris 13, France
University of Milano-Bicocca, Italy
Humboldt University of Berlin, Germany
University of Zaragoza, Spain
NUS, Singapore
University of Cambridge, UK
University of Rostock, Germany
Newcastle University, UK


Preface by Guest Editors
This volume of ToPNoC contains revised versions of a selection of the best workshop
papers presented at the 36th International Conference on Application and Theory of Petri
Nets and Other Models of Concurrency (Petri Nets 2015) and the 15th International
Conference on Application of Concurrency to System Design (ACSD 2015), and papers
describing winning contributions from the model checking contest.
We, Jörg Desel and Jetty Kleijn, are indebted to the Program Committees of the
workshops and the model checking contest and in particular to their chairs. Without their
enthusiastic work, this volume would not have been possible. Many members of the
Program Committees participated in reviewing the new versions of the papers selected
for this issue. We asked for the strongest contributions to the following satellite events:
– ATAED 2015: Workshop on Algorithms & Theories for the Analysis of Event Data
(chairs: Wil van der Aalst, Robin Bergenthum, Josep Carmona)
– PNSE 2015: International Workshop on Petri Nets and Software Engineering
(chairs: Daniel Moldt, Heiko Rölke, Harald Störrle)
– Model Checking Contest @ Petri Nets 2015 (chairs: Fabrice Kordon, Didier Buchs)
The best papers of the workshops were selected in close cooperation with their

chairs. The authors were invited to improve and extend their results where possible,
based on the comments received before and during the workshops. The resulting revised
submissions were reviewed by two referees. We followed the principle of asking for
fresh reviews of the revised papers, also from referees not involved initially in the
reviewing of the original workshop contributions. All papers went through the standard
two-stage journal reviewing process, and eventually nine were accepted after rigorous
reviewing and revising. In addition to these first nine papers, two papers were submitted
directly to the editor-in-chief of the ToPNoC series and handled by him as is usual for
journal submissions. The papers describing the best tools of the model checking contest
were evaluated and revised based on remarks and suggestions from several reviewers.
They are summarized by the introductory contribution of Fabrice Kordon et al.
The paper “Pragmatics Annotated Coloured Petri Nets for Protocol Software
Generation and Verification” by Kent Inge Fagerland Simonsen, Lars M. Kristensen,
and Ekkart Kindler provides a formal definition of Pragmatics Annotated Coloured
Petri Nets (PA-CPN), a class of Petri nets that can automatically be transformed into
protocol software. The paper, moreover, demonstrates how to exploit the structure of
PA-CPNs for verification.
The paper “A Petri Net-Based Approach to Model and Analyze the Management of
Cloud Applications” by Antonio Brogi, Andrea Canciani, Jacopo Soldani, and
PengWei Wang extends the TOSCA standard for specifying the topology and
orchestration of cloud applications to behavioral aspects of management operations and
their relations with states, requirements, and capabilities. This behavior is modelled by
Open Petri Nets, thus supporting automated analysis of deployment plans.
The paper “Non-Interference Notions Based on Reveals and Excludes Relations for
Petri Nets” by Luca Bernardinello, Görkem Kılınç, and Lucia Pomello introduces a


XII

Preface by Guest Editors

variety of non-interference notions for Petri nets that indicate that some internal
behavior of a Petri net component cannot be inferred from its interface behavior. The
notions are based on the previously known reveals relation (whenever a certain event
occurs in a maximal occurrence net, the related one occurs, too) and a newly
introduced, converse excludes relation.
The paper “Validating DCCP Simultaneous Feature Negotiation Procedure” by
Somsak Vanit-Anunchai investigates the feature negotiation procedure of the Datagram
Congestion Control Protocol in RFC 4340 using Coloured Petri Nets and state space
analysis. The analysis result shows that the protocol can fail to an undesired state,
which has the property that the feature values of both sides do not match and both sides
are not aware of the mismatch. Simultaneous negotiation could be broken on even a
simple lossless FIFO channel.
The paper “Integrating Petri Net Semantics in a Model-Driven Approach: The
Renew Meta-Modeling and Transformation Framework” by David Mosteller,
Lawrence Cabac, and Michael Haustermann deals with the development of modeling
languages and automated generation of according tools for model-driven development
on the basis of ontology-based meta-models. The approach is based on Petri nets;
high-level Petri nets and low-level Petri nets in various forms can be used as target
models. The RMT framework provides the generation of modeling tools and the
transformation into executable and analyzable models, based on the respective Petri net
semantics.
The paper “Mining Conditional Partial Order Graphs from Event Logs” by Andrey
Mokhov, Josep Carmona, and Jonathan Beaumont uses Conditional Partial Order
Graphs (CPOGs) for compact representation of families of partial orders for process
mining. In particular, the representation problem of event logs with data is addressed.
The paper provides algorithms for extracting both the control flow and the relevant data
parameters from a given event log. Moreover, it shows how CPOGs can be used for
efficient and effective visualization of the obtained results, which also can be used to
reveal the hidden interplay between the control and data flows of a process.

The paper “Conditions for Petri Net Solvable Binary Words” by Kamila Barylska,
Eike Best, Evgeny Erofeev, Łukasz Mikulski, and Marcin Piątkowski studies finite
words with two letters that can be viewed as behavioral descriptions of place/transition
Petri nets, which necessarily neither exhibit concurrency nor choices and possess only
two transitions. Two conjectures providing different characterizations of this class of
words are motivated and proposed. Several results are described, which amount to a
partial proof of these conjectures.
The paper “Self-Tracking Reloaded: Applying Process Mining to Personalized
Health Care from Labeled Sensor Data” by Timo Sztyler, Josep Carmona, Johanna
Völker, and Heiner Stuckenschmidt provides ideas on how process-mining techniques
can be used as a fine-grained evolution of traditional self-tracking, applied for
personalized health care and based on daily live data recorded on smart devices. These
ideas are applied to data of a set of people, yielding interesting conclusions and
challenges.
The paper “A Method for Assessing Parameter Impact on Control-Flow Discovery
Algorithms” by Joel Ribeiro and Josep Carmona tackles the problem of identifying
parameters in control-flow discovery algorithms that are important for the applicability


Preface by Guest Editors

XIII

of the algorithm to a given log, according to a given quality metric. The suggested
solution is based on sensitivity analysis. The paper also presents a first, promising
evaluation of this approach.
The paper “Negotiations and Petri Nets” by Jörg Desel and Javier Esparza was
originally a contribution to the PNSE 2015 workshop and suggested for this issue by
the workshop chairs. Since one of the authors, Jörg Desel, is involved as a guest editor
of this issue, it was submitted directly to the editor-in-chief and handled by him

independently. This paper studies the relation between negotiations, a previously
introduced model of concurrency with multi-party negotiation atoms as primitive, and
Petri nets. In particular, translations in either directions are considered as well as the
resulting relative size of the respective models. The paper shows that sound and
deterministic negotiations are closely related to live and safe free-choice Petri nets.
The paper “A Formal Framework for Diagnostic Analysis for Errors of Business
Processes” by Suman Roy and A.S.M. Sajeev was submitted directly to ToPNoC
through the regular submission track. This article develops a formal framework of
diagnosing errors by locating their occurrence nodes in business process models at the
level of sub-processes and swim-lanes. Graph-theoretic techniques and Petri net-based
analyses are used to detect syntactic and control flow-related errors, respectively. The
authors discover how error frequencies change with error depth, how they correlate
with the size of the sub-processes and swim-lane interactions in the models, and how
they can be predicted in terms of process metrics.
The book ends with contributions from the model checking contest, held at the
2015 Petri Net conference. In the article “MCC 2015 — The Fifth Model Checking
Contest,” the authors introduce the event itself, but also the algorithms and tools that
were successful at the contest. Therefore, this paper can be viewed as an introduction to
the remaining four papers, in which the authors of successful tools describe their
respective approaches and experiences.
As guest editors, we would like to thank all authors and referees who contributed to
this issue. The quality of this volume is the result of the high scientific value of their
work. Moreover, we would like to acknowledge the excellent cooperation throughout
the whole process that has made our work a pleasant task. We are also grateful to the
Springer/ToPNoC team for the final production of this issue.

June 2016

Jörg Desel
Jetty Kleijn

Organization of This Issue

Guest Editors
Jörg Desel
Jetty Kleijn

FernUniversität in Hagen, Germany
Leiden University, The Netherlands

Workshop Co-chairs
Wil van der Aalst
Robin Bergenthum
Didier Buchs
Josep Carmona
Fabrice Kordon
Daniel Moldt
Heiko Rölke
Harald Störrle

Eindhoven University of Technology, The Netherlands
FernUniversität in Hagen, Germany
University of Geneva, Switzerland
Universitat Politecnica de Catalunya, Spain
University of Paris 6, France
University of Hamburg, Germany
DIPF, Germany
Technical University of Denmark, Denmark

Reviewers
Wil van der Aalst
Robin Bergenthum
Luca Bernardinello
Seppe vanden Broucke
Lawrence Cabac
Piotr Chrząstowski-Wachtel
José Manuel Colom
Dirk Fahland
Jorge Figueiredo
Luciano García-Bañuelos
Wolfgang Halang
Hendrik Jan Hoogeboom
Fabrice Kordon
Agnes Koschmider

Lars Michael Kristensen
Robert Lorenz
Daniel Moldt
Andrey Mokhov
Laure Petrucci
Marta Pietkiewicz-Koutny
Pascal Poizat
Astrid Rakow
Stefan Schwoon
Natalia Sidorova
Jan Martijn van der Werf
Harro Wimmel
Karsten Wolf
Sebastian van Zelst

Contents

Pragmatics Annotated Coloured Petri Nets for Protocol Software
Generation and Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Kent Inge Fagerland Simonsen, Lars M. Kristensen, and Ekkart Kindler

1

A Petri Net-Based Approach to Model and Analyze the Management
of Cloud Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Antonio Brogi, Andrea Canciani, Jacopo Soldani, and PengWei Wang

28

Non-interference Notions Based on Reveals and Excludes Relations
for Petri Nets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Luca Bernardinello, Görkem Kılınç, and Lucia Pomello

49

Validating DCCP Simultaneous Feature Negotiation Procedure . . . . . . . . . . .
Somsak Vanit-Anunchai
Integrating Petri Net Semantics in a Model-Driven Approach: The Renew
Meta-Modeling and Transformation Framework . . . . . . . . . . . . . . . . . . . . .
David Mosteller, Lawrence Cabac, and Michael Haustermann

71

92

Mining Conditional Partial Order Graphs from Event Logs . . . . . . . . . . . . .
Andrey Mokhov, Josep Carmona, and Jonathan Beaumont

114

Conditions for Petri Net Solvable Binary Words . . . . . . . . . . . . . . . . . . . . .
Kamila Barylska, Eike Best, Evgeny Erofeev, Łukasz Mikulski,
and Marcin Piątkowski

137

Self-tracking Reloaded: Applying Process Mining to Personalized
Health Care from Labeled Sensor Data . . . . . . . . . . . . . . . . . . . . . . . . . . .
Timo Sztyler, Josep Carmona, Johanna Völker,
and Heiner Stuckenschmidt
A Method for Assessing Parameter Impact on Control-Flow
Discovery Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Joel Ribeiro and Josep Carmona
Negotiations and Petri Nets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Jörg Desel and Javier Esparza
A Formal Framework for Diagnostic Analysis for Errors
of Business Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Suman Roy and A.S.M. Sajeev

160

181
203

226


XVIII

Contents

MCC’2015 – The Fifth Model Checking Contest . . . . . . . . . . . . . . . . . . . .
Fabrice Kordon, Hubert Garavel, Lom Messan Hillah,
Emmanuel Paviot-Adet, Loïg Jezequel, César Rodríguez,
and Francis Hulin-Hubard

262

Running LoLA 2.0 in a Model Checking Competition . . . . . . . . . . . . . . . . .
Karsten Wolf

274

MARCIE’s Secrets of Efficient Model Checking. . . . . . . . . . . . . . . . . . . . .
Monika Heiner, Christian Rohr, Martin Schwarick,
and Alexey A. Tovchigrechko

286

A Symbolic Model Checker for Petri Nets: pnmc . . . . . . . . . . . . . . . . . . . .
Alexandre Hamez

297

TAPAAL and Reachability Analysis of P/T Nets . . . . . . . . . . . . . . . . . . . .
Jonas F. Jensen, Thomas Nielsen, Lars K. Oestergaard, and Jiří Srba

307

Author Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

319


Pragmatics Annotated Coloured
Petri Nets for Protocol Software
Generation and Verification
Kent Inge Fagerland Simonsen1,2(B) , Lars M. Kristensen1 , and Ekkart Kindler2
1
2

Department of Computing, Bergen University College, Bergen, Norway
{kifs,lmkr}@hib.no
DTU Compute, Technical University of Denmark, Kgs. Lyngby, Denmark
{kisi,ekki}@dtu.dk

Abstract. Pragmatics Annotated Coloured Petri Nets (PA-CPNs) are
a restricted class of Coloured Petri Nets (CPNs) developed to support
automated generation of protocol software. The practical application of
PA-CPNs and the supporting PetriCode software tool have been discussed and evaluated in earlier papers already. The contribution of this
paper is to give a formal definition of PA-CPNs, motivate the definitions, and demonstrate how the structure of PA-CPNs can be exploited
for more efficient verification.

1

Introduction

Coloured Petri Nets (CPNs) [1] have been widely used for modelling and verifying protocols. Examples include application layer protocols such as IOTP and
SIP, transport layer protocols such as DCCP and SCTP, and network layer
protocols such as DYMO and ERDP [2,3]. Formal modelling and verification
have been useful in gaining insight into the operation of the protocols and have
resulted in improved protocol specifications. However, this work did not fully
leverage the investment in making CPN models: the models were used for better
understanding and verifying protocols, but not for actually creating implementations of these protocols from the constructed models. There exist only very
limited approaches that support the automatic generation of protocol implementations from CPN models that were made for verification purposes. Existing
approaches have either restricted the target platform for code generation to the
Standard ML language used by the CPN Tools simulator or have considered a
specific target language based on platform-specific additions to the CPN models.
This has motivated us to develop an approach and an accompanying tool
called PetriCode that supports the automated generation of protocol software
from CPN models, which was presented [3–7] and evaluated [8] in earlier work. At
the core of the PetriCode approach is a slightly restricted subclass of CPNs called
Pragmatic Annotated CPNs (PA-CPNs). The restrictions of PA-CPNs make the
structure of the protocol system, its principals, channels, and services explicit.
A key feature of PA-CPNs are code generation pragmatics, which are syntactical
c Springer-Verlag Berlin Heidelberg 2016
M. Koutny et al. (Eds.): ToPNoC XI, LNCS 9930, pp. 1–27, 2016.
DOI: 10.1007/978-3-662-53401-4 1


2

K.I.F. Simonsen et al.

annotations to certain elements of the PA-CPNs. These pragmatics represent
concepts from the domain of communication protocols and protocol software,
and are used to indicate the purpose of the respective modelling element. The
role of the pragmatics is to extend the CPN modelling language with domainspecific elements and make implicit knowledge of the modeller explicit in the
CPN model such that it can be exploited for code generation. Even though we
have used PA-CPNs in our earlier work, a precise formal definition of PA-CPNs
was still missing1 .
The contribution of this paper compared to our earlier work is threefold.
Firstly, motivated by the practical relevance of the net class demonstrated in
earlier work, we give a formal definition of PA-CPNs here. Secondly, we discuss
the concepts of PA-CPNs and how they are used for modelling and developing
protocol software. Thirdly, we show that PA-CPNs are amenable to verification.
Specifically, we show how the structural restrictions allow us to add service
testers to the model of the protocol, which reduce the state space of the model.
Furthermore, we discuss how the structural restrictions of PA-CPNs can be used
to automatically compute a progress measure for the sweep-line method [10].
For the rest of the paper, we assume that the reader is familiar with the
basic concepts of Petri nets and high-level Petri nets. The paper is organised as
follows: Sect. 2 introduces the protocol example used throughout this paper and
provides the definitions of CPNs needed for defining PA-CPNs. Section 3 gives
the formal definition of PA-CPNs. Section 4 discusses the modelling concepts
and process of PA-CPNs from an application perspective. Section 5 formalises
control flow decomposability, which is central in generating code for the protocol
services. Section 6 introduces and formalises service testers. Section 7 shows how
to define progress measures for the sweep-line method based on service level and
service tester modules of PA-CPNs, and presents results from an experimental
evaluation. Finally, in Sect. 8, we discuss related work and, in Sect. 9, we draw
the overall conclusions concerning the PetriCode approach.

2

Protocol Example and Coloured Petri Nets

The definition of PA-CPNs is based on the standard definition of hierarchical
CPNs [1]. Therefore, we include the definitions and notations for hierarchical
CPNs here as far as they are needed for the definition of PA-CPNs. For better understandability, we discuss an example of a hierarchical CPN first before
presenting the definitions of CPNs. Note that, in this paper, we give the formal
definitions for the syntax of hierarchical CPNs only; we do not give a definition
of their semantics. The reason is that PA-CPNs constitute a syntactical restriction of CPNs, so that we do not need to change the semantics of CPNs at all.
PA-CPNs have exactly the same semantics as ordinary hierarchical CPNs [1].
Protocol Example. As a running example, we use a protocol consisting of a
sender and a receiver communicating over an unreliable channel which may both
1

Note, that this paper is a revised and extended version of the workshop paper [9].


Pragmatics Annotated Coloured Petri Nets

3

Fig. 1. The system level CPN module (left) and sender principal level module (right).

re-order and loose messages. The sender sends messages tagged with sequence
numbers to the receiver and waits for an acknowledgement for each message
to be returned from the receiver before sending the next message. Hence, the
protocol operates according to the stop-and-wait principle.
The CPN model of this protocol consists of eight hierarchically organised
modules. Below, we present selected modules of the CPN model2 in order to

illustrate the concepts, the definitions, and the verification techniques in this
paper. Figure 1 (left) shows the top-level module consisting of three substitution transitions (drawn as double-bordered rectangles) representing the Sender,
the Receiver, and the Channel connecting them. The two places SenderChannel
and ReceiverChannel represent buffering communication endpoints connecting
the sender and the receiver to the communication channel. The definition of
the colour set (type) Endpoint, which determines the kind of tokens that can
reside on these two places, is provided in Fig. 2. Each of the three substitution
transitions has an associated submodule indicated by the rectangular tag positioned next to the substitution transition. These submodules define the behaviour associated with the substitution transitions. The annotations written in
are pragmatic annotations, which are formally introduced in the next section
when defining PA-CPNs. These pragmatics indicate the role of certain CPN
model elements in the protocol; for now, they can be ignored or considered to
be comments.
Figure 1 (right) shows the Sender module, which is the submodule associated
with the Sender substitution transition in Fig. 1 (left). It defines the protocol for
the Sender principal. The module has two substitution transitions modelling the
main operations of the sender which are sending messages (substitution transition Send) and receiving acknowledgements (substitution transition receiveAck).
The places ready, runAck, and nextSend are used to model the internal state of
the sender. The place ready has an initial marking consisting of a token with
the colour () (unit), which is the single value contained in the predefined colour
set UNIT; this is the CPN equivalent of a “black token” in classical low-level
Petri nets. This token indicates that initially the sender is ready to perform a
send operation. For a place with colour set UNIT, we omit (by convention) the
2

The complete model is available at />

4

K.I.F. Simonsen et al.

specification of the colour set in the graphical representation. The place runAck,
which has a boolean colour set, initially contains a token with the value false
indicating that the sender initially cannot receive acknowledgements. The place
nextSend is used to keep track of the sequence number of the message that the
sender is currently sending. The place SenderChannel is a port place (indicated by
the double border) and is used by the module to exchange tokens with its upper
level module in Fig. 1 (left). In this case, SenderChannel is an input-output port
place as specified by the In/Out tag positioned next to the place. The place is
associated with the SenderChannel socket place in Fig. 1 (left), which means that
any token removed from (added to) this place in the Sender module will also be
removed from (added to) the place SenderChannel of the Protocol module.
Figure 3 shows the Send module, which is the submodule associated with the
Send substitution transition in Fig. 1 (right). This submodule models the sending
of a list of messages from the sender to the receiver. The port places ready,
SenderChannel, nextSend, and runAck are associated with the accordingly named
socket places in the module shown in Fig. 1 (right). The list of messages to be sent
is provided via the place message (at the top of the module) annotated with the
driver pragmatic. This place is a fusion place as indicated by the rectangular
tag positioned next to the place. The name inside the tag specifies the fusion set
that the place belongs to. A fusion set is a set of places with the property that
when tokens are removed from (added to) one place in the set, then the token
will be removed from (added to) all members. Conceptually, all the places of a
fusion set are merged into a single compound place. The place endSend (at the
bottom) annotated with a driver pragmatic is also a member of a fusion set.
These fusion sets are used to connect PA-CPNs to service tester modules, which
we introduce later; these places are, formally, not part of the service level module
or the complete protocol. The places annotated by the driver pragmatic are
used by the service tester module to control the order and the parameters of the
invocation of the services of the protocol during the verification of the protocol
(see Sects. 6 and 7). The code generator ignores these places since, in the actual

Fig. 2. Colour set (type) declarations used in Fig. 1


Pragmatics Annotated Coloured Petri Nets

5

Fig. 3. The send module (service level)

Fig. 4. Colour set (type) declarations used in Fig. 3

protocol software, the services of the protocol are invoked externally; the order
in which the services are invoked and the concrete parameters are determined
by the protocol’s environment.
Sending a list of messages starts with the occurrence of the transition send,
which places the messages to be sent on place messageToSend, puts a token on
nextSend corresponding to the first sequence number, and a token on runAck
to indicate that acknowledgements can now be received. The place limit is used
to bound the number of retransmissions of a message. After an occurrence of
transition send, transition sendMsg may occur sending a message by putting it in
the output buffer modelled by the place SenderChannel. The guard on the transition sendMsg (by convention written in square brackets next to the transition)
ensures that the data being sent matches the sequence number of the message
currently being sent. If the retransmission limit is reached, the sender will stop
as modelled by the transition return putting a token on place endSend. If the
retransmission limit is not reached for the current message, the transition loop


6

K.I.F. Simonsen et al.

will put a token back on startSending such that the next message can be sent.
The colour set definitions and variables used in Fig. 3 are provided in Fig. 4.
Formal Definitions of Hierarchical CPNs. Above, we have presented the example
CPN model that will be used as a running example throughout this paper, and
we have informally introduced the constructs of hierarchical CPNs in the form
of modules, substitution transitions, port and socket places, and fusion places.
Next, we formally define hierarchical CPNs. These definitions are later
extended when formally defining PA-CPNs. As usual, we use N = (P, T, A)
to denote the net structure of a Petri net, where P denotes the set of places, T
the set of transitions, and A the set of arcs, respectively. Definition 1 provides the
formal definition of CPN modules. In this definition, we use T ype[v] to denote
the type of a variable v, and we use EXP RV to denote the set of expressions
with free variables contained in a set of variables V . For an expression e containing a set of free variables V , we denote by e b the result of evaluating e in a
binding b that assigns a value to each variable in V . Moreover, T ype[e] denotes
the type of an expression e. For a non-empty set S, we use SM S to denote the
type corresponding to the set of all multi-sets over S.
Definition 1. A Coloured Petri Net Module (Definition 6.1 in [1]) is a
tuple CP N M = (CP N, Tsub , Pport , P T ), such that:
1. CP N = (P, T, A, Σ, V, C, G, E, I) is a CPN (Definition 4.2 in [1]) where:
(a) P is a finite set of places and T is a finite set of transitions such that
P ∩ T = ∅.
(b) A ⊆ (P × T ) ∪ (T × P ) is a set of directed arcs.
(c) Σ is a finite set of non-empty colour sets and V is a finite set of typed
variables such that T ype[v] ∈ Σ for all variables v ∈ V .
(d) C : P → Σ is a colour set function assigning a colour set to each place.
(e) E : A → EXP RV is an arc expression function that assigns an arc
expression to each arc a such that T ype[E(a)] = C(p)M S , where p is the
place connected to the arc a.

(f ) G : T → EXP RV is a guard function that assigns a guard to each
transition t such that T ype[G(t)] = Bool.
(g) I : P → EXP R∅ is an initialisation function that assigns an initialisation expression to each place p such that T ype[I(p)] = C(p)M S .
2. Tsub ⊆ T is a set of substitution transitions.
3. Pport ⊆ P is a set of port places.
4. P T : Pport → {IN, OUT, I/O} is a port type function that assigns a port
type to each port place.
Socket places of a CPN are not defined explicitly in the above definition,
since that information can be derived from the information available in a CPN:
if a place has an arc connecting it with a substitution transition, it is a socket
place of this transition. For a substitution transition t, the set of its socket places
is denoted by Psock (t). Furthermore, ST (t) denotes a mapping that maps each


Pragmatics Annotated Coloured Petri Nets

7

socket place p into its type, i.e., ST (t)(p) = IN if p is an input socket, ST (t)(p) =
OUT if p is an output socket, and ST (t)(p) = I/O if p is an input/output socket.
Technically, the arc expression function E(a) is defined for arcs a ∈ A of the
CPN only. For convenience, however, we assume that E(a) = empty, whenever
a ∈ A, where the expression empty evaluates to the empty multiset of tokens.
A hierarchical CPN consists of a set of disjoint CPN modules, a submodule
function assigning a (sub)module to each substitution transition, and a portsocket relation that associates port places in a submodule to the socket places
of its upper layer module. Furthermore, port and socket places can only be
associated with each other, if they have the same colour set and the same initial
marking. Definition 2 formalises these requirements where Tsub denotes the union
of all substitution transitions in the modules of the hierarchical CPN.
Definition 2. A hierarchical Coloured Petri Net (Definition 6.2 in [1]) is

a four-tuple CP NH = (S, SM , P S, F S) where:
1. S is a finite set of modules. Each module is a Coloured Petri Net Module
s
s
, Pport
, P T s ). It is required that
s = ((P s , T s , As , Σs , V s , C s , Gs , E s , I s ), Tsub
s1
s1
s2
s2
(P ∪ T ) ∩ (P ∪ T ) = ∅ for all s1 , s2 ∈ S with s1 = s2 .
2. SM : Tsub → S is a submodule function that assigns a submodule to each
substitution transition. It is required that the module hierarchy (see below) is
acyclic.
3. PS is a port–socket relation function that assigns a port–socket relaSM (t)
tion PS (t) ⊆ Psock (t) × Pport
to each substitution transition t. It is
required that ST (t)(p) = P T (p ), C(p) = C(p ), and I(p) = I(p ) for
all (p, p ) ∈ PS (t) and all t ∈ Tsub .
4. F S ⊆ 2P is a set of non-empty and disjoint fusion sets such that C(p) =
C(p ) and I(p) = I(p ) for all p, p ∈ f s and all f s ∈ F S.
The module hierarchy of a hierarchical CPN model is a directed graph with
a node for each module and an arc leading from one module to another module
if the latter module is a submodule of one of the substitution transitions of the
former module. The module hierarchy is required to be acyclic and the root
nodes of the module hierarchy are referred to as prime modules.

3

Pragmatic Annotated CPNs

PA-CPNs mandate a particular structure of the CPN models and allow the CPN
elements to be annotated with additional pragmatics. In a PA-CPN, the modules
of the CPN model are required to be organised into three levels referred to as
the protocol system level , the principal level , and the service level . We have seen
examples for modules on each of these levels in Sect. 2 already.
In a PA-CPN, it is required that there exists exactly one prime module.
This prime module represents the protocol system level. The Protocol module
shown in Fig. 1 (left) comprises the protocol system level of the PA-CPN model
of our example protocol; it specifies the protocol principals in the system and the


8

K.I.F. Simonsen et al.

channels connecting them. The substitution transitions representing principals
are specified using the principal pragmatic, and the substitution transitions
representing channels are specified using the channel pragmatic. As mentioned
already, all pragmatics annotations of a CPN are included between guillemets:
. Some of the pragmatics can have additional attributes or parameters, which
give more detailed information. In our example of Fig. 1 (left), the channel
pragmatic has attributes, which specify that the communication channel is bidirectional, unreliable, and does not preserve the order of messages.
On the principal level, there is one module for each principal of the protocol
as defined on the protocol system level. Our example protocol has two modules
at the principal level: one for the sender and one for the receiver. Figure 1 (right)
shows the principal level module for the sender. A principal level module models
the services that the principal is providing, and the internal states and lifecycle of the respective principal. For the sender in our example, there are two
services: send and receiveAck. Substitution transitions representing services that

can be externally invoked are specified using the service pragmatic, whereas
services that are to be invoked only internally are specified using the internal
pragmatic. The service level modules model the behaviour of the individual
services of the principals. The module shown in Fig. 3 is an example of a module
at the service level modelling the send service provided by the sender.
We formally define PA-CPNs as a tuple consisting of a hierarchical CPN, a
protocol system module (PSM), a set of principal level modules (PLMs), a set
of service level modules (SLMs), a set of channel modules (CHMs), and a structural pragmatics mapping (SP) that maps substitution transitions into structural
pragmatics and capturing the annotation of the substitution transitions.
Definition 3. A Pragmatics Annotated Coloured Petri Net (PA-CPN)
is a tuple CP N P A = (CP N H , P SM , P LM , SLM , CHM , SP ), where:
1. CP N H = (S, SM, P S, F S) is a hierarchical CPN with P SM ∈ S being
a protocol system module (Definition 4) and the only prime module of
CP N H .
2. P LM ⊆ S is a set of principal level modules (Definition 5); SLM ⊆ S
is a set of service level modules (Definition 6) and CHM ⊆ S is a set of
channel modules s.t {{P SM }, P LM , SLM , CHM } constitute a partitioning of S.
3. SP : Tsub → {principal, service, internal, channel} is a structural pragmatics mapping such that:
(a) Substitution transitions with principal have an associated principal
level module: ∀t ∈ Tsub : SP (t) = principal ⇒ SM (t) ∈ P LM .
(b) Substitution transitions with service or internal are associated
with a service level module:
∀t ∈ Tsub : SP (t) ∈ {service, internal} ⇒ SM (t) ∈ SLM .
(c) Substitution transitions with channel are associated with a channel
module: ∀t ∈ Tsub : SP (t) = channel ⇒ SM (t) ∈ CHM .


Pragmatics Annotated Coloured Petri Nets

9

It should be noted that channel modules do not play a role in the code generation; they constitute a CPN model artifact used to connect the principals for
verification purposes. Therefore, we do not impose any specific requirements on
the internal structure of channel modules. The behaviour of the channel module must match the characteristics specified by the attributes of the channel
pragmatics, though. But this is not part of the formal definition of PA-CPNs.
Protocol System Module (PSM). The module shown in Fig. 1 (left) comprises
the protocol system level of the example PA-CPN model. It specifies the two
protocol principals in the system and the channels connecting them. The substitution transitions representing principals are specified using the principal
pragmatic, and the substitution transitions representing channels are specified
using the channel pragmatic. The PSM module is defined as a tuple consisting
of a CPN module and a pragmatic mapping P M that associates a pragmatic
with each substitution transition. The requirement on a protocol system module
is that all substitution transitions are annotated with either a principal or
a channel pragmatic. Furthermore, two substitution transitions representing
principals cannot be directly connected via a place: there must be a substitution transition representing a channel in between reflecting that principals can
communicate via channels only.
Definition 4. A Protocol System Module of a PA-CPN with a structural
pragmatics mapping SP is a tuple CP N P SM = (CP N P SM , P M ), where:
1. CP N P SM = ((P P SM , T P SM , AP SM , ΣP SM , V P SM , C P SM , GP SM , E P SM ,
P SM
P SM
, Pport
, P T P SM ) is a CPN module such that all transitions
I P SM ), Tsub
P SM
are substitution transitions: T P SM = Tsub
.
P SM
2. P M : Tsub → {principal, channel} is a pragmatics mapping s.t.:
(a) All substitution transitions are annotated with either a principal or

P SM
channel pragmatic: ∀t ∈ Tsub
: P M (t) ∈ {principal, channel}.
(b) The pragmatics mapping P M must coincide with the structural pragmatic
P SM
: P M (t) = SP (t).
mapping SP of PA-CPN: ∀t ∈ Tsub
(c) All places are connected to at most one substitution transition with
principal and at most one substitution transition with channel :
∀p ∈ P P SM : ∀t1 , t2 ∈ X(p) : P M (t1 ) = P M (t2 ) ⇒ t1 = t2 .
Principal Level Module (PLM). On the principal level, there is one module for
each principal of the protocol as defined by the principal pragmatic on the
protocol system level. Our example protocol has two modules at the principal
level corresponding to the sender and the receiver. Figure 1 (right) shows the
principal level module for the sender. The principal level module represents the
services that the principal is providing, and the internal state and life-cycle of the
principal. For the sender, there are two services as indicated by the service
and internal pragmatics on send and receiveAck. The non-port places of a
principal level module (places drawn without a double border) can be annotated
with either a state or an LCV (life-cycle variable) pragmatic. Places annotated


10

K.I.F. Simonsen et al.

with a state pragmatic represent internal states of the principal. In Fig. 1
(right), there are two places with state used to enforce the stop-and-wait
pattern when sending data messages and receiving acknowledgements. Places
annotated with an LCV pragmatic represent the life-cycle of the principal and

restrict the order in which services can be invoked. As an example, the place
ready in Fig. 1 (right) ensures that only one message at a time is sent using the
send service.
A principal level module is defined as a tuple consisting of a CPN module and
a principal level pragmatic mapping. Each service is represented by a substitution
transition which can be annotated with either a service or an internal
pragmatic depending on whether the service is visible externally or not.
Definition 5. A Principal Level Module of a PA-CPN is a tuple
P LM
P LM
, Pport
, P T P LM , P LP ) where:
CP N P LM = (CP N P LM , Tsub
1. CP N P LM = ((P P LM , T P LM , AP LM , ΣP LM , V P LM , C P LM , GP LM , E P LM ,
P LM
P LM
, Pport
, P T P LM ) is a CPN module with only substitution tranI P LM ), Tsub
P LM
P LM
sitions: T
= Tsub .
P LM
P LM
∪ P P LM \Pport
→ {service, internal, state, LCV} is a
2. P LP : Tsub
principal level pragmatics mapping satisfying:
(a) All non-port places are annotated with either a state or a LCV pragP LM
⇒ P LP (p) ∈ {state, LCV}

matic: ∀p ∈ P P LM \Pport
(b) All substitution transitions are annotated with a service or internal
P SM
pragmatic: ∀t ∈ Tsub
: P LP (t) ∈ {service, internal}.
It should be noted that we do not associate pragmatics with the port places
as it follows from the definition of the protocol system module that a port place
in a principal level module can only be associated with a socket place connected
to a substitution transition with a channel pragmatic.
Service Level Module (SLM). The service level modules specify the behaviour of
the respective services of the principals. They constitute the lowest level modules in a PA-CPN model. In particular, there are no substitution transitions
in modules at this level. The module in Fig. 3 is an example of a module at
the service level. It models the behaviour of the send service in a control flow
oriented manner. The control flow path, which defines the control flow of the
service, is made explicit via the use of the Id pragmatics. The entry point of
the service is indicated by annotating a single transition with a service pragmatic, and the exit (termination) point of the service is indicated by annotating
a single transition with a return pragmatic. In addition, non-port places can
be annotated with a state pragmatic to indicate that this place models a local
state of the service. The driver pragmatic is used by service tester modules
(see Sect. 6) to facilitate verification. The places associated with Id pragmatic
determine a subnet of the module, which we call the underlying control flow
net: it is obtained by removing all CPN annotations and considering only places
with Id pragmatic and transitions connected to these places, which in Fig. 3, are