Mapping Petri Nets onto a Calculus of Context-Aware Ambients

Abstract

Petri nets are a graphical notation for describing a class of discrete event dynamic systems whose behaviours are characterised by concurrency, synchronisation, mutual exclusion and conflict. They have been used over the years for the modelling of various distributed systems applications. With the advent of pervasive systems and the Internet of Things, the Calculus of Context-aware Ambients (CCA) has emerged as a suitable formal notation for analysing the behaviours of these systems. In this paper, we are interested in comparing the expressive power of Petri nets to that of CCA. That is, can the class of systems represented by Petri nets be modelled in CCA? To answer this question, an algorithm is proposed that maps any Petri net onto a CCA process. We prove that a Petri net and its corresponding CCA process are behavioural equivalent. It follows that CCA is at least as expressive as Petri nets, i.e., any system that can be specified in Petri nets can also be specified in CCA. Moreover, tools developed for CCA can also be used to analyse the behaviours of Petri nets.

1. Introduction

Over the years, a large number of mathematical formalisms for concurrency theory have been developed, each with its distinct features. Petri nets [1,2] were among the first formalisms for modelling interacting sequential processes. Then, Tony Hoare developed the calculus of Communicating Sequential Processes (CSP) [3], and Robin Milner the Calculus of Communicating Systems (CCS) [4]. These formalisms provided notations for modelling different forms of concurrency. Later on, the $\pi$-calculus [5] was introduced to extend CCS with the notion of mobility. In the $\pi$-calculus, mobility is modelled using the mechanism of scope extrusion, i.e., a name sent through a receptor (i.e., a name that is used to receive messages) can also be used as a receptor. However, this makes the implementation of the $\pi$-calculus difficult in distributed systems. Join-calculus [6] was thus developed by Fournet and Gonthier to provide a formal basis for the design of distributed programming languages, by replacing the communication and mobility mechanisms of $\pi$-calculus with the notion of join definition, which is much easier to implement in distributed systems. Recently, the Calculus of Context-aware Ambients (CCA) [7,8], inspired by the Calculus of Mobile Ambient (MA) [9], was developed to provide constructs for concurrency, mobility and context awareness based on a single notion of ambient, which is an abstraction of a place where computation can happen. CCA emerges as a suitable formalism to reason with the behaviours of pervasive systems and the Internet of Things [10].

It is customary in formal methods to compare the expressive powers of formalisms, i.e., whether one formalism can be mapped onto another. In [11], Mennicke presents operational Petri net semantics for join-calculus. An approach to mapping Petri nets to concurrent programs in CC++ is proposed in [12], which establishes a link between Petri nets and object-oriented concurrent programming and forms a foundation for a Petri-net-based transformational software development methodology. Similarly, Ref. [13] proposes a mapping from Petri nets to the language of the B-Method in an effort to incorporate the Petri nets’ graphical notation into a software development method based on the B-language. A mapping of Petri nets to DEVS (Discrete Event System Specification) is presented in [14], so DEVS-based platforms can be used to analyse systems specified in Petri nets.

This paper proposes an approach to mapping Petri nets onto CCA. This allows for the graphical language of Petri nets to be used in combination with CCA for the modelling of complex distributed systems. The contributions of the paper is fivefold:

• We propose an algorithm that transforms any Petri net into a CCA process (Section 2.3).
• We prove that a Petri net and its corresponding CCA process are behavioural equivalents (Section 2.3.3). This shows that CCA is at least as expressive as Petri nets, i.e., any system that can be specified in Petri nets can also be specified in CCA.
• We demonstrate that the proposed algorithm is efficient and scalable (Section 2.3.4). Indeed, the time complexity of the algorithm is quadratic (i.e., the execution time is in the order of the square of the size of the Petri net in input) and the size of the CCA process generated in output grows linearly with the size of the Petri net in input.
• The proposed algorithm is implemented in Python so a Petri net can be translated into a CCA process automatically at a click of a button (Section 2.3.4 and Appendix A).
• The proposed approach is illustrated using a case study of the dining cryptographers problem (Section 3).

The remainder of the paper is structured as follows. Section 2 presents the proposed algorithm for mapping Petri nets onto CCA and discusses the efficiency and scalability of the algorithm. The notion of behavioural equivalence is also introduced in this section. The case study is presented in Section 3. In Section 4, we discuss the results. Section 5 concludes the paper and proposes future work.

2. Materials and Methods

2.1. Overview of Petri Nets

Petri nets are a graphical formalism to describe systems whose dynamics are characterised by concurrency, synchronisation, mutual exclusion and conflict [2,15]. A Petri net consists of places, transitions, and directed arcs. A place is represented by a circle and a transition by a rectangle. Arcs run from a place to a transition or vice versa, and never between places or between transitions. A place may contain a non-negative integer number of marks called tokens. An example of a Petri net is depicted in Figure 1. Any distribution of tokens over the places will represent a configuration of the net called a marking.

The places from which an arc runs to a transition are called the input places of the transition; the places to which arcs run from a transition are called the output places of the transition. Similarly, the transitions from which an arc runs to a place are called the input transitions of the place; the transitions to which arcs run from a place are called the output transitions of the place. Therefore, a Petri net can be defined formally as a tuple $(P,T,I,O,m_0)$, where

• P is a finite set of places.
• T is a finite set of transitions, such that $P\cup T\ne \varnothing$ and $P\cap T=\varnothing$.
• $I:P\times T\to \mathbb{N}$ is an input function. $I(p,t)$ is the number of directed arcs from the place p to the transition t.
• $O:T\times P\to \mathbb{N}$ is an output function. $O(t,p)$ is the number of directed arcs from the transition t to the place p.
• $m_0:P\to \mathbb{N}$ is the initial marking, which defines the initial number of tokens in each place.

Example 1. 

The Petri net shown in Figure 1 models the following ball game [16]. The tokens in the places red and black represent red and black balls in an urn, respectively. As long as there are at least two balls in the urn, a person takes two balls from the urn. If the balls are of the same colour, then a black ball is returned; otherwise, a red ball is returned. Transition rb fires if the person takes two balls of different colours, transition rr fires if two red bails are taken and transition bb fires if two black balls are taken. This Petri net is formally defined as follows:

• $P=\{red,black\}$
• $T=\{bb,rb,rr\}$
• $I=\left\{\right(red,bb,0),(red,rb,1),(red,rr,2),(black,bb,2),(black,rb,1),(black,rr,0\left)\right\}$
• $O=\left\{\right(bb,red,0),(rb,red,1),(rr,red,0),(bb,black,1),(rb,black,0),(rr,black,1\left)\right\}$
• $m_0=\{(red,3),(black,2)\}$

Let us denote by $Input\left(t\right)$ (with respect to $Output\left(t\right)$) the set of all input places (with respect to all output places) of a transition t, i.e., $Input\left(t\right)=\{p\in P|I(p,t)>0\}$ and $Output\left(t\right)=\{p\in P|O(t,P)>0\}$. Transitions are the active components of a Petri net. A transition t is enabled if each of its input places p contains at least $I(p,t)$ tokens, as formulated in (1), where m is the marking of the Petri net.

$$enabled\left(t\right)=\forall p\in Input\left(t\right):m\left(p\right)\ge I(p,t).$$

(1)

A transition may execute (or fire) if it is enabled. The execution of a transition t is atomic and consumes $I(p,t)$ tokens from each input place p, and creates $O(t,p)$ tokens in each output place p. Therefore, the execution of a transition t updates the marking of each place p connected to it, as in (2), where $m\left(p\right)$ is the marking of a place p before the transition is executed and $m^{\prime }\left(p\right)$ is the marking of a place p after the transition is executed.

$$m^{\prime }\left(p\right)=m\left(p\right)-I(p,t)+O(t,p).$$

(2)

For example, Figure 2 shows the marking of the Petri net of Figure 1 after the transition $rr$ has been executed. The execution of Petri nets is non-deterministic: when multiple transitions are enabled at the same time, they will execute in any order.

2.2. Overview of CCA

