Upload
trannguyet
View
272
Download
10
Embed Size (px)
Citation preview
Formalised Approach for the Description of
Operational Scenarios for ERTMS Level 2
Documentation of the process to identify, capture and describe
Operational Scenarios for ERTMS Level 2 Trackside
Version: 0.5
Total Number of Pages: 27
Copyright © 2005 UIC / Euro-Interlocking All Rights Reserved
EUR INTERLOCKING
Approach ERTMS Operational Scenarios v5 30 August 2005 Page 2 of 27
Euro-Interlocking Approach ERTMS Operational Scenarios
Document Data Sheet
Filing name
Approach ERTMS Operational Scenarios v5
Document Type Last saved
30.08.05 12:45 Version: 0.5 Last saved by
Nick Koenig
Languages Title of Document
Formalised Approach for the Description of Operational Scenarios for ERTMS Level 2
Original
English Translations
Pages Figures Tables Subject
Documentation of the process to identify, capture and describe Operational Scenarios for ERTMS Level 2 Trackside
27
Price Author(s)
Wulf, Koenig Document
Right of Use
Performing Body
Sponsoring Body
Approved by Performing Body Approved by Sponsoring Body Availability of Document
Name
Name
Application Used
Microsoft Word 9.0 Template Name
EI Report6.dot Last Printed
30 August 2005 Date of Publication
August 2005 Abstract
Approach ERTMS Operational Scenarios v5 30 August 2005 Page 3 of 27
Euro-Interlocking Approach ERTMS Operational Scenarios
Table of Contents
Document Data Sheet....................................................................................................... 2
Table of Contents..............................................................................................................3
Abbreviations .................................................................................................................... 5
References to Cited Text .................................................................................................. 7
1. Introduction ........................................................................................................... 8
2. System Boundaries ............................................................................................... 9
2.1. Scope of the System ............................................................................................. 9
3. Formalised Method for Operational Scenario Description................................... 10
3.1. Actors.................................................................................................................. 12
3.1.1. Signaller .......................................................................................................... 12
3.1.2. On-Board Unit (OBU)...................................................................................... 12
3.1.3. Adjacent System ............................................................................................. 12
3.1.4. Level Crossing ................................................................................................ 12
3.1.5. Point................................................................................................................ 12
3.1.6. Track Vacancy Proving (TVP)......................................................................... 13
3.2. UML Use Case Diagram ..................................................................................... 13 3.3. Archetype for an Operational Scenario Specification .......................................... 13
3.4. UML Sequence Diagram..................................................................................... 14
4. Communication with the Trackside System......................................................... 15
4.1.1. Communication with the Signaller................................................................... 15
4.1.2. Communication with the OBU......................................................................... 15
4.1.3. Communication with Adjacent Systems .......................................................... 17
4.1.4. Communication with Level Crossings ............................................................. 17
4.1.5. Communication with Points............................................................................. 17
4.1.6. Communication with Track Vacancy Proving .................................................. 18
5. Identification of Scenarios ................................................................................... 18
5.1. Structure of the operational Scenarios ................................................................ 18
5.2. List of Operational Scenarios .............................................................................. 19
6. ERTMS/ETCS Modes and Mode Changes ......................................................... 20
6.1. Relationship between Scenarios and Mode Changes......................................... 24
7. Conclusion .......................................................................................................... 26
Approach ERTMS Operational Scenarios v5 30 August 2005 Page 4 of 27
Euro-Interlocking Approach ERTMS Operational Scenarios
Amendment Sheet .......................................................................................................... 27
Approach ERTMS Operational Scenarios v5 30 August 2005 Page 5 of 27
Euro-Interlocking Approach ERTMS Operational Scenarios
Abbreviations
EOA End of Authority
ERTMS European Rail Traffic Management System
ETCS European Train Control System
FS Full Supervision Mode
GSM-R Global System for Mobile Communications - Rail
IS Isolation Mode
MA Movement Authority
NL Non Leading Mode
NP No Power Mode
OBU ETCS On-Board Unit
OS On Sight Mode
PT Post Trip Mode
RBC Radio Block Centre
RV Reversing
SB Stand By Mode
SE STM European Mode
SF System Failure Mode
SH Shunting Mode
SL Sleeping Mode
SN STM National Mode
SR Staff Responsible Mode
TCCS Traffic Control and Command Systems
TR Trip Mode
TSR Temporary Speed Restriction
Approach ERTMS Operational Scenarios v5 30 August 2005 Page 6 of 27
Euro-Interlocking Approach ERTMS Operational Scenarios
TVP Track Vacancy Proving System
UML Unified Modelling Language
UN Unfitted Mode
Approach ERTMS Operational Scenarios v5 30 August 2005 Page 7 of 27
Euro-Interlocking Approach ERTMS Operational Scenarios
References to Cited Text
[1] ERTMS/ETCS Class 1 System Requirements Specification (SRS) 2.2.2
[2] Operational Scenario – ERTMS Level 2 Enquiry Document 1.0 Botniabanan 04.02.2004
Approach ERTMS Operational Scenarios v5 30 August 2005 Page 8 of 27
Euro-Interlocking Approach ERTMS Operational Scenarios
1. Introduction This document describes the approach taken within the Euro-Interlocking ESIS project for the identification, capture and description of ERTMS Operational Scenarios for ERTMS Level 2 Trackside systems. It serves as a guideline document and instruction manual for understanding the formalised approach taken in the project for the description of Operational Scenarios. The definitions, scope of the system and a description of the formalised approach necessary for the development of the operational scenarios are given in this document.
Operational Scenarios shall describe the operational behaviour of a given system in a specific situation. For this, it is crucial that the scope of the given system is clearly defined. The Euro-Interlocking ESIS Operation Scenarios deal with the Trackside ERTMS Level 2 System. At a European level, much work has been done to develop operational rules and regulations for ERTMS Level 2 from a train-borne perspective. What makes the Euro-Interlocking ESIS Operational Scenarios unique is that they have been developed from a purely trackside / rail infrastructure perspective.
Also unique is that the extended definition for ERTMS Trackside used in these Operational Scenarios includes not only the classical Radio Block Centre (RBC) and GSM-R systems, but also the Interlocking and Traffic Control and Command systems (TCCS) needed for full ERTMS Level 2 operations. This extended definition is crucial since implementation of ERTMS Level 2 systems place new functional demands on both Interlocking and TCCS systems.
Another key element in the approach is that the Level 2 Trackside system (RBC, GSM-R, Interlocking and TCCS) is regarded as a black box from the perspective of the Operational Scenarios. This means that the internal structure and the internal functions of the Trackside System are not defined in the Operational Scenarios. Only the communication between the Trackside System and external systems is analysed. The Operational Scenarios then serve as the basis for the development of the RBC, Interlocking and TCCS Functional Requirements for ERTMS Level 2 Trackside, also being developed within the context of the Euro-Interlocking ESIS project. In Euro-Interlocking understanding, the operational Scenarios do not contain signallers or drivers action.
First, a clear definition of the borders and scope of the Trackside System is given. This is also important for the identification of those systems or elements that are outside the Trackside System, and which communicate with the Trackside System. In this guideline, these outlying systems are identified, and the communication between them and the Trackside System is analysed. This communication is then basis for the development of the operational scenarios. The analysis of the communication flow delivers the structure and approach for the identification and capture of the Operational Scenarios.
The crucial question is, which method should be used to describe the Operational Scenarios? It is important to find a formal and yet intuitively understandable method for capturing the scenarios. An established approach for this is the UML (Unified Modelling Language) based Use Case Method. With
Approach ERTMS Operational Scenarios v5 30 August 2005 Page 9 of 27
Euro-Interlocking Approach ERTMS Operational Scenarios
the help of textual Use Case descriptions, UML Use Case Diagrams and UML Sequence Diagrams the operational scenarios are described in a formalised manner.
2. System Boundaries The first step for developing operational scenarios is to get a clear definition of the system, its scope and boundaries. Therefore the system is considered in detail, the actors of the system are identified and the communication flow between the actors and the system is analysed.
2.1. Scope of the System
For the identification of the scope of the system, all systems needed for the operation of ERTMS Level 2 are considered. In Figure 1 a context diagram, containing the most important elements and subsystems for the ERTMS Level 2 Trackside system, are shown. The connecting lines also illustrate important relationships between the elements and subsystems shown. The grey area contains all elements or subsystems that are defined to be part of the ERTMS Trackside system.
Interlocking System
RBCJuridical recorder
Traffic control systemGSM-R
Euro-Balise
ETCS On-Board Unit
Point
Diagnostic System
Maintenance System
TVPLevel crossing
Data preparation system
Signaller
Adjacent Interlocking
Trackside ERTMS Level 2 System
DriverTrain
Maintenance Staff
Figure 1: Scope of the ERTMS Trackside System
For the development of the Euro-Interlocking ESIS Operational Scenarios, the Trackside System is treated as one entity. All elements and subsystems within
Approach ERTMS Operational Scenarios v5 30 August 2005 Page 10 of 27
Euro-Interlocking Approach ERTMS Operational Scenarios
the scope of the Trackside ERTMS System are viewed as one system from a “Black Box” perspective.
Figure 2 shows the Trackside System as a black box for the purpose of Operational Scenario analysis. For the development of the scenarios, the subsystems inside the black box are not analysed. The detail analysis of the subsystems within the ERTMS Trackside system is done within the framework of the development of the ERTMS Trackside Functional Requirement, also being developed within the context of the Euro-Interlocking ESIS project. The Euro-Interlocking ESIS Operational Scenarios are analysed based on messages and information coming into or leaving the system. How the messages are handled inside the system is outside the scope of the Operational Scenarios and is covered by the ESIS ERTMS Level 2 Functional Requirements. For the scenarios, it is the communication flow between the Trackside System and connected systems which is important.
ETCS On-Board Unit
Point TVPLevel crossing
Signaller
Adjacent Interlocking
Trackside ERTMS Level 2 SystemMaintenance
Staff
Figure 2: Trackside System as black box
3. Formalised Method for Operational Scenario Description The key to describe operational scenarios lies in ensuring that they are easy and intuitive to understand, yet formally structured and described.
Most work to date in describing ERTMS operational scenarios has been done using plain text, often in the form of tables. Several European railways have also applied the Use Case method to a limited degree.
Approach ERTMS Operational Scenarios v5 30 August 2005 Page 11 of 27
Euro-Interlocking Approach ERTMS Operational Scenarios
An analysis by the Euro-Interlocking Project Team and formal method advisors to the team concluded that the formal use of the UML Use Case method would be the most appropriate for the description of the Operational Scenarios. This includes the use of Use Case descriptions, Use Case Diagrams and Sequence Diagrams, all part of the UML world standard.
Use Cases describe the behaviour of a system from a users standpoint by describing actions and reactions. They allow the definition of the system’s boundary and the relationships between the system and its environment. A Use Case corresponds to a specific kind of system use, in our case, an operational scenario. It is an indication of a systems functionality, which is triggered in response to the stimulation of an external actor.
Important elements for the use of the Use Case method are firstly, a clear definition of the scope of the given system (above) and secondly, the so-called Actors. Based on the context diagram Figure 1, for Use Cases the external systems are called Actors since they interact with the system, by sending or receiving information.
In Figure 3, the Actors of the system are shown. This diagram is the basis for the Use Case Diagrams, which are used to describe the structure and organisation of the Operational Scenarios. Use Case Diagrams are described in Chapter 3.2
AdjacentSystem
Level CrossingPoint TVP
Signaller
On-Board Unit
MaintenanceStaff
Trackside ERTMS System
Figure 3: Actors of the system
Approach ERTMS Operational Scenarios v5 30 August 2005 Page 12 of 27
Euro-Interlocking Approach ERTMS Operational Scenarios
3.1. Actors
3.1.1. Signaller
The Signaller is the operator or user of the ERTMS Trackside system. He controls and observes the train movements and the status of the trackside elements (points, signals) with the help of the system. By the input he gives to the system the behaviour of the system is steered and controlled. The signaller is able to see the actions performed by the system in their operational context.
The signaller has knowledge about the timetable, which defines the movements of the train. He knows about the relevant operational rules and regulations, for instance the priority rules for different trains. It is his main objective to assure safe and dependable operation conform to the given timetable and he is able to solve conflicts and problems as they arise.
The signaller is generally a human being but can also be supported by automated systems that perform many of the signaller’s tasks automatically.
3.1.2. On-Board Unit (OBU)
The ETCS On-Board Unit is the ERTMS/ETCS on-board equipment and containing the on-board part of the GSM-R radio system. It is one of the main actors for the Trackside System. Between the Trackside System and the On-Board Unit a nearly continuous GSM-R communication session exists. The Trackside Systems influences and controls the train movements through information exchange with the On-Board Unit. Due to the fact that most operational scenarios will treat with influencing the train movement, the On-Board Unit will take part in most of the scenarios.
3.1.3. Adjacent System
An Adjacent System (Adjacent Trackside System) interacts with the Trackside System when the handover of a train is taking place.
3.1.4. Level Crossing
A Level Crossing is the point of contact between the railway traffic and the road traffic.
3.1.5. Point
The Point generally is used to guiding the direction that a train will take. A point must be in the correct position and locked be a route can be set or a Movement Authority can be given. The Trackside System or more specifically, the interlocking system controls the point.
Approach ERTMS Operational Scenarios v5 30 August 2005 Page 13 of 27
Euro-Interlocking Approach ERTMS Operational Scenarios
3.1.6. Track Vacancy Proving (TVP)
The Track Vacancy Proving system detects the location of trains and track sections where no train is present. By its nature, the Track Vacancy Proving system as Actor only gives information to the Trackside System. In the case of axle counters, it can also receive certain information from the Trackside System.
3.2. UML Use Case Diagram
A UML Use Case diagram gives an overview over the scenarios, their structure and the actors involved. Each scenario is described in detail in textual form. For this, an archetype for the Operational Scenarios specification, based on the standard UML Use Case description, is defined. As well, in order to visualise the communication flow between the Trackside System and the Actors, the Operational Scenarios are also described using UML Sequence Diagrams.
In the ESIS ERTMS/ETCS Level 2 work, all Operational Scenarios are summarised in Use Case diagrams.
AdjacentSystem
Level CrossingPoint TVP
Signaller
On-Board Unit
Use Case X
Use Case Y
Use Case Z
«include»
Trackside ERTMS System
Figure 4: Example of a Use Case Diagram
In the Use Case diagram, if an Actor is involved in a use cases he is connected with the use case. Relationships between use cases can exist also exist and is shown in the diagram. One example of a relationship between two use cases is called an “include” relationship. In UML terms, this means that an instance of the source use case also includes the behaviour described by the target use case.
3.3. Archetype for an Operational Scenario Specification
Approach ERTMS Operational Scenarios v5 30 August 2005 Page 14 of 27
Euro-Interlocking Approach ERTMS Operational Scenarios
Based on standardised UML Use Case descriptions, the following archetype for the specification of ERTMS/ETCS Level 2 Operational Scenarios was developed.
Use case Name Name of the use-case Ref
ID Explicit Identifier of the use-case
Context The use-cases’s context
Objective Objective of the use case
Short description Scope of the use-case to be described
Actors Actors, who provide or receive information
Pre conditions Conditions that have to be fulfilled in order to trigger the use-case
Trigger Action or event that starts the use-case
Step Action
1. Short description of all Steps within the use-cases’s scope
Scenario description
2. ...
Step Action
1a1 Description of amendments and alternatives
Amendments / alternatives
1a2 … …
Post conditions The system’s condition or state after processing the use-case
Comments (optional) Annotations, questions, etc.
3.4. UML Sequence Diagram
UML Sequence Diagrams show the communication between objects from a temporal standpoint. A vertical bar represents each object. Time elapses from
Approach ERTMS Operational Scenarios v5 30 August 2005 Page 15 of 27
Euro-Interlocking Approach ERTMS Operational Scenarios
top to bottom. The Sequence Diagram shows only the message chronology. The vertical bars are decorated with rectangular stripes in order to show control flow distribution among the various objects.
4. Communication with the Trackside System Generally, all Actors give input to the Trackside System. The communication flow between the Trackside System and some actors (e.g. the On-Board Unit) is defined in detail in the ERTMS SRS, version 2.2.2, and other documents from railways. On the other hand there is little information available to date concerning the definition of the communication between Actors like the Signaller and the Trackside System.
4.1.1. Communication with the Signaller
The signaller influences the behaviour of the system so that it is able to fulfil his operational targets. As mentioned above, the signaller views the behaviour of the system in an operational context. The input from the signaller always results from the need to execute a certain scenario. These inputs from the signaller lead directly to operational scenarios for the Trackside System.
The signaller can trigger scenarios, for example by sending a request to the Trackside System to generate, to shorten or to release a Movement Authority,. The Signaller can send the request to the system to lock certain route elements, to set up a temporary speed restriction for certain route elements or to revoke an emergency stop message.
4.1.2. Communication with the OBU
The ERTMS/ETCS SRS [1] defines certain messages that can be sent by the On-Board Unit to the RBC. The reception of a message by the RBC demands a reaction of the system. This trigger can be the basis for an operational scenario or at least be part of a scenario. The messages defined by the SRS are the following.
• Validated Train Data (Message 129)
• Request for Shunting (Message 130)
• Movement Authority Request (Message 132)
• Train Position Report (Message 136)
• Session Established (Message 159)
• Request for shorten Movement Authority is granted (Message 137)
• Request to shorten Movement Authority is rejected (Message 138)
• Acknowledgement (Message 146)
Approach ERTMS Operational Scenarios v5 30 August 2005 Page 16 of 27
Euro-Interlocking Approach ERTMS Operational Scenarios
• Acknowledgement of Emergency Stop (Message 147)
• Track Ahead Free Granted (Message 149)
• End of Mission (Message 150)
• Radio in-fill request (Message 153)
• No compatible version (Message 154)
• Initiation of a communication session (Message 155)
• Termination of a communication session (Message 156)
• Start of Mission Position Report (Message 157)
The ERMTS/ETCS SRS although defines messages, which are sent by the RBC to the OBU. This messages will not trigger a operational scenario, but will be part of a scenario.
• SR Authorisation (Message 2)
• Movement Authority (Message 3)
• Recognition of exit from TRIP mode (Message 6)
• Acknowledgement of Train Data (Message 8)
• Request to Shorten MA (Message 9)
• Conditional Emergency Stop (Message 15)
• Unconditional Emergency Stop (Message 16)
• Revocation of Emergency Stop (Message 18)
• General message (Message 24)
• SH Refused (Message 27)
• SH Authorised (Message 28)
• MA with Shifted Location Reference (Message 33)
• Track Ahead Free Request (Message 34)
• In-fill MA (Message 37)
• Train Rejected (Message 40)
• Configuration Determination (Message 32)
Approach ERTMS Operational Scenarios v5 30 August 2005 Page 17 of 27
Euro-Interlocking Approach ERTMS Operational Scenarios
• Initiation of a communication session (Message 38)
• Acknowledgement of termination of a communication session (Message 39)
• Train Accepted (Message 41)
• SoM position report confirmed by RBC (Message 43)
4.1.3. Communication with Adjacent Systems
Generally, there is little communication is necessary to adjacent systems. The only thing that has to be managed between two neighbouring systems is the handover of a train. A system can
• Announce the approach of a train to the adjacent system,
• Accept a train announced by an adjacent system.
4.1.4. Communication with Level Crossings
The level crossing reports its status to the Trackside System. The following information can be send by a Level crossing:
• Level Crossing is open.
• Level Crossing is closed.
• Level Crossing is defective.
The level crossing can also receive commands from the Trackside System, triggered by the Signaller. The following commands can be given:
• Open Level Crossing.
• Close Level Crossing.
4.1.5. Communication with Points
A point can be moved and locked by the Trackside System and reports its status back to the Trackside System. The information that can be send by a point is:
• Point is in right position.
• Point is in left position.
• Point is defective.
Approach ERTMS Operational Scenarios v5 30 August 2005 Page 18 of 27
Euro-Interlocking Approach ERTMS Operational Scenarios
The commands that can be send to the Points by the Trackside System are:
• Move Point in Right Position
• Move Point in Left Position
4.1.6. Communication with Track Vacancy Proving
The Track Vacancy Proving system gives the Trackside System information concerning the occupancy or the vacancy of the a given track section. The information that the Track Vacancy Proving system can send is:
• Track is free.
• Track is occupied.
• Track Vacancy Proving system is defective.
In some cases the Trackside System can send commands to the Track Vacancy Proofing. If the TVP is an Axle Counter there is the command:
• Reset count.
5. Identification of Scenarios In order to organise operational scenarios, a clear structure for the scenarios had to be developed. The structure can aid in finding missed scenarios and to avoid that certain parts of scenarios are repeated. During the identification process of the operational scenarios it was analysed if a given scenario has an impact on the Trackside System. In some cases, different information received by the Trackside System lead to the same scenario. For example, it makes no difference if a point, a TVP system or a level crossing reports a defect, in all cases the Trackside System has to assure that no Movement Authority can be set across the given trackside element.
5.1. Structure of the operational Scenarios
For the scenarios, a clear and simple structure was found derived from the train mission as it is seen from the point of view of the Trackside System. In principle, for the Trackside System a train mission consist out of three steps. The train “appears” in the system, the train moves within the system and the train “disappears” from the system. On a train is within the control of the system, the train can also be built or altered, for example if two trains are joining. This results in the basic structure of the operational scenarios, shown in Figure 5.
Approach ERTMS Operational Scenarios v5 30 August 2005 Page 19 of 27
Euro-Interlocking Approach ERTMS Operational Scenarios
Composition Movement
Deregistration
Registration
Figure 5: Categories for Scenarios
5.2. List of Operational Scenarios
Based on the communication between the Actors and the Trackside System as well as the mode and mode changes possible in ERTMS/ETCS Level 2, operational scenarios were then identified and placed in the given structure as follows:
Registration
• Setup a communication session
• Registration of a train
• Registration of a train with no train data
• Take over a train from ETCS Area
Movement
• Generate MA requested by Signaller
• Generate MA requested by OBU
• Shorten MA
• Override End of Authority
Approach ERTMS Operational Scenarios v5 30 August 2005 Page 20 of 27
Euro-Interlocking Approach ERTMS Operational Scenarios
• Reversing of a train
• Trip of a train
• Conditional Emergency Stop
• Unconditional Emergency Stop
• Revocation of an Emergency Stop
• Setup a Temporary Speed Restriction
• Release a Temporary Speed Restriction
• Block a track section
• Release the blocking of a track section
Composition
• Move train in On Sight mode
• Move train in Staff Responsible mode
• Prepare Shunting (OBU)
• Prepare Shunting (Signaller)
• End shunting mode
• Update train data
Deregistration
• Deregistration of a train
• Hand over a train to a ERTMS Area
6. ERTMS/ETCS Modes and Mode Changes For the On-Board Unit, it is possible to operate in 16 different modes, each defined in the ERTMS/ETCS SRS. Each change between two modes is reported to the RBC. Due to the fact that not every mode change is possible and that there are certain preconditions that have to be fulfilled before the change of mode is possible, the report of a mode change through the On-Board Unit might be identified as part of a certain scenario. Therefore, the analysis of the possible mode changes was an important method used to identify operational scenarios. An overview concerning all possible modes and mode changes (including the preconditions for the changes) defined in the ERTMS/ETCS SRS is given in Figure 6.
Approach ERTMS Operational Scenarios v5 30 August 2005 Page 21 of 27
Euro-Interlocking Approach ERTMS Operational Scenarios
Shunting Full Supervision
Staff Responsible On Sight
Stand By
No Power
Trip
Non Leading Stand By
Reversing
Shunting
Full Supervision
Staff Responsible On Sight
Unfitted
No Power
Post Trip
4
No train data
Train data
31
37
15,40
37
7
Sleeping
5,6
46
14
2,3
19
46
47
29
5,65,61 25 44 34
67,39
62
5,6
5,6,50,51
15,4010
8 15
6021
28,19
28
16,17,18,41,65,66
31
59
49,52,65
16,17,18,41,65,66
18,42,36,54,65
No Power
Isolation
System Failure
29
1
13*
*exept SL, NL, NP
31 8,37 15
Figure 6: Mode Change Overview
List of Preconditions for Mode Change
[1] The driver isolates the ERTMS/ETCS on-board equipment. [2] (a desk is open) [3] (no “go sleeping” input signal is received any more) AND (train is at standstill) [4] The ERTMS/ETCS on-board equipment is powered. [5] (train is at standstill) AND (ERTMS/ETCS level is 0 or 1) AND (driver selects
Shunting mode)
Approach ERTMS Operational Scenarios v5 30 August 2005 Page 22 of 27
Euro-Interlocking Approach ERTMS Operational Scenarios
[6] (train is at standstill) AND (ERTMS/ETCS level is 2 or 3) AND (reception of the information “Shunting granted by RBC”, due to a request from the driver)
[7] (the driver acknowledges the train trip) AND (the train is at standstill) AND (the ERTMS/ETCS level is different from 0, STM)
[8] (Staff Responsible mode is proposed to the driver) AND (driver selects Staff Responsible) {4}
[9] Empty [10] (Train Data is stored on board) AND (MA + SSP +gradient are on-board) AND (no
specific mode is required by a Mode Profile) [11] Empty [12] Empty [13] The ERTMS/ETCS on-board equipment detects a fault that affects safety [14] (The “sleeping” input signal is received) AND (train is at standstill) AND (all desks
connected to the ERTMS/ETCS on-board equipment are closed) [15] (An ackn. request for On Sight is displayed to the driver) AND (the driver
acknowledges) see {1} here under [16] The train/engine overpasses the EOA/LOA of its MA. [17] The on-board reacts according to a linking reaction set to “trip”. [18] (the train/engine receives and uses a “trip” information given by balise) AND (override
is not active) [19] (driver selects “exit Shunting”) AND (train is at standstill). [20] Empty [21] (ERTMS/ETCS level switches to 0) see {2} here under [22] Empty [23] Empty [24] Empty [25] (ERTMS/ETCS level switches to 1,2 or 3) AND (MA+SSP+gradient are on-board)
AND (no specific mode is required by a Mode Profile) [26] Empty [27] Empty [28] (desks are closed) [29] the ERTMS/ETCS on-board equipment is NOT powered [30] Empty [31] (MA+SSP+gradient are on-board) AND (no specific mode is required by a Mode
Profile) [32] Empty [33] Empty [34] (A Mode Profile defining an On Sight area is on-board) AND (The train passes the
beginning of the On Sight area with its front end) AND (The ERTMS/ETCS level switches to 1,2 or 3)
[35] Empty [36] (the identity of the over-passed balise group is not in the list of expected balises
related to SR mode). [37] (driver selects “override”) AND (train speed is under max. speed limit for triggering
the “override” function) see {3} here under [38] Empty [39] (The ERTMS/ETCS level switches to 1,2 or 3) AND (no MA has been received) [40] (A Mode Profile defining an On Sight area is on-board) AND (The train passes the
beginning of the On Sight area with its front end) [41] (T_NVCONTACT is passed) AND (associated reaction is “train trip”) [42] (the distance to run in SR mode is passed) [43] Empty [44] (“override” function is active) AND (ERTMS/ETCS level switches to 1 or 2 or 3) see
{3} here under [45] Empty [46] (Driver selects NON LEADING) AND (train is at standstill)
Approach ERTMS Operational Scenarios v5 30 August 2005 Page 23 of 27
Euro-Interlocking Approach ERTMS Operational Scenarios
[47] (NON LEADING is ended) and (train is standstill) [48] Empty [49] (reception of information “stop if in shunting”) [50] (An ackn. request for Shunting is displayed to the driver) AND (the driver
acknowledges) see {5} here under [51] (A Mode Profile defining the entry of a Shunting area is used on-board) AND (The
train passes this entry with its estimated front end) [52] (the identity of the over-passed balise is not in the list of expected balises related to
SH mode). [53] Empty [54] (reception of information “stop if in Staff Responsible”) [55] (the ERTMS/ETCS level is “STM”) AND (SE mode is required for the STM) [56] (the ERTMS/ETCS level is “STM”) AND (SN mode is required for the STM) [57] (the ERTMS/ETCS level is “STM”) AND (SE mode is required for the STM) AND
(driver has selected Start) [58] (the ERTMS/ETCS level is “STM”) AND (SN mode is required for the STM) AND
(driver has selected Start) [59] (train is at standstill) AND (driver has acknowledged the reversing) see {6} here
under [60] (an acknowledgement request for UN mode is displayed to the driver) AND (the
driver acknowledges) [61] (A Mode Profile defining a Shunting area is on-board) AND (The train passes the
beginning of the Shunting area with its front end) AND (The ERTMS/ETCS level switches to 1,2 or 3)
[62] (the driver acknowledges the train trip) AND (the train is at standstill) AND (the ERTMS/ETCS level is 0)
[63] (the driver acknowledges the train trip) AND (the train is at standstill) AND (the ERTMS/ETCS level is STM) AND (STM is National)
[64] (the driver acknowledges the train trip) AND (the train is at standstill) AND (the ERTMS/ETCS level is STM) AND (STM is European)
[65] (A balise telegram with a non compatible version of the ERTMS/ETCS language is received) AND (ERTMS/ETCS level is 1, 2 or 3)
[66] A balise group contained in the linking information is passed in the unexpected direction
[67] (The ERTMS/ETCS level switches to level 1) AND (a trip order has been received) AND (override is not active)
{1} The request to acknowledge On Sight is displayed to the driver only if certain conditions are fulfilled. These conditions are not specified here. See the “On Sight” procedure” of SRS-§5 (for transitions from FS/SR/UN to OS) and the "Start of mission" procedure (for transition from SB to OS). {2} This transition to the Unfitted mode is also a transition of level.. For further information, See the “Level Transition” procedure” (SRS-§5) for transitions from FS/SR/OS to UN and the “Start Of Mission” procedure” (SRS-§5) for transition from SB to UN. {3} See the “Override” procedure” of SRS-§5. {4} The Staff Responsible mode is proposed to the driver only if certain conditions are fulfilled. These conditions are not specified here. See the “Start Of Mission” procedure and the "Train Trip" procedure of SRS-§5. {5} The request to acknowledge Shunting is displayed to the driver only if certain conditions are fulfilled. These conditions are not specified here. See the “Entry in Shunting” procedure and the
Approach ERTMS Operational Scenarios v5 30 August 2005 Page 24 of 27
Euro-Interlocking Approach ERTMS Operational Scenarios
“Start Of Mission” procedure of SRS-§5. {6} The request to acknowledge Reversing is displayed to the driver when certain conditions are fulfilled. These conditions are not specified here. See the “reversing” procedure of SRS-§5.
6.1. Relationship between Scenarios and Mode Changes
Many Operational Scenarios for the Trackside System are derived from ERTMS/ETCS Level 2 modes and mode changes: The following table gives an overview of the relationship between Operational Scenarios and mode changes.
Mode
Data in out Prec.
Registration
Setup a communication session
Registration of a train x NP SB 4
Registration of a train with no train data
/ SB SH 5.6
Take over a train from ETCS Area x FS FS
Movement
Generate MA requested by OBU x
SB PT
FS OS SR SH
FS OS SR SH FS OS SR SH FS OS SR SH
10, 15, 8 5,6 31 15 8,37 5,6
Generate MA requested by Signaller
x
SB PT
FS OS SR SH
FS OS SR SH FS OS SR SH FS OS SR SH
10, 15, 8 5,6 31 15 8,37 5,6
Approach ERTMS Operational Scenarios v5 30 August 2005 Page 25 of 27
Euro-Interlocking Approach ERTMS Operational Scenarios
Mode
Data in out Prec.
Shorten MA x mode mode
Override End of Authority x mode OS
Reversing of a train x FS OS
RV RV
59
Trip of a train x SH FS SR OS TP
TP TP TP TP PT
49,52,65 16,17,18,41,65,6618,42,36,54,65 16,17,18,41,65,667
Conditional Emergency stop x SH FS SR OS
TP TP TP TP
49,52,65 16,17,18,41,65,6618,42,36,54,65 16,17,18,41,65,66
Unconditional Emergency stop x mode mode
Revocation of an Emergency stop
Setup a Temporary Speed Restriction
x mode mode
Release a Temporary Speed Restriction
x mode mode
Block a track section - - -
Release the blocking of a track section
- - -
Composition
Move train in On Sight mode SB SR FS PT UN
OS OS OS OS OS
15 15,40 15,40 15 34
Move train in Staff Responsible mode
SB FS OS PT UN
SR SR SR SR SR
8 37 15,40 8,37 44
Prepare Shunting (OBU) SB FS SR OS
SH SH SH SH
5,6 5,6,50,51 5,6,50,51 5,6,50,51
Approach ERTMS Operational Scenarios v5 30 August 2005 Page 26 of 27
Euro-Interlocking Approach ERTMS Operational Scenarios
Mode
Data in out Prec.
PT UN
SH SH
5,6 5,61
Prepare Shunting (Signaller) (x) SB FS SR OS PT UN
SH SH SH SH SH SH
5,6 5,6,50,51 5,6,50,51 5,6,50,51 5,6 5,61
End Shunting mode / SH SB 28.19
Update train data mode mode
Deregistration
Deregistration of a train SB SB
NP SB
29
Hand over to a ERTMS Area FS SR OS
FS SR OS
7. Conclusion The use of the Use Case method, part of the UML world standard, has proven valuable to provide a formalised method for the description of ERTMS/ETCS Level 2 Operational Scenarios in the Euro-Interlocking ESIS project. The Use Case method includes using Use Case descriptions (definition of archetype for Operational Scenarios specifications), Use Case Diagrams and Sequence Diagrams.
With the application of this method, it should provide a strong basis for experts at both railways and suppliers to easily understand the Operational Scenarios developed by the Euro-Interlocking Project Team. This in turn should support the process to create scenarios that are complete, consistent and harmonised for all railways and suppliers in Europe.
Approach ERTMS Operational Scenarios v5 30 August 2005 Page 27 of 27
Euro-Interlocking Approach ERTMS Operational Scenarios
Amendment Sheet
No. Version Section Amended By Whom Amendment Date
1 0.1 A. Wulf Creation of the Document
2 0.2 all N. König Input and review to all sections, restructuring
22.07.05
3 0.3 5, 6 A. Wulf Update of scenarios
4 0.5 all A. Wulf Review