Electronic File Location. CCMS ref: Version History

Transcription

1

2 Electronic File Location CCMS ref: Version History Issue Date Comments /06/13 Initial draft for internal review and comment /09/13 Updated for further internal review /11/13 Updated by Harv Bhatia & Arvind Bali /06/14 Updated from Reference Design for internal review /06/15 Updated by Arvind Bali from Consolidation Workshop and Reference Design /08/15 Extract from DOORS database for Technical Author review /08/15 Updated by Arvind Bali after Technical Author review /01/16 Updated after ORRG, SRSG, NRT and internal review /03/16 Updated post Requirements Consolidation Workshop for telecoms. For Technical Author review /03/16 First Issue /04/16 Update following Reference Design requirement harmonisation /08/16 Update for SRSG /08/16 Update from SRSG /09/16 Update for SRSG /09/16 Release for ESB / OSG review /01/17 Update from Industry review /03/17 Formal issue Disclaimer Network Rail has used its best endeavours to ensure that the content, layout and text of this document are accurate, complete and suitable for its stated purpose. It makes no warranties, expressed or implied, that compliance with the contents of this document shall be sufficient to ensure safe systems of work or operation. Network Rail will not be liable to pay compensation in respect of the content or subsequent use of this document for any purpose other than its stated purpose or for any purpose other than that for which it was prepared except where it can be shown to have acted in bad faith or there has been wilful default. NETWORK RAIL Page 2 of 18

3 Contents 1 INTRODUCTION Purpose of this Document Scope Context Abbreviations Requirements: Form, Applicability and Identification Requirements Assurance Requirements Change Areas for Development REQUIREMENTS... 7 APPENDIX A: ABBREVIATIONS APPENDIX B: LIST OF REFERENCES APPENDIX C: OPTIONS LOOKUP TABLE APPENDIX D: AREAS FOR DEVELOPMENT NETWORK RAIL Page 3 of 18

4 1 INTRODUCTION 1.1 Purpose of this Document This document provides a specification that is intended to promote effective implementation of the ETCS. It is applicable to ETCS installations, and provides requirements that are optimised for operation on the GB rail network. As stated in the industry-agreed and issued National ETCS Requirements Management Strategy [RD1] and Plan [RD2], the document provides the requirements which have been developed as part of a suite of ETCS requirements covering all elements required to optimise performance and operation of an ETCS railway. The document can be utilised as a standalone specification for the Telecoms aspect of the ETCS; further details of the parent requirements that drive the development of this specification are included within the System Requirements Specification [RD3] and the other Sub-system Requirements (Trackside, Onboard, and Operations [RD4], [RD5] & [RD6]). This Specification for the ETCS Telecoms sub-system has been written to complement the European Union Agency for Railways specification for Baseline 3 ETCS 1 [RD7] & [RD8]. Every effort has been made to avoid conflict with the Baseline 3 specification but, in case of conflict, the Baseline 3 specification takes precedence. The document is set out in the form of standard requirements with the ETCS Telecoms Requirement (ETCSS) identifier, followed by rationale and guidance notes where appropriate. 1.2 Scope This document consists of requirements which describe the functionality and application of the ETCS Telecoms sub-system optimised for application on the GB rail network at all required levels of operation. These requirements do not prevent the ETCS operating in conjunction with an Automatic Train Operation (ATO) system. Requirements will be added at a later date once the European specification for adding ATO to an ETCS sub-system has been finalised. Projects are encouraged to seek advice from the ERTMS Systems Body if there is a wish to facilitate early introduction of ATO. These requirements do not prevent the ETCS operating in conjunction with a Traffic Management (TM) system. No specific TM requirements have been identified for inclusion to date. Specific requirements and domain knowledge for a particular application are not included within this document, and will need to be defined by the Contracting Entity or their appointed Agent. Nothing in this document obviates any legal requirement with which any of the parties must comply. Furthermore, it does not preclude operation of a TSI-compliant vehicle on the GB rail network, nor a vehicle compliant to this specification operating on TSI-compliant infrastructure outside the GB rail network. 1.3 Context This document has been developed from a number of sources. 1 Note: This suite of requirements has been written to meet Baseline 3 Release 2, although the ETCS DOORS requirements database has the capability of producing a suite of requirements to meet Baseline 3 Maintenance Release 1. Should a suite of Baseline 3 Maintenance Release 1 requirements be needed, or if any background information be required for any specific requirement, then an with specifics should be sent to: nationalertmsrequirements@networkrail.co.uk NETWORK RAIL Page 4 of 18

