European railway traffic management system validation using UML/Petri nets modelling strategy

2.1 ERTMS components

Together, these components form the new signalling and management system for Europe enable interoperability throughout the European Rail Network.

2.2 ERTMS characteristics

The ERTMS system has to replace many railway signalling systems that currently exist in Europe. To deal with the very different configurations in the signalling equipments in the member states, ETCS has been conceived with three so-called application levels, which are a way to express the possible relationships between track and train [35].

In application level 1 (Fig. 1), the track transmits to the train information allowing it to calculate constantly its maximum authorized speed. This information is transmitted to the trains by means of Eurobalises placed along the track and connected to the existing signalling system. The train position is detected by traditional trackside occupancy controlling devices, which are linked to the interlocking. The track is considered as a set of structured fixed block sections [Web1]. In application level 2 (Fig. 1), the ETCS uses a continuous radio communication mean, the GSM-R, to exchange information between the track and the train. The interlocking transfers the status of trains routes to the RBC (Radio Block Centre) which, in turn, calculates the correct movement authorities and the safe speed instructions it transmits to trains. In this level, balises are mainly used for odometry purposes and the train position is detected by the track [Web1]. Compared to Level 1, the track-train communications are done by GSM-R. Finally, in application level 3, RBC uses the GSM-R transmission between the track and the trains like for Level 2. But at level 3, the track receives the train location and the train integrity from trains [Web1]. Compared to level 2, this configuration offers a great simplification with cost reduction of the equipment on the track and an independence from structured fixed block sections by using moving blocks. Required for any new line in Europe, this paper focuses only on application level 2 of ERTMS [35]. For this application level, as any other level, the ETCS is distributed partly trackside and partly on board the trains (Fig. 2).

Open image in new window

Open image in new window

The Functional Requirement Specifications (FRS) [32] and the System Requirement Specifications (SRS) [33] constitute the system level ERTMS specifications [35]. They are defined in a text format. The FRS identifies the functions required for technical interoperability. The SRS define the system requirements for the European Train Control System of ERTMS. They are the translation of the mandatory functional requirements defined in the FRS.

2.3 ERTMS implementation

European Commission imposes to take into account the return of these experiences in order to review the migration strategy and adapt it to the reality of the field for the deployment of the corridors. Indeed, the Memorandum of Understanding (MoU), signed at July 2008, between the European Commission and the European Railway Associations (CER – UIC – UNIFE – EIM – GSM-R Industry Group – ERFA), concerns the strengthening of cooperation for speeding up the deployment of ERTMS. Our work belongs to this European approach. Indeed, in the chapter 5 of the MoU, testing procedures are considered as a fundamental factor to successfully implement ERTMS. The Parties acknowledge and welcome the efforts made by the suppliers in the field of interoperability testing between different suppliers in-lab, on site or in dedicated test facilities.

4.1 UML modelling approach

The Object oriented analysis (OOA) applies object modelling techniques to analyse the requirements for a system. OOA views the world as objects with data structures and behaviours. The idea that a system can be viewed as a population of interacting objects, each of which is an atomic bundle of data and functionality, is the foundation of object technology and provides an attractive alternative for the development of complex systems. This is a radical departure from prior methods of requirement specification, such as functional decomposition and structured analysis and design [38]. As opposed to the traditional data or functional views of systems, OOA can yield the following benefits: maintainability through simplified mapping to the real world, which provides for less analysis effort, less complexity in system design, and easier verification by the user; reusability of the analysis artefacts which saves time and costs; and, depending on the analysis method and programming language, productivity gains through direct mapping to features of Object-Oriented Programming Languages [1]. Numerous OOA methods have been described since 1988. They include: Shlaer-Mellor [30], Jacobson [14], Coad-Yourdon [6], Booch [5] and Rumbaugh [28]. In 1997, Rumbaugh, Booch and Jacobson gathered their methods to produce the Unified Modelling Language (UML) which has became the standard modelling language used in object-oriented analysis and design.