CCA [7,8] is a process calculus for specifying and reasoning regarding the behaviour of context-aware, mobile and concurrent systems. CCA is based on a single notion of ambient, which conceptualises an entity in which a computation can happen. An ambient is represented in the form $n\left[P\right]$, where n is the name of the ambient and P is a process describing the behaviour of the ambient. We can also say that the process P is executed by the ambient n. An ambient can contain other ambients, called child ambients, forming a hierarchy of ambients. For example, in $n\left[P\right|m\left[Q\right]]$, n is the parent ambient of m and m is a child ambient of n. Two ambients that have the same parent are siblings. There is a special ambient called root, which represents the root of the ambient hierarchy. Any ambient in CCA is a descendent of the root ambient. Ambients can be composed in parallel, using the parallel operator “|”, to form a concurrent system. During their execution, ambients can communicate through a hand-shake message passing mechanism; i.e., an ambient (the sender) can send a message to another ambient (the receiver) and the sender and the receiver must synchronise for the communication to happen, as explained in Section 2.2.2. An ambient can be mobile; the mobility capabilities “$\mathtt{in}$” and “$\mathtt{out}$”, described in Section 2.2.2, allow an ambient to move inside a sibling ambient and outside its parent ambient, respectively. An ambient can also be aware of its context so that its behaviour can change in response to changes in the context. This is undertaken using context expressions and context-guarded processes (see Section 2.2.4). A context expression is a predicate over the state of the ambient hierarchy. In distributed systems, each component of a system can be modelled as an ambient, e.g., sensors and computers. An example is given in Section 2.2.5.

CCA is formally described by the grammar in

Table 1. Syntax of CCA.

$P,Q$	$::=$		Processes	$\kappa$	$::=$		Context Expressions
		$\mathtt{0}$	inactivity			$\mathtt{0}$	empty context
		$P|Q$	parallel composition			$\mathtt{true}$	true
		$\left\{P\right\}$	block			$\mathtt{false}$	false
		$\left(\mathtt{new}n\right)P$	name restriction			$n=m$	name match
		$!P$	replication			$\mathtt{this}$	hole
		$n\left[P\right]$	ambient			$n\left[\kappa \right]$	location context
		$<\kappa >M.P$	context-guarded prefix			${\kappa }_1|{\kappa }_2$	parallel composition
		$\mathtt{if}<{\kappa }_1>M_1.P_1$	if-then			${\kappa }_1\mathtt{and}{\kappa }_2$	conjunction
		…				${\kappa }_1\mathtt{or}{\kappa }_2$	disjunction
		$<{\kappa }_{\ell }>M_{\ell }.P_{\ell }\mathtt{fi}$				$\mathtt{not}\kappa$	negation
		$\mathtt{if}<{\kappa }_1>M_1.P_1$	if-then-else			$\mathtt{next}\kappa$	spatial next modality
		$\dots$				$\mathtt{somewhere}\kappa$	somewhere modality
		$<{\kappa }_{\ell }>M_{\ell }.P_{\ell }\mathtt{else}P\mathtt{fi}$
		$\mathtt{let}{x}_1=e_1,\dots ,x_{\ell }=e_{\ell }\mathtt{in}P$	arithmetic
		$\mathtt{find}{x}_1,\dots ,x_{\ell }:\kappa \mathtt{for}P$	search
		$\mathtt{proc}x(y_1,\dots ,y_{\ell })P$	process abstraction
M	$::=$		Capabilities	$\alpha$	$::=$		Locations
		$\mathtt{skip}$	one transition			@	any parent
		$\mathtt{in}n$	move into ambient n			$n@$	specific parent n
		$\mathtt{out}$	move out of parent			#	any child
		$\mathtt{del}n$	delete ambient n			$n\#$	specific child n
		$\alpha \mathtt{recv}(y_1,\dots ,y_{\ell })$	receive data from $\alpha$			$::$	any sibling
		$\alpha \mathtt{send}(z_1,\dots ,z_{\ell })$	send data to $\alpha$			$n::$	specific sibling n
		$\alpha x(z_1,\dots ,z_{\ell })$	process abstraction call			$ϵ$	locally

, based on three syntactic categories: processes P (or Q), capabilities M, and context expressions $\kappa$. The symbols n, x, y and z are names. Note that comments can be added anywhere in a specification using the prefix // for a single line comment or the pair /* and */ for a multiline comment.

2.2.1. Processes

The syntax of a process P is given in Table 1. The process $\mathtt{0}$, also known as the inactivity process, does nothing and terminates immediately. The process $P|Q$ denotes the parallel composition of the processes P and Q. A process of the form $\left\{P\right\}$ behaves just like P. The process $\left(\mathtt{new}n\right)P$ creates a new name n and the scope of that name is limited to the process P. The replication $!P$ denotes a process which can always create a new parallel copy of P, i.e., $!P$ is equivalent to $P|!P$. The process $n\left[P\right]$ denotes an ambient named n whose behaviour is described by the process P. A context expression $\kappa$ is a logical formula that specifies a property upon the state of the environment. A context-guarded prefix $<\kappa >M.P$ is a process that waits until the environment satisfies the context expression $\kappa$, and then performs the capability M and continues like the process P. We let $M.P$ denote the process $<\mathtt{true}>M.P$. An if-then process $\mathtt{if}<{\kappa }_1>M_1.P_1\dots <{\kappa }_{\ell }>M_{\ell }.P_{\ell }\mathtt{fi}$ waits until at least one of the context expressions ${\left({\kappa }_i\right)}_{1\le i\le \ell }$ holds, and then proceeds non-deterministically like one of the $<{\kappa }_j>M_j.P_j$ processes for which ${\kappa }_j$ holds. An if-then-else process $\mathtt{if}<{\kappa }_1>M_1.P_1\dots <{\kappa }_{\ell }>M_{\ell }.P_{\ell }\mathtt{else}P\mathtt{fi}$ behaves like an if-then process, but does not wait and continues like the P process if none of the branches can be executed. A process $\mathtt{let}{x}_1=e_1,\dots ,y_{\ell }=e_{\ell }\mathtt{in}P$ behaves like the process P in which each occurrence of $x_i$ is substituted to the value of the arithmetic expression $e_i$, for $1\le i\le \ell$ and $\ell \ge 1$. A search process $\mathtt{find}{x}_1,\dots ,x_{\ell }:\kappa \mathtt{for}P$ looks for a list of names $n_1,\dots ,n_{\ell }$ in the context such that the context expression $\kappa$ in which each occurrence of $x_i$ is replaced by $n_i$ holds, and continues like the process P in which each occurrence of $x_i$ is replaced with $n_i$, $1\le i\le \ell$ and $\ell \ge 1$. A process of the form $\mathtt{proc}x(y_1,\dots ,y_{\ell })P$ defines a process abstraction named x, whose behaviour is described by the process P. The names $y_1,\dots ,y_{\ell }$ are the formal parameters and the process abstraction is $\ell \ge 0$. A process abstraction is a mechanism to give a name, say x, to a process P and to later use that name anywhere to refer to the process P, just the same way as functions and procedures are used in programming languages.

2.2.2. Capabilities

A capability is an elementary action that an ambient can perform. The syntax of a capability M is given in Table 1. The capability $\mathtt{skip}$ represents one transition, i.e., one execution step. An ambient can move into a sibling ambient n by performing the capability $\mathtt{in}n$, and move out of its parent ambient by executing the capability $\mathtt{out}$. An ambient can exchange messages with another ambient using the output capability $\alpha \mathtt{send}(z_1,\dots ,z_{\ell })$ to send a list of names $z_1,\dots ,z_{\ell }$ to a location $\alpha$, and the input capability $\alpha \mathtt{recv}(y_1,\dots ,y_{\ell })$ can receive a list of names from a location $\alpha$ for the variables $y_1,\dots ,y_{\ell }$, for some $\ell \ge 0$. The location $\alpha$ can be ‘@’ to mean any parent, ‘$n@$’ to mean a specific parent n, ‘#’ to mean any child ambient, ‘$n\#$’ to mean a specific child n, ‘$::$’ to mean any sibling, ‘$n::$’ to mean a specific sibling n, or  $ϵ$ (empty string) to mean the executing ambient itself. A capability $\mathtt{del}n$ deletes an empty child ambient n (i.e., $n\left[\mathtt{0}\right]$). A capability of the form $\alpha x(z_1,\dots ,z_{\ell })$ calls the process abstraction x defined at the location $\alpha$, and the names $z_1,\dots ,z_{\ell }$ are the actual parameters, $\ell \ge 0$.

2.2.3. Context Model

In CCA, a context is modelled as a process with possibly a single hole in it. The hole (denoted by ⊙) in a context C represents the position of the process, for which C is a context. For example, suppose a system is modelled by the process $P\left|n\right[Q\left|m\right[R\left|S\right]]$. Therefore, the context of the process R in that system is $P\left|n\right[Q\left|m\right[\odot \left|S\right]]$, and  that of the ambient named m is $P\left|n\right[Q|\odot ]$. Thus, the context of a CCA process is described by the grammar in

Table 2. Syntax of contexts.

C

$::=$

$\mathtt{0}|\odot |n\left[C\right]\left|C\right|P\left|\right(\mathtt{new}n)C$

. A context expression (CE, for short) is a formula representing some property over context.

2.2.4. Context Expressions

