FEASIBILITY STUDY EUROPEAN SIGNALLING INTERFACE STANDARDS (THE ESIS PROJECT)

Transcription

1 FEASIBILITY STUDY EUROPEAN SIGNALLING INTERFACE STANDARDS (THE ESIS PROJECT) EI Version: v2.1 Created: 3 February 05 Saved: :33 Total Number of Pages: 36 Filing Name: \\Euroint3\euroint\Project Management\Project Planning\ESIS UIC\Feasibility study\esis Feasibility v2.1.doc

2 Document Data Sheet Filing name ESIS Feasibility v2.1 Title of Document Document Type Last saved Subject :33 Version: v2.1 Languages Original English Last saved by Lumbard Translations Pages Figures Tables ESIS Author(s) Price Dr. Martin Schroeder (DB) Anne-Sophie Golsong (Euro-Interlocking) Niklaus König (Project Manager Euro-Interlocking) Document Performing Body Sponsoring Body Right of Use Approved by Performing Body Approved by Sponsoring Body Availability of Document Name Name Application Used Template Name Last Printed Date of Publication Microsoft Word August 2005 August 2005 Abstract text entered in "Comments" of the document properties will appear here ESIS Project v March 2005 Page 2 of 36

3 Table of Contents Document Data Sheet... 2 Table of Contents... 3 Acknowledgment... 5 Abbreviations Scope of the Study Premises and Objectives Main Focus Definitions Interface Communication Layer 1-6 (non-functional) Application Layer 7 (FIS - functional) Approach for the ESIS Project High-Level Requirements Operational Scenarios Operational Requirements System Functional Requirements Functional Requirements Architecture Functional Requirements Modules Apportionment of functions to ERTMS sub-systems Derivation of application layers for the interfaces Physical/ Technical Requirements Present ERTMS Signalling System Architecture Categorisation of Interfaces ESIS CATEGORY ESIS CATEGORY ESIS CATEGORY Opportunities and threats for European Interface standardisation The railway s point of view The supplier s point of view ESIS Project v March 2005 Page 3 of 36

4 6. Priorities from Railways Harmonisation of Track Elements Harmonisation of technical requirements of track elements Harmonisation of track element components Standardisation of category 2.2 interfaces Recommendation Evaluation and recommended approach Background Driving factors and facts Driving factors Facts Recommended approach Assumption ERTMS Environment Supplier proposal for the future ERTMS System Architecture Standardised Signalling Interface Communication Layer Strategic consequences of the recommended approach Recommended Deliverables Recommended Process for development of deliverables Priorities of Interface standards and ERTMS Architectures Commitments Organisation Decision committee Organisation Achievement Model Euro-Interlocking European Commission support Time Plan Time Plan Summary of recommendations Document Control Sheet ESIS Project v March 2005 Page 4 of 36

5 Acknowledgment We would like to express a special thank you to all the individuals and organisations who have contributed to this feasibility study. Their perserverance in gathering and supplying valuable information as well as their suggestions, ideas and methodology for this study have shown the strength of the European spirit to work together in achieving common goals and has made work on the development of this business case both interesting and pleasurable. Amongst all who were involved, we would especially like to thank: DB BV ProRail RFF REFER ERTMS Alcatel Bombardier Invensys/ Westinghouse MM. Staneff and Klinge MM. Frej and Nielssen M. van der Werff M. Levi M. Vendas User s group, M. Tamarit M. Michler MM. Otteborn, Johansson and Pettersson MM. Heijnen and Bamforth Members of the Euro-Interlocking Steering Group Members of the Euro-Interlocking Core Team No part of this report may be reproduced, stored in a retreival system, or transmitted in any form or by any means, electronic, mechanical, photocopying or otherwise, without the prior written permission of the UIC / Euro-Interlocking Project Manager. Copyright 2004 UIC / Euro-Interlocking All Rights Reserved ESIS Project v March 2005 Page 5 of 36

6 Abbreviations CCB EC DGTREN EMC ERA ERTMS/ETCS ESIS FIS FRS GENERIS I/L I/L K ISO/OSI IT LED LEU O/C RBC R&D RIS STAR STREP TCCS TSI UIC UML Change Control Board European Commission s Directorate General for Transport and Energy Electromagnetic compatibility European Rail Agency European Rail Traffic Management System/European Train Control System Functional Interface Specification Functional Requirement Specification Generic European Requirements for Interlocking Systems Interlocking System Interlocking Kernel International Organization for Standardization /Open Systems Interconnection Information Technology Light-emitting diode Lineside Electronic Unit Object Controller (by definition, part of the interlocking system) Radio Block Centre Research & Development Radio Interlocking System Standardized Track elements And their Requirements Specific Targeted Research and Innovation Project Traffic Control and Command System Technical Specification for Interoperability International Union of Railways Unified Modeling Language ESIS Project v March 2005 Page 6 of 36

