EUR INTERLOCKING - UIC · ERTMS European Rail Traffic Management System ... ERTMS/ETCS Class 1 System Requirements Specification (SRS) ... Interlocking System RBC

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



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



Amendment Sheet .......................................................................................................... 27



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



TVP Track Vacancy Proving System

UML Unified Modelling Language

UN Unfitted Mode



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



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



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



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.



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



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.



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



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



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)



• 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)



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



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.



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



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



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)



[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)



[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



“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



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



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.



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

Documents

EUR INTERLOCKING - UIC · ERTMS European Rail Traffic Management System ... ERTMS/ETCS Class 1 System Requirements Specification (SRS) ... Interlocking System RBC