The syntax of a process expression $\kappa$ is given in Table 1. The formal semantics of context expressions (CEs) with respect to the context model of Table 2 are given in

Table 3. Satisfaction relation for context expressions.

	⊧	$\mathtt{true}$
C	⊧	$n=m$	iff	$n=m$
C	⊧	$\mathtt{0}$	iff	$C=\mathtt{0}$
C	⊧	$\mathtt{this}$	iff	$C=\odot$
C	⊧	$\mathtt{not}\kappa$	iff	$C\cancel{\vDash }\kappa$
C	⊧	${\kappa }_1|{\kappa }_2$	iff	$\mathrm{exist}{C}_1,C_2\mathrm{such} \mathrm{that}C=C_1|C_2$$\mathrm{and}{C}_1\vDash {\kappa }_1\mathrm{and}{C}_2\vDash {\kappa }_2$
C	⊧	${\kappa }_1\mathtt{and}{\kappa }_2$	iff	$C\vDash {\kappa }_1 \mathrm{and} C\vDash {\kappa }_2$
C	⊧	$n\left[\kappa \right]$	iff	$\mathrm{exists}{C}^{\prime }\mathrm{such} \mathrm{that}C=n\left[C^{\prime }\right]\mathrm{and}{C}^{\prime }\vDash \kappa$
C	⊧	$\mathtt{next}\kappa$	iff	$\mathrm{exist}{C}^{\prime },n\mathrm{such} \mathrm{that}C=n\left[C^{\prime }\right]\mathrm{and}{C}^{\prime }\vDash \kappa$
C	⊧	$\mathtt{somewhere}\kappa$	iff	$C\vDash \kappa$ or $\mathrm{exist}{C}^{\prime },n\mathrm{such} \mathrm{that}C=n\left[C^{\prime }\right]\mathrm{and}$ $C^{\prime }\vDash \mathtt{somewhere}\kappa$

, where the notation $C\vDash \kappa$ means that the context C satisfies the context expression $\kappa$. We also write $\vDash \kappa$ to mean that a context expression $\kappa$ is valid, i.e., $\kappa$ is satisfied by all contexts.

The CE $\mathtt{true}$ holds for all contexts, while the CE $\mathtt{false}$ holds for no context. A CE $n=m$ holds if the names n and m are identical. The CE $\mathtt{0}$ holds for the empty context $\mathtt{0}$. The CE $\mathtt{this}$ holds solely for the hole context, i.e., the position of the process evaluating that context expression. Propositional operators such as $\mathtt{not}$, $\mathtt{and}$ and $\mathtt{or}$ expand their usual semantics to context expressions. A CE ${\kappa }_1|{\kappa }_2$ holds for a context if that context is a parallel composition of two contexts such that ${\kappa }_1$ holds for one and ${\kappa }_2$ holds for the other. A CE $n\left[\kappa \right]$ holds for a context if that context is an ambient named n such that $\kappa$ holds inside that ambient. A CE $\mathtt{next}\kappa$ holds for a context if that context has a child context for which $\kappa$ holds. A CE $\mathtt{somewhere}\kappa$ holds for a context if there exists somewhere in that context a sub-context for which $\kappa$ holds. Some examples of context expressions that are used later in this paper are given in

Table 4. Examples of context expressions.

$has\left(n\right)$	=	$\mathtt{somewhere}\left(\mathtt{this}\right|n\left[\mathtt{true}\right]\left|\mathtt{true}\right)$	n is located at self.
$at\left(n\right)$	=	$\mathtt{somewhere}\left(n\right[\mathtt{next}\left(\mathtt{this}\right|\mathtt{true}\left)\right]\left|\mathtt{true}\right)$	self is located at n.
$at(n,m)$	=	$\mathtt{somewhere}\left(n\right[m\left[\mathtt{true}\right]\left|\mathtt{true}\right]\left|\mathtt{true}\right)$	m is located at n.
$with\left(n\right)$	=	$\mathtt{somewhere}\left(n\right[\mathtt{true}\left]\right|\mathtt{next}\left(\mathtt{this}\right|\mathtt{true}\left)\right|\mathtt{true})$	self is with n.
$with(n,m)$	=	$\mathtt{somewhere}\left(n\right[\mathtt{true}\left]\right|m\left[\mathtt{true}\right]\left|\mathtt{true}\right)$	n is with m.
$state(p,x)$	=	$\mathtt{somewhere}\left(p\right[x\left[0\right]\left|\mathtt{true}\right]\left|\mathtt{true}\right)$	the current state of p is x.
$state\left(x\right)$	=	$\mathtt{somewhere}\left(p\right[x\left[0\right]\left|\mathtt{true}\right]\left|\mathtt{true}\right)$	self current state is x.
$lockOn\left(\right)$	=	$\mathtt{somewhere}\left(lock\right[on\left[0\right]\left|\mathtt{true}\right]\left|\mathtt{true}\right)$	the lock is on.

.

Context expressions are used in CCA to specify context-aware processes. We recall in

Table 5. Semantics of context-aware processes.

(R1)	$C(M.P)⟶C^{\prime }\left(P\sigma \right)\Rightarrow C(<\kappa >M.P)⟶C^{\prime }\left(P\sigma \right)$   if $C\vDash \kappa$
(R2)	$C(<{\kappa }_i>M_i.P_i)⟶C^{\prime }\left(P_i\sigma \right)$
	$\Rightarrow C(\mathtt{if}<{\kappa }_1>M_1.P_1\dots <{\kappa }_{\ell }>M_{\ell }.P_{\ell }\mathtt{fi})⟶C^{\prime }\left(P_i\sigma \right)$, for some i, $1\le i\le \ell$.
(R3)	$C(\mathtt{if}<{\kappa }_1>M_1.P_1\dots <{\kappa }_{\ell }>M_{\ell }.P_{\ell }\mathtt{fi})⟶C^{\prime }\left(P_i\sigma \right)$
	$\Rightarrow C(\mathtt{if}<{\kappa }_1>M_1.P_1\dots <{\kappa }_{\ell }>M_{\ell }.P_{\ell }\mathtt{else}P\mathtt{fi})⟶C^{\prime }\left(P_i\sigma \right)$
(R4)	$C(\mathtt{if}<{\kappa }_1>M_1.P_1\dots <{\kappa }_{\ell }>M_{\ell }.P_{\ell }\mathtt{else}P\mathtt{fi})⟶C\left(P\right)$
	if $\forall i\in [1,\ell ]\cancel{\exists }(C^{\prime },\sigma )\mathrm{such} \mathrm{that}C(<{\kappa }_i>M_i.P_i)⟶C^{\prime }\left(P_i\sigma \right)$.
(R5)	$C(\mathtt{find}{x}_1,\dots ,x_{\ell }:\kappa \mathtt{for}P)⟶C\left(P\{x_1\leftarrow n_1,\dots ,x_{\ell }\leftarrow n_{\ell }\}\right)$
	if $C\vDash \kappa \{x_1\leftarrow n_1,\dots ,x_{\ell }\leftarrow n_{\ell }\}$
(R6)	$C(\mathtt{let}{x}_1=e_1,\dots ,x_{\ell }=e_{\ell }\mathtt{in}P)\equiv C\left(P\{x_1\leftarrow val\left(e_1\right),\dots ,x_{\ell }\leftarrow val\left(e_{\ell }\right)\}\right)$
(R7)	$\mathtt{skip}.P⟶P$
(R8)	$\mathtt{del}n.P\left|n\right[\mathtt{0}]⟶P$
(R9)	$!P⟶P|!P$
(R10)	$\mathtt{recv}(y_1,\dots ,y_{\ell }).P|\mathtt{send}(z_1,\dots ,z_{\ell }).Q⟶P\{y_1\leftarrow z_1,\dots ,y_{\ell }\leftarrow z_{\ell }\}|Q$, for $\ell \ge 0$
(R11)	$n[::\mathtt{recv}(y_1,\dots ,y_{\ell }).P|R]|m[::\mathtt{send}(z_1,\dots ,z_{\ell }).Q|S]⟶$
	$n\left[P\{y_1\leftarrow z_1,\dots ,y_{\ell }\leftarrow z_{\ell }\}\right|R]|m\left[Q\right|S]$, for $\ell \ge 0$
(R12)	$n[::\mathtt{recv}(y_1,\dots ,y_{\ell }).P|R]|m[n::\mathtt{send}(z_1,\dots ,z_{\ell }).Q|S]⟶$
	$n\left[P\{y_1\leftarrow z_1,\dots ,y_{\ell }\leftarrow z_{\ell }\}\right|R]|m\left[Q\right|S]$, for $\ell \ge 0$
