eur interlocking - uic · r510 esis technical strategy 15 march 2005 page 2 of 21 euro-interlocking...

ESIS TECHNICAL STRATEGY DOCUMENT

2005 / 2006

EI

Version: vo.1 Draft

Created: 15 March 05

Saved: 15.03.05 12:15

Total Number of Pages: 21

Filing Name:

\\Euroint3\euroint\Project Management\Project Planning\ESIS UIC\Reports\R510 Technical Strategy.doc

EUR INTERLOCKING

R510 ESIS Technical Strategy 15 March 2005 of 21

EURO-INTERLOCKING ESIS technical Strategy Document

Document Data Sheet

Filing name

R510 Technical Strategy

Document Type Last saved

15.03.05 12:15 Version: vo.1

Draft Last saved by

Lumbard

Languages Title of Document

ESIS technical Strategy Document Original

English Translations

Pages Figures Tables Subject

2005 / 2006 21

Price Author(s)

Lumbard 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

22 August 2005 Date of Publication

August 2005 Abstract

The strategy document has been written as an aid to understanding how the main deliverables, the ERTMS functional requirements and the standards for the Interfaces will be produced.



Table of Contents

Document Data Sheet...................................................................................................... 2

Table of Contents............................................................................................................. 3

Table of Figures ............................................................................................................... 4

Abbreviations ................................................................................................................... 5

1. Introduction .......................................................................................................... 7

2. Objectives Of ESIS Project .................................................................................. 7

3. Aims Of Strategy Document................................................................................. 8

4. Approach.............................................................................................................. 9

4.1 Deliverables 2005/ 2006 .................................................................................... 12

4.1.1 High-Level Requirements .................................................................................. 12

4.1.2 Operational Scenarios ....................................................................................... 12

4.1.3 Operational Requirements................................................................................. 12

4.1.4 System Functional Requirements...................................................................... 12

4.1.5 Functional Requirement Architecture................................................................. 13

4.1.6 Functional Requirements Modules .................................................................... 13

4.2 Strategy.............................................................................................................. 13 4.2.1 High-level requirements and Operational Scenarios.......................................... 13

4.2.2 Use of input documents ..................................................................................... 14

4.3 Role of Railways ................................................................................................ 14

4.4 Role of Suppliers/Unisig..................................................................................... 14

4.5 Co-ordination with EC and ERA......................................................................... 15

4.6 Co-ordination with ERTMS corridors.................................................................. 15

5. Time Plan........................................................................................................... 16

6. Conclusion ......................................................................................................... 17

References to Cited Texts.............................................................................................. 18

Document Control Sheet................................................................................................ 19

Appendices .................................................................................................................... 20

Amendment Sheet ......................................................................................................... 21



Table of Figures

Figure 1 Functional Modules Development Process ...................................................... 9

Figure 2 Review Process ............................................................................................. 10

Figure 3 Functional Modules Requirement Development Process............................... 11

Figure 4 High-speed rail corridors ................................................................................ 15

Figure 5 Overview of Time Plan ................................................................................... 16



Abbreviations

CCB Change Control Board CoCoSig Control-Command and Signalling

CSM Common Safety Methods CST Common Safety Targets DOORS Dynamic Object Oriented Requirements System EC European Commission EC DGTREN European Commission’s Directorate General for Transport

and Energy EEIG European Economic Interest Group EMC Electromagnetic compatibility ERA European Rail Agency ERTMS European Rail Traffic Management System ESIS European Signalling Interface Standard ETCS European Train Control FIS Functional Interface Specification FRS Functional Requirement Specification FS Feasibility Study GENERIS Generic European Requirements for Interlocking Systems I/L Interlocking System I/L K Interlocking Kernel ISO/OSI International Organization for Standardization /Open

Systems Interconnection IT Information Technology LED Light-emitting diode LEU Lineside Electronic Unit O/C Object Controller (by definition, part of the interlocking

system) R&D Research & Development RBC Radio Block Centre RIS Radio Interlocking System SELRED Structured English Language for Requirements

Development SWOT Strength, Weakness, Opportunities and Threats TCCS Traffic Control and Command System

http://www.atis.org/tg2k/_international_organization_for_standardization.html

http://www.atis.org/tg2k/_light-emitting_diode.html



TSI Technical Specification for Interoperability UIC International Union of Railways UML Unified Modelling Language WBS Work Breakdown Structure