7 1. Scope of the Study 1.1 Premises and Objectives In 2003, it was decided to form a new project under the umbrella of the Euro- Interlocking Consortium for the development of a comprehensive set of signalling interface standards on the basis of work to date and hand in hand with the GENERIS project for functional requirements for interlocking systems. The new project is (ESIS). Within the framework of this ESIS Euro-Interlocking project the current ESIS team has started to work on this feasibility study in February 2004 in accordance with a decision of the project Steering Group in November Members of the ESIS team are Niklaus König (ESIS project manager), Dr. Martin Schroeder (DB AG, leader feasibility study) and Ms. Anne-Sophie Golsong (Euro- Interlocking core team). The team has focussed its study to the fields of signalling systems installed technologies (conventional signalling systems), and also on future signalling systems (ERTMS). The study is based on the ESIS business case delivered to the Steering Group in November Furthermore, a certain number of railways and suppliers were interviewed and three strategic workshops were convened to collect the needs, expectations and priorities. The issue of interfaces in railway signalling systems plays an important role. Railways expect from standardized interfaces more transparency, better interchangeability. For a successful realisation, a win-win strategy and clear commitments with long-term objectives on both sides need to be agreed upon and where railways and suppliers find satisfying economical returns. 1.2 Main Focus The scope of the study is to identify signalling interfaces, to classify them in appropriate categories, to gather priorities from railways and suppliers. As a main result of the study, an approach is proposed to achieve standardised interfaces specifications including the organisational framework. ESIS Project v March 2005 Page 7 of 36

8 2. Definitions 2.1 Interface An interface can be specified according to the ISO/OSI model. To reduce complexity this study only deals with the communication and application layers. Application layer Information / Data Functional Interface Specification, FIS Communication layer Data Protocol Safety Protocol Interface Hardware specification Non-functional interface specification Figure 1 Interface Application Layer (FIS) and Communication layer Communication Layer 1-6 (non-functional) The communication layer describes the mechanism by which data is transported over an interface between sub-systems (TCCS; interlocking system, etc ). The following example illustrates the task of the communication layer: To communicate between themselves, human beings use ears and mouth. Acoustic voice signals are sent out from the mouth and received by the ears. If only the communication layer is defined humans can hear voices but they cannot interpret the content of what has been sent via voices. For their interpretation they need additionally the application layer. Furthermore, the communication layer has to ensure the safety and security of the data transportation. A majority of railways ask for a strict distinction between safety and security layer. The security layer ensures that the data transport is protected against third party attacks. It is only required in open networks. The safety layer ensures, that the data channel itself is not corrupted. ESIS Project v March 2005 Page 8 of 36

9 2.1.2 Application Layer 7 (FIS - functional) The application layer describes the semantics of communication. The application layer is not the application itself! It supports the application software and should be regarded as the interface between application and network. Regarding the example of the communication layer, the application layer ensures, that humans do not only hear voices, but also interpret the content transmitting via voices in words and sentences so that they can understand the meaning of each word. 2.2 Approach for the ESIS Project The following is an overview of the approach for the ESIS Project that is proposed based on input from suppliers and railways in the ESIS technical workshops and meetings. The approach is essentially top-down, the following being the deliverables that are foreseen: High Level Requirements Operational Scenarios Operational Requirements System Functional Requirements Functional requirement Architecture Functional requirement modules Apportionment of functions to ERTMS sub-systems Derivation of application layers The following is a more detailed description of each of these tasks High-Level Requirements The high-level requirements cover the essential requirements for an ERTMS system. The following are some examples of high-level requirements: Headways needed Capacity, e.g. number of trains per hour and direction) Maximum speed Operational Scenarios The operational scenarios describe how a line equipped with ERTMS is to be operated, including at least the following scenarios: ESIS Project v March 2005 Page 9 of 36

10 Scenarios for running a normal train Scenarios for shunting Scenarios for driving into and out of a ERTMS line or zone Scenarios for degraded mode It is foreseen that the operational scenarios are to be described using UML Use Cases Operational Requirements The operational requirements describe what is needed from an ERTMS system from the viewpoint of railway operations. The following are some examples of types of operational requirements: Requirements on ERTMS for shunting manoeuvres Requirements on ERTMS for degraded mode operations 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. Typical functional requirements could include, for example, the following requirements: The ERTMS system shall provide for movement authority for operational train movements. Train movements in the ERTMS system shall be protected by flank protection Functional Requirements Architecture In order to bring structure into the system functional requirements and to modularise the functional requirements, a functional requirements architecture is necessary. The following functional modules are proposed within the functional requirements architecture: Functional Architecture Modules TCCS RBC I/L Track elements X Y ESIS Project v March 2005 Page 10 of 36