The main objective of this research is the generation of test scenarios to check the behaviour of an on-board ERTMS component (EVC: European Vital Computer) compared to specifications. Then, it is necessary to model the dynamic view of the ERTMS system by using different behavioural UML diagrams. Among these diagrams, the State Machines are especially suitable for modelling the dynamic view of systems. Sequence and collaboration diagrams are used to model single cycles inside the system and, therefore, they cannot be directly useful for investigation of the whole behaviour. UML State Machines are widely accepted in industry because of the availability of suitable software tools. They contain simple states, composite states, transitions, pseudostates [25]. A state has several parts, namely Name (textual string for identification), Entry activity (action always executed upon entering the state), Do activity (internal action in the state), Exit activity (action always performed whenever the state is left, regardless of which transition is taken). In our work, Entry and Exit activities are not used (Fig. 4). Concerning the Pseudostates, which are transient vertices with special semantics, they can be used to connect multiple transition paths into more complex ones. In our work, pseudostates allowed include initial state and choice. Join and fork are not used because we have no parallel scenarios in our case study. A transition has five parts, namely Source state (state affected by the transition), Event Trigger (event whose reception makes the transition fireable, Fig. 4), Guard Condition (Boolean expression that is evaluated before a transition fires. The transition can fire only if the condition evaluates to true, Fig. 4), Action (executable atomic computation, Fig. 4), and Target state (state that becomes active after the completion of the transition).

Open image in new window

In this study, ERTMS system is described by a set of State machines (that describe the behaviour of objects) and that Sequence diagrams are used to emphasize specific patterns of interactions among State machines. The proposed analysis is based on the combined use of Sequence diagrams and State machines because of the consistency between these two types of UML diagrams. For instance, components of the Sequence Diagram are those of State machines, or are a proper subset.

4.2 UML model transformation into Petri Nets

In the following, we explain our approach for the transformation of UML State Machines and UML Sequence diagrams into Petri Nets aimed at test scenario generation. The translation of both State machines and Sequence diagrams to Petri nets is automatic. However, we are aware, that at this point, we cannot claim completeness for transforming all State Machine elements and constructs because we transform only elements used in our case study. Indeed, there are some ambiguities for which we have made a specific choice, and also some characteristics that we have decided not to translate. So, the translation proposed here provides a formal semantics for a subset of the State machines (and the same is true for Sequence diagrams). The approach is based on a decomposition of UML State Machines into its basic elements, such as states, pseudostates, and transitions. For each element, transformation rules from State Machines into Petri Net fragments are presented. Thereby, time constraints on transitions are taken into account. For Sequence diagrams, they are used to guide the connection of these Petri Net fragments, providing a single Petri net for the system under study.

4.2.2 Petri net formalism

Petri nets are a promising tool for describing systems that are characterized as being concurrent, asynchronous, distributed, parallel, non deterministic, and/or stochastic. As a graphic tool, it is used like as a means of communication and it is similar to the state machine diagram.

Définition 1

A Petri net R is a quadruple  < P, T, A, M > where:

• ▪ P denotes a finite set of places (containing tokens);

• ▪ T is a finite set of transitions (which specify how tokens move from one place to another);

• ▪ W ∈ (P × T) ∪ (T × P) →N is the weighted flow relation representing the arcs. It associates to each pair (place, transition) or (transition, place) the weight of the corresponding arc in the net;

• ▪ M _init : P → N₊ is an initial marking in R (tokens contained in the initial places).

We chose this class of Petri nets because of the similarity with the UML state machines. However, in order to translate our state machines diagrams to Petri nets, we added some elements to the previous definition. In deed, the Petri net used in our study is defined in the following Petri net Meta-model.

Petri net Meta-model

The Petri net is considered like the target formalism in the transformation technique. It consists of places, transitions, and arcs that connect them. Input arcs connect places with transitions, while output arcs start at a transition and end at a place. In addition, tokens are used in places in order to simulate the dynamic and concurrent activities of systems. The transitions model the activities which can occur, thus changing the state of the system. They are only allowed to fire if they are enabled, which means that all the preconditions for the activity must be fulfilled. As a mathematical tool, it is possible to set up state equations, algebraic equations, and other mathematical models describing the behaviour of systems [24]. In order to comply with UML State machine, the Petri net is enriched by the addition of operators and predicates. A predicate is associated to the transition and allows expressing of a condition guard. An operator allows performing of an action and is also associated to a transition.