1. Introduction The ESIS project has the task of producing trackside interfaces specifications standards for European signalling systems which encompasses ERTMS with conventional signalling systems though the main focus is on new systems, remaining in the ERTMS environment and not existing, legacy systems. The functional requirements for the main signalling sub-systems will be harmonised into a kernel of European functional commonalities for ERTMS so that the interface standards can be specified. To achieve this aim the strategy document has been written as an aid to understanding how the main deliverables, the ERTMS functional requirements and the standards for the Interfaces will be produced using the methodologies and guidelines introduced by this document.

2. Objectives Of ESIS Project The Objectives of the ESIS project are:

Produce a large kernel of commonalities in ERTMS Functional Requirements of European Railways by a harmonisation process.

With respect to the Harmonised ERTMS Functional Requirements Specifying the standards for the interfaces between the Trackside Sub-systems of ERTMS Level 2 and Level 3 with specific focus on the following interfaces:

Interlocking to TCCS

Interlocking to Interlocking

Interlocking to RBC

RBC to RBC

RBC to TCCS

Developing a detailed task description for the definition of a standardised communication layer that can generically be used for the interfaces between all IT based signalling sub-systems.

To get the Railways and Rail Industry/Suppliers actively involved in the development and use of the work achieved by the project.

Encourage the Rail Industry/Suppliers to produce a SWOT analysis of future ERTMS architectures and harmonise their results so that agreed architecture and interfaces can be achieved.

Consider interface standards required for future ERTMS architecture where Interlocking and RBC could become fully integrated to produce a Radio Interlocking System.



3. Aims Of Strategy Document The aims of this document are to show how the Euro-Interlocking Core team will meet the objectives of the ESIS project within 2005/2006.

This will be done by:

Define the work to be achieved as laid out by the Feasibility Study.

Defining the source documents to be used by the team.

State the processes to be followed by the team.

Define the relationship with/interfaces to the European Railways.

Define the relationship with/interfaces to the European Rail Industry/Suppliers.

Define the relationship with/interfaces to the European Commission Working Groups.

State a time plan for deliverables.



4. Approach The following figure depicts the approach to be made in meeting the application layer aspect of the ESIS project which is the generation of a set of Harmonised Functional Requirements for ERTMS Level 2 and Level 3. These Harmonised Requirements can then be used as a basis for producing the Interface Standards.

Functional Architecture

Functional Modules

ERTMS FRS’sUNISIG Class 1

ERTMS Corridor Project Information

National ERTMS Projects

Systems Boundary Analysis

Operational Scenarios

TSI’s

Operational Requirements

System Functional Requirements

High Level Requirements

ERTMS USER Group/UNISIG

Documents

NationalRule Books

and Standards

ERTMS Boundary Analysis

Harmonisation Workshops



Functional Modules

Apportionment

Key

Primary Source Documents

Documents as basis for Review

Internal AnalysisExternal Source

Documents

Deliverable

Figure 1 Functional Modules Development Process

As can be seen in figure 1 a group of External Source Documents have been recognised and their relation to the project Deliverable have been made. The figure also shows the Deliverables that require harmonisation workshops and



analysis work to be done by the Core Team. The Deliverable’s which require harmonisation will go through a review procedure as described by figure 2.


Rail Industry/ Railways

Euro Interlocking Core Team

Review Issues

External Review

Internal Review

Common Agreement

CCB Review

EI Change Control Board

EI Steering Group

SG Review

ERTMS User Group/ UNISIG/ ERA

EC Review

Technical Specification for Interoperability

EC Review

Tim

e Li

ne

Time Line

Figure 2 Review Process



Figure 2 shows the review hierarchy which will be implemented by the project where all review issues will be but to the Harmonisation Workshops and where major review comments at any stage within the process will take the relevant document back to the stage of the internal review.

The project core team works within a CENELEC concepts and processes verification environment and will use the tools and methods shown in Figure 3 which shows all the activities required to develop the Functional Requirement Modules.

CENELEC Concepts and Processes Verification Area

Functional Requirements

Requirements Simulation

Cassandra

Tools:

Requirements Capture

SELRED formatEIFFRA Process

Tools:

Functional Requirements Functional Model

Simulation Results

UML Artisan RtS

Requirements Modelling

Tools:

Requirements Management

DOORS

Tools:

Figure 3 Functional Modules Requirement Development Process

The activities of the ESIS project 2005/ 2006 are:

Collect reference material from Railway and Industry.



Set up ESIS DOORS environment and capture all requirement information to DOORS.

Generate Systems Boundary Analysis to aid capture of High Level Requirements.

Generate High level Requirements.

Generate Operational Scenarios.

Generate Operational Requirements.