11 Figure 2 Functional architecture and its functional modules It is likely that this architecture will further evolve as the project progresses. 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 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 The work in this task involves the capturing, development and harmonisation of the functional requirements for each of these modules. The requirements in these modules are to use the approach and work in the Euro-Interlocking GENERIS project as far as possible Apportionment of functions to ERTMS sub-systems The functional requirements in the modules are then to be apportioned to the ERTMS sub-systems Derivation of application layers for the interfaces Based on the functional requirements apportionment, the application layers of the various interfaces can then be derived. 2.3 Physical/ Technical Requirements Technical requirements focus not on functions but on the physical, electrical, mechanical attributes of the system and its sub-systems. For IT based systems such as interlockings, RBCs and TCCSs, the Euro-Interlocking Qualitative Requirements cover these requirements. ESIS Project v March 2005 Page 11 of 36

12 However, for the track elements (e.g. points, signals, track vacancy proving) physical/technical requirements must be defined. It is proposed that the development and standardisation of these requirements be handled in a separate project (see proposal in section 7). 3. Present ERTMS Signalling System Architecture The goal of this study is to clarify the status of common interests with respect to interface standardisation between different countries. The aims are to set up priorities for specification of a selection of interfaces and later to achieve their standardisation. It is also to find out a way in cooperation with signalling suppliers, how the interface specification can be achieved for different interface categories, and to establish links to related Euro-Interlocking projects. Within this study, existing signalling system architectures (conventional signalling systems) have been taken into account, as well as future signalling system architectures like ETCS Level 3 / Regional ERTMS. Technology trends and existing public standards have also been considered. The present ERTMS signalling system architecture (Option A architecture) and the interfaces (identified and categorised) are shown in the following figure. TCCS RBC Diagnostic System Level crossing Miscellaneous Safety Systems Juridical records Kernel I/L Line block Kernel I/L O/C O/C O/C O/C O/C O/C Interlocking System Interlocking System Category 1 Track Elements Category 2 Category 3 Figure 3 Option A Signalling System Architecture ESIS Project v March 2005 Page 12 of 36

13 4. Categorisation of Interfaces Based on the results of our preparation work we have classified three categories of interfaces. The aim being that for each of the interface, standardisation will be the result for both communication and application layers. 4.1 ESIS CATEGORY 1 Category 1 concerns sub-systems in connection with the other IT-signalling subsystems (RBC, TCCS, Interlocking System) and where functionalities of subsystems are complex. CATEGORY 1.1 CATEGORY 1.2 I/L-I/L I/L-RBC (ETCS Level 2,3,Regional) I/L-TCCS I/L-I/L I/L-LEU (ETCS Level 1) I/L-TCCS I/L Line block RBC-TCCS The interfaces of category 1.1 focus more on the existing conventional signalling system interfaces, although the interface to the LEU is included. The interfaces of category 1.2 focus more on the future of signalling systems, especially the use of ETCS level 2 (or 3 or Regional) in combination with interlocking systems. ESIS CATEGORY 2 Category 2 interfaces concern the interfaces between interlockings, O/C and track elements. CATEGORY 2.1 CATEGORY 2.2 I/L K O/C (signal) O/C point I/L K O/C (point) O/C track vacancy proving system I/L K O/C (track vacancy proving sys) O/C signal I/L K level crossing I/L K Misc. safety system O/C O/C Two basic interfaces exist in this category, one IT based between the interlocking kernel and the object controllers (Category 2.1.). The other, a more hardware based interface between the object controllers and the track elements themselves (Category 2.2). ESIS Project v March 2005 Page 13 of 36

14 4.3 ESIS CATEGORY 3 Category 3 interfaces concern interfaces from kernel to non-safety critical subsystems such as diagnostics and juridical recording units. This feasibility study has elected not to focus upon these sub-systems. I/L Diagnostic Systems I/L Juridical recorder I/L Miscellaneous Systems 5. Opportunities and threats for European Interface standardisation When working towards European interfaces standards (ISO Layers 1 to 7), with the presumption that technical and functional requirements from each sub-system are harmonized, stable and well known; it will result in both opportunities and threats for railways and suppliers. 5.1 The railway s point of view Railways expect from standardised interfaces, that they will be able to renew or replace certain sub-systems independently from the rest of the ERTMS system due to different life times of the sub-systems (e.g. to renew the safety kernel of an interlocking independently from the track elements). To achieve further benefits, like economies of scale effect and competition, also the functional requirements of each sub-system may have to be harmonised. Regarding trackside elements, the harmonisation of technical requirements is a further important task, in order to open markets. This task is addressed in chapter 7. Once requirements are harmonised and interfaces standardised, railways purchasing companionships could emerge for a better procurement. Furthermore a quality improvement would result from a quality competition. On the other hand railways fear the increase of technical responsibility. In a highly modularised system railway s responsibility for system integration becomes an open task, which can be handled by the railways themselves or by a designated system integrator. To enable safe and efficient system integration, more detailed requirements and interface specifications are needed. To adjust functionalities of a sub-system or to adjust a certain interface, a process has to be defined between system integrator, sub-system suppliers and railways. In a phase of migration an increase of cost is expected due to the necessary adaptation of existing interfaces. Furthermore logistic cost for railways could ESIS Project v March 2005 Page 14 of 36