5 Input from the ETCS programme, ETCS suppliers, and the wider rail industry has been used to develop the requirements. A series of workshops and industry consultations have identified new requirements. Guidance has been added to justify changes. Requirements amended and deleted through this development process have been captured within the requirements database, along with justification for their amendment or removal. 1.4 Abbreviations Abbreviations are explained in full where used in Requirements. A fuller explanation of Terms and Abbreviations can be found in Appendix A: and the ERTMS Glossary [RD9]. 1.5 Requirements: Form, Applicability and Identification Requirement Functionality Requirements may be functional or non-functional: Functional Requirements - Technical details that define what a system needs to accomplish, i.e. how suppliers equipment will be applied, what it needs to do, and what processes, procedures and rules need to be in place to achieve that. Non-Functional Requirements - Constraints on the design or implementation, such as performance, security, competence, training, and reliability requirements. Functional requirements have been derived through the Reference Design generation process [RD10], whereas non-functional requirements have been derived from the Cambrian Requirements suite and supplemented by workshop input [RD11] Basic Requirement Form All requirements are in the following form: Safety Requirement text. Unique ETCSS-Identifier Status: Normative/Application-Specific/Preferred. (See Section below). Rationale: Shows applicability of the requirement. Guidance: Supplementary information to support Requirement interpretation and satisfaction. Options: Reference Design Topics (If applicable). (See Section below) Safety Requirement Where a requirement has been associated with a Safety Measure, this is identified Normative / Application-Specific / Preferred status Each requirement within this document is identified as one of: normative, preferred, or application-specific. These are defined as follows: Normative o Necessary to achieve compatibility or optimisation of the system in relation to the GB rail network, or o A system feature that is deemed to be cost-effective and universally beneficial. NETWORK RAIL Page 5 of 18

6 Satisfaction of normative requirements in compliance with this document is expected to be a requirement of individual delivery contracts. Application-Specific o A requirement which may not be relevant or applicable to every implementation of the ETCS. It is expected that, where a requirement is applicable, it will be applied. Satisfaction of application-specific requirements in compliance with this document is expected to be a requirement of individual delivery contracts, as appropriate to the implementation being considered. Preferred o A requirement of lower importance which, whilst not essential, the industry would prefer were satisfied. It is expected that, where a requirement is applicable, it will be applied Options Satisfaction of preferred requirements in compliance with this document is not expected to be a requirement of individual delivery contracts unless explicitly specified within the relevant contract. Where applicable, the Reference Design Topic has been identified, as detailed in the Topics Lookup Table in Appendix C:. 1.6 Requirements Assurance Requirements assurance has been explained in the ETCS Requirements Assurance Statement [RD12]. 1.7 Requirements Change The ETCS Requirements Change Management Process [RD13] will be used to raise Change Requests (CRs) to amend existing requirements or add new requirements. 1.8 Areas for Development Noting that this document represents the best understanding of the needs of GB s rail network at the time of publishing, it is recognised that there are a number of areas where the document may be deficient. New deficiencies may be identified as understanding of the ETCS develops, as well as areas being closed out through further work being undertaken. The current known areas of deficiency are listed in Appendix D: NETWORK RAIL Page 6 of 18