Harmonise High Level Requirements, Operational Scenarios and Operational Requirements through the review process.

Capture Functional Requirements from the Regional ERTMS FRS and UNISIG Class 1 Documentation.

Harmonise Functional Requirements through the review process.

Analyse the Functional Requirements to produce an architecture based on grouping similar functionality.

Apportion Functional Requirements into architecture modules.

Produce a fact finding report on the development of the definition of a standardised communication layer.

4.1 Deliverables 2005/ 2006

4.1.1 High-Level Requirements

The high level requirements cover the essential requirements for a railway which deal with concepts of Headway, Capacity and Safety.

4.1.2 Operational Scenarios

The operational scenarios describes how a line equipped with ERTMS is to be operated.

4.1.3 Operational Requirements

The operational requirements describe what is needed from an ERTMS system from the viewpoint of railway operations.

4.1.4 System Functional Requirements

Based on the high-level requirements, the operational scenarios and operational requirements, the overall system functional requirements for ERTMS systems can be defined.



4.1.5 Functional Requirement Architecture

In order to bring structure into the system functional requirements and to modularise the functional requirements, a functional requirements architecture is necessary.

It is important to note that the functional requirements architecture is not the physical system architecture and also does not place constraints on the physical architecture of present or future ERTMS systems.

4.1.6 Functional Requirements Modules

Based on the functional requirements architecture, the following functional requirements modules are example of what could be defined:

TCCS The traffic control and command system refers to the process by which the movement of a train is influenced without any action by the driver. For the purposes of this specification, reference to the train control system also encompasses automatic train protection, automatic train operation and in-cab signalling.

RBC (Radio Block Centre). An ERTMS/ETCS term referring to a centralised safety unit to establish and control train separation using radio as the infrastructure to train communication medium.

Interlocking System

Track elements

4.2 Strategy

As can be seen in figure 1 the strategy is to work from primary source documents which can be analysed to understand the boundary of the system being dealt with and to capture from them relevant Operational Scenarios, High level, Operational and Functional Requirements. These deliverables will be reviewed against a information derived from European Railways with national ERTMS Projects.

4.2.1 High-level requirements and Operational Scenarios

The High-Level requirements will be sourced from the Technical Specifications for Interoperability (TSIs). In particularly the Control-Command and Signalling (CoCoSig) TSI because of it being the one directly related to the development and implementation of ERTMS/ETCS.

Operational Scenarios will be captured from the ERTMS user groups series of documents on Functional Analysis of Trans-European Rail Operation and the UNISIG documents.



To review the High-Level requirements and Operational Scenarios the rule books and national standards from the participating European railway will be used as background information.

4.2.2 Use of input documents

The input documents to the Functional Requirements will be the:

Regional ERTMS Functional Requirement Specification

ERTMS/ETCS Functional Requirement Specification

ERTMS/ETCS Functional Requirement Specification (Swedish)

ERTMS/ETCS Operational Scenarios (Swedish)

ERTMS/ETCS Class 1 Specifications

ERTMS/ETCS Functional Statements

These documents will be analysed and relevant Functional Requirements will be captured.

To review the Functional Requirements, the ERTMS corridor projects and national ERTMS projects information will be used as a basis of the review.

4.3 Role of Railways

The railways should commit to the harmonisation process and provide skilled resources to review all the deliverables. They should attend the Harmonisation Workshops to discuss harmonisation review issues and come to a common agreement on them.

The railway should provide information on ERTMS corridor projects and national ERTMS projects and other relevant documentation they feel could aid the review process.

4.4 Role of Suppliers/Unisig

The Suppliers should commit to the harmonisation process and provide skilled resources to review all the deliverables. They should attend the Harmonisation Workshops to discuss harmonisation review issues and come to a common agreement on them.

Rail Industry/Suppliers should produce a SWOT analysis of future ERTMS architectures and harmonise their results so that agreed architecture and interfaces can be achieved.

Rail Industry/Suppliers should give aid in the production of the Communication Layer fact finding report.



UNISIG should commit to reviewing and commenting on the project deliverables and take them into account in their further development work.

4.5 Co-ordination with EC and ERA

The European Commission through EEIG ERTMS Users Group and the ERA should commit to reviewing and commenting on the project deliverables. The project work should then be considered when updates to the TSIs and operational analysis are made.

4.6 Co-ordination with ERTMS corridors