15 increase, due to the deposition of spare parts for each sub-system supplier. With the harmonization of functional requirements, railways may fear a resignation of certain national requirements. Opportunity Lower life-cycle costs for ERTMS systems Lower risks of project delays and overrun of project costs Independency of railways for renewal and replacement of sub-systems More suppliers per railway Consolidated market, scale effects Purchasing railways companionships for better procurement volume/conditions Quality improvement via quality competition Threat System integration as new tasks Technical responsibility More detailed requirements specifications for each sub-system Resignation of a certain number of national requirements Definition of clear adjustment processes between system integrators and sub-system suppliers Risks of higher logistic costs and migration costs. Table 1 Opportunities and threats viewed from Railways 5.2 The supplier s point of view Standardized interfaces and harmonized sub-systems allow existing and new suppliers to address larger market volumes. A European market instead of a certain national market offers lower variances in total order volume. Furthermore the European market will reduce R&D investment risks, since there is a larger market for one developed product. The overall system responsibility of suppliers may decrease, since sub-system suppliers may only be responsible for a certain part of the overall system. There exists the potential of possible internal rationalisation for a future sub-system supplier since system integration won t be for him necessary anymore. On the other hand former system suppliers can offer system integration as a new service to railways. ESIS Project v March 2005 Page 15 of 36

16 The main threat from harmonized requirements and standardized interfaces for the existing suppliers is that former protected markets will break. Especially there is the threat that the protected markets are going to break unequally, so that a certain supplier could loose his home market, but high barriers to other markets would still exist for him. Opportunity Reduction of market barriers Easier entry to new markets Larger market volume addressable => market growth Less variance in total order volume Switch of total system responsibility Lean structure, possible internal rationalisation Less R&D investment risks (larger market potential for one developed product) New service product system integration Threat Losing protecting markets Internal reorganisation Table 2 Opportunities and threats viewed from suppliers ESIS Project v March 2005 Page 16 of 36

17 6. Priorities from Railways In order to determine the railway priorities for interface standardisation, the needs and expectations from each railway were gathered. A questionnaire (in Annex) was sent, to which most of the railways provided valuable answers (not weighted). The summary of this questionnaire is represented graphically in the figures below. Figure 4 Interface Railway Priorities for the communication layer Figure 5 Interface Railway Priorities for the application layer ESIS Project v March 2005 Page 17 of 36

18 7. Harmonisation of Track Elements The harmonisation of track elements has the potential to significantly lower the life-cycle costs of signalling and ERTMS systems. An analysis within the scope of this feasibility study has shown that there are three major areas that the harmonisation of track elements cover: Harmonisation of technical requirements of track elements Harmonisation of track element components Standardisation of category 2.2 interfaces These three areas of standardisation are described in more detail in the following sections. 7.1 Harmonisation of technical requirements of track elements For track elements, the harmonisation of technical requirements of trackside elements plays an important role, since the functional requirements are of lower complexity. Technical requirements focus on such things as: Power supply requirements EMC requirements Mechanical requirements Physical requirements Failure management of track elements (e.g. short circuit detection) 7.2 Harmonisation of track element components A further aspect of the standardisation of track elements is the harmonisation of the components that are used in track elements. This includes such things as: Signal bulbs Point drives LED Signalling matrix Power supply for track elements Given the large variety of these components today, even within a single railway, the harmonisation of these components has the potential to reduce both the investment and maintenance costs of track elements. ESIS Project v March 2005 Page 18 of 36

19 7.3 Standardisation of category 2.2 interfaces The final area of harmonisation is the standardisation of the interfaces from the track elements to their object controllers. This covers the category 2.2 interfaces as defined in this study in section Recommendation In order to harmonise the trackside elements, it is propose that a new project be started to carry out the standardisation in this area. Furthermore, it is proposed that the project runs under the name Standardized Track elements And their Requirements, abbreviated with STAR, under the Euro-Interlocking suite of projects and within the Euro-Interlocking project organisation and structure. The aims of the proposed STAR project are as follows: Lower life-cycle cost for track elements Standardise the technical (non-functional) requirements for track elements and further miscellaneous safety systems Standardise components for track element, for example: - Standardised signal bulb(s) - Standardised point machine (s) - Standardised LED signal panel Standardise the category 2.2 interfaces between the track elements and their object controllers. Recommendation 1 It is proposed that the Euro-Interlocking STAR project be started in 2005 with a feasibility study analyzing the potential and possibilities to harmonise and standardise track elements. This feasibility study could be financed as a work package in Euro-Interlocking Projects 3, 4 and 5. At the ESIS workshop of 6 July 2004 the majority of railways present as well as the attending suppliers, supported the proposal to carry out this feasibility study for the STAR project. ESIS Project v March 2005 Page 19 of 36

