This section describes the proposed conversion algorithm to translate CPN models to B abstract machines. First of all, a general survey of previous contributions will be presented to point out the difficulties and limitations of the establishment of a complete and applicable transformation method. Then, the translation approach consists in defining, firstly, the transformation rules of a CPN’s generic structural properties. Yet, the conversion of CPN model to B language will be complemented by the integration of the behavioral specification and dynamic properties.
Known transformation approaches and literature survey
According to [15], formalism transformation could be done under three main approaches: mapping approach, pivot approach and the layered approach. Mapping approach states that for each pair of formalisms a mapping is created which transforms expressions in the source formalism to expressions in the target formalism. It can be well adapted to the two specific formalisms and, therefore, involves the smallest loss of information. Concerning the pivot approach, transformation between two different formalisms is done via a chosen formalism called the pivot. The pivot formalism must be very expressive to avoid losing information in the transformation, especially if the system involves formalisms that are unlike each other. A pivot approach was conducted in [16] for Petri net transformation into DEVS formalism. However this method concerns only elementary place/transition nets because of their small amount of information. The layered approach uses a layered architecture containing languages with increasing expressiveness. This approach has been proposed in order to avoid using a very expressive language and to ensure tractable reasoning with the integrated languages. In such a layered architecture, representations can be translated into languages higher in the hierarchy without loss of information.
The method proposed in this paper is based on informed transformation [17], which is in accordance with the mapping approach in the scope of Model Driven Engineering [18]. Informed transformation stipulates that a mapping of the source formal description of a formalism to the target one exists. The transformation between formalisms uses this formal description and the mapping between them. Within Model Driven Engineering, input Petri net models conform to the metamodel presented in [19], which is based on Jensen’s formal definition.
A recent previous work with the same goal and using a mapping approach is presented by BON.P in [20]. However, that conversion method was tested and it was found that the resulting machines are not accepted by the B tools due to the use of a large amount of definitions, added to their unpractical heaviness. Indeed, this method tries to define both the structural and behavioral properties of CPNs thanks to heavy definitions, and copes with these CPN modeling as a rigid graphical formalism. Consequently, the obtained machines are very hard to express or simulate and cannot be verified using B tools.
Another recent and important work to refer to is the work presented in [21], where a very close issue was considered, but this time for a mapping from Place/Transition Petri Nets to the B-language. This work constitutes a simplified version of the author’s original mapping form Evaluative Petri Nets to B machines. However this paper’s mapping does not cover Colored Petri Nets, the ideas presented are significantly interesting for our transformation framework in order to provide a future formal description of the present methodology.
Therefore, this paper presents and describes the framework of a new transformation method, based on a deeper analysis of the functioning and the handling of Colored Petri Nets with special focus on their component tasks. One of the basic starting principles is the ability of applying the method to a complete safety study case, as it is presented in this paper. The methodology is also likely to lead to an elaborate formal description of the transformation and open to undergo improvements. Furthermore, this new method intends to provide a transformation able to be encoded in order to develop an interactive software platform for automatic CPN conversion into B abstract machines. So, this work describes in detail the principles of the transformation and its application and will constitute the base framework for the establishment of formal representations and proof of the transformation.
The next sections detail the transformation theory, starting with basic Multisets definition, structural properties transformation rules, and finally, the description of CPN behavioral characteristics transformation according to the spirit of the B method. Afterward, the B machines behavior equivalence to the original CPN models is demonstrated, which constitute a first step toward a formal proof of the correctness of the method. The simulation of a typical railway example, which validates the syntax acceptance, supports this transformation framework and visualizes the exact matching of the machine’s behavior and proves the safety invariant conservation.
Multisets definition
A multiset is specified as a relationship between the base set of the multiset and natural numbers. As in [8, 13], the elements of a multiset are pairs (ee ↦ nn) where ee is a member of the base set and nn is an integer which represents the coefficient (number of occurrences) of the element in the multiset.
Ms (ss) is a multiset based on ss defined as a total function from ss to all natural numbers:
$$ \boldsymbol{Ms}\ \left(\boldsymbol{ss}\right)==\boldsymbol{ss}\boldsymbol{\to}\boldsymbol{NAT}. $$
The empty multiset, based on ss, is composed of pairs of elements of the support set related to 0. Thus, it is a total function, which for each element of the starting set combines the integer 0:
$$ \mathrm{Ms}\_\mathrm{empty}\ \left(\mathrm{ss}\right)==\left\{\mathrm{elt}\ |\ \mathrm{elt}:\mathrm{ss}\times \left\{0\right\}\right\} $$
This work uses only these two Multiset definitions that will appear in all the machines obtained for each Petri net color. The following sections will detail the transformation rules.
Petri net structure transformation rules
For several reasons of formalization as the transformation and its automation, the construction of the transformation rules was based on Jensen’s formal definition of Colored Petri Nets. For each point of the formal definition of Petri Net structure, an associated transformation rule is then given. The following paragraph details these rules.
A set of the abstract machine is associated to each color of Σ. If the color is described by an enumerated set, it matches to an enumerated set in the clause “SETS” of the abstract machine B. Regarding non-enumerated sets; they correspond to definitions of the clause “DEFINITIONS” as shown in Fig. 3.
The places of the set P are defined by their identifier and their state (marking). Therefore, they are translated by the variables state_Idplace. Places are also defined by their type color. This invariant property will be translated by the invariant state_Idplace ϵ Ms. (color) in the “INVARIANT” clause (Fig. 4).
A transition is defined by its identifier as well as its state (enabled or non-enabled). The structure of a transition is translated into a Boolean variable that expresses the transition’s state. Of course, the name of the variable describes the identifier, and the invariant in B describes the type. Elements of transition guard are handled in the section describing Petri Net behavior transformation (Fig. 5).
Note: Arcs do not explicitly appear in the abstract machine. In fact, the goal of the translation is to provide a B abstract machine behaving exactly as the considered Petri Net. For this reason, arcs are analyzed through their function in a Petri Net which is to ensure the logical evolution of states, using expressions of arcs. Therefore, the information of arcs is not lost in the transformation process, but it will appear in the dynamic part of the machine which is covered in the section describing the behavioral transformation of a Colored Petri Net.
The initial marking of each site is assigned to the INITIALISATION clause as is shown in Fig. 6.
Elt_color is an element of the set color and n is a natural number which expresses the occurrence of the token, according to the previous definition of the multiset Ms_empty.
Note: The clauses “VARIABLES” and “INITIALISATION” will also include the declaration and the initialization of variables of type “NATURAL” describing the occurrence of each token color of a given place, denoted occ_eltcolor_idplace. These variables represent only the state of the places (marking) of the Petri Net. They will mainly allow expression properties invariants and help the machines automatic proof of the Atelier B.
Petri net behavior transformation rules
The behavior of a Petri Net corresponds to the evolution of its places states (markings). This evolution is governed by the crossing of enabled transitions, following the instructions of expressions of arcs and guards.
Of course, a transition is enabled if and only if all incoming places (with incoming arcs) have a number of tokens with the type indicated on the incoming arcs and if the predicate of the guard is true. The definition of a transition state (enabled or non-enabled) will be translated by an operation Op_Enabled_Idtransion. This will aim to change the Boolean variable describing the state of the transition Enabled_Idtransion. Regarding transition crossing (firing), it consists in transforming the states of adjacent places, according to the guidelines of the guard and outgoing arcs to outgoing places, and subtracting consumed tokens in incoming places. Crossing a transition will be translated by a second operation Op_Fired_Idtransion.
Note: The behavioral transformation is characterized by the introduction of two operations for each transition, when the use of only one operation (op_Fired_Idtransition) might be absolutely sufficient in most cases. The main idea behind the operation Op_Enabled_Idtransion is to leave open the use of the Boolean variables enabled_Idtransition in expressing safety invariants related to transition or events. In fact, sometimes, it is difficult to establish invariants using variables corresponding to places or tokens. If the transformation is used in critical software development for example, this operation could be omitted or removed in the refinement phases.
Therefore, the evolution of Colored Petri Nets will be translated into B through operations in the kind of substitutions with precondition “PRE” and “SELECT” substitutions that will represent the evolution of places and transitions states which are already declared as variables. The use of “SELECT” in the op_Fired_Idtransition is justified by the fact that the firing of the transition may involve different tokens (colors) choices according to the elements of the “color set” related to the incoming and outgoing places (all tokens in those places are necessarily one of these elements, i.e. token ϵ X where X ϵ Σ).
The predicate part of the guard expressions and incoming arcs expressions will be translated by a predicate in the PRE section of the substitution with precondition in the operation Op_Enabled_Idtransion. The THEN section will include the action on Boolean variable Enabled_Idtransion:=TRUE (Fig. 7).
On the other hand, the guard may also have an action part. Expressions of outgoing arcs can be considered as actions as well. These actions (guards and outgoing arcs) aim to change the state of outgoing places, thus changing the state of the corresponding variables in B abstract machine, and possibly other variables according to the Petri Net. They will be translated in the “THEN” section of the substitution with selection in Op_Fired_Idtransion operation. The change of variables corresponding to states of places is done by an overload in the B machine. This part will always contain the substitution Op_Enabled_Idtransion:= FALSE so that Op_Enabled_Idtransion operation is no longer enabled. The “SELECT” (and WHEN) part of this second operation will include the following predicate: Enabled_Idtransion = TRUE & Predicate_P. the Predicate_P gives an indication of the selected token and the decrement condition of occurrences variables (Fig. 8).
At this point, the Colored Petri Net conversion methodology into B abstract machines was described. The following sections will emphasizes the behavioral equivalence of the input CPN models and the obtained B machines, before showing the use of this method through an academic railway example.
Note: the predicates in the obtained B machine could be enriched in order to facilitate the proving task without affecting the behavior of the machines or the quality of the transformation.
Behavioral equivalence
According to Jensen’s formal definition of the behavior of a Colored Petri Net:
-
(1)
A transition is enabled ⇔ there are enough tokens of the correct values specified on arcs on each input-place and the guard evaluates to true.
-
(2)
When a transition is fired ⇔ a multi-set of tokens is removed from each input-place and a multi-set of tokens is added to each output-place.
To ensure that the transformation keeps the elements of the initial model, these two basic equivalences have to be verified in terms of their element’s corresponding components in the B abstract machine:
-
(1)
An operation Op_Enabled_Idtransion is enabled ⇔ the predicate of the clause PRE in Op_Enabled_Idtransion is true.
-
(2)
An operation Op_Fired_Idtransion is executed ⇔ the substitution in the clause THEN in Op_Fired_Idtransion contains a multisets overload and is executed.
The demonstration of these two equivalences, presented hereafter, is direct and can be done using the basic B abstract machine definitions. In this work part of the PERFECT project, such a demonstration supports the correctness of the transformation and provides materials for the construction of its formal proof.
Demonstration 1
For the first equivalence, let us suppose that: An operation Op_Enabled_Idtransion is enabled and let us prove that the predicate of the clause PRE in Op_Enabled_Idtransion is true (direct implying): by construction, the substitutions with precondition operation (containing “PRE” and “THEN”) is enabled if and only if the substitution after PRE is true. So, the predicate of the clause PRE in Op_Enabled_Idtransion is true.
Let us suppose now that the predicate of the clause PRE in Op_Enabled_Idtransion is true and let us prove that the operation Op_Enabled_Idtransion is enabled (reverse implying): since the predicate of the operation clause PRE is true, the THEN substitution can be executed, and that means, by construction, that the operation Op_Enabled_Idtransion is enabled.
Demonstration 2
For the second equivalence, let us suppose that: an operation Op_Fired_Idtransion is executed and let us prove that the substitution in the clause THEN in Op_Fired_Idtransion contains a multisets overload and is executed (direct implying): the transformation method specifies that the change of variables corresponding to states of places is done by an overload in the B machine. So this implication is proved directly.
Let us suppose now that the substitution in the clause THEN in Op_Fired_Idtransion contains a multisets overload and is executed and let us prove that operation Op_Fired_Idtransion is executed (reverse implying): by definition, an operation is executed if and only if the THEN substitution of this operation is executed. Therefore, this implication is directly proved.