7 2 REQUIREMENTS The GSM-R infrastructure shall, as a minimum, meet the Telecommunications Reliability, Availability & Maintainability (RAM) requirements specified in the ERTMS Reliability Specification (NR/AM/SA/SPE/00147) [RD14]. ETCSS-1 Rationale: NR/AM/SA/SPE/00147 defines ETCS reliability and availability targets, which are then apportioned to the respective Onboard, Trackside and Telecommunications elements. Guidance: RAM Requirements for the network sub-systems are specified in the ERTMS Reliability Specification NR/AM/SA/SPE/00147 Issue: A07 [RD14]. The specification only considers single GSM-R components; however, it is acknowledged that the overall network architecture needs to be considered holistically, and the Guidance Note 'GSM-R Availability Assessment for ETCS Traffic' (NEPT/ERTMS/HBK/0402 ver1.1) [RD15] addresses how to meet the availability requirement of the route. Options: A1-1, A1-2, A2-1, A2-2, O2-1, O2-2, HH Whole life Service Level Agreements (SLAs) and procedures related to planned telecoms infrastructure system maintenance outages shall be reviewed and updated before each ETCS route deployment. ETCSS-2 Rationale: System outages will be required in order to carry out system maintenance and upgrades to the Fixed Telecommunications Network (FTN) and Global System for Mobile Communications Railway (GSM-R) networks and their supporting systems, e.g. power supplies. The procedures for handling such outages need to be discussed with Industry and agreed at the National level as part of the ETCS life cycle plan. Guidance: SLAs will be agreed at the National level and will have to be in place before each route commissioning. Unambiguous procedures shall be provided for degraded and abnormal telecoms conditions. ETCSS-65 Rationale: Telecoms personnel must advise operations personnel so that operators can safely and efficiently manage the situation in degraded working. Guidance: In the event of any service affecting failure of the telecoms network, operational procedures will be implemented immediately by the Telecommunications network provider to advise the signallers of the nature of the failure and ensure that they are aware of the operational implications and projected recovery times. Operation of the ETCS on the Telecommunications network shall not have a detrimental impact on existing services using the Telecommunications network. Rationale: The introduction of ETCS must not adversely impact other existing users. ETCSS-70 NETWORK RAIL Page 7 of 18

8 Guidance: Existing services using the Telecommunications network include GSM-R voice, Supervisory Control & Data Acquisition (SCADA), level crossings, etc. In the event of failure of voice communications following application of the ETCS, there shall be an alternative means of voice communication with the signaller. Rationale: To provide a suitable method of communication with the signaller to meet operational or safety obligations. Guidance: Drivers, track workers and members of the public may need to maintain communications with the signaller regardless of the availability of the GSM-R. Locations can include platforms, level crossings, tunnels and key junctions. Options: A4, HH ETCSS-61 The characteristics and performance of the data bearer services provided by the GSM-R network shall satisfy Subset 093. Rationale: Subset 093 is currently a non-mandatory specification within the Control, Command and Signalling Technical Specification for Interoperability (CCS TSI) [RD8] and needs to be applied in the absence of any other Quality of Service (QoS) specification. Guidance: Subset-093 provides end-to-end service requirements for GSM-R networks. Subset-093 provides end-to-end minimum QoS, including establishment of a connection, the connection loss rate, and re-establishment of connection. Options: A1-1, A1-2, A2-1, A2-2, O2-1, O2-2, R1 ETCSS-3 Subset-037 and A 11 T 6001 configuration parameters for communications shall be optimised. ETCSS-12 Rationale: Subset-037 and A 11 T 6001 specify the parameters that need to be optimised. Guidance: Subset-037 version (Euroradio FIS) and A 11 T 6001 version (Radio Transmission FFFIS for EuroRadio) contain parameters that need to be optimised to take into account GSM-R network behaviour. Options: R1 Processes and procedures shall be in place to maintain the levels of GSM-R network service throughout the lifetime of the GSM-R system. ETCSS-9 Rationale: Loss of the GSM-R has an immediate impact on an ETCS railway. Guidance: The levels of service are as specified in Subset-093 and network coverage requirements are contained in the European Integrated Railway Radio Enhanced Network (EIRENE) System Requirements Specification (SRS) [RD8]. Options: A1-1, A1-2, A2-1, A2-2, A4, O2-1, O2-2, EE2 NETWORK RAIL Page 8 of 18