20 8. Evaluation and recommended approach 8.1 Background With the introduction of the CENELEC safety standards EN to EN 50129, high demands were placed on railways and suppliers to produce functional requirements for interlocking systems that are described in a formalised way and that can be validated in a one-one basis. An essential complement to functional requirements for signalling systems are corresponding interface standards describing the interaction between the interlocking and other signalling subsystems. Based on the CENELEC phases according the standard EN listed below, the interfaces can be considered to be in phase 5: Phase 1, Concept Phase Phase 2, System definition Phase 3, Risk Analysis Phase 4, System requirements Phase 5, Apportionment of system requirements Phase 6, Design and implementation Phase 7, Manufacture Phase 8, Installation Phase 9, System validation, including safety acceptance and commissioning Phase 10, System acceptance Phase 11, Operation and maintenance As a consequence, the interface specification work is a follow-up of the system requirements specification work (phase 4). For this reason, interface specifications for each interface category and the concerned functional/technical requirements specifications for each sub-system cannot be dissociated. It should be noted however, that documentation required in phases 2 to 4 is generally not of the quality needed for the later phases. It is the aim of the Euro- Interlocking Projects 2, 3, 4 and 5, the ESIS project and the GENERIS project to improve the quality of these documents and to bring about standardisation and harmonisation across Europe as far as possible. ESIS Project v March 2005 Page 20 of 36

21 8.2 Driving factors and facts Driving factors Thanks to the harmonisation at European level of the interfaces between the major signalling sub-systems, the proposed outcome of the ESIS work should produce a more open procurement market. Intensified competition resulting from open interface standards should benefit railways in terms of lower prices and product functionality, focus technology efforts on meeting market demands, and promote innovation and service improvement. The ESIS project concentrates on the driving factors for an interface standardisation with the following objectives: o Lower life-cycle costs for signalling systems o To build a larger market o Promote the cross acceptance of signalling systems and their components throughout Europe o Ease migration or implementation of ERTMS systems and new traffic command and control systems (TCCSs) o To lower railway-specific development costs due to harmonized system requirements Facts Today, the operational rules of railways are not harmonised. However, it is not known today how large the differences in functional requirements between the existing national signalling systems are. As suppliers have stated, the differences in functional requirements among railways is the main cost barrier for expanding into new markets. Currently for signalling systems, it is almost impossible to think about an open European market. The reality is that railways and suppliers develop themselves in protected markets. There are several indications that underline this statement: Bombardier Germany developed a totally new Interlocking to enter the German Market. They only used the safety platform from their generic EBILOK product. The UNISIG position towards ESIS/ GENERIS presented at the steering committee September 2003 Discussion with Invensys, UK and Bombardier, Sweden ESIS Project v March 2005 Page 21 of 36

22 Apart from this, suppliers as well as railways have already started investments into ERTMS/ETCS technology and some pilot projects are under way. The European TSIs (96/48 and 2001/16) have guidelines that eventually may make the implementation of ETCS mandatory. Based on the work within the feasibility study, the ESIS team recommends the following approach for the standardisation of interfaces, in which commitments and strategic consequences are detailed. 8.3 Recommended approach Assumption The ERTMS/ETCS Class 1 specification is shortly to be updated to version 3.0 and it is assumed that this version will be stable over a longer period of time (3 to 4 years) ERTMS Environment ESIS Team is convinced that the best way to result in standardisation of system interfaces is to start to harmonize functions within the ERTMS environment. Our recommendation is driven by a several major factors, summarized hereafter: o A majority of railways questioned are in favour of standardised interfaces within the context of ERTMS o Suppliers are focusing on ERTMS applications o The Europe Community is aiming at making ERTMS mandatory o Railways and suppliers are prioritising resources towards ERTMS migration o Diversity of national operational rules and its negative implications cannot be neglected in the long run o Use of the consolidated ERTMS standard for improvements in such a way that train control and interlocking functions are integrated Interface standardisation should be fully accomplished (application as well as communication layers) to provide realistic interchangeability options. With the arguments given above, it is recommended that Recommendation 2 ESIS project should focus on the harmonisation of deliverables as specified under Recommendation 3 ESIS project encompasses the ERTMS environment. Recommendation 4 It is recommended to consider both ERTMS level 2 and level 3 ESIS Project v March 2005 Page 22 of 36

