 Original Paper
 Open Access
European railway traffic management system validation using UML/Petri nets modelling strategy
 Sana Jabri^{1}Email author,
 El Miloudi El Koursi^{1},
 Thomas Bourdeaud’huy^{2} and
 Etienne Lemaire^{1}
https://doi.org/10.1007/s1254401000305
© The Author(s) 2010
 Received: 4 May 2009
 Accepted: 26 March 2010
 Published: 17 April 2010
Abstract
Purpose
The European Union set up a European management system for rail traffic: the ERTMS system to ensure, in full safety, train circulation on different European networks. As the full deployment of this system is long and expensive, evolutions are necessary and raise other technological challenges. The goal is to determine how to use ERTMS specifications to produce test scenarios. This paper presents methods, models and tools dedicated to the generation of test scenarios for the validation of ERTMS components based on functional requirements.
Methods
The development of ERTMS system requires adequate methods for modelling and checking its behaviour. Evaluation and certification of the system can be done by generating test scenarios applying formal methods. The Unified Modelling Language (UML) is a widely accepted modelling standard in industry. However, it is a semiformal language and it does not allow verification of system behaviour. In this case, formal models like Petri Net can be used.
Results
These methods are used in order to formalize ERTMS specification. Tests scenarios are generated on the basis of Petri net models. One scenario is considered like a firing sequence in the reachability graph of the Petri net. Then, test scenarios are applied on ERTMS platform simulator in order to check the components and to give test verdicts.
Conclusions
Finally, the approach, developed in this paper, has been applied to ERTMS components in order to demonstrate the validation and certification costs reduction and also to minimize the upgrade and retrofit constraints and validation cost.
Keywords
 ERTMS system
 UML
 Petri net
 Model transformation
 Test
 System validation
1 Introduction
On international trains, onboard equipment for the various national control command systems must be installed. This is becoming more and more expensive due to the increasing sophistication and expense of equipment. A train crossing several European countries must switch to the controlcommand systems in the country it crosses. So, in order to remove these obstacles through the European rail network, the European Commission encouraged the development of a signalling and management system common to all member states: the ERTMS system (European Rail Traffic Management System). This will, therefore, reduce the validation and certification costs of ERTMS component implementation in different member states. The objective of this research work is to facilitate the interoperability through the mutual recognition of the ERTMS components between the member states by proposing test scenarios enabling cover checking.
Being a realtime distributed system, ERTMS can be considered as complex industrial system. It also uses a great number of actors and, as it is a railway signalling system, it must comply with very strict safety constraints. It is then necessary to check and validate the ERTMS system in order to give confidence to all parts [17]. These checking activities suggest various techniques such as: static analysis, model checking, and conformity test. Conformity tests verify if an implementation satisfies the behaviour described in the specification. This method detects the errors of implementation by performing sequences of actions; in order to determine whether system behaviours are those initially specified. This type of test was developed for the validation of communication protocols [29]. Conformity tests have three steps: (1) the derivation of tests scenarios which aims to generate abstract test scenarios on the basis of the protocol specification, (2) allows the implementation of test scenarios in order to make them executable for a particular implementation, and (3) apply the implemented test scenarios in order to determine the conformity verdict.
Regarding ERTMS specifications, FRS (Functional Requirement Specifications) and SRS (System Requirement Specifications) contain functional requirements at system level, which place the core of this study in the functional testing field. However, the structure of the specifications (inputs, outputs, requirements) is not formal enough and, therefore, not appropriate to the preparation of test scenarios. The objective of this work consists in producing “standard bricks” which will describe and specify each requirement. Then, a transformation process allows obtaining formalised models which will be used in this work. This formalisation requires analysing, classifying, and structuring of the specifications.
The remainder of the paper is organised as follows: Section 2 presents the UML (Unified Modelling Language) modelling of ERTMS/ETCS specifications. In Section 3, the transformation of the UML model into Predicate Transitions Petri Nets is introduced with an application example. Finally, before conclusion, the generation of test scenarios on the basis of the Petri Net model is described.
2 ERTMS system
The ERTMS system aims at remedying for the fragmentation of the European rail network, identified as a major obstacle to the development of international rail traffic [19]. In fact, the principle of the system is to standardize several signalling systems currently coexisting in Europe and to produce an economic and technical solution to railway interoperability [7]. It is defined as “The aptitude of the conventional transeuropean railway system to allow sure circulation and without interruption of trains by achieving the necessary performances for these lines. This aptitude is based on the whole of the lawful, technical and operational conditions which must be met to satisfy essential requirements” [8]. From a functional point of view, interoperability is characterized by four major points: At the borders, the train should not change locomotives, the train should not stop, it should not have a change of control agent and the driver should not carry out control actions other than ERTMS standardized ones [13].
2.1 ERTMS components