9 Safety A quality of service monitoring system shall be implemented across the telecoms infrastructure. ETCSS-10 Rationale: This is required for gathering service statistics to predict potential performance degradation. Safety requirement for hazard N-H028. Guidance: Service statistics required for ETCS operations include, but are not limited to, the number of successful ETCS calls, the number of failed ETCS calls, and the cell handover success rate for ETCS calls encountered. The following should also be included, but not be limited to: ETCS Connection Establishment Delay, ETCS Connection Errors, ETCS Connection Loss Rate, delayed Subset-026 messages, High-Level Data Link Control (HDLC) Frame Error, Cyclic Redundancy Check (CRC) error, retransmitted frames, and lost frames. Options: N2-1, O2-1, O2-2 The Telecommunications system shall be supported by a life cycle management plan. Rationale: To ensure that budgets and system design deliver whole-life cost-efficiency. Guidance: The telecoms lifecycle management plan will need links into a life cycle management strategy for the ETCS as a system on the rail network to enable effective management of configuration and reliability through industry Data Recording Analysis and Corrective Action System (DRACAS) processes. ETCSS-16 The GSM-R network capacity shall support ETCS data and voice traffic for normal, degraded and emergency operations on the route. ETCSS-4 Rationale: To provide Telecommunications traffic capacity that will be required to support the ETCS and voice communications. This will include the capacity required to support online key management. Guidance: The Guidance Note 'GSM-R Capacity Assessment for ETCS Traffic' [RD17] provides instruction on what needs to be considered when identifying the data capacity requirements, taking into consideration future increase in rail operations, Radio Block Centre (RBC) handovers, Start of Mission, degraded operations, etc. The Operational Concept for ERTMS [RD18] defines normal operations as situations expected to be encountered entering, exiting, and making train movements in the ETCS, and any setting up or closing down arrangements as part of start of service or end of service. Degraded operation is defined as planned or unplanned reduction in the ability of the ETCS to operate in its normal manner. This could include a partial degradation where it remains acceptable to continue to operate the ETCS. Options: A1-1, A1-2, A2-1, A2-2, A4, C, J3, J4, N1-1, N2-1, N2-2, O2-1, O2-2, S5-1, U1, U2, U4, U5, U6, V1, V2, EE2, JJ1, JJ2, JJ3, JJ4, JJ5, JJ6, JJ7, JJ8 The Telecommunications network shall satisfy the route's apportioned availability requirement for the telecoms network. ETCSS-64 NETWORK RAIL Page 9 of 18

10 Rationale: To support the route in selecting a system configuration that is suitable for that route. Expenditure on telecoms availability needs to be considered against the impact of loss of service on the route. Guidance: The route will have a business plan for delay reduction when the ETCS is operational. Applying apportionment modelling will derive a budget of allowable delay for the route and the system. The Guidance note 'GSM-R Availability Assessment for ETCS Traffic' [RD15] provides guidance on the process to support the route in selecting a suitable system configuration. Options: A1-1, A1-2, A2-1, A2-2, O2-1, O2-2 The Telecommunications network shall allow trains to register and de-register from the ETCS at any location which is ETCS data-enabled. ETCSS-72 Rationale: GSM-R coverage is required in all locations where ETCS-fitted trains plan to operate under ETCS control. Guidance: The Guidance Note 'GSM-R Coverage Assessment and Cell Planning' [RD16] provides guidance on operational areas that need to be considered. Locations include terminus / turnback stations, ETCS level transition points, and relevant depots / sidings. De-registration in areas not fitted with the ETCS will be achieved through timeout. Options: B, C, G1-1, G1-2, G2, G4-3, I, O1, O2-1, O2-2, O3 Where there is a requirement to provide General Packet Radio Service (GPRS) for capacity reasons, the whole of the RBC operational area shall be provided with GPRS capability, including the RBC to RBC handover zones. ETCSS-71 Rationale: This aligns with Subset 037 version Guidance: Once in an RBC area, it is not possible for the Onboard to switch automatically from packet-switched data to circuit-switched data. Options: R1 GSM-R network coverage shall be provided in all areas where ETCS-fitted trains will enter, operate in, and exit Level 2. ETCSS-13 Rationale: GSM-R data coverage is required in all areas where ETCS-fitted trains enter, operate in, and exit Level 2. Guidance: This includes associated depots, maintenance facilities and sidings, as well as possessions, and during emergency degraded and abnormal conditions. Coverage is also required to support online key management. The Guidance Note 'GSM-R Coverage Assessment and Cell Planning' [RD16] provides guidance on signal strengths in the operational areas that need to be considered. The Guidance Note asks for higher levels than those defined in the EIRENE System Requirements Specification and provides target coverage levels by location, including major stations, junctions, tunnels, and urban and rural lines. It also provides coverage guidance for RBC handovers, Start of Mission, transition into Level 2, etc. Options: A1-1, A1-2, A2-1, A2-2, A4, G1-1, G1-2, G2, G4-1, G4-2, J2, J3, J4, J5, L1, N1-1, N2-1, O2-1, O2-2, S5-1, V1, V2, HH NETWORK RAIL Page 10 of 18