23 As an optimal result, the functional requirements for main signalling sub-systems will become homogenised in a larger kernel of European functional commonalities. Based on this, the functional interface standardisation can be easily defined. The main focus is on new systems, remaining in the ERTMS environment (and not existing, legacy systems) Supplier proposal for the future ERTMS System Architecture At the ESIS Workshop in October 2004, Unisig and supplier representatives proposed to focus on the following ERTMS system architecture, where the interlocking system and the RBC are fused into one system. The system that then combines the functions of both the interlocking system and the RBC has been coined with the name Radio Interlocking System (RIS). This concept would result in the following simplified system architecture for future ERTMS applications: TCCS R I S Radio Interlocking System O/C O/C Figure 6 Simplified ERTMS architecture Recommendation 5 It is recommended that the ESIS project work on functional requirements for ERTMS also reflect the concept of the Radio Interlocking System (RIS) as defined in this section. Based on this input at the ESIS Workshop in October 2004 from participating suppliers and Unisig representatives, this would result in the following future ERTMS system architecture (Option B architecture): ESIS Project v March 2005 Page 23 of 36

24 TCCS GSM-R Diagnostic System Level crossing Miscellaneous Safety Systems Juridical records n n I/L RBC Radio Interlocking System RIS Line block RIS O/C O/C O/C O/C O/C O/C Category 1 Track Elements Category 2 Category 3 Figure 7 Option B ERTMS Signalling System Architecture Again, the Radio Interlocking System (RIS) is foreseen as a future solution combining the system functions of today s interlocking systems used for ERTMS application and the RBC into one system (RIS). The following are some of the main reasons for proposing Option B architecture for future ERTMS systems: - Experience with ERTMS projects in Europe has shown that, for a number of reasons, when implementing ERTMS Level 2 and 3 on conventional lines, interlockings will need to be replaced. - Lower overall investments since there are fewer systems and interfaces. - Suppliers foresee delivering RIS type solutions in the future. - Easier migration to ERTMS Level 2 and 3 on conventional lines since the new system can be built parallel to the interlocking system in service. - With today s architecture of having the interlocking and RBC as two separate systems, many interlocking functions are duplicated in the RBC. ESIS Project v March 2005 Page 24 of 36

25 - The architecture above is less complex and has a better overall system performance than the present ERTMS architecture. - The EU would like to see a RIS type solution for future ERTMS systems. - There are no systems like the architecture above being implemented today. This makes it easier to harmonise the system functions and to standardise the interfaces shown in Figure 7. The ESIS project deliverables as defined in section are to be based on the ERTMS system architecture as is defined in Figure 7. It will therefore be the role of organisations participating in the ESIS project to define the functional requirements that will be needed in the RIS system. Recommendation 6 It is recommended that suppliers carry out a detailed Opportunities and Threats Analysis with the aim to investigate, propose and agree on the future ERTMS system architecture and the standardisation of interfaces within that architecture. This analysis should also compare the ERTMS architecture shown in Figure 7 to the present ERTMS architecture given in Figure Standardised Signalling Interface Communication Layer The present Unisig work on the standardisation of the interface communication layer is focused on the RBC-RBC interface. If the UNISIG Communication Layer specification cannot be used for other signalling system interfaces, railways may have to create their own specification. In projects like the SBB AlpTransit Gotthard project, railways are forced to procure ETCS Level 2 equipment without proper interface specifications or standards, which creates major problems and risks in high-profile projects such as these. If the Unisig communication layer RBC-RBC cannot be used for further signalling interfaces, it will be necessary for the ESIS project that a standardised signalling interface communication layer be defined. The financing of this work is not included in the present ESIS budget. If a standardised signalling communication were to be defined, it should be based on communication layer standards and specifications used by other industries such as telecommunication, avionics and aerospace. Recommendation 7 It is recommended that a new work package be started in the ESIS project with the aim to develop 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 (e.g. IL-TCCS, IL-IL) Recommendation 8 it is recommended that a proposal be prepared to secure financing for the definition of the standardised signalling communication layer ESIS Project v March 2005 Page 25 of 36

26 The following are some possibilities where financing for the standardised communication layer could come from: Increase in the UIC ESIS project budget Financing by the EC DGTREN Financing within the context of the EU 6 th Framework Programme 8.4 Strategic consequences of the recommended approach The following are the key strategic consequences of the recommended approach: o Use of the ERTMS environment as a base to achieve harmonisation system functionalities. o Harmonization is likely only possible if railways do not implement national trackside fault-back modes in ETCS. The ESIS team believes that such direction will enable success in harmonising functional requirements and thus standardising interfaces. Based on the approach recommended, this will result the FFFIS for the given interfaces as an outcome from the ESIS project. In the following sections, the recommended deliverables and process are given that would lead to the definition of sub-system functional requirements and standardised interfaces within the ERTMS environment Recommended Deliverables Based on the approach for the ESIS project in section 2 of this study, the following deliverables are proposed for the project: 1. High-level Requirements 2. Operational Scenarios 3. Operational Requirements 4. System Functional Requirements 5. Functional Requirements Architecture 6. Functional Requirements Modules 7. Apportion Functions to sub-systems based on the appropriate ERTMS system architecture 8. Derive application layer of interfaces Recommendation 9 It is recommended that the above deliverables be used as a basis for the ESIS project. ESIS Project v March 2005 Page 26 of 36

