# A CPN/B method transformation framework for railway safety rules formal validation

- 1.5k Downloads

## Abstract

This paper presents a “CPN/B method” based process for railway systems safety analysis. Achieving interoperability through the European Rail Traffic Management System (ERTMS/ETCS) is facing difficulties in railway safety assessment due to the interaction of national and European operating specifications. These specifications have been modeled using several formalisms, which makes it is extremely hard to preserve all requirements when switching between different formalisms. However, this problem, crucial for efficient progress in railway safety research, has received very little attention in the literature. In this respect, the purpose of this contribution is to provide a methodology to demonstrate safety in railway systems by converting CPN models, widely used in modeling, into B abstract machines. It aims at enabling a stronger combination of formal design techniques and analysis tools able to cope with the real complexity of systems and automatically prove that safety properties are unambiguous, consistent and not contradictory, considering an industrial railway context.

### Keywords

Colored Petri nets B method Transformation methodology Railway safety ERTMS## 1 Introduction

Today, Europe has more than twenty signaling and train control systems for railway transport that are different in terms of performance and safety. Therefore, rail interoperability in Europe requires a gradual transition to a common system for the various member states, the European Rail Traffic Management System (ERTMS/ETCS).

Performing railway interoperability allowed by ERTMS requires a common understanding of requirements by all involved parties. In this context, formal rigorous models are effective tools to identify and clarify ambiguities. The PERFECT (Performing Enhanced Rail Formal Engineering Constraints Traceability) project is a French scientific project that aims to formalize railway specifications and validate various systems. Systems’ models will be developed and formally analyzed to determine, when possible, the compliance between ERTMS and National railway specifications. Our work focuses on modeling of the functional and safety aspects of railway systems (ERTMS, national rules, human factor…) and their validation by the B formal method. Several studies have been conducted in this context using formal methods and techniques. We can quote the project Open-ETCS led by a European consortium.

In this regard, the transportation technology and electrification growing influence on performance and safety of systems operations, especially railways, requires from safety research, such as PERFECT research, to address the more than ever complex task of real scenario modeling. That is why railway safety systems have been modeled using different formalisms, such as Petri nets, UML and others [1, 2, 3, 4, 5, 6], in order to facilitate the expression of the know-how of industrial experts who may not be familiar with mathematical formalisms. Yet, in order to link and analyze all railway models, B machines will constitute a common destination point that allows us to arrive at rigorous conclusions. One of the ultimate goals of this study is to provide a conversion methodology capable of giving B abstract machine which behave exactly like Colored Petri Nets models, and, therefore, ensure the preservation of initial expert modeling and assessment.

This paper will present at first, High Level Petri Nets and their interest in railway modeling. Afterwards, the B method and its tools will be shown before presenting the core of this contribution, which is a concrete translation method from Colored Petri Nets to B abstract machines. As the purpose of this work is to introduce the transformation framework and the way it could be used within safety rules validation processes, the next sections will detail, on the one hand, a simple railway case study in which Petri nets are used in modeling before their transformation to B abstract machines and safety analysis, and on the other hand, describe how addressing an ERTMS RBC procedure could benefit from such a translation methodology. Finally, last section sums up and shows some interesting perspectives to this work.

## 2 High level Petri nets modeling

Petri Nets were developed in 1960–1962 by the German mathematician and computer scientist Carl Adam Petri. They have become famous thanks to the work of American researchers who used them in the 1970s (MIT Project on Mathematics and Computation-MAC project).

These networks constitute a powerful tool for studying a wide variety of discrete event systems. They are useful for both static modeling through their structure and dynamic representation through their operating rules. Therefore, they cannot only study the architecture of systems, but also their evolution and their reaction during the simulation.

### 2.1 Place/transition Petri nets

A Petri Net is represented by a graph with two types of nodes: places, represented graphically by circles, and transitions that are represented by bars or boxes. Places and transitions are connected by directed arcs: arcs can only link a place to a transition or a transition to a place. A Petri Net is characterized by its initial state called initial marking. Detailed explanation is given in [7].

Using Place/transition Petri Nets to model big complex systems, such as railway systems, is very limited, due to the size and complexity of the obtained models. For this reason, it is necessary to use High-Level Petri Nets.

### 2.2 High level Petri nets: Colored Petri nets

In elementary Petri Nets, tokens cannot be distinguished. However, modeling real complex systems requires the possibility of transforming the nature of tokens through a transition. Thereby, a new type of Petri Nets handling tokens transformation and labeled by a first-order language was born, called High-Level Petri Nets. The first interesting class of High Level Petri Nets was the “predicate/transition” nets developed by Hartmann Genrich [8]. The next step forward was achieved by the development of Algebraic Petri Nets [9], and later the development of Colored Petri Nets introduced by Kurt Jensen [10]. In the PERFECT project, Colored Petri Nets are considered rather than the other High-Level Petri Nets forms especially for their bigger modeling power in the case of complex railway systems.

Colored Petri Nets are an extension of Petri Nets based on a functional language where the notion of typing is fundamental. They allow the association with a value named color to differentiate tokens. Color of tokens can be transformed or tested during their passage in arcs and transitions. The formal definition of a Colored Petri Net is given below [10].

### Definition 1

*CPN*= (

*Σ*,

*P*,

*T*,

*A*,

*N*,

*C*,

*G*,

*E*,

*I*) satisfying the following requirements:

- (i)
is a finite set of non-empty types, called colour sets.**Σ** - (ii)
is a finite set of places.**P** - (iii)
is a finite set of transitions.**T** - (iv)
is a finite set of arcs such that:**A***P*∩*T*=*P*∩*A*=*T*∩*A*=*Ø*. - (v)
is a node function. It is defined from**N***A*into*P*×*T*∪*T*×*P*. - (vi)
is a colour function. It is defined from**C***P*into*Σ*. - (vii)
is a guard function. It is defined from T into expressions such that: ∀**G***t ϵ T*: [*Type*(*G*(*t*)) =*Bool*∧*Type*(*Var*(*G*(*t*))) ⊆*Σ*]. - (viii)
is an arc expression function. It is defined from**E***A*into expressions such that:$$ \forall a\ \epsilon\ A:\left[ Type\ \left( E(a)\right)= C{\left( p(a)\right)}_{MS}\wedge \kern0.5em Type\left( Var\ \left( E(a)\right)\right)\subseteq \varSigma \right] $$

*p*(

*a*) is the place of

*N*(

*a*).

- (ix)
is an initialization function. It is defined from**I***P*into closed expressions such that:$$ \forall p\ \epsilon\ P:\left[ Type\ \left( I(p)\right)= C{(p)}_{MS}\right]. $$

To have more details on the above definition, the reader can refer to [10].

Later in this paper, an academic railway example of trains’ safe movements is introduced and modeled using the CPN-tool. Then, simulating the exact coherence between the CPN model and the obtained B abstract machine will be shown.

## 3 B method and tools

The B method is a formal method for developing secure software. It was designed by Jean-Raymond Abrial [14]. The B method provides a formal specification and rigorous analysis of the functionality and behavior of a system. It covers all phases of the life cycle of software development from specification to implementation. Industrial applications of the B method are mainly destined to rail systems, including the commissioning of the metro line 14 (METEOR, 1998) and the automation of line 1 (2005) by the RATP and other developments autopilots subways.

Pre-condition: defined by the set of states from which the state change is possible.

Operation: consists of the list of changes made to the pairs (predicate expression).

Post-condition characterizes acceptable statements as results of change.

Sometimes, in the formalism of the method B, the notion of “substitution” replaces the concepts of pre-and post-condition.

### 3.1 Mathematical notation and B abstract machines

Data modeling and their properties, with the B language based on mathematical notation, is essentially based on theory of sets. Nevertheless, the B theory of sets includes the notion of typing. In other words, all the elements of a set have the same type. B properties are expressed by formulas of first order predicate calculus. That is to say, in addition to the predicates constructed with conventional propositional operators (and (∧) or (∨) ...), there is equality and predicates composed of existentially quantified variables (∃) and universally quantified ones (∀).

The B method is based on the notion of abstract machines. These abstract machines can be associated to imperative programing, which describes the operations in terms of sequences of elementary instructions executed to change the program state. Each machine declares its own variables and operations and variables can only be changed by the machine’s operations.

**MACHINE**: Declaration of the name of the abstract machine and the formal parameter list (sets or values).**CONSTRAINTS**: Declaration of logical properties of parameters (sets or values) of the machine.**SETS**: Declaration of the definitions of machine’s abstract or listed sets.**CONSTANTS**: Declaration of identifiers of constants.**PROPERTIES**: Declaration of logical properties of sets and constants declared with typing and evaluation of constants.**VARIABLES**: Declaration of identifiers of variables.**INVARIANT**: Declaration of the invariant logical properties of variables declared with typing of variables.**ASSERTIONS**: Declaration of definitions of the machine’s new logical assertions.**INITIALISATION**: Declaration of the generalized substitution initializing the machine variables.**OPERATIONS**: Declaration of machine operations in the form of a header and a body.**END**: End of the machine definition.

### 3.2 “ProB” and “Atelier B” tools

One interesting point of this study is the use of automatic proof and check tools of the B method, especially to visualize the behavior of B abstract machines and check safety properties of the modeled railway problem. The tools used in this context are ProB^{1} animator and model checker^{1}, added to the “Atelier B”^{2} prover. ProB is an animator and model checker for the B-Method that allows fully automatic animation of many B specifications, and can be used to systematically check a specification for a range of errors. The constraint-solving capabilities of ProB can also be used for model finding, deadlock checking and test-case generation. ProB is now being used within Siemens, Alstom, and several other companies for data validation of complicated properties.

Model checking within ProB does the verification of a system model with respect to the properties that are expected on this model. The result of this analysis is the confirmation that each property is, or is not, maintained by the model. In the latter case, and this is one of the main interests of this tool, the model checker returns a counter-example of how the property is not maintained.

Otherwise, developed by Clearsy, “Atelier B” is an industrial tool that allows for the operational use of the B Method to develop defect-free proven software. It is used to develop safety automatisms for the various subways installed throughout the world by Alstom and Siemens, and also for Common Criteria certification and the development of system models by ATMEL and STMicroelectronics. Additionally, it has been used in a number of other sectors, such as the automotive industry, to model operational principles for the onboard electronics of three car models.

Atelier B provides a theorem prover for the B models. Unlike model checking, theorem provers are not based on finite and decidable systems. They are mostly less simple to use than the model checker but used to address various problems where, for example, the model checker cannot be used. They allow us to bring proof of correctness of the program or system to be modeled.

Accordingly, these two tools are complementary where the use of ProB suits better in the early conception phases, especially for a fast error debug, and the use of Atelier B comes later to give the proof of properties correctness. Therefore, the use of both of these tools reinforces the conclusions of the work presented in this paper.

## 4 Description of the transformation methodology

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.

### 4.1 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.

### 4.2 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* ↦

*) where*

**nn***is a member of the base set and*

**ee***is an integer which represents the coefficient (number of occurrences) of the element in the multiset.*

**nn***is a multiset based on*

**Ms (ss)***defined as a total function from*

**ss***to all natural numbers:*

**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:*

**ss**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.

### 4.3 Petri net structure transformation rules

**(i)**is a finite set of non-empty types, called colour sets.**Σ**

*Σ*. 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.

**(ii)****P****is a finite set of places. (iii)****T****is a finite set of transitions. (iv)****A****is a finite set of arcs such that:**∩**P**=**T**∩**P**=**A**∩**T**=**A****Ø****. (v)****N****is a node function. It is defined from****A****into**×**P**∪**T**×**T****P****. (vi)****C****is a colour function. It is defined from****P****into****Σ****.**

*. Places are also defined by their type*

**state_Idplace***. This invariant property will be translated by the invariant*

**color***in the “INVARIANT” clause (Fig. 4).*

**state_Idplace ϵ Ms. (color)****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.

**(ix)****I****is an initialization function. It is defined from****P****into closed expressions such that:**∀: [**p ϵ P**(**Type**(**I**)) =**p**(**C**)**p**_{MS}]**.**

* Elt_color* is an element of the set

*and*

**color***is a natural number which expresses the occurrence of the token, according to the previous definition of the multiset*

**n***.*

**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.

### 4.4 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

*. 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*

**Enabled_Idtransion***.*

**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

*is to leave open the use of the Boolean variables*

**Op_Enabled_Idtransion***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.*

**enabled_Idtransition***” and “*

**PRE***” substitutions that will represent the evolution of places and transitions states which are already declared as variables. The use of “*

**SELECT***” in the*

**SELECT***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*

**op_Fired_Idtransition***,*i.e.

*token*ϵ X where X ϵ

*Σ*).

**(vii)****G****is a guard function. It is defined from****T****into expressions such that:**∀: [**t ϵ T**(**Type**(**G**)) =**t**∧**Bool**(**Type**(**Var**(**G**))) ⊆**t**]**Σ****. (viii)****E****is an arc expression function. It is defined from****A****into expressions such that:**∀: [**a ϵ A**(**Type**(**E**)) =**a**(**C**(**p**))**a**_{MS}∧(**Type**(**Var**(**E**))) ⊆**a**]**Σ****where**(**p**)**a****is the place of N(a).**

*section of the substitution with precondition in the operation*

**PRE***. The*

**Op_Enabled_Idtransion***section will include the action on Boolean variable*

**THEN***(Fig. 7).*

**Enabled_Idtransion:=TRUE***section of the substitution with selection in*

**THEN”***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_Fired_Idtransion***so that*

**Op_Enabled_Idtransion:= FALSE***operation is no longer enabled. The “*

**Op_Enabled_Idtransion***(and*

**SELECT”***) part of this second operation will include the following predicate:*

**WHEN***. the*

**Enabled_Idtransion = TRUE & Predicate_P***gives an indication of the selected token and the decrement condition of occurrences variables (Fig. 8).*

**Predicate_P**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.

### 4.5 Behavioral equivalence

- (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.**

- (1)
An operation

is enabled ⇔ the predicate of the clause PRE in**Op_Enabled_Idtransion**is true.**Op_Enabled_Idtransion** - (2)
An operation

is executed ⇔ the substitution in the clause THEN in**Op_Fired_Idtransion**contains a multisets overload and is executed.**Op_Fired_Idtransion**

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

*in*

**PRE***is true (direct implying): by construction, the substitutions with precondition operation (containing “*

**Op_Enabled_Idtransion***” and “*

**PRE***”) is enabled if and only if the substitution after*

**THEN***is true. So, the predicate of the clause*

**PRE***in*

**PRE***is true.*

**Op_Enabled_Idtransion**Let us suppose now that the predicate of the clause PRE in * Op_Enabled_Idtransion* is true and let us prove that the operation

*is enabled (reverse implying): since the predicate of the operation clause*

**Op_Enabled_Idtransion***is true, the*

**PRE***substitution can be executed, and that means, by construction, that the operation*

**THEN***is enabled.*

**Op_Enabled_Idtransion**### 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

*in*

**THEN***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.*

**Op_Fired_Idtransion**Let us suppose now that the substitution in the clause * THEN* in

*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*

**Op_Fired_Idtransion***substitution of this operation is executed. Therefore, this implication is directly proved.*

**THEN**## 5 Railway study case

As well as the rigorous construction of the transformation from CPNs to B machines in the context of railway safety, its applicability of the validation process is crucial and extremely important, especially for the PERFECT project results requirements. That is why, in parallel to the development of an elaborate and formal transformation, based on the framework presented here and comprising the description of transformation rules, the early application on small case studies figures in the work agenda. In this section, a complete process is shown, from the Colored Petri Net modeling step to the validation of safety properties by B machine analysis, which is applied to a theoretical railway case study. The correctness of transformation is also checked using “ProB” and “CPN-tools” simulation tools.

### 5.1 Description of the railway case study

*ta*and

*tb*(Fig. 9). Train movements are specified by the following general rules (constraints):

C1: the network is composed of consecutive elementary portions called track circuits (CdV).

C2: trains run on that network in a given direction.

The functioning of this e railway is governed by two other safety rules:

C’1: there cannot be two trains on the same track circuit.

C’2: there must always be a free track circuit between two trains.

### 5.2 Railway case study modeling using CPNs

*ta*and

*tb*, and the train movements are represented by transitions.

Note that the initial marking is represented with the token “* ta*” in the place “

*”, “*

**0***” in the place “*

**tb***”. The other places contain the token “*

**4***” which denotes the non-presence of a train in the track circuit modeled by the place.*

**no**### 5.3 The obtained B abstract machine after transformation

### 5.4 Simulation of the exact correspondence between the obtained machine and the initial Petri net

Before the introduction of the safety invariants to validate and achieve the purpose of this study, a first check of the obtained B abstract machine is conducted by the “Atelier B” prover and the ProB model checking and animation platform. **The “Atelier B” prover has generated 174 proof obligations and has proved 174 one (a 100% rate)**. Furthermore, with the prover, if we demonstrate that the system has a rate of 100%, the typing of the machine is then correct. The ProB animation, added to this proof, will show that the obtained machine behaves correctly like the Petri Net model. For this purpose, this paper will compare the evolution of state spaces of the CPN model and the B machine for the same sequence of events.

The simulation continues using the ProB animator until all the states are reached. This section visualized then that the obtained abstract machine behaves exactly like the transformed Colored Petri Net and keeps all the modeled requirements, which is reinforcing our conclusions to use the transformation rules presented in this paper as a base framework for the construction of all the aspects of the transformation, such as its formalization, formal proof and automation. Note that in the industrial practice, the use of simulation tools and small applications during the early phases of a project is very important in order to ensure the right orientation of the efforts while progressing.

### 5.5 Safety constraints validation by B tools

In the case study, two safety rules are to be proved by B method tools: There cannot be two trains on the same track circuit and there must always be a free track circuit between two trains.

At first, it is necessary to express these safety rules by an invariant predicate. An invariant predicate which guarantees at the same time that only one train occupies a track circuit and that there is always a free track circuit between two trains is:

Thereby, the use of the model check of ProB which stops when all operations are covered proves that this invariant is respected by the abstract machine.

“Atelier B” proof reached a **rate of 100%** after having added the previous invariant and concretized the implicit conditions of the B machine operations, such as completing the implicit conditions expressed by “* state_Idplace* =

*with the precondition “*

**Ms_empty(train)”***”, which does not affect the behavior of the obtained B machine.*

**occ_eltcolor1_idplace =0 & … & occ_eltcolorN_idplace=0**## 6 An example of ERTMS case study – RBC handover

Incoming events of Handing over RBC

Event | Description |
---|---|

HOV condition detected | Handover condition detected |

RRI request necessary | Handing over RBC detects that route related information is required from the accepting RBC |

RRI received | NRBC message “Route Related Information” received |

Condition “Border passed by safe front end” detected | Position report received and condition “Border passed by maximum safe front end” detected |

TOR received | NRBC message “Taking Over Responsibility” received |

Condition “Border passed by safe rear end” detected | Position report received and condition “Border passed by minimum safe rear end” detected |

Cancellation condition detected | Condition for cancellation of the RBC/RBC handover transaction is detected in the handing over RBC |

ACK received | NRBC message “Acknowledgement” has been received |

Cancellation received | NRBC message “Cancellation” received |

Life Sign received | NRBC message “Life Sign” received |

Request for RRI Confirmation received | NRBC message “Request for RRI Confirmation” received |

RRI Confirmation condition detected | RRI Confirmation condition detected |

One clear advantage of transforming the Petri Net model describing the RBC Handover’s transaction is the ability to use, without losing the logic of the process, the resulting B machine in formally proving safety properties of a bigger train operations model. Besides, such an bridge between the two formalisms could, in the case of ERTMS equipment development, help the implementation of safe by design sotware solutions.

## 7 Conclusion and perspectives

Under the project PERFECT (Performing Enhanced Rail Formal Engineering Constraints Traceability), consistency between ERTMS specifications and national operating railway rules is to be checked and validated using formal techniques. In this context, researchers and experts model the railway conduct and rules through different formalisms, such as High-Level Petri Nets and UML. One of the biggest challenges of the project is to introduce validation methodologies based on formal techniques and convert all the obtained models to a common powerful formal tool able to link those models and keep all their initial information.

In this respect, this work makes a significant step toward the main goal of the project. It brings the base framework, of Colored Petri Nets conversion into B abstract machines, where behavioral equivalence of the two formalisms was demonstrated. An illustrative case study was conducted to show the application process of such a validation methodology in the railway context using the tools of the B method.

Therefore, this contribution has several perspectives. One of them is the establishment of an elaborate formal description of the transformation base on the rules presented here and the development of a software platform for its automation. Indeed, an automatic conversion tool is very important to facilitate the generation of B abstract machines because it takes a very long time to establish them manually, especially for large models. On the other hand, this work leads to question on how it is possible to link different B machines obtained from different input models, and those established by means of diverse formalisms, such as Petri Nets and UML in the case of the PERFECT project, with the purpose of checking the consistency between ERTMS and national railway specifications using the B tools [3, 4, 23]. This will help the project to achieve its main goal and propose an interesting background for railway safety scientific researches. A further purpose of this work is to develop a complete automatic railway safety rules validation tool.

## Footnotes

### References

- 1.Ghazel M (2014) Formalizing a subset of ERTMS/ETCS specifications for verification purposes. Transportation research-Part C: Emerging technologies 42: 60-75. DOI:10.1016/j.trc.2014.02.002, ELSEVIER, http://www.sciencedirect.com/science/journal/0968090X, 0968-090X
- 2.Jabri S, El-Koursi EM, Bourdeauhuy TH, Lemaire E (2010) European railway traffic management system validation using UML/Petri nets modelling strategy. Eur Transp Res Rev (ETRR), ECTRI 2:113-128. DOI: 10.1007/s12544-010-0030-5, Springer, http://www.springer.com/engineering/mechanical+eng/journal/12544
- 3.Boudi Z, El-Koursi EM, Collart-Dutilleul S, Khaddour M (2014) High level Petri net modeling for railway safety critical scenarios. In: Proc. of 10th FORMS/FORMAT symposium on formal methods. Braunchweig, pp 65-75Google Scholar
- 4.Ben Ayed R, Collart-Dutilleul S, Bon P, Idani A, Ledru Y (2014) B formal validation of ERTMS/ETCS railway operating rules. In: Ait Ameur Y, Schewe K-D (eds) ABZ 2014, LNCS, vol 8477. Springer, Heidelberg, pp 124–129Google Scholar
- 5.Sun P, Collart-dutilleul S, Bon P (2014) Formal modeling methodology of French railway interlocking system via HCPN. 14th International conference on Railway Engineering Design and Optimization, Rome, ItalyGoogle Scholar
- 6.Antoni M (2009) Formal validation method for computerized railway interlocking systems. Computers Industrial Engineering. CIE 2009. International Conference on, pp 1532–1541Google Scholar
- 7.Murata T (1989) Petri nets: properties, analysis and applications, an invited survery paper. Proc IEEE 77(4):541–580CrossRefGoogle Scholar
- 8.Genrich HJ (1991) Predicate/Transition Nets. K. Jensen and G. Rozenberg (Eds.): High-level Petri Nets. Theory and Application. Springer-Verlag, pp 3-43Google Scholar
- 9.Reisig W (1991) Petri nets and algebraic specifications. Theor Comput Sci 80(1):1–34CrossRefMATHGoogle Scholar
- 10.Jensen K (1992) Coloured Petri Nets – Basic Concepts, Analysis Methods and Practical Use-Vol. 1. EATCS Monographs on Theoretical Computer Science. Springer-Verlag, Berlin, pp 1-X, 1–236Google Scholar
- 11.Jensen K, Kristensen LM, Wells L (2007) Coloured Petri nets and CPN tools for Modelling and validation of concurrent systems. Int J Softw Tools Technol Trans (STTT) 9(3–4):213–254CrossRefGoogle Scholar
- 12.Ratzer AV, Wells L, Lassen HM, Laursen M, Qvortrup JF, Stissing MS, Westergaard M, Christensen S, Jensen K (2003) CPN Tools for Editing, Simulating, and Analysing Coloured Petri Nets. Proc. of 24th International Conference on Applications and Theory of Petri Nets (Petri Nets 2003). Lecture notes in computer Science, vol 2679. Springer-Verlag Berlin, pp 450–462Google Scholar
- 13.Lalouette J, Brinzei N, Malasse O, Caron R, Scherb F, Aubry J-F (2010) Modeling and performance assessment of a railway signaling system integrating ETCS and BAL using colored Petri nets. Version 1, Sixth International French Conference of Automatic, CIFA 2010, Nancy, FranceGoogle Scholar
- 14.Abrial J-R (1996) The B-book: assigning programs to meanings. Cambridge University PressGoogle Scholar
- 15.Stuckenschmidt H (2002) Ontology-Based Information Sharing in Weakly Structured Environments. PhD thesis, University of VrijeGoogle Scholar
- 16.Redjimi M, Boukelkoul S (2013) Algorithmic tools for the transformation of Petri nets to DEVS. Informatica 37:411–418Google Scholar
- 17.Aubrecht P, Zakova M, Kouba Z (2005) Ontology Transformation Using Generalized Formalism. Znalosti, roèníku conference, pp. 154-161, V©B-TUOGoogle Scholar
- 18.Combemale B, Crégut X, Garoche PL, Thirioux X (2009) Essay on semantic definitions in MDE - an instrumented approach for model verification. JSW, vol 4(9):943–958Google Scholar
- 19.Istoan P. Methodology for the derivation of product behavior in a Software Product Line. PhD thesis, University of Rennes 1, University of Luxembourg, February 2013Google Scholar
- 20.Bon P, Collart-Dutilleul S (2013) From a solution model to a B model for verification of safety properties. J UCS 19(1):2–24Google Scholar
- 21.Korečko S, Sobota B (2014) Petri nets to B-language transformation in software development. Acta Plotechnica Hungarica 11(6):2014Google Scholar
- 22.UNISIG. Subset-039: FIS for the RBC/RBC Handover. April 2009Google Scholar
- 23.Bon P, Collart-Dutilleul S, Sun P. Study of implementation of ERTMS with respect to French national rules using a B centred methodology, International Conference on Industrial Engineering and Systems Management IESM’2013 October 28–October 30 Rabat – MoroccoGoogle Scholar

## Copyright information

**Open Access** This article is distributed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits unrestricted use, distribution, and reproduction in any medium, provided you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license, and indicate if changes were made.