11 The Telecommunications network shall provide sufficient GSM-R signal strength and overlapping coverage at locations where marginal coverage or loss of coverage would cause significant disruption to railway operations. Rationale: Loss of coverage or marginal coverage in key areas would cause significant disruption to railway operations. Guidance: The Guidance Note 'GSM-R Coverage Assessment and Cell Planning' [RD16] provides guidance on operational areas that need to be considered. Although minimum levels are defined by the EIRENE SRS, this requirement is to make sure that critical areas have the best coverage. Options: A1-1, A1-2, A2-1, A2-2, I ETCSS-73 The Telecommunications network shall provide sufficient GSM-R signal strength to mitigate against interference from Mobile Network Operator (MNO) interferer sites. ETCSS-74 Rationale: To minimise the likelihood of interference from MNO sites disrupting railway operations. Guidance: The GSM-R network design should take into consideration that the base-stations are authorised to operate only within the power limits defined in the Wireless Telegraphy Act licence. Coordination and cooperation with MNOs could provide additional measures to minimise interference. Options: A1-1, A1-2, A2-1, A2-2, I The Telecommunications network shall provide coverage overlap between adjacent GSM-R cells to allow successful circuit-switched handovers or General Packet Radio Service (GPRS) re-selections to take place at line speed at the required signal level. ETCSS-75 Rationale: GSM-R coverage is required in all locations where ETCS-fitted trains will operate. Guidance: The Guidance Note 'GSM-R Coverage Assessment and Cell Planning' [RD16] provides guidance on operational areas that need to be considered. Options: EE1, EE2 The Telecommunications system shall support the testing associated with the introduction of, and future changes to, ETCS installations. ETCSS-62 Rationale: There are locations that will need ETCS coverage purely to test GSM-R functionality on its introduction, or as a result of maintenance. Guidance: This will be needed at test tracks, in depots, and on the mainline and would cover General Packet Radio Service (GPRS), Enhanced Data rates for GSM Evolution (EDGE), and the complex rail environment. The telecoms application design shall facilitate ease of maintenance, repair and replacement, and configuration control of components. ETCSS-66 NETWORK RAIL Page 11 of 18

12 Rationale: Ease of maintenance and installation contributes to whole-life cost reduction. Guidance: The design should enable ease of installation and maintenance activities for rapid fault resolution. The Telecommunications system shall be protected from threats with sufficient physical, procedural and technical controls to minimise damage and security risks. ETCSS-67 Rationale: Telecommunications systems can be compromised at several levels. This requirement addresses intended and unintended consequences of the system being compromised. Guidance: Access to systems must be controlled to avoid unauthorised access, either unintentional or deliberate. Consideration should be given to the location and environment of the equipment to be protected. Network Rail s Security Assurance Framework (SAF) [RD19] should be used to assess GB operational rail systems (including communications networks) for risk. The Telecommunications sub-system equipment, processes and people shall not give rise to unacceptable and unmanageable safety risks. ETCSS-68 Rationale: To ensure that the complete system of systems is safe. Guidance: The Telecommunications sub-system equipment and processes will interact with other systems. The interaction encompasses intentional interaction via a defined interface and unintentional interaction where there is no defined interface. The Telecommunications network provider shall provide profiled Subscriber Identity Module (SIM) cards to support deployment of the ETCS. ETCSS-5 Rationale: The Telecoms network provider intends to procure a large number of SIM cards in advance and profile them in time for deployment on the route. Guidance: The SIM cards will be profiled for the desired service, e.g. data, testing, voice, etc. The total number of SIM cards for end-user equipment will need to be specified for each application. All the necessary SIM cards for the lifetime of the project will be made available before the deployment of the route. All Subscriber Identity Module (SIM) cards shall be profiled for both Circuit Switched and Packet Switched communications modes. Rationale: The TSI specifies the GSM-R SIM card as an Interoperability constituent. Guidance: The SIM needs to be profiled for both circuit switched and packet switched modes to allow the ETCS Data Only Radio (EDOR) to use packet switching where required. ETCSS-92 NETWORK RAIL Page 12 of 18