27 8.4.2 Recommended Process for development of deliverables Recommendation 10 It is recommended that the following process be used as a basis for the ESIS project. 1. Capture and assess the present requirements, using the ERTMS/ETCS Class 1 specification, the ERTMS/ETCS FRS, as well as railway and supplier documents as sources. 2. Determine the structure of the requirements and distil the requirements into the given structure. 3. Working together with the railways, suppliers and third partly organisation (e.g. ERA), seek for the harmonisation of the requirements Priorities of Interface standards and ERTMS Architectures Based on the survey done among participating railways and summarised in Figure 5 in Section 6, the following interfaces are to be given first priority for standardisation: Interlocking to TCCS systems Interlocking to interlocking system Interlocking to RBC system Interlocking to LEU (ETCS Level 1) Interlocking Kernel to Point Object Controller Interlocking Kernel to Track Vacancy Proving (TVP) System Object Controller Interlocking Kernel to Level Crossing Object Controller Recommendation 11 It is recommended that the above interfaces be given first priority for development in the ESIS project. ESIS Project v March 2005 Page 27 of 36

28 Since the sub-system functionalities of the ERTMS architecture in Figure 3 are closely related to those in the architecture shown in Figure 7, it is assumed that the following interface standards can also be reused for the interfaces shown in Figure 7. As well, it is assumed that the following interface standards developed within the context of the Category 1.2 interfaces can also be reused for Category 1.1 systems. Present ERTMS Architecture Category 1.2 (Figure 3) Interlocking to TCCS System Interlocking to Interlocking System Future ERTMS Architecture (Figure 7) Radio Interlocking System (RIS) to TCCS RIS to RIS System Present ERTMS Architecture Category 1.1 Interlocking to TCCS System Interlocking to Interlocking System 9. Commitments Table 3 Reuse of Interface Standards for future ERTMS Architecture The ESIS project has already registered substantial commitment (voting for the project with financial commitment, support of project objectives and direction as well as making railways experts available to the project at their own costs) to the UIC ESIS project by the following railways: BLS BV SBB / CFF DB AG JVB MAV ÖBB PKP/PLP ProRail REFER RHK SNCB BLS Lötschbergbahn AG CH Banverket S Schweizerische Bundesbahnen CH Deutsche Bahnen D Jernbaneverket N MÁV Rt. Budapesti HU Österreichisches Bundesbahnen AT Polskie Koleje Państwowe P Prorail NL Rede Ferroviária Nacional PT Banförvaltningscentralen FI Chemins de Fer belges B Table 4 Railway participants in the ESIS project ESIS Project v March 2005 Page 28 of 36

29 Although the above-mentioned participants are crucial to the success of the project, some additional involvement will be needed from the suppliers and railways. We have listed below the expected additional commitments. o Railways commit to harmonise their functional requirements in the ERTMS environment and to achieve at least a large kernel of commonalties. o Suppliers actively promote the harmonisation process and commit to further development in that direction. o Railways commit to provide skilled resources o Suppliers commit to use the UNISIG proposal for the communication layer. If this is not the case, the basis for communication layer will need to be re-studied. Recommendation 12 The additional commitments listed above are expected of the suppliers and railways. Recommendation 13 The aim is to have industries actively involved in the project 10. Organisation 10.1 Decision committee With reference to railway and industry feedback, it is of high importance to consider that a decisive body takes the responsibility for ensuring that the interface standards are also implemented. For this reason, it is necessary that a decision committee exist in order to approve the interface standards and ensure their implementation. Recommendation 14 This decision committee is the existing Steering Group of the Euro-Interlocking ESIS project Organisation The ideal solution would be to have railways and suppliers jointly furnishing effort and commitment. The railways will agree upon recommendations from this study at the Steering Group meeting in September For the recommended approach, the ESIS team suggests to deepen the work and resource plan and commitment of the project partners. The results will then be submitted to railways and suppliers for approval at the Steering Group meeting in November ESIS Project v March 2005 Page 29 of 36

30 The decision process is shown in Figure 8 below. Report Feasibility study Including possible best ways Solution 1 Solution 2 Etc. CCB Document approved Document not approved Steering Group approval including conditions of approval Steering Group Comittee S ept. 04 Iterative changes S pecific proposals from S uppliers CCB Steering Group Comittee Nov. 04 S tart of technical phase of E S IS project Final approval Figure 8 Process of decisions for the ESIS feasibility study 10.3 Achievement Once there is approval from both railways and suppliers for the recommendations of this study, the work of capturing the functional requirements of the main subsystems will start. Capturing requirements and scenarios as defined under Team with representatives from each country via Pilot project Participation of suppliers voluntary Agree on functional requirements architecture Harmonisation of requirements and scenarios as defined under Interfaces standardisation Implementation Each country at least one project. Railways as implementation support for suppliers Models Euro Interlocking Models Euro Interlocking Figure 9 Phases for a project development Once a level of harmonisation is obtained and accepted by all the involved railways (by the decision committee) the phase of interfaces standardisation and ESIS Project v March 2005 Page 30 of 36