▪ ETCS( European Train Control System) allows transmitting the permitted speed and movement information to the train driver and constant monitoring of the driver’s compliance with these instructions. An onboard computer compares the train speed with the permitted speed and brakes automatically when it is necessary.

▪ GSMR (GSM for Railways) is the radio system used for information transmission between the track and the train. It is based on the standard GSM but using different frequencies specific to rail.
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 socalled application levels, which are a way to express the possible relationships between track and train [35].
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
Lines with ETCS in commercial operation [36]
Country  Line  Length (km)  ETCS level  Year  Supplier 

Austria  Vienna to Hungarian border section Hegyesschalom  67  1  2006  Siemens / Thales 
Bulgaria  Sofia – Plovdiv – Burgas  440  1  2001  Thales 
Germany  Berlin – Halle/Leipzig  135  2  2005  Siemens / Thales 
Hungary  Hodos – ZalacsébS.  23  1  2004  Thales 
(Vienna) Hegyeshalom – Budapest  Thales  1  2007  Thales  
Italy  Milano – Bologna  182  2  2008  Ansaldo STS/Alstom 
Torino – Novara  90  2  2006  Ansaldo STS/Alstom  
Roma – Napoli  200  2  2005  Ansaldo STS/Alstom  
Luxembourg  60% of the CFL network, including Luxembourg station  162  1  2005  2008  Thales 
Netherlands  Betuwe Line Rotterdam – Zevenaar  110  2  2007  Alstom 
Spain  Lérida – Roda  91  1/2  2006  Thales 
Córdoba – Malaga  155  1/2  2006  Invensys  
Roda – Barcelona  99  1/2  2008  Thales  
Madrid Valladolid  180  1/2  2007  Thales  
Madrid Lérida  440  1/2  2006  Ansaldo STS  
Switzerland  Mattstetten – Rothrist (Olten – Berne)  45  2  2007  Thales 
Löstchberg base tunnel between Frutigen – Visp (Bern Brig)  35  2  2007  Thales  
Total length of lines with ETCS in commercial operation  2,644 km 

✓ The heritage of the past. Each National Railway has its own constraints, then, it seems to be difficult to organise the railway traffic around them. Indeed, despite the huge amount of similitudes, the details vary considerably and the safety is linked to these details.

✓ A timing problem. The scheduling and the time frame of the ERTMS deployment along the corridor is driven by the national Member State considerations as budget allocation, law application process, or what has been established below.