13 Options: None The Telecommunications network provider shall manage the provision of Subscriber Identity Module (SIM) cards and configuration databases throughout the lifetime of the ETCS. ETCSS-76 Rationale: To support Railway Undertakings (RUs) in replacing defective ETCS Data only Radios (EDORs). Guidance: Replacement SIM cards will need to be profiled for the desired service (e.g. data, test, etc.) and the GSM-R configuration database will need to be maintained to enable the EDOR to work on the GSM-R network. Packet switched data communications shall be available at all locations where online key updates are required to take place. Rationale: To enable keys to be updated when required. Guidance: To provide packet switched data communications at locations where key transfers are required to take place. These include ETCS running lines, maintenance depots and stabling points attached to ETCS running lines, maintenance depots where ETCS equipped trains will be maintained, private sidings and facilities, and other locations, as required. Options: EE1, EE2 ETCSS-77 Safety The Telecommunications system shall record system event data suitable for use to monitor system performance and investigate incidents effectively. ETCSS-78 Rationale: Speedy investigation and resolution of incidents is critical to keep the service running. Safety requirement for hazard N-H028. Guidance: It must be possible to understand how the whole system has behaved (including those who operate it) in order to determine the underlying causes of any incident or performance failure. Therefore, data from the Onboard, Trackside and Telecommunications sub-systems must be collected and synchronised. Information relating to the human element would be managed through review of written records and interviews as well as actions at the human machine interfaces recorded by sub-systems. GSM-R network coverage shall be provided when the train's reporting of position or requesting of Movement Authority updates might be used to influence the operation of the level crossing. ETCSS-79 Rationale: Good coverage is required where ETCS is used to influence the operation of the level crossing. Guidance: The coverage would be from a point which allows the ETCS and the level crossing system to react, taking into consideration the braking distance of the NETWORK RAIL Page 13 of 18

14 Options: train. This can be approximated to 4 minutes running time at linespeed from the crossing. A1-1, A1-2, A2-1, A2-2, JJ1, JJ2, JJ3, JJ4, JJ7 There shall be no designed radio holes from a point 200m on the approach to an End Of Authority (EOA) protecting a level crossing and the level crossing itself. ETCSS-80 Rationale: Trains crossing a failed level crossing need to be able to receive the movement authority and mode profile in this area. Options: JJ8 NETWORK RAIL Page 14 of 18

15 APPENDIX A: ABBREVIATIONS The following abbreviations are used within this document, and can also be found in the ETCS Glossary [RD9]. ATO CCS CRC DRACAS EDGE EDOR EIRENE ERTMS ESB ETCS FTN GPRS GSM-R HDLC MNO QoS RAM RBC RU SCADA SIM SLA TM TSI VBS Automatic Train Operation Control, Command & Signalling Cyclic Redundancy Check Data Recording Analysis and Corrective Action System Enhanced Data rates for GSM Evolution ETCS Data Only Radio European Integrated Radio Enhanced Network European Rail Traffic Management System ERTMS Systems Body European Train Control System Fixed Telecommunications Network General Packet Radio Service Global System for Mobile Communications - Railway High-Level Data Link Control Mobile Network Operator Quality of Service Reliability, Availability & Maintainability Radio Block Centre Railway Undertaking Supervisory Control And Data Acquisition Subscriber Identity Module Service Level Agreement Traffic Management Technical Specification for Interoperability Voice Broadcast Service NETWORK RAIL Page 15 of 18