(R13)	$n[m::\mathtt{recv}(y_1,\dots ,y_{\ell }).P|R]|m[::\mathtt{send}(z_1,\dots ,z_{\ell }).Q|S]⟶$
	$n\left[P\{y_1\leftarrow z_1,\dots ,y_{\ell }\leftarrow z_{\ell }\}\right|R]|m\left[Q\right|S]$, for $\ell \ge 0$
(R14)	$n[m::\mathtt{recv}(y_1,\dots ,y_{\ell }).P|R]|m[n::\mathtt{send}(z_1,\dots ,z_{\ell }).Q|S]⟶$
	$n\left[P\{y_1\leftarrow z_1,\dots ,y_{\ell }\leftarrow z_{\ell }\}\right|R]|m\left[Q\right|S]$, for $\ell \ge 0$

the formal semantics of context-aware processes, where $\sigma$ is a substitution of names, ≡ is the congruence relation of processes and ⟶ is the reduction relation of processes. The notation $val\left(e\right)$ represents the value of an expression e. The complete formal semantics of CCA can be found in [7,8].

2.2.5. An Example

This example illustrates how to model a distributed system in CCA. Consider a simple access control system that consists of a RFID tag, RFID reader, a garage door and a server. The system controls access to the garage through the door. When the reader detects an RFID tag, it reads the ID (aka identification) number of the tag and sends an access request to the server. The server checks if the ID number is valid (i.e., permitted to access), in which case the reader shows a green light and the garage door opens. If the ID number is invalid, the reader shows a red light (to mean that the access request is denied) and the door stays closed. Let us assume that a valid ID number is a value between 100 and 200, exclusive. Each component (RFID tag, RFID reader, garage door and the server) of this distributed system can be modelled as an ambient in CCA.

Indeed, an RFID tag is a device that stores an ID number. The ID number is sent to an RFID reader when the tag is in the range of the reader. In CCA, an RFID tag and an RFID reader can be represented as ambients. The boundary of the reader ambient delimits the range of the reader, i.e., an RFID tag is in the range of a reader if that tag is a child ambient of the reader. An RFID tag that contains the ID number 166 can be modelled in CCA by the ambient in Listing 1. It is assumed that initially the RFID tag is not in the range of the RFID reader, and then it moves into the range of the reader using the capability “in” (described in Section 2.2).

Listing 1. The ambient representing the RFID tag.

RFID_tag[ !@send(166).0 | in RFID_reader.0 ]

An RFID reader can be specified, as in Listing 2. It reads the value of an RFID tag and requests the access control service (ac_service) from the server. Upon receipt of a response (status) from the server, the reader shows a green light (status=valid) to indicate that the access request is authorised, and a red light (status=invalid) if the access request is denied.

Listing 2. The ambient representing the RFID reader.