A detailed report entitled ‘Implementing the European Train Control System’, written by Dr. Peter Winter on behalf of the UIC, contains an analysis of implementing ERTMS on cross-border European corridors. This report makes proposals to remove the risk of a patchwork of ERTMS implementations across the network. Ten corridors have been analysed, four high speed and six conventional. In each case a migration strategy is proposed, which involves the removal of heritage control systems with low mileages of implementation and concentrates on a few widespread systems. For example, on the Madrid to Paris/Zurich/Milan corridor the existing systems (ASFA, Crocodile, KVB, TVM, Signum, ZUB 121, BACC and SCMT), would be replaced with ETCS and TVM. This would dramatically reduce the number of onboard systems that a train on this route would have to carry.

Figure 4 High-speed rail corridors

High-speed rail corridors concerned by ETCS - Madrid to Paris/ Zurich/ Milan - Paris to Luxembourg/ Mannheim/ Zurich - Paris to London/ Brussels to Amsterdam/ Cologne - Zurich/ Geneva/ Munich to Naples

Information from these high-speed rail corridors will be used to review the project deliverables so feeding valuable implementation experience into the development of the deliverables.



5. Time Plan A detailed time plan has been produced for the project as described by this document. The time plan is presented as an overview below.

Figure 5 Overview of Time Plan



6. Conclusion The ESIS project has now a firm strategy statement laid down in this document which gives a clear guide to how the project work will be produced and has clearly stated the important issues that have been derived from the feasibility study.

These being:

What the objectives of the ESIS Project are

The processes to be followed by the core team.

The source documents to be used by the team.

The relationship with the European Railways.

The relationship with the European Rail Industry/Suppliers.

The relationship with the European Commission Working Groups.

A time plan for deliverables.

References to Cited Texts

Ref. Version Title Origins Type Status

1 2.1 Feasibility Study (The ESIS Project) Euro-Interlocking

Study

2 2.0 ERTMS/ETCS Functional Statements UIC FS

3 4.29 ERTMS/ETCS Functional Requirement Specification UIC FRS

4 3.00 REGIONAL ERTMS Functional Requirement Specification UIC FRS

5 2.2.2 ERTMS/ETCS Class1 Specifications UNISIG SRS

6 Directive 2001/16 Technical Specification for Interoperability "Control-Command and Signalling" Sub-System

AEIF TSI

7 2 Functional Analysis of Trans-European Rail Operation

EEIG 01E129

ERTMS Users Group

OS

8 Functional Requirement Specification (Swedish) FRS

9 Operational Scenarios (Swedish) OS

Document Control Sheet

Name Institution Level Task Date



Appendices

The European Commission

The EC High Speed Interoperability Directives 96/48/EC and 2001/16/EC aim to ensure that trains can run freely across the European network, and that railway equipment can be traded without restrictions. They define a number of ‘Essential Requirements’ to be met for interoperability, including safety requirements for products and subsystems (trains, signalling, infrastructure and maintenance), and set out a process for the production of detailed technical standards, namely Technical Specifications for Interoperability (TSIs). The Control-Command and Signalling (CoCoSig) TSI being the one directly related to the development and implementation of ERTMS/ETCS.

The TSI’s and UNISIG

The majority of the technical specifications are provided by the ETCS Class 1 specifications, which are referenced in Annex A of the CoCoSig TSI. These specifications describe the key interfaces and functionality of the CoCoSig sub-system. They include a Functional Requirements Specification (FRS) drafted by the main European rail organisations, and a System Requirements Specification (SRS) with supporting specifications produced by UNISIG.

The EEIG ERTMS User Group

The EEIG ERTMS Users Group is developing the detailed specifications, test procedures and operational rules necessary for the successful implementation of ERTMS in commercial operation.

The ERA

The European Railway Agency (ERA) came from the EC Safety Directive requiring a European technical agency to co-ordinate work on CSTs and CSMs, create a network of national authorities, and report on performance. Also the Interoperability Directives set the need for a European technical agency to give advice on implementation, lead the development, update standards, and support the EC in proposed new or updated national standards. Hence ERA activity 16 ‘Change Control Management of The ERTMS Specifications’

The ERA shall ensure the Change Control Management (CCM) of the ERTMS specifications both for command/control and signalling (ERTMS/ETCS) and GSM-R. This includes the management of the due process for the handling, assessment and eventual incorporation in the reference set of ERTMS specifications of those changes that might be required by technical, operational or safety reasons.

This involves the transition from the current tiered CCM structure based on the AEIF, UNISIG, ERTMS Users Group, EIRENE project and GSM-R Industry Group towards a more centralised framework to be placed under the aegis of the Agency.



Amendment Sheet

No. Version Section Amended By Whom Amendment Date