16 APPENDIX B: LIST OF REFERENCES Note: Unless otherwise stated, reference should be made to the most recent authorised version of the document. [RD1] National ETCS Requirements Management Strategy, NEPT/ERTMS/REQ/0003 [RD2] ETCS Requirements Management Plan, NEPT/ERTMS/REQ/0001 [RD3] ETCS Baseline 3 - System Requirements Specification, NEPT/ERTMS/REQ/0005 [RD4] ETCS Baseline 3 GB Trackside Subsystem Requirements, NEPT/ERTMS/REQ/0006 [RD5] ETCS Baseline 3 GB Onboard Subsystem Requirements, NEPT/ERTMS/REQ/0007 [RD6] ETCS Baseline 3 GB Operational Subsystem Requirements, NEPT/ERTMS/REQ/0009 [RD7] COMMISSION REGULATION (EU) 2016/919 of 27 May 2016 on the technical specification for interoperability relating to the control-command and signalling subsystems of the rail system in the European Union [RD8] Baseline 3 Release 2 (TSI CCS Annex A set of specifications #3, which includes GSM-R Baseline 1 (EIRENE FRS V8.0.0 & SRS V16.0.0)) [RD9] ERTMS Programme Glossary of Terms, ERTMS/PGM/D0115 [RD10] ERTMS Reference Design, NEPT/ERTMS/SYS/0032 [RD11] National ETCS Requirements Consolidation Process, CCMS: [RD12] ETCS Requirements Assurance Statement, CCMS No: [RD13] ETCS Requirements Change Management Process, NEPT/ERTMS/REQ/0013 [RD14] ERTMS Reliability Specification NR/AM/SA/SPE/00147 Issue: A07. [RD15] Guidance Note 'GSM-R Availability Assessment for ETCS Traffic', NEPT/ERTMS/HBK/0402 version 1.1 [RD16] Guidance Note 'GSM-R Coverage Assessment and Cell Planning', NEPT/ERTMS/HBK/0403 version 2.1 [RD17] Guidance Note 'GSM-R Capacity Assessment for ETCS Traffic', NEPT/ERTMS/HBK/0401 version 1.1 [RD18] Operational Concept for ERTMS, RSSB-ERTMS-OC, Issue 2 [RD19] NR Security Assurance Framework, NRT/SY/2015/036 The TSI and Class 1 Specifications are obtainable from the European Union Agency for Railways. NETWORK RAIL Page 16 of 18

17 APPENDIX C: OPTIONS LOOKUP TABLE Note: (W) indicates a Working Version and not a Release Version. Topic ID Topic Title Version A Continuing Movement 3.0 B Operation in Possession 6.0 C End of Mission 2.0 D Train Dispatch 2.0 E Stopping at an End of Authority (EOA) 3.0 F Applying Speed Restrictions 3.0 G Starting 3.1 H Permissive Moves 3.0 I Attaching and Detaching 3.0 J Stopping Trains 3.0 K Changing Driver ID and TRN mid-journey 3.0 L ETCS Route Release 3.0 M Neutral Sections, Traction Changeover and Pantograph Management 5.0 N Entering ETCS 3.0 O Exiting ETCS (Leaving Level 2 and 3) 3.0 R Boundaries 4.0 S5 Degraded or Abnormal Working, Route Not proved 5.0 T Inhibition of Transition 5.0 U System Controls for Issue of Movement Authorities 4.0 V Provision of Routing Information 5.0 Y Miscellaneous 4.0 Z Non trackside 2.0 AA Consistent Provision of Lineside Signage 4.0 CC Utilisation of Packet 44 in ETCS Areas 3.0 EE Key Management 2.7 HH Train Maintenance and Testing 4.0 II Balise Configuration Rules 4.0 JJ Level Crossing Operation and Protection 5.0 KK Transmission of National Values 3.0 LL Use of Track Condition Functions 5.0 NETWORK RAIL Page 17 of 18

18 APPENDIX D: AREAS FOR DEVELOPMENT No. Issue Description Identified in version Closed in version 1 Reference Design The Specification Requirements need to be updated to incorporate the latest requirements from the Release Versions of the Reference Design Topics Z and EE, which are identified as (Provisional). 2 Automatic Train Operation When Automatic Train Operation has been developed and European standards published further requirements may need to be included. 3 ETCS Level 3 When ETCS Level 3 has been developed and European standards and GB application rules published further requirements may need to be included. 4 Remaining comments from Industry Review 5 Operational Test Scenario input Remaining comments from the Industry review need to be closed out. There will be consequential amendments required arising from the output from the OTS work NETWORK RAIL Page 18 of 18