31 then the implementation in projects can start. For this to happen, a certain number of teams (railways and suppliers) with clear responsibilities will be initiated. The working process should follow the defined Euro-Interlocking model. Recommendation 15. Each participating railway initiates a project to implement the system according to the specifications. The Euro-Interlocking project makes an effort to ensure that each participating railway initiates a project to implement the system according to the specifications. For the implementation phase, the suppliers remain at the front with the support from the railways. The financial solutions should be discussed and solved along the evolution of the ESIS project Model Euro-Interlocking Recommendation 16 The best process for running the ESIS project is the Euro-Interlocking Model process. This model is the Euro-Interlocking project working model and processes that have been used in the project in the last years. The project processes are defined in the Euro-Interlocking Project Handbook, available from the project office in Zurich. Euro-Interlocking set up a team which will have the responsibility to capture the full range of requirements for signalling systems across Europe. In addition along the process, harmonisation-working teams will be created, to work on specific group of sub-systems and interfaces. The team collects the needed information and requirements from the supporting organisations. The Core Team will analyse the information obtained to produce clear and consistent documents. The draft requirements will then be validated by the supporting organisations and the decision committee, prior to their approval. ESIS Project v March 2005 Page 31 of 36

32 11. European Commission support Within the context of the ESIS project, it is foreseen to gain the support of the European Commission. In order to improve the acceptance and impact of the new interface standards, it is seen as a distinct advance if the European Commission supports the standardisation work. This also applies to the new European Railway Agency (ERA). If the European Commission or the ERA were to be actively engaged, the suppliers, as well as railways may have a chance receive European funding for the implementation of the standards and the results of standardisation work may take on a more authoritative character. The Core Team together with railways and suppliers in the project are to make a concentrated and co-ordinated effort to gain this support. Another possibility for financial support of the project work is to apply for STREP financing within the context of the EU 6 th Framework Programme. Recommendation 17 The ESIS working team suggests submitting a proposal for a Strategic Targets and Research Project (STREP) under the 6 th framework programme. It is important to note that the completion of the ESIS project, however, will not depend on a European Commission decision. ESIS Project v March 2005 Page 32 of 36

33 12. Time Plan Recommendation 18 The railways agree to the following proposed detailed time plan for the ESIS project: 13. Summary of recommendations The ESIS team will ask the Euro-Interlocking Steering Group to agree upon the recommendations in this study in order that the corresponding tasks in the ESIS project may be pursued. The following is a summary of the recommendations in ESIS Project v March 2005 Page 33 of 36

34 this study. It is proposed that they receive final approval from the Steering Group in Berlin in November Recommendation 1 Recommendation 2 Recommendation 3 Standardised Track elements and their Requirements. Start Feasibility study in 2005 Harmonisation of sub-systems functional requirements according approach described under Use the ERTMS environment Recommendation 4 Consider both ERTMS levels 2 and 3 Recommendation 5 Recommendation 6 Recommendation 7 Recommendation 8 Recommendation 9 Recommendation 10 ESIS project work on functional requirements for ERTMS also reflect the concept of the Radio Interlocking System (RIS). Suppliers carry out a detailed Opportunities and Threats Analysis with the aim to investigate, propose and agree on the future ERTMS system architecture and the standardisation of interfaces within that architecture Definition of a standardised communication layer that can be used for the IT interfaces as a new work package Prepare proposal to secure financing for the definition of the standardised signalling communication layer Agree on the deliverables as described in section Agree on the process as described in section ESIS Project v March 2005 Page 34 of 36

35 Recommendation 11 Recommendation 12 Recommendation 13 Recommendation 14 Recommendation 15 Recommendation 16 Recommendation 17 Recommendation 18 The interfaces in section be given first priority for development in the ESIS project Railways agree with the commitments listed in section 9 Aim to have suppliers actively participating in the ESIS project The decision committee is the Euro- Interlocking Steering Group. Each participating railway makes its best efforts to initiate a project by December 2005, implementing the system according to the resulting specifications Use the Model Euro-Interlocking to achieve goals. The ESIS working team suggests submitting a proposal for a Strategic Targets and Research Project (STREP) within the 6 th framework programme. Railways agree to support the time plan (high level overview) presented under paragraph 12. Table 5 Summary of recommendations from the ESIS ESIS Project v March 2005 Page 35 of 36