✓ An organisational problem. The introduction of ERTMS system and more generally the opening of the Railway Market has introduced new stakeholders, a new split of responsibilities and new contractual or other type of relationship between them. The speed of the migration depends on a clear definition of the role of each stakeholder, their corresponding scope and activity and the coordination of their collaboration.
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 – GSMR 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 inlab, on site or in dedicated test facilities.
3 Methodology and objectives
The industrial context of this study imposes strict safety requirements. The proposed methodology consists in generating conformity test scenarios from the specification. This specification has an informal description, so it is not appropriate for the test scenarios generation. Then, we need to model and formalize this specification.
4 Modelling and transformation technique
The ERTMS specifications constitute the basis of this research. The description of these specifications is not formal, hence the need to build formal and standard models. At a first time, SADT (Structured Analysis and Design Technique) method was proposed to organize the specifications because it is a functional analysis method [IGL, 89] and commonly used in railway sectors. This method provides a static, clear, and precise architecture of the ERTMS specifications. However, carrying out checks of the ERTMS/ ETCS system appears to be difficult using SADT models. Indeed, the SRS are evolving while SADT models are static and cannot be easily reused. So, a migration from this functional modelling to an object oriented one is proposed in order to apprehend the dynamic behaviour of the system and to allow the reuse of models. The selected object formalism is UML (Unified Modelling Language).
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 ObjectOriented Programming Languages [1]. Numerous OOA methods have been described since 1988. They include: ShlaerMellor [30], Jacobson [14], CoadYourdon [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 objectoriented analysis and design.
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.1 Background
King and Pooley used the Generalized Stochastic Petri Nets (GSPNs) [22] in [16, 27] in order to represent the behaviour of StateCharts. Indeed, each state is mapped into a place and each state transition becomes a transition in the Petri Net. The resulting submodels are combined using UML collaboration diagrams. In our study, the combination of our submodels is done using the UML sequence diagram. Another approach for model transformation of UML diagrams is proposed by Merseguer [23] and Bernardi et al. [3]. In their study, extended UML diagrams are translated into labelled GSPN modules, which are subsequently merged into a complete model. In [11] an extension of UML models with probabilistic choice and stochastic timing is also proposed.
In [31], the authors proposed to model the behaviour of technical systems by means of UML State Machines and the extending UML Profile for Schedulability, Performance, and Time (SPT). A model transformation technique of UML diagram into a Stochastic Petri Net is established in order to measure performance by simulation or numerical analysis. In [21], LopezGaro, Merseguer and Campos proposed to model the dynamic view of the system by using UML activity diagrams. Since UML defines “informally” their semantics, they choose to translate each diagram into a Labelled Generalized Stochastic Petri net (LGSPN), an extension of the wellknown GSPN formalism [22], gaining a formal semantics for them.
Bernardi, Donatelli and Merseguer used UML Sequence Diagrams and Statecharts for the validation and the performance evaluation of systems in [3]. They consider that a system is specified as a set of Statecharts and that Sequence Diagrams are used to represent “executions of interest”. It is not possible for them to apply mathematical techniques directly on UML diagrams because it lacks a formal semantics. So, they propose an automatic translation of Statecharts and Sequence Diagrams into Generalized Stochastic Petri Nets, and a composition of the resulting net models suitable for reaching a given analysis goal. Like this study, the contribution of our work is to propose a formal translation of two types of UML diagrams and to establish relationships between them according to the UML metamodel. Since the main characteristics of our approach are that the translation is automatic using a model transformation technique, that consistency between States machines and Sequence Diagrams is taken into account and the model transformation is meant also for automatic test generation purposes.
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

▪ 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 Metamodel.
Petri net Metamodel
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.
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 metamodels, 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].
 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
 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
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.
 C
Transition
Definition
Rule C1
A simple transition in the state machine is transformed to a simple transition in the Petri net.
Rule C2

✓ 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).