RFID_reader[ !recv().#recv(id).server::send(RFID_reader, ac_service, id). server::recv(status).send().0 | send().0 ]

The server can be modelled as the ambient in Listing 3. It receives a service request from a client and executes the requested service. A service is modelled as a process abstraction. In this example, there is only one service: the access control service ac_service.

Listing 3. The ambient representing the server.

server[ proc ac_service(client, door, id) { if < (id>100) and (id<200) > client::send(valid). door::send(open).send().0 else client::send(invalid).door::send(close).send().0 fi } | !recv().::recv(client, service, id).service(client, garage_door, id).0 | send().0 ]

The last component of the system to specify is the garage door. The door can be controlled by the server and is modelled by the ambient in Listing 4. It closes if it receives the command “close” from the server and opens if it receives the command “open”. The current state of the door (closed/opened) is checked using the context expression $state\left(x\right)$ defined in Table 4.

Listing 4. The ambient representing the garage door.

garage_door[ !recv().server::recv(x). if < x = close and state(opened) > del opened.send().closed[0] < x = open and state(closed) > del closed.send().opened[0] else send().0 fi | send().0 | closed[0] // initially the door is closed. ]

The overall access control system is modelled in Listing 5 as the parallel composition of its four components described in Listings 1–4.

Listing 5. The CCA process representing the access control system of Section 2.2.5.

RFID_tag[ !@send(166).0 | in RFID_reader.0 ] | RFID_reader[ !recv().#recv(id).server::send(RFID_reader, ac_service, id). server::recv(status).send().0 | send().0 ] | server[ proc ac_service(client, door, id) { if < (id>100) and (id<200) > client::send(valid). door::send(open).send().0 else client::send(invalid).door::send(close).send().0 fi } | !recv().::recv(client, service, id).service(client, garage_door, id).0 | send().0 ] | garage_door[ !recv().server::recv(x). if < x = close and state(opened) > del opened.send().closed[0] < x = open and state(closed) > del closed.send().opened[0] else send().0 fi | send().0 | closed[0] // initially the door is closed. ]

Since CCA specifications are executable, the simple access control system can be analysed using the CCA simulator ccaPL, and the simulation outputs are illustrated in Figures 4 and 5 in Section 3.1. The next section presents an algorithm for translating a Petri net into an equivalent CCA process.

2.3. An Algorithm for Mapping a Petri Net onto a CCA Process

Algorithm 1 translates a Petri net (see Section 2.1) into a CCA process. The algorithm takes as input a Petri net $(P,T,I,O,m_0)$ and returns in output a CCA process in the variable $cca\_str$. In CCA, Petri net places and transitions are modelled as ambients, as explained in Section 2.3.1 and Section 2.3.2. We call a place ambient an ambient that models a Petri net place. Likewise, we call a transition ambient an ambient that models a Petri net transition. A semaphore is used to guarantee that the execution of a transition ambient is atomic, i.e., at most one transition ambient can be executed at a time. In order to execute, a transition ambient must obtain the semaphore; otherwise, the transition ambient must wait until the semaphore is released by another transition ambient. This semaphore is described in CCA by the ambient $\mathtt{lock}$ defined in Listing 6. The semaphore is in the obtained state if the ambient contains a child ambient $\mathtt{on}\left[\mathtt{0}\right]$ and is in the released state otherwise.

Algorithm 1: Mapping a Petri net onto a CCA process.

Listing 6. The ambient representing the semaphore $\mathtt{lock}$.

lock[ recv().::recv(t).{ on[0] | t::recv().del on.send().0 } | send().0 ]

The behaviour of the ambient $\mathtt{lock}$ can be explained as follows. Initially, the semaphore is in the released state, i.e., no transition ambient is being executed. The ambient waits (using the capability $::\mathtt{recv}\left(\mathtt{t}\right)$) until a transition ambient t is willing to obtain the semaphore, and then creates a child ambient $\mathtt{on}\left[\mathtt{0}\right]$ to indicate that the semaphore is obtained by the transition ambient t. The semaphore remains in the obtained state until it is released by the transition ambient t (using the capability $\mathtt{t}::\mathtt{recv}\left(\right)$), in which case the child ambient $\mathtt{on}\left[\mathtt{0}\right]$ is deleted. The context expression $\mathtt{lockOn}\left(\right)$ defined in Table 4 holds if the semaphore $\mathtt{lock}$ is in the obtained state, i.e., if it contains a child ambient $\mathtt{on}\left[\mathtt{0}\right]$.

In Algorithm 1, the declaration of the context expression $\mathtt{lockOn}\left(\right)$ is created in line 2, together with other simulation directives such as the execution mode and the simulation length. In ccaPL, these declarations appear between the keywords “BEGIN_DECLS” and “END_DECLS”. The semaphore $\mathtt{lock}$ is created in line 3 of Algorithm 1. The lines 5–7 of Algorithm 1 are explained in Section 2.3.1 and the lines 9–25 are explained in Section 2.3.2.

2.3.1. Modelling Places

In this section, we show how a Petri net place can be modelled as an ambient in CCA. For each place $p\in P$, an ambient (called place ambient) of the same name is created in line 7 of Algorithm 1. The general form of this place ambient is given in Listing 7. Initially, a place ambient contains $m_0\left(p\right)=x$ tokens. This is represented in the place ambient in Listing 7 by the process “$\mathtt{send}\left(\mathtt{x}\right).\mathtt{0}$”. A child ambient of the place ambient is also created as “$\_(\mathtt{1000}+\mathtt{x})\left[\mathtt{0}\right]$”, e.g., if $\mathtt{x}=\mathtt{1}$ then the child ambient is “$\_\mathtt{1001}\left[\mathtt{0}\right]$”. This encoding reflects in the child ambient’s name the number of tokens in the place ambient and satisfies the property stated in Theorem 1. Therefore, the names of the child ambients of the place ambients can be compared instead of the number of tokens of these place ambients. The behaviour of a place ambient can be summarised as follows. A place ambient (see Listing 7) reads its current number of tokens, calculates the name of its child ambient and then waits until a transition ambient it is connected to starts executing (see “$::\mathtt{recv}\left(\mathtt{v}\right)$”). It then deletes its current child ambient, updates its number of tokens according to (2) and creates a child ambient that reflects its new number of tokens. It also signals to the running transition ambient that it has completed updating (see “$::\mathtt{send}\left(\right)$”). For example, the place ambients for the places red and black of the Petri net in Figure 1 are given in Listing 8. The loop in lines 5–7 of Algorithm 1 creates such a place ambient for each place $p\in P$ and composes them in parallel.

Listing 7. General form of a place ambient.

p[ send(x).0 | !recv(n).let zz=_+(1000+n) in ::recv(v).del zz. let w=n+v, y=_+(1000+n+v) in send(w).::send().y[0] | _(1000 + x)[0] ]

Definition 1. 

Let $str\left(z\right)$ be the string representation of an integer value z. For example, $str\left(0\right)=$“0” and $str\left(23\right)=$“23”.

Definition 2. 

The marking (also known as the number of tokens) of a place ambient is a non-negative integer number x such that the name of its child ambient is $‘‘\_’’+str(1000+x)$. For example, the marking of the place ambient $\mathtt{red}$ in Listing 8 is 3 and that of the place ambient $\mathtt{black}$ is 2.

Theorem 1. 

Let n, x and y be three integers such that $n\ge 1$, $0\le x<{10}^n$ and $0\le y<{10}^n$. Then,

$$x\ge y\iff str({10}^n+x)\ge str({10}^n+y).$$

Listing 8. Examples of the place ambients for the places red and black of Figure 1.

red[ send(3).0 | !recv(n).let zz=_+(1000+n) in ::recv(v).del zz. let w= n+v, y=_+(1000+n+v) in send(w).::send().y[0] | _1003[0] ] black[ send(2).0 | !recv(n).let zz=_+(1000+n) in ::recv(v).del zz. let w= n+v, y=_+(1000+n+v) in send(w).::send().y[0] | _1002[0] ]

The proof of Theorem 1 can be carried out by induction on n, as follows.

Proof. 

Let $\parallel z\parallel$ denote the number of digits in a non-negative integer z. For example, $\parallel 0\parallel =1$, $\parallel 23\parallel =2$ and $\parallel 100\parallel =3$.

• Base case:

Prove that the theorem holds for $n=1$.

We have $0\le x<10\Rightarrow \parallel x\parallel =1$. Similarly, $\parallel y\parallel =1$. Therefore, $x\ge y\Rightarrow str(10+x)=$“$1x$” $\ge str(10+y)=$“$1y$”.

Conversely, “$1x$” ≥“$1y$” ⇒ “x” ≥ “y”. And since $\parallel x\parallel =1$ and $\parallel y\parallel =1$, it follows that $x\ge y$.

• Induction case:

Suppose that the theorem holds for n and prove that the theorem also holds for $n+1$.

• If $0\le x<{10}^n$ and $0\le y<{10}^n$, then $0\le x<{10}^{n+1}$, and $0\le y<{10}^{n+1}$. Let $str({10}^n+x)=$“$1\overline{x}$” and $str({10}^n+y)=$“$1\overline{y}$”, for some strings $\overline{x}$ and $\overline{y}$. It follows that $str({10}^{n+1}+x)=$“$10\overline{x}$” and $str({10}^{n+1}+y)=$“$10\overline{y}$”. In string comparison, “$1\overline{x}$” ≥ “$1\overline{y}$” ⇔ “$10\overline{x}$”≥ “$10\overline{y}$”. We conclude that $x\ge y\iff str({10}^{n+1}+x)\ge str({10}^{n+1}+y).$
• If ${10}^n\le x<{10}^{n+1}$ and $0\le y<{10}^n$, then $\parallel x\parallel \ge \parallel y\parallel +1$. Let $str({10}^{n+1}+x)=$“$1\sigma \overline{x}$” and $str({10}^{n+1}+y)=$“$10\overline{y}$” for some digits $\sigma \ge 1$ and strings $\overline{x}$ and $\overline{y}$ of equal length n. Since $\sigma \ge 1$, “$1\sigma \overline{x}$” ≥ “$10\overline{y}$” is always true. Therefore, we conclude that $x\ge y\iff str({10}^{n+1}+x)\ge str({10}^{n+1}+y).$
• If ${10}^n\le x<{10}^{n+1}$ and ${10}^n\le y<{10}^{n+1}$, then let $x=\sigma \times {10}^n+x^{\prime }$ and $y=\theta \times {10}^n+y^{\prime }$, for some integers $x^{\prime }<{10}^n$ and $y^{\prime }<{10}^n$, and digits $\sigma \ne 0$ and $\theta \ne 0$. There are two cases: $\sigma =\theta$ or $\sigma \ne \theta$.

  -

  If $\sigma =\theta$, then $x\ge y\iff (\sigma \times {10}^n+x^{\prime }\ge \sigma \times {10}^n+y^{\prime })\iff x^{\prime }\ge y^{\prime }\iff str({10}^n+x^{\prime })\ge str({10}^n+y^{\prime })\iff str(\sigma \times {10}^n+x^{\prime })\ge str(\sigma \times {10}^n+y^{\prime })\iff str({10}^{n+1}+\sigma \times {10}^n+x^{\prime })\ge str({10}^{n+1}+\sigma \times {10}^n+y^{\prime })\iff str({10}^{n+1}+x)\ge str({10}^{n+1}+y)$.

  -

  If $\sigma \ne \theta$, let $str({10}^{n+1}+x)=$ “ $1\sigma \overline{x^{\prime }}$” and $str({10}^{n+1}+y)=$ “$1\theta \overline{y^{\prime }}$”, for some strings $\overline{x^{\prime }}$ and $\overline{y^{\prime }}$. It follows that “$1\sigma \overline{x^{\prime }}$” > “$1\theta \overline{y^{\prime }}$” $\iff \sigma >\theta \iff \sigma \times {10}^n>\theta \times {10}^n\iff \sigma \times {10}^n+x^{\prime }>\theta \times {10}^n+y^{\prime }\iff x>y$.

Therefore, we conclude that $x\ge y\iff str({10}^{n+1}+x)\ge str({10}^{n+1}+y)$.

   □

2.3.2. Modelling Transitions

Similarly to a place, a Petri net transition can be modelled as an ambient in CCA. Indeed, Algorithm 1, in the lines 9–25, creates for each transition $\mathtt{t}\in T$ an ambient (called transition ambient) named $\mathtt{t}$ of the form described in Listing 9. The transition ambient uses the context expression $state(p,x)$ defined in Table 4 to check if a place ambient p has a child ambient x. Note that the name of a child ambient of a place ambient is encoded to reflect the number of tokens of that place ambient and to satisfy the property stated in Theorem 1. In Listing 9, the variables p1, …, pn denote the names of the input place ambients of the transition ambient and q1, …, qk denote the input or output place ambients of the transition ambient. The behaviour of the transition ambient is an iterative process, which waits until the semaphore $\mathtt{lock}$ is released and then obtains the semaphore $\mathtt{lock}$ (line 2 in Listing 9). It then finds the names of the child ambients of the input place ambients p1, …, pn (line 3) and checks if the guard of the if-statement holds (line 4), in which case the number of tokens of each place ambient connected to it is updated according to (2) (line 5). Finally, the process releases the semaphore $\mathtt{lock}$ and readies itself for further execution (lines 6 and 7). The guard of the if-statement can be formulated as in (3), where t (with respect to p) denotes a transition (with respect to a place) and $t_a$ (with respect to $p_a$) the transition ambient of t (with respect to the place ambient of p).

$$guard\left(t_a\right)=\forall p\in Input\left(t\right)\exists x:state(p_a,x)\wedge x\ge ‘‘\_’’+str(1000+I(p,t)).$$

(3)

Definition 3. 

We say that a transition ambient $t_a$ is enabled if $guard\left(t_a\right)$ holds.

An example of a transition ambient is given in Listing 10 for the transition rr of the Petri net in Figure 1.

Listing 9.General form of a transition ambient.

1. t[ 2. !< not lockOn() >lock::send(t). 3. find _M_p1: state(p1,_M_p1) for ... find _M_pn: state(pn,_M_pn) for if 4. <_M_p1 >=_(1000 + I(p1,t)) and ... and _M_pn >=_(1000 + I(pn,t)) > 5. q1::send(-I(q1,t)+O(t,q1)).q1::recv(). ... .qk::send(-I(qk,t)+O(t,qk)).qk::recv(). 6. lock::send(end).0 7. else lock::send(not_enabled).0 8. fi.0 9. ]

Listing 10.Example of the transition ambient for the transition rr of Figure 1.

rr[ !< not lockOn() >lock::send(rr). find _M_red: state(red,_M_red) for if < _M_red>=_1002 > red::send(-2).red::recv(). black::send(1).black::recv().lock::send(end).0 else lock::send(not_enabled).0 fi.0 ]

In summary, the CCA process generated by Algorithm 1 for a Petri net is the parallel composition of the semaphore $\mathtt{lock}$, all the place ambients and all the transition ambients. For example, the CCA process generated for the Petri net of Figure 1 is presented in Listing 11.

Table 6. Mapping of Petri net concepts to CCA concepts.

Petri Net Concepts	CCA Concepts
a place	an ambient of the form in Listing 7, called place ambient .
a transition	an ambient of the form in Listing 9, called transition ambient.
the number of tokens (also known as marking) of a place	the name of the child ambient of a place ambient encodes the number of tokens of the place ambient, as in Definition 2.
a Petri net	the parallel composition of the semaphore ambient lock defined in Listing 6 with all the place ambients and all the transition ambients. An example is given in Listing 11

summarises the mapping of the Petri net concepts to CCA concepts.

Listing 11.Example of the CCA process generated by Algorithm 1 for the Petri net in Figure 1.

BEGIN_DECLS def lockOn() = { somewhere (lock[on[0] | true] | true) } def state(p,x) = { somewhere (p[x[0] | true] | true) } //display code //display congruence mode random length=100 END_DECLS lock[ ! recv().::recv(t).{ on[0] | t::recv(x).del on.send().0 } | send().0 ] | red[ send(3).0 | !recv(n).let zz=_+(1000+n) in ::recv(v).del zz.let w= n+v, y=_+(1000+n+v) in send(w).::send().y[0] | _1003[0] ] | black[ send(2).0 | !recv(n).let zz=_+(1000+n) in ::recv(v).del zz.let w= n+v, y=_+(1000+n+v) in send(w).::send().y[0] | _1002[0] ] | rb[ !< not lockOn() >lock::send(rb).find _M_red: state(red,_M_red) for find _M_black: state(black,_M_black) for if < _M_red>=_1001 and _M_black>=_1001 > red::send(0).red::recv(). black::send(-1).black::recv().lock::send(end).0 else lock::send(not_enabled).0 fi.0 ] | rr[ !< not lockOn() >lock::send(rr).find _M_red: state(red,_M_red) for if < _M_red>=_1002 > red::send(-2).red::recv().black::send(1). black::recv().lock::send(end).0 else lock::send(not_enabled).0 fi.0 ] | bb[ !< not lockOn() >lock::send(bb).find _M_black: state(black,_M_black) for if < _M_black>=_1002 > black::send(-1).black::recv().lock::send(end).0 else lock::send(not_enabled).0 fi.0 ]

2.3.3. Behavioural Equivalence

In this section, we prove that the behaviour of a Petri net and that of its corresponding CCA process, generated by Algorithm 1, are equivalent according to Definition 4.

Definition 4  (Behavioural Equivalence)

A Petri net $(P,T,I,O,m_0)$ is behaviourally equivalent to its corresponding CCA process generated by Algorithm 1 if:

• Each place $p\in P$ and its corresponding place ambient $p_a$ have the same initial marking, i.e.,

  $$\forall p\in P:m_0\left(p\right)=m_0\left(p_a\right).$$
• A transition $t\in T$ is enabled if and only if its corresponding transition ambient $t_a$ is enabled, i.e.,

  $$\forall t\in T:enabled\left(t\right)\iff guard\left(t_a\right).$$
• For each transition $t\in T$, the execution of its corresponding transition ambient $t_a$ is atomic, i.e., two transition ambients cannot execute at the same time.
• For each transition $t\in T$, the execution of its corresponding transition ambient $t_a$ updates the markings of the place ambients, as in (2).

In the following lemmas, we assume a Petri net $(P,T,I,O,m_0)$ and its corresponding CCA process generated by Algorithm 1. For each place $p\in P$, we let $p_a$ denote the corresponding place ambient, and for each transition $t\in T$, we let $t_a$ denote the corresponding transition ambient.

Lemma 1. 

$\forall p\in P:m_0\left(p\right)=m_0\left(p_a\right)$.

Proof. 

By construction, Algorithm 1 creates for each place $p\in P$ a place ambient $p_a$ that has a child ambient named $‘‘\_’’+str(1000+m_0\left(p\right))$ (see lines 6 and 7 in Algorithm 1). From Definition 2, we can conclude that $m_0\left(p\right)=m_0\left(p_a\right)$.    □

Lemma 2. 

$\forall t\in T:enabled\left(t\right)\iff guard\left(t_a\right)$.

Proof. 

For $t\in T$,

 

$enabled\left(t\right)=\forall p\in Input\left(t\right):m\left(p\right)\ge I(p,t)$

⇔

$\forall p\in Input\left(t\right):‘‘\_’’+str(1000+m(p\left)\right)\ge ‘‘\_’’+str(1000+I(p,t\left)\right)$, from Theorem 1.

⇔

$\forall p\in Input\left(t\right):‘‘\_’’+str(1000+m\left(p_a\right))\ge ‘‘\_’’+str(1000+I(p,t))$, from Lemma 1.

⇔

$\forall p\in Input\left(t\right):state(p_a,‘‘\_’’+str(1000+m\left(p_a\right)))\wedge ‘‘\_’’+str(1000+m\left(p_a\right))\ge ‘‘\_’’+str(1000+I(p,t))$, from Table 4 and Definition 2.

⇔

$\forall p\in Input\left(t\right)\exists x:state(p_a,x)\wedge x\ge ‘‘\_’’+str(1000+I(p,t))$, from predicate logic.

⇔

$guard\left(t_a\right)$.

   □

Lemma 3. 

The execution of a transition ambient is atomic, i.e., two transition ambients cannot execute at the same time.

Proof. 

A semaphore lock (defined in Listing 6) is used to guarantee that two transition ambients cannot execute at the same time. The execution of a transition ambient is guarded by a guarded prefix “< not lockOn() >lock::send(t)”, as shown in Listing 9. Therefore, the execution starts only if the context expression “not lockOn()” holds, i.e., if the semaphore is not in the obtained state, according to the semantic rule (R1) in Table 5 and the definition of the context expression “lockOn()” in Table 4. When the semaphore is not in the obtained state, a transition ambient can obtain the semaphore by sending its name to the semaphore using the semantic rules (R9), (R10), (R1) and (R12) in sequence. Once the semaphore has been obtained, it is released only when it receives a message from the transition ambient t that obtained it, according to the continuation process “t::recv().del on” in Listing 6. This continuation is executed by applying the semantic rule (R14) followed by (R8). This happens only when the transition ambient t has reached Line 6 (or Line 7) of Listing 9, and is willing to send a message to the semaphore lock using the semantic rule (R14). Therefore, no two transition ambients can execute at the same time.    □

Lemma 4. 

The execution of an enabled transition ambient updates the markings of the place ambients, as in (2).

Proof. 

The general form of a transition ambient is given in Listing 9, and that of a place ambient is shown in Listing 7. Therefore, the execution of an enabled transition ambient t (i.e., (3) holds for this transition ambient) is carried out as follows, using the semantic rules of Table 5.

• In Line 2 of Listing 9, the rules (R9) and (R12) are applied to obtain the semaphore lock.
• In Line 3, the rule (R5) is applied to find the name of the child ambient of each input place ambient.
• In Line 4, the condition of the if-statement is evaluated to be true, since the transition ambient is enabled (see (3)). Therefore, Line 5 is executed next, according to the semantic rule (R3).
• In line 5, for each input or output place ambient p of the transition ambient t, the process “p::send(-I(p,t)+O(t,p)).p::recv()” is executed to send (using the rule (R12)) to p the value $-I(p,t)+O(t,p)$, and then it must wait for the acknowledgement (using the rule (R13)) that p has successfully updated its marking. Note that the value $-I(p,t)+O(t,p)$ is a constant for each pair $\{p,t\}$.
• In Line 6, the transition ambient releases the semaphore lock using the semantic rule (R14).

In the meantime, each input or output place ambient p (specified as in Listing 7) runs in parallel to t and behaves as follows.

• The rules (R9) and (R10) are applied to receive in the variable n the current marking of p.
• Rule (R6) is applied to calculate the name of the current child ambient of p in the variable $zz$.
• Rule (R12) is used to receive the value $-I(p,t)+O(t,p)$ sent by the running transition ambient t in the variable v.
• Rule (R8) is applied to delete the current child ambient.
• Rule (R6) is applied to calculate the new value ($w=n+v$) of the marking of p in the variable w, as in (2), and to calculate (at the same time) the new name of the child ambient of p ($y=‘‘\_’’+str(1000+w)$) in the variable y.
• Rules (R9) and (R10) are applied to set the new marking of the place ambient to w.
• Rule (R13) is used to tell the running transition ambient that the marking of p has been updated.
• Finally, the new child ambient named y is created.

We conclude that the execution of an enabled transition ambient updates the makings of the place ambients, as in (2).    □

Theorem 2. 

A Petri net $(P,T,I,O,m_0)$ and its corresponding CCA process generated by Algorithm 1 are behaviourally equivalent.

Proof. 

The proof of Theorem 2 is straight forward from Definition 4 and Lemmas 1–4.    □

2.3.4. Complexity of the Algorithm

It is important to discuss the complexity of the algorithm in terms of the execution time, and the size of the CCA process produced as the output in comparison to the size of the Petri net received as the input. For a Petri net of n places and m transitions, Algorithm 1 takes $O\left(n\right)$ time to generate the place ambients (see the loop in line 5) and $O\left(nm\right)$ time to generate the transition ambients (see the loop in line 9). Therefore, the overall time complexity of Algorithm 1 is $O\left({\tilde{n}}^2\right)$, where $\tilde{n}=max(n,m)$; i.e., the execution time is in the order of the square of the size of the input. In addition, the algorithm creates two ambients for each place (see lin 5): a place ambient with a child ambient, as depicted in Listing 7. However, a single ambient is created for each transition in line 9 of Algorithm 1. The general form of a transition ambient is depicted in Listing 9. Finally, a unique semaphore ambient named lock (see Listing 6) is created in line 3. Thus, the total number of ambients created is $2\times n+m+1$, and so the size of the CCA process generated by Algorithm 1 is in the order of $O\left(\tilde{n}\right)$, i.e.,  the size of the CCA process generated as the output grows linearly with the size of the Petri net as the input. The proposed algorithm is thus efficient and scalable. An implementation of the algorithm in Python (version 3.10.11) is given in Appendix A, so the mapping of a Petri net onto a CCA process can be carried out automatically at the click of a button.

3. Results

In this section, the proposed algorithm is validated through experiments using a case study of the dining cryptographers problem. The experiments are carried out using the CCA simulator ccaPL.

3.1. Overview of the CCA Simulator ccaPL

The syntax of a ccaPL program is given in

Table 7. Syntax of a ccaPL program.

<Program> ::= <DeclarationBlock> P <DeclarationBlock> ::= e | ‘‘BEGIN_DECLS’’ <DeclarationList> ‘‘END_DECLS’’ <DeclarationList> ::= e | <Declaration><DeclarationList> <Declaration> ::= ‘‘def’’ <Id> ‘‘(’’ <ParamList> ‘‘) = {’’ k ‘‘}’’ | ‘‘mode random’’ | ‘‘display code’’ | ‘‘length = ’’ <Val> | ‘‘display congruence’’ <ParamList> ::= e | <Id> <Params> <Params> ::= e | ‘‘,’’ <Id> <Params>

, where P is a process and k is a context expression defined in Table 1; <Id> stands for an identifier (i.e., a name), e for empty string, and <Val> is a non-negative integer number.

It follows that a ccaPL program is composed of a declaration block (optional) and a body, which is a CCA process. The declaration block starts with the keyword BEGIN_DECLS and ends with the keyword END_DECLS. In between these keywords, one can add the definitions of context expressions using the keyword def, and the declarations of execution directives. Note that ccaPL programs are case-sensitive. An example of a ccaPL program is given in Listing 11. The execution directives control how the parallel processes of a program are executed. By default, at each execution step the process to be executed is chosen deterministically based on two criteria: how long the process has been willing to execute (FIFO (First In First Out)) and, in case of conflict, the sequential order as they appear in the program text. The execution directive mode random changes the execution mode to a random selection of the processes to be executed. The directive display code forces the program code to be displayed after each execution step. By default, only reduction steps are shown in the execution traces; with the directive display congruence, the congruence steps are also shown in the execution traces. The directive length = xx stops the execution of the program after xx steps. Comments can be added anywhere in a program text using the prefix // for a single line comment or the pair /* and */ for a multiline comment, just like in the Java programming language. The ccaPL tool can generate three types of execution output, as shown in Figure 3: a textual execution trace, a communication graph and a behaviour graph. For illustration, the execution outputs for the simple access control system described in Section 2.2.5 are depicted in Figure 4 and Figure 5.

3.1.1. Textual Execution Trace

The execution trace is a text describing the execution steps. An example of textual execution trace is given in Figure 4. Each execution step trace is prefixed by the symbol --> (with respect to <-->) for a reduction step (with respect to a congruence step), followed by the explanation of the execution step between a pair of curly brackets { and }. For example, the explanation of a message-passing step has the form {child to parent: A ===(X)===> B}, meaning that a message X is sent by a child ambient A to a parent ambient B. Notations such as Child to parent, Parent to child, Sibling to sibling and local provide information about the relationship between the sender A and the receiver B. In particular, local means the sender is the receiver (i.e., A and B are the same ambient). An explanation of the form {binding: n -> X} corresponds to the execution of a statement of the form find n:k for P and means that the value (i.e., name) X has been found for the variable n such that the context expression k holds in the current context. The variable n will then be replaced by the name X in the process P (see the semantic rule R5 in Table 5). The remaining execution step explanations are straightforward. To generate a textual execution trace, use the following command line, where myprog.cca is your program file.

$$\mathtt{java}-\mathtt{jar} \mathtt{ccaPL}.\mathtt{jar}-\mathtt{e} \mathtt{myprog}.\mathtt{cca}$$

3.1.2. Communication Graph

The execution trace is a diagram showing the timeline of the communications between the ambients. An example of the communication graph is given in Figure 5a. The top row of the diagram is the list of the ambients being executed. The execution timeline of each ambient is denoted by a vertical dashed line, and the time increases from top to bottom. An arrow from one timeline (sender ambient) to another (receiver ambient) indicates a communication step between the corresponding ambients. This arrow is labelled with the message exchanged. A communication graph is created using the following command line, where XXX is the image format, like ps, jpg, png, PDF and so on.

$$\mathtt{java}-\mathtt{jar} \mathtt{ccaPL}.\mathtt{jar}-\mathtt{gXXX} \mathtt{myprog}.\mathtt{cca}$$

3.1.3. Behaviour Graph

This is similar to a communication graph, but in addition it shows the movement steps using a grey box containing a text of the form A --> B on the timeline of an ambient to indicate that the ambient has moved from Location A to Location B. An example of a behaviour graph is given in Figure 5b. Recall that an ambient can move from one location to another by performing the capability in or the capability out (see Section 2.2). The following command line will generate a communication graph myprog_0.XXX and the corresponding behaviour graph myprog_1.XXX.

$$\mathtt{java}-\mathtt{jar} \mathtt{ccaPL}.\mathtt{jar}-\mathtt{gxXXX} \mathtt{Xmyprog}.\mathtt{cca}$$

Note that the generation of the graphical execution traces requires that the Graphviz package [17] be installed on your computer.

3.2. A Case Study: The Dining Cryptographers Problem

The standard dining cryptographers problem [18] consists of three diners and requires that the identity of the person who pays the bill (which may be one of the cryptographers or an external person) remains anonymous. In this section, we consider a simplified version of the problem with just two diners. This version is also used in [19,20], and can be extended to three or more diners. Alice and Bob are two cryptographers who have a dinner in a restaurant. When it is time for the bill, they are informed by the waiter that the bill has already been paid. Both Alice and Bob, would like to know whether the bill was paid by a third person, or whether it was one of them. However, if it is the second case, then they do not want an eavesdropper, Yves, on a neighbouring table to know which of them paid. The following is the protocol that they decided to use to solve this problem.

3.2.1. A Dining Cryptographers Protocol

Firstly, they toss two coins that are visible to both of them. At the same time, they ensure that Yves cannot see either of them. If Alice paid, she lies about the parity of the two coins i.e., she calls ‘agree’ if she sees a head and a tail, and ‘disagree’ otherwise. If Alice did not pay, she tells the truth about the parity of the coins. The same applies for Bob. Now Alice and Bob both know whether one of them paid. In case their calls are the same they know that a third person paid, otherwise it must have been one of them—in this example they actually both know which. On the other hand, Yves can only tell whether or not one of Alice and Bob paid, but not which one. It should be noted that Yves also knows about the protocol. A possible encoding of the protocol using a Petri net is depicted in Figure 6. The two places at the left of the net represent Alice’s initial state: having paid is shown by placing a single token in place $AP$, and having not paid is shown by placing a single token in place $A\neg P$. The initial state of Bob is represented by the places on the right. The three possible initial markings for Alice and Bob are given in (4).

$$\{AP,B\neg P\},\{A\neg P,BP\},\{A\neg P,B\neg P\}$$

(4)

The top two places in the centre of the net represent the first coin: heads is represented by placing two tokens in the place $c_{1}h$, and tails is represented by placing two tokens in the place $c_{1}t$. The bottom two places, $c_{2}h$ and $c_{2}t$, represent the second coin. As was mentioned, both Alice and Bob must see the coins. For this reason, the marked places must contain two tokens. As a result, the possible initial markings for the coins are the multi-sets in (5).

$$\begin{array}{c}\{c_{1}h,c_{1}h,c_{2}h,c_{2}h\},\{c_{1}h,c_{1}h,c_{2}t,c_{2}t\},\\ \{c_{1}t,c_{1}t,c_{2}h,c_{2}h\},\{c_{1}t,c_{1}t,c_{2}t,c_{2}t\}\end{array}$$

(5)

The cross-product of the cryptographer markings in (4) and the coin markings in (5) denotes the set of all 12 possible initial markings. The eight transitions on the right represent the eight possible scenarios for Bob, given by two possibilities for each coin multiplied by the two possibilities for his own initial state. The transitions on the right represent Bob saying that the coins ‘disagree’ ($B0$) or Bob saying that the coins ‘agree’ ($B1$), and it is similar for Alice on the left.

3.2.2. Mapping the Petri Net of the Dining Cryptographers Protocol onto a CCA Process

Algorithm 1 was applied to map the Petri net in Figure 6 onto a CCA process. In this section, it is shown that the CCA process and the Petri net behave in the same way. To achieve this, the CCA process is executed in ccaPL for each of the 12 possible initial markings. The result is summarised in

Table 8. Comparison of the behaviours of the Petri net in Figure 6 to those of its corresponding CCA process. The column # numbers the 12 possible initial markings of the Petri net.

Inputs		Outputs
Coin	Cryptographer	Petri Net	CCA Process
Markings	Markings	Enabled Transitions	Executed Ambients	#
	$\{AP,B\neg P\}$	$A{0}_a$, $B{1}_c$	A0a, B1c	1
$\{c_{1}h,c_{1}h,c_{2}h,c_{2}h\}$	$\{A\neg P,BP\}$	$A{1}_c$, $B{0}_a$	A1c, B0a	2
	$\{A\neg P,B\neg P\}$	$A{1}_c$, $B{1}_c$	A1c, B1c	3
	$\{AP,B\neg P\}$	$A{1}_a$, $B{0}_c$	A1a, B0c	4
$\{c_{1}h,c_{1}h,c_{2}t,c_{2}t\}$	$\{A\neg P,BP\}$	$A{0}_c$, $B{1}_a$	A0c, B1a	5
	$\{A\neg P,B\neg P\}$	$A{0}_c$, $B{0}_c$	A0c, B0c	6
	$\{AP,B\neg P\}$	$A{1}_b$, $B{0}_b$	A1b, B0b	7
$\{c_{1}t,c_{1}t,c_{2}h,c_{2}h\}$	$\{A\neg P,BP\}$	$A{0}_d$, $B{1}_b$	A0d, B1b	8
	$\{A\neg P,B\neg P\}$	$A{0}_d$, $B{0}_d$	A0d, B0d	9
	$\{AP,B\neg P\}$	$A{0}_b$, $B{1}_d$	A0b, B1d	10
$\{c_{1}t,c_{1}t,c_{2}t,c_{2}t\}$	$\{A\neg P,BP\}$	$A{1}_d$, $B{0}_b$	A1d, B0b	11
	$\{A\neg P,B\neg P\}$	$A{1}_d$, $B{1}_d$	A1d, B1d	12

. It follows that the transitions enabled in the Petri net correspond exactly to the transition ambients executed by the CCA process. A sample of the execution traces, in the form of a communication graph, is given in Figure 7. This corresponds to the simulation of the case in which Alice paid the bill and Bob did not (i.e., $\{AP,B\neg P\}$), and the toss of the two coins shows heads for coin 1 and tails for the other (i.e., $\{c_{1}h,c_{1}h,c_{2}t,c_{2}t\}$). The execution trace indicates, with a pair of consecutive arrows, a transition ambient that is not enabled (see (3)). The current number of tokens of each place ambient is shown as a label to a loop-arrow along the execution timeline (i.e., the vertical dashed line) of the place ambients. The execution trace of an enabled transition ambient starts with an arrow labelled with the name of the transition ambient and terminates with an arrow labelled end. Therefore, in Figure 7, the simulation shows that the only enabled transitions (and thus those executed) for this case are the transition ambients A1a and B0c. This experiment can be reproduced using the Python implementation of Algorithm 1 given in Appendix A to generate the CCA process for the dining cryptographers protocol, and then the CCA process can be executed in the simulation tool ccaPL.

4. Discussion

There has been a substantial amount of research that adapts and relates features of process algebras to Petri nets. Petri Box calculus [21,22], for instance, is a process algebra based on CCS that presents compositional semantics for high-level constructs of concurrent programming languages with regard to Petri nets. Reference [23] proposed a translation from Condition/Event (C/E) nets to Circal process algebra based on a binary composition and hiding operators. Moreover, in [24,25,26], frameworks that endow Petri nets with labelled transition systems are presented, applying techniques come from process algebra. In particular, in [24], the theory of bigraphs is applied to C/E nets, by converting C/E nets to bigraphs and examining their behavioural theory. Moreover, there has been significant work in translating process algebra to Petri nets [27], with applications in the verification of mobile systems [28]. For instance, refs.  [29,30] proposed a translation of CCS into Petri nets, while [31] presented distributed semantics for $\pi$-calculus based on Petri nets.

Powerful, usable and flexible contemporary systems are characterised by features such as dynamic reconfigurability, where nodes in networks can dynamically appear or vanish, and logical mobility, where connections in ad hoc networks can be formed dynamically. These systems are also called reference-passing systems (RPS) [27]. As the number of such systems is constantly increasing, the correct functionality of such systems is of paramount importance to eliminate potential costly errors in the design phase.

There are a number of formalisms that are suitable for modelling and verifying specifications that are characterised by concurrency and the ability to form dynamic logical connections between individual modules [32,33]. The major factors and trade-offs in selecting an appropriate formalism are its expressiveness and the tractability of the associated verification techniques. Formalisms that are expressive are Turing-powerful, and so not decidable in general. However, it is possible to apply some restrictions (e.g., finiteness of the control) that would ensure decidability, while preserving a reasonable modelling power.

In [34], the authors present a number of equivalence notions on Petri nets that can be used in the construction of algebraic models. In [29], the authors proposed a new set of inference rules for a subclass of Calculus of Communicating Systems (CSS). This allowed for a direct translation to a subclass of Petri nets, and more particularly to condition/event nets. Early work on translating Petri nets into CCA is presented in [35], but the proposed algorithm is limited to a subset of Petri nets without multiple arcs between a place and a transition. Our algorithm can handle Petri nets with multiple arcs between places and transitions, e.g., the Petri net in Figure 1. In [36], a notion of net calculus is introduced, which is defined through a place/transition Petri net. The authors proposed a calculus of nets, called SCONE. Based on this, relationships between SCONE and a subset of CCS are studied. In [37], different approaches for the modelling of parallel processes are examined. The work considers process algebra, like CCS and communicating sequential processes (CSP) as main representatives. It is shown that the construction of transition nets is possible for all CCS programs in which recursive calls start sequentially. In [32], Finite Control Processes (FCP), a subclass of $\pi$-calculus, have been proposed, where the system is defined as a parallel composition of sequential entities. In [27], the authors introduced a translation of FCP to safe Petri nets to formally verify mobile systems.

5. Conclusions

In formal methods, it is customary to compare the expressive power of various languages and provide ways of mapping one language to another. This paper has followed the same approach and proposes an algorithm that maps Petri nets onto CCA. It is formally proven that a Petri net and its corresponding CCA process (generated by the proposed algorithm) are behaviourally equivalent. This demonstrates that any system that can be specified in Petri nets can also be specified in CCA. Thus, CCA is at least as expressive as Petri nets. It follows from this work that a Petri net can now be analysed using CCA verification tools like ccaPL. To do so, a Petri net is first translated into a CCA process using the proposed algorithm, and then the CCA process is analysed using ccaPL. The algorithm is implemented in Python so that the translation of a Petri net into a CCA process can be performed automatically at the click of a button. A real-world case study of the dining cryptographers problem was used to illustrate the proposed approach.

In future work, we will investigate how the proposed algorithm can be extended to handle more advanced Petri net variants like coloured Petri nets. We will also look at whether, conversely, CCA can be mapped onto Petri nets.