The description of the elements composing the Petri net constitutes the meta-model. A meta-model is a model that defines the expression language of a model, or the modelling language. The meta-modelling is an activity which allows defining of a modelling language meta-model. In the Fig. 5, we present a simple meta-model for the Petri net developed in our study.

Open image in new window

4.2.3 Transformation rules

As already said in the previous paragraph, UML provides several types of diagrams which allow capturing of different aspects and views of the system. The abstract syntax of each modelling notation is described by means of meta-models, which are graphically represented with Class Diagrams, together with textual comments. The approach adopted for the transformation of State machines and Sequences Diagrams consists at first in translating the two UML notations into Petri Net separately, starting from the metamodel of the UML State Machines. The translation of the Sequence Diagrams is used to connect the different elements obtained after State machines translation. The Resulted Petri net model is then built on the basis of the UML State machine and offers the possibility to check all existing paths within the states graph, where one path constitutes one scenario to be tested [26].

The model transformation allows translating a model Ma into a model Mb in accordance with their respective meta-models MMa and MMb. These meta-models may be identical in the case of endogenous transformation or different in the case of an exogenous transformation. On the other hand, the model transformation can be vertical when there is a move from one abstraction level to another. But if we keep the same abstraction level, the transformation will be horizontal. The transforming relationship of a model Ma consistent with its meta-model MMa into a model Mb consistent with its meta-model MMb through a transformation model Mt can be described as follows:

Open image in new window

In this paper, we transform models in the same abstraction level; it is therefore a horizontal transformation. This transformation is also exogenous because that the UML meta-model and the Petri net meta-model are different. The translation between the source model and the target model needs some rules to match the elements modelled in UML to other elements, which compose the Petri net. To formalize this transformation [20], the first step is that the structure, so called metamodel, of both UML and Petri Net models must be known. The UML meta-models of the State machine and Sequence diagram metamodel are available in [25]. Figure 5 shows the Petri net meta-model [INRIA, 05]. Based on these meta-models, the second step consists in defining some rules to match the elements modelled in UML to elements composing the Petri Net one (Fig. 6).

Open image in new window

In the UML StateMachine Metamodel, a StateMachine sm is basically composed of regions and pseudostates. In particular, a region r ∈ sm.region is composed of states, pseudostates and transitions (Fig. 6). A state s ∈ r.states can be composed of regions in the case of composite state. A state s can be also composed of s.pseudostates, s.constraint, s.trigger and s.behavior. A transition tr ∈ r.transtions is a complete response of sm to a particular event instance tr.trigger. Firing of a transition provokes a behaviour tr.behaviour to be performed. In the Fig. 6, these UML elements are mapped to elements which compose the Petri net metamodel (Fig. 5) in order to transform the State machine diagram into a PrT Petri net diagram. In the following we describe some transformations rules between the State machine and the Petri net.

1. A-

   Initial Pseudostate

    

Definition

The initial Pseudostate is a state that defines the starting point for the default state machine. It is represented by a black circle. The outgoing transition from the initial vertex may have behaviour, but not trigger or guard.

Rule A

An initial Pseudostate is transformed into a place in the Petri net with a token (Fig. 7). The place name is composed by the modelled object name followed by “init”.

Open image in new window

1. B-

   Simple State

    

Definition

A simple state is a state that does not have substates (i.e., it has no regions and it has no submachine state machine).

Rule B1

A simple state without internal activity is transformed into two places and a transition: a place that marks the entrance to the state, another place that marks the exit of the state and a transition between the two (Fig. 8). A simple transition between the initial and the next state is translated into a transition in the corresponding Petri net

Open image in new window

Rule B2

A simple state including an internal activity (do activity) is transformed like this: a place to enter the state, a transition, a place that marks the beginning of the “do activity”, a transition with an operator that defines the action to do in the activity, an exit place from the method that marks the end of the action, a transition to the place that marks the exit of the state.

1. C-

   Transition

    

Definition

A transition leaving a source state has usually a trigger event, a guard condition, an effect (action) and a target state. Four types of transitions exist: external transitions, internal transitions, entry transitions and exit transitions. The most common type that we use in our work is the external transition. This is a response to an event that causes a state change or a self-transition, and a specified effect. It is represented by an arrow from the source state to target state, with other attached properties in text form (Fig. 9).

Open image in new window

Rule C1

A simple transition in the state machine is transformed to a simple transition in the Petri net.

Rule C2

A transition with a trigger and an effect is transformed like this:

• ✓ A trigger is represented in the Petri net by two places and a transition: a first place to declare that the message is arrived, a transition that allows variables assignment (operator) and a place to declare that the message is received (Fig. 10).

  Open image in new window

• ✓ An effect is represented in the Petri net by three places and a transition: a first place to call the action, a transition that allows variables assignment (operator), a place to show that the message is sent and a place to declare that the message is arrived (Fig. 10).

Rule C3

A transition with a guard condition is transformed into two transitions in the Petri net. A predicate is attributed to each transition. The first predicate checks if the guard is true and the second predicate checks if the guard is false (Fig. 11).

Open image in new window

1. D-

   Choice Pseudostate

    

Definition

Choice vertices which, when reached, result in the dynamic evaluation of the guards of the triggers of its outgoing transitions. This realizes a dynamic conditional branch. It allows splitting of transitions into multiple outgoing paths such that the decision on which path to take may be a function of the results of prior actions performed in the same run-to-completion step. If more than one of the guards evaluates to true, an arbitrary one is selected. If none of the guards evaluates to true, then the model is considered ill-formed. (To avoid this, it is recommended to define one outgoing transition with the predefined “else” guard for every choice vertex.)

Rule D

In our study, the choice has two outgoing transitions with two guards. So the choice is transformed into two transitions in the corresponding Petri net. A predicate is associated to each transition representing guards of the state machine (Fig. 11).

4.3 Start Of Mission (SOM) Application

The ERTMS system is composed of two parts, on-track and on-board equipment. It is necessary to consider two system points of view in order to identify external actors. In the first point of view, the considered system is the on-board one, so actors are defined as driver, RBC, and GSM-R. In the second point of view, the considered system is the trackside one, so actors are defined as trains (EVCs), traffic manager, and interlocking. This allows defining system use cases which are a sequence of actions carried out by the system and producing an observable result for a particular actor. The first point of view was chosen in order to comply with the research aim and to check the EVC component. Therefore, a complete use case must be modelled in order to use it for verification and validation. The table of requirements used to model this procedure is available in [33]. This procedure is a use case for the on-board system and needs to be detailed in a State machine diagram in order to understand the dynamic behaviour of the EVC.

4.3.1 The UML modelling of SOM procedure

The procedure Start of Mission (SOM) allows the start of a train and it is triggered by the driver in these cases: Once the train is awake, or once shunting movements are finished, or once a mission is ended, or once a slave engine becomes a leading engine. The common point of all these situations is that the ERTMS/ETCS on-board is in Stand-By mode, but the Start of Mission will be different, since some data may be already stored on-board, depending on the previous situation. Once the ERTMS/ETCS on-board equipment is in Stand-By mode, the start of mission is not the only possibility; the engine may be remote controlled (sleeping). At the beginning of the Start of Mission procedure, the data required may be in one of three states: “valid” (the stored value is known to be correct) or “Invalid” (the stored value may be wrong) or “Unknown”. This refers to the following data: Driver ID, ERTMS/ETCS level, RBC ID/phone number, Train Data, Train Running Number and Train Position.

The State machine diagram presented in this section (Fig. 12) describes the behaviour of the EVC during the identification of SOM data.

Open image in new window

4.3.2 The transformation of SOM model into Petri net

In order to apply the different transformation rules, we choose at first, to transform a simple part of the UML State machine (Fig. 12), the identification of the driver (Fig. 13). In fact, the Start of Mission procedure shall be engaged when the ERTMS/ETCS on-board equipment is in Stand-By mode with a desk open and if no pending communication session and/or radio safe connection is established. After, depending on the stored status of the Driver-ID, the ERTMS/ETCS on-board equipment shall request the driver to enter the Driver-ID (if the status of Driver-ID is unknown) or shall request the driver to revalidate or re-enter the Driver-ID (if the status of the Driver-ID is invalid). Then, the ERTMS/ETCS on-board equipment shall check if the entered Driver-ID is valid or invalid. In the case of a valid DI, the ERTMS/ETCS on-board equipment updates the stored DI. In the case of a stored valid DI, it is possible to check the status of the Train running number (TRN).

Open image in new window

The application of our defined transformation rules allows obtaining the Petri Net shown in Fig. 14.

Open image in new window

5.1 Approach

A test scenario is considered as a firing sequence in the Petri net. So, the test scenarios generation corresponds to the generation of firing sequences in the reachability graph. Various methods have been suggested to handle the PN reachability problem. In this paper, we are interested in the Petri net logical abstraction technique proposed initially by Benasser [2]. This method consists of developing a unique sequence of partial steps corresponding to the total behaviour of the system. The proposal approach was validated on several examples using logical constraint programming techniques. Numerical results using Prolog IV have shown that the method can be more effective than other generic solvers. However, the practical resolution performance is limited by the incremental search mechanism used: memory overflows appear early when the size of the problem grows.

If we recall the definition 1 of Section 4.2.2, we add the definition of the following matrices: Precondition (Pre: m × n), Postcondition (Post: m × n) and Incidence (C: m × n).

Open image in new window

In a Petri net, the markings of places represent the state of the corresponding system at a given moment. This marking can be modified according to the firing of transitions. A transition t is firable for a marking m₀ (denoted by m₀ [t〉), when ∀ p ∈ P, m₀ (p) ≥ W (p, t). If this condition is satisfied, a new marking m₁ is produced from the marking m0 (denoted by m₀ [t〉m₁): ∀ p ∈ P, m₁ (p) = m₀ (p) − W (p, t) + W (t, p).

In the following section, we propose new approaches to find firable transitions sequences leading to a target marking. Our methods are based on the Petri net logical abstraction and mathematical programming techniques.

5.2 Test generation

Benasser [2] proposed an algorithm to solve the reachability problem using the logical abstraction and constraint programming techniques. This algorithm iterates the number of partial steps used, adding one new step at each iteration, in order to test all the lengths of complete sequences of partial steps lower than K.

This algorithm is correct since the sequences found are effectively sequences of steps which produce the desired final marking. It is also complete since it can enumerate all the solutions of length lower than a given integer. In each iteration, the algorithm uses a mechanism of linear constraints solving. It has been implemented using the constraint logic programming software Prolog IV. The interest of the use of Prolog IV lies in the fact that its constraints resolution mechanism is incremental [15]. Indeed, it is not necessary to redefine in each iteration the constraints incorporated into the previous stage. The constraints are added in the constraints solver so that it can reuse the results of the previous constraints propagation. The search for the concrete results is made at the end by an enumeration of all the possible integer solutions.

In the previous figure (Fig. 15), we show how to generate sequences from resulted Petri net (transformation of UML diagram in Fig. 14). The Pre and Post matrices are generated in order to be used for sequences generation. Indeed, as shown in Fig. 15, we can generate sequences with fixed length for all final markings. We can also generate sequences whose maximum length is l. The final marking can be also fixed. In this case, all possible sequences, which can reach this final marking, are generated.

Open image in new window

5.3 Simulation

Both the train operational simulator and traffic simulator can be used stand alone or interconnected to put the train driver in a simulated traffic (Fig. 16). They use the same offline tools so tracks can be used either for traffic or operational train scenarios.

Open image in new window