✓ 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
 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 runtocompletion 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 illformed. (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, ontrack and onboard 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 onboard one, so actors are defined as driver, RBC, and GSMR. 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 onboard 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 onboard is in StandBy mode, but the Start of Mission will be different, since some data may be already stored onboard, depending on the previous situation. Once the ERTMS/ETCS onboard equipment is in StandBy 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.
4.3.2 The transformation of SOM model into Petri net
5 Test scenarios generation
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.
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_{0} (denoted by m_{0} [t〉), when ∀ p ∈ P, m_{0} (p) ≥ W (p, t). If this condition is satisfied, a new marking m_{1} is produced from the marking m0 (denoted by m_{0} [t〉m_{1}): ∀ p ∈ P, m_{1} (p) = m_{0} (p) − W (p, t) + W (t, p).

✓ A set of nodes A(R, m_{0}) which represent all the markings reachable by any firable transition sequence. Formally, A(R, m_{0}) = {m_{f}∃ σ ∈ T (R, m_{0}) s.t. m_{0}[σ〉 m_{f} };

✓ A set of arcs, where an arc (m_{i}, m_{j}) labelled t connects nodes representing the markings m_{i} and m_{j} if m_{i} [t〉 m_{j}.

✓ The first one consists of managing the combinatorial explosion without modifying the studied reachability graph. Classical approaches are graph compressions and forward checking [9, 10].

✓ Other techniques construct a reduced reachability graph associated to the original, based on some properties to preserve [4, 12].

✓ The last ones are based on the state equation: we can distinguish parameterized analysis and algebraic methods [18].
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.
5.3 Simulation

▪ A single train operational simulator with its 3D visualization of the tracks

▪ An ERTMS traffic simulator:

▪ a route map controller;

▪ an interlocking system

▪ up to 2 Radio Block Centres

▪ up to 11 trains including the operational train simulator


▪ Offline tools:

▪ A track editor for constructing tracks and a set of elements of the tracks (track, points, balises, boards...)

▪ A scenario editor for setting the dynamic parameters of each scenario.

6 Conclusions
In this paper, we developed a methodology of test scenarios generation. At a first step, we formalized specification by a using a transformation technique of UML models. The obtained Petri net models are used in order to generate test scenarios. One scenario is considered like a firing sequence in the reachability graph. So, we developed a method allowing generation of firing sequences from an initial marking to a final marking.
Generally, the number of tests is directly linked with the product of its amount of functions and the degree of freedom of its application conditions. It means the more flexible is the solution the biggest is the number of tests and its related costs. The approach, developed in this paper, has been applied to components of a flexible system ERTMS (European Rail Traffic Management System) in order to demonstrate the validation and certification costs reduction and also to minimize the upgrade and retrofit constraints and validation cost.
In future work, we take into account the time in order to formalize specifications. In ERTMS context, interactions may be related to time constraints. A transformation of UML models based on time constraints is interesting. Then, the coverage of the generated test scenarios must be defined. In this paper, we generate a set of test scenarios from the reachability graph accessibility based on constraint programming. Later we want to define a coverage criterion to ensure that tests adequately cover the specification
Declarations
Open Access
This article is distributed under the terms of the Creative Commons Attribution Noncommercial License which permits any noncommercial use, distribution, and reproduction in any medium, provided the original author(s) and source are credited.
Authors’ Affiliations
References
 Baudoin C, Hollowell G (1996) Realizing the objectoriented lifecycle. Prentice Hall, Upper Saddle RiverGoogle Scholar
 Benasser A (2000) “L’accessibilité dans les réseaux de Petri : une approche basée sur la programmation par contraintes”, PhD thesis, Université des sciences et technologies de LilleGoogle Scholar
 Bernardi S, Donatelli S, Merseguer J (2002) From UML Sequence Diagrams and Statecharts to analysable Petri Net models, In Proc. of the 3rd Int. Workshop on Software and Performance (WOSP), pp 35–45, Rome, Italy, JulyGoogle Scholar
 Berthelot G (1986) Transformations and decompositions of nets. In: Brauer W, Reisig W, Rozenberg G (eds) Advances in Petri Nets 1986 Part I. Proceedings of an Advanced Course 254:359–376Google Scholar
 Booch G (1991) Object Oriented Design with Applications, Redwood City, CA:Benjamen/CummingsGoogle Scholar
 Coad P, Yourdon E (1991) Objectoriented analysis, 2nd edn. Yourdon Press, Prentice Hall, Englewood CliffsGoogle Scholar
 European Commission (2006) ERTMS – Delivering flexible and reliable rail traffic, DG TREN,16pGoogle Scholar
 European Communities Commission (2001) Council Directive 2001/16/EC of the European Parliament and of the Council on the interoperability of the transEuropean conventional rail system, Official Journal of the European UnionGoogle Scholar
 Fernandez JC, Jard C, Jéron T, Mounier L (1992) On the fly verification of finite transition systems. Formal Methods in System DesignGoogle Scholar
 Gunnarsson J (1998) Symbolic tools for verification of large scale DEDS. IEEE Int. Conf. on Systems, Man, and Cybernetics (SMC’98), 1114 October 1998, SanDiego, CA, pp 722–727Google Scholar
 Hopkins R, Smith M, King P (2002) Two approaches to integrating UML and performance models. In Proc. of the 3rd Int. Workshop on Software and Performance (WOSP), pp 91–92, JulyGoogle Scholar
 Huber P, Jensen AM, Jepsen LO, Jensen K (1985) Towards reachability trees for highlevel Petri nets, Lecture Notes in Computer Science: Advances in Petri Nets 1984, 188:215–233Google Scholar
 Jabri S, Lemaire E (2007) Modeling of the European railway system for automatic checking”, 15th International Symposium EURNEX ZEL 2007: Towards more competitive European rail systemGoogle Scholar
 Jacobson I (1987) Object Oriented development in an industrial environment, Proceedings on ObjectOriented programming systems, languages and applications, pp 183191Google Scholar
 Jaffar J, Michaylov S, Stuckey P, Yap R (1992) The CLP (R) language and system. ACM Trans Program Lang Syst 14(3):339–395View ArticleGoogle Scholar
 King P, Pooley R (1999) Using UML to derive stochastic Petri net models. In Proceedings of the 15th UK Performance Engineering Workshop, pp 45–56, Bristol, UK, JulyGoogle Scholar
 El Koursi EM, Kampmann B (2002) Qualitative and quantitative safety assessment of ERTMS Operating rules. Comprail, pp 671680Google Scholar
 Lautenbach K (1987) Linear algebraic techniques for place/transition nets. In Advances in Petri Nets 1986, Part I, Proceedings of an Advanced Course, 254:142–167Google Scholar
 Lochman L (2009) Background for ERTMS. In: IUC (ed) Compendium on ERTMSGoogle Scholar
 Lopes D, Hammoudi S, Bezivin J, Jouault F (2005) Mapping Specification in MDA: From Theory to Practice. Proceedings of INTEROPESA, pp 253264Google Scholar
 LopezGaro JP, Merseguer J, Campos J (2004) From UML activity diagrams to stochastic Petri Net models: Application to Software Performance Engineering. Proceedings of the 3rd Int. workshop on Software and performance, pp 2536Google Scholar
 Marsan MA, Balbo G, Conte G, Donatelli S, Franceschinis G (1995) Modelling with Generalized Stochastic Petri Nets. Series in parallel computing. WileyGoogle Scholar
 Merseguer J (2004) On the use of UML State Machines for Software Performance Evaluation, In Proc. of the 10th IEEE RealTime and Embedded Technology and Applications Symposium (RTAS)Google Scholar
 Murata T (1989) Petri nets: Properties, analysis and applications. Proc IEEE 77(4):541–574View ArticleGoogle Scholar
 Object Management Group (2005) Unified Modelling Language: superstructure, version 2.0 http://www.omg.org
 Pettit RG, Gomaa H (2000) Validation of Dynamic Behavior in UML Using Colored Petri Nets, Workshop on Dynamic Behavior in UML Models: Semantic QuestionsGoogle Scholar
 Pooley R, King P (1999) The Unified Modelling Language and Performance Engineering. In IEE Proceedings  Software, volume 146(2), MarchGoogle Scholar
 Rumbaugh J, Blaha M, Premerlani W, Eddy F, Lorensen W (1997) OMT, Tome1 : Modélisation et conception orientées Objet, DunodGoogle Scholar
 Samuel P, Mall R, Kanth P (2007) Automatic test case generation from UML communication diagrams. Inf Softw Technol 49:158–171View ArticleGoogle Scholar
 Shlaer S, Mellor S (1988) Objectoriented systems analysis. Yourdon Press Computing SeriesGoogle Scholar
 Trowitzsch J, Zimmermann A (2006) Using UML state machines and Petri nets for the quantitative investigation of ETCS. Proceedings of the 1st Int. conference on Performance evaluation methodologies and tools, ItalyGoogle Scholar
 UNISIG, ERTMS Users Group (1999) FRS V4.29, Functional System Requirements Specification, FRSGoogle Scholar
 UNISIG, ERTMS Users Group (2008) Subset0265, System Requirements Specification, SRSGoogle Scholar
 Wendler E (2009) Influence of ETCS on the capacity of lines. In: UIC (ed) Compendium on ERTMSGoogle Scholar
 Winter P (2009a) Train controlcommand: the ETCS developments. In: UIC (ed) Compendium on ERTMSGoogle Scholar
 Winter P (2009b) European ERTMS applications in commercial operation. In: UIC (ed) Compendium on ERTMSGoogle Scholar
 Winter P (2009c) Conclusions and outlook. In: UIC (ed) Compendium on ERTMSGoogle Scholar
 Yourdon E, Constantine L (1979) Structured Design. Prentice Hall, Englewood CliffsGoogle Scholar