Digital Railway GB Generic Interface Requirements Specification

Transcription

1 Reference NWR-SPE-ESE- Digital Railway GB Generic Interface Requirements Specification Prepared By: Jonathan Evans Lead Integration Validation Engineer JJE Date: 23/04/2018 Reviewed By: Tracey Best Head of Systems Engineering TLB Date: 24/04/2018 Approved By: Anders Møller Head of System Requirements and Integration ANDM Date: 25/04/2018

2 Electronic file reference: hdms.co.uk/digitalrail/search/quicklink.aspx?n= nwr-spe-ese- &t=3&d=main%5cdigital-rail-production&sc=global&state=latestrevision&i=view Disclaimer Group Digital Railway 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 will be sufficient to ensure safe systems of work or operation. Group Digital Railway 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. Copyright 2018 Group Digital Railway. This document is the property of Group Digital Railway. It shall not be reproduced in whole or in part, nor disclosed to a third party, without the written permission of Group Digital Railway. Document owner: Anders Møller, Head of System Requirements and Integration Version History Issue Date Comments /04/18 First draft of populated document /04/18 Second draft incorporating comments on draft 0.1 and review against Basis of Design document /04/18 First formal issue Exclusions These are items currently missing from this version of the document that should be included in a later publication. 1. Table in Appendix A.3 will be populated in a later version. 2. Full attribution of safety tagged requirements will be included in a later version. 3. Best endeavours have been used during the development of this specification to align it to the relevant Concepts of Operations documents which have been updated in parallel. Final assurance of the complete alignment of this specification with the relevant industry-endorsed Concepts of Operations will be achieved in a later version. 4. Sections that do not currently contain any requirements will be populated in a later version. 5. There may be further requirements related to degraded mode scenarios to be added in a later version once the Basis of Design document has been expanded to include these scenarios. Page 2 of 53

3 Assumptions These are items upon which the validity of this document relies and which will be delivered by others. Non-delivery of these items will necessitate a change to this document. 1. For a list of assumptions please refer to section 4.2 Dependencies These are no identified items upon which the validity of this document depends. Page 3 of 53

4 Content ABBREVIATIONS, ACRONYMS AND DEFINITIONS... 7 REFERENCES INTRODUCTION Purpose Scope Business Need for this Specification Document Maintenance APPLICATION OF THIS SPECIFICATION Requirements Presentation SAFETY TAGGED REQUIREMENT UNIQUE REQUIREMENT IDENTIFIER REQUIREMENT STATUS Identification of Applicable Requirements INTERFACE REQUIREMENTS Presentation Requirements Elicitation TMS to ETCS Trackside TMS TO ETCS TRACKSIDE FUNCTIONAL REQUIREMENTS TMS TO ETCS TRACKSIDE COMMUNICATION REQUIREMENTS TMS to Layered Information Exchange (LINX) TMS TO LINX FUNCTIONAL REQUIREMENTS TMS TO LINX COMMUNICATIONS REQUIREMENTS TMS to Voice Communications Systems TMS TO VOICE COMMUNICATIONS SYSTEMS FUNCTIONAL REQUIREMENTS TMS TO VOICE COMMUNICATIONS SYSTEMS COMMUNICATIONS REQUIREMENTS TMS to Closed Circuit Television (CCTV) Systems TMS TO CCTV SYSTEMS FUNCTIONAL REQUIREMENTS TMS TO CCTV SYSTEMS COMMUNICATIONS REQUIREMENTS TMS to Supervisory Control and Data Acquisition (SCADA) Systems TMS TO SCADA FUNCTIONAL REQUIREMENTS TMS TO SCADA COMMUNICATIONS REQUIREMENTS TMS to Trackside Objects ETCS Onboard to Key Management System (KMS) ETCS ONBOARD TO KMS FUNCTIONAL REQUIREMENTS ETCS ONBOARD TO KMS COMMUNICATIONS REQUIREMENTS ETCS Onboard to Onboard Voice Communications Systems Page 4 of 53

5 ETCS ONBOARD TO ONBOARD VOICE COMMUNICATIONS SYSTEMS FUNCTIONAL REQUIREMENTS ETCS ONBOARD TO ONBOARD VOICE COMMUNICATIONS SYSTEMS COMMUNICATIONS REQUIREMENTS ETCS Onboard to Class B Train Protection Systems ETCS Onboard to Other Onboard Systems ETCS ONBOARD TO OTHER ONBOARD SYSTEMS FUNCTIONAL REQUIREMENTS ETCS ONBOARD TO OTHER ONBOARD SYSTEMS COMMUNICATIONS REQUIREMENTS ETCS Trackside to ETCS Onboard ETCS TRACKSIDE TO ETCS ONBOARD FUNCTIONAL REQUIREMENTS ETCS TRACKSIDE TO ETCS ONBOARD COMMUNICATIONS REQUIREMENTS ETCS Trackside to KMS ETCS TRACKSIDE TO KMS FUNCTIONAL REQUIREMENTS ETCS TRACKSIDE TO KMS COMMUNICATIONS REQUIREMENTS ETCS Trackside to Trackside Worker Warning Systems ETCS TRACKSIDE TO TRACKSIDE WORKER WARNING SYSTEMS FUNCTIONAL REQUIREMENTS ETCS TRACKSIDE TO TRACKSIDE WORKER WARNING SYSTEMS COMMUNICATIONS REQUIREMENTS C-DAS to LINX C-DAS TO LINX FUNCTIONAL REQUIREMENTS C-DAS TO LINX COMMUNICATIONS REQUIREMENTS C-DAS to Other Onboard Systems C-DAS TO OTHER ONBOARD SYSTEMS FUNCTIONAL REQUIREMENTS C-DAS TO OTHER ONBOARD SYSTEMS COMMUNICATIONS REQUIREMENTS ETCS Trackside to ETCS Trackside ETCS TRACKSIDE TO ETCS TRACKSIDE FUNCTIONAL REQUIREMENTS ETCS TRACKSIDE TO ETCS TRACKSIDE COMMUNICATIONS REQUIREMENTS ETCS Trackside to Trackside CCS Objects ETCS TRACKSIDE TO TRACKSIDE CCS OBJECTS FUNCTIONAL REQUIREMENTS ETCS TRACKSIDE TO TRACKSIDE CCS OBJECTS COMMUNICATIONS REQUIREMENTS ETCS Trackside to Adjacent Interlocking (non-etcs) ASSOCIATED INFORMATION Open Points Assumptions Dependencies Constraints Page 5 of 53

6 APPLICABILITY ASSESSMENT TEMPLATE A.1 Guidance on Populating the Template A.2 Feedback A.3 Template NEW INTERFACE REQUIREMENTS TEMPLATE Page 6 of 53

7 ABBREVIATIONS, ACRONYMS AND DEFINITIONS Abbreviations are explained in full on first use within this document. A comprehensive list of abbreviations and definitions is contained in the Glossary [RI1]. Page 7 of 53

8 REFERENCES Dependent References An update to one of these references requires an update to this document RD1 RD2 RD3 RD4 RD5 RD6 RD7 RD8 RD9 RD10 RD11 Digital Railway System of Systems Concept of Operation (details TBA) Digital Railway ETCS Concept of Operations (details TBA) Digital Railway TM Concept of Operations (details TBA) Digital Railway C-DAS Concept of Operations (details TBA) Digital Railway Programme Interface Description Document, NWR-RCD- ESE , Version 4.0 Digital Railway GB Generic System of Systems Customer Requirements Specification, NWR-SPE-ESE , Version 1.0 Digital Railway GB Generic Customer Requirements Specification for ETCS Onboard, NWR-SPE-ESE , Version 1.0 Digital Railway GB Generic Customer Requirements Specification for ETCS Trackside, NWR-REP-ESE , Version 1.0 Digital Railway GB Generic Customer Requirements Specification for Traffic Management Systems (TMS), NWR-SPE-ESE , Version 1.0 Digital Railway GB Generic Customer Requirements Specification for Connected Driver Advisory System, NWR-SPE-ESE , Version 1.0 Technical Specification for Interoperability (CCS), Commission Regulation (EU) 2016/919, 27 th May 2016 RD12 Baseline 3 Release 2 (TSI CCS Annex A set of specifications #3) RD13 Digital Railway Integration Fundamentals Handbook, NWR-GDN-MPM , Version 1.0 RD14 Digital Railway Customer Requirements Specification Requirements Management Plan NWR-PLN-ESE , Issue 1.0, 13 th February 2018 RD15 Digital Railway SoS Basis of Design, NWR-REP-ESE , Version 1.0 RD16 RD17 RD18 Digital Railway Customer Requirements Deployment Policy, NWR-SPE- ESE , Version 1.0 Digital Railway Customer Requirements Requirements Change Control Process, NWR-SPE-ESE , Version 1.0 Digital Railway System of Systems Data Specification, NWR-SPE , Version 1.0 Informative References These references have no material bearing on the content of this document. Page 8 of 53

9 RI1 Digital Railway Glossary of Terms and Abbreviations, NWR-SPE-ESE , Issue 1.0, 15 th February 2018 Page 9 of 53

10 1. Introduction Purpose The purpose of this document is to set out the generic Interface Requirements that apply between: 1. two component parts of the Digital Railway System of Systems; 2. a component part of the Digital Railway System of Systems and an external system. These requirements apply whenever the Digital Railway System of Systems, or any of its component parts, is deployed on the GB railway network. These Interface Requirements are intended as a baseline to ensure that the system solutions adopted on any individual deployment project will integrate and be compatible across route boundaries. All deployment projects involving the deployment of any component part of the Digital Railway System of Systems will use this document as an essential part of their requirements suite as described in section 2.2. Scope This document provides the generic Interface Requirements applicable to each component of the Digital Railway System of Systems. During Phase 2 of the SR&I Programme, it will be fully aligned to the various Concept of Operations documents [RD1], [RD2], [RD3] and [RD4], which describe how the GB railway is intended to operate when these systems are deployed. The overall Digital Railway System of Systems architecture and the individual interfaces within and associated with it are defined in the System of Systems Interface Definition Document [RD5]. This document is an essential part of the DR Programme Generic Requirements Suite and should be used in conjunction with the GB Generic System of Systems Customer Requirements Specification [RD6] and the GB Generic Customer Requirements Specifications for the individual systems within the System of Systems [RD7], [RD8], [RD9] and [RD10]. It is particularly important that this document is read in conjunction with the Generic System of Systems Customer Requirements Specification [RD6] as the two documents, taken together, are intended to set out the requirements which deliver the overall functionality described in the Basis of Design [RD15]. This document does not set out requirements which relate solely to the capabilities of any one system as these are contained, for the Digital Railway systems, within the relevant Customer Requirements Specification and compliance with these, in addition to this document, is necessary to support a successful implementation of the systems. This document does not set out requirements which relate to activities which need to be performed by humans interacting with the systems. These will be captured in the Operational Readiness work stream at a later date and recorded in the appropriate specifications. This document does not contain details of any deployment project-specific requirements. These may be found in deployment project-specific documentation, which is subordinate to this document. Section 2.2 of this document sets out how a deployment project will identify which of the requirements in this document are relevant to its needs. Page 10 of 53

11 Nothing in this document obviates any legal requirement with which the parties using it must comply. Business Need for this Specification There are many potential solutions for implementing the Digital Railway Strategy and realising the visions set out in the Concepts of Operations. However, if left totally unconstrained, there is a risk that different deployment projects could independently generate solutions that were sufficiently different as to create technical or operational compatibility issues at the railway system boundaries. Compatibility issues of this nature would inhibit the GB railway s ability to meet the objectives set out above and must, therefore, be avoided. Examples of compatibility issues could include: one project s Traffic Management System solution being unable to provide a second project s Traffic Management System solution with all the information needed for effective management of train services crossing the boundary between them; or, a train driver having to learn and apply different sets of operational procedures relating to the same underlying system across different geographical areas. The generic Interface Requirements are intended to promote the development of technically, operationally and environmentally compatible solutions which are safe and secure, and which could be deployed across the GB rail network in order to maximise the benefits which the industry can reap from the adoption of digital technologies. This document should be read in conjunction with the suite of generic Digital Railway Customer Requirements Specifications as follows: SoS Customer Requirements Specification [RD6]; C-DAS Customer Requirements Specification [RD10]; TMS Customer Requirements Specification [RD9]; ETCS Onboard Customer Requirements Specification [RD7]; ETCS Trackside Customer Requirements Specification [RD8]. Where this document sets out Interface Requirements related to the European Train Control System (ETCS) they are intended to be complementary to the Command, Control and Signalling Technical Specification for Interoperability (CCS TSI) [RD11] and associated Baseline 3 Release 2 ETCS specifications [RD12] issued by the European Union Agency for Railways. Every effort has been made to avoid conflict with the CCS TSI and Baseline 3 Release 2 specifications but, in case of conflict, the CCS TSI (including the UK specific cases) and Baseline 3 Release 2 specifications take precedence. Document Maintenance This document is owned by the DR Programme s Head of System Requirements and Integration. A process for the management of change to this document will be undertaken by the document owner. This process will encompass the review of the document in response to lessons learnt through procurement and deployment experience and the management of formal change proposals from the GB rail industry or suppliers. It is envisaged that the following criteria will be used to support the impact assessment of proposed changes with a view to determining whether any proposed change should be implemented: Ability to meet the business needs of the GB railway Page 11 of 53

12 Ability to deliver the vision set out in the Concepts of Operations Technical and operational compatibility with deployment projects procured against an earlier version of this document Ability for the supplier to be innovative Page 12 of 53

13 2. Application of this Specification Requirements Presentation All requirements are in the following form: Reference NWR-SPE-ESE- Safety Requirement text. Unique-Identifier Identifies where the requirement originated. or Application-Specific. (See Section 2.2). Shows applicability of the requirement, including why the requirement exists, who it is for, what industry benefit could be achieved, what the constraints are, and any other essential detail. Note: Cross-referencing should be used to avoid overlengthy rationales. Supplementary information to support Requirement interpretation and satisfaction Safety Tagged Requirement Where a requirement has been associated with a Safety Measure, this is identified and referenced to the hazard record number Unique Requirement Identifier Each requirement has been identified uniquely. The requirement numbers have been generated within the DOORS database, which means that the requirement numbering may be neither sequential nor gap-free Requirement Status Each requirement within this document is identified as either or Application- Specific. requirements are mandatory for all deployment projects. Application-specific requirements are mandatory for all deployment projects on which the interface addressed by the requirement occurs. Identification of Applicable Requirements The generic Interface Requirements in this document cover each of the interfaces identified in [RD5]. For deployment projects that do not implement all component parts of the System of Systems it is possible that not all of the interfaces will be relevant and therefore some degree of selectivity is appropriate. In addition, it is possible that some deployment projects may encounter local interfaces that are not covered by the generic Interface Requirements Specification. Page 13 of 53

14 Consequently, each deployment project must ensure that it establishes and documents the appropriate set of Interface Requirements for its circumstances. The process for doing so is covered in outline within the Integration Fundamentals Handbook [RD13] and in detail for Infrastructure deployment projects in the Customer Requirements Deployment Policy [RD16] and may be summarised as follows: 1. The starting point is the generic Interface Requirements Specification (i.e. this document). 2. All Interface Requirements associated with any component of the System of Systems being provided by the deployment project are mandatory for that project. 3. Any Interface Requirements that are not associated with any component of the System of Systems being provided by the deployment project may be deleted. 4. New Interface Requirements may be generated to address local issues which only apply to a specific deployment project but are not covered in the generic Interface Requirements Specification, provided that they do not compromise the achievement of cross-boundary compatible solutions. The consequence of this for deployment projects which are only providing part of the System of Systems is that the component systems that they do provide will be capable of supporting all the interfaces they would need in order to deliver the complete System of Systems. This approach supports the efficient addition of the remaining components of the System of Systems at a later date with the minimum of future integration activities. For example, a project that was providing a Traffic Management System (TMS) but not a Connected Driver Advisory System (C-DAS) would still be expected to ensure that the TMS implemented the TMS to C-DAS interface requirements so that a C-DAS could be added at a later date with minimal change to the TMS. Appendix A contains a template which deployment projects can populate to indicate which of the Interface Requirements are applicable to their particular circumstances (steps 2 and 3 above). Appendix B contains a template which deployment projects can use to record any new Interface Requirements they generate for their particular circumstances (step 4 above). Note that a deployment project is not permitted to: 1. amend the wording of an existing generic Interface Requirement; or, 2. replace an existing generic Interface Requirement with a differently worded requirement relating to the same issue. These restrictions are necessary to prevent the risk of generating a project-specific set of Interface Requirements that may not achieve a cross-boundary compatible solution. If a deployment project considers that the wording or status of an existing Interface Requirement is incorrect, or wishes to add a new requirement to cover any local issues which apply to the deployment project but are not covered in the generic Interface Requirements Specification, then this should be raised with the document owner via the change request process for consideration at a national level, as described in section 1.4 and in detail in the DR Customer Requirements Requirements Change Control Process [RD17]. Page 14 of 53

15 3. Interface Requirements Presentation In this section the Interface Requirements are grouped by the interface to which they relate, with a sub-section for each interface. Each sub-section contains all Interface Requirements related to that interface, irrespective of which of the involved systems has generated them, for example, the sub-section entitled TMS to ETCS Trackside contains both requirements placed on the ETCS Trackside by the TMS and requirements placed on the TMS by the ETCS Trackside. It should be noted that, in accordance with the architecture set out in [RD5], interlocking functions are considered to be within the scope of the ETCS Trackside. Therefore, interface requirements that relate to interfaces which would traditionally exist between the interlocking and another system are categorised in this document in the section that describes the interface between the ETCS Trackside and the relevant other system. There is no explicit requirement for interlocking and radio block centre functions to be performed on separate hardware. Requirements Elicitation The requirements in this document have been elicited through examination of the Interface Definition Document [RD5], the Basis of Design document [RD15] and consultation with the Lead Architects for each of the systems within the System of Systems. In addition, candidate requirements have been adopted and developed from the pre-existing system requirements suites for the systems where appropriate. The requirements creation principles set out in the Requirements Management Plan [RD14] have been employed during this process. There are some sections of this Specification which do not currently contain any requirements. It is envisaged that additional requirements will be identified to populate these sections in later versions of this Specification as the detail of each interface matures. At present, the requirements in this Specification do not define in detail the data which needs to pass over each interface, focusing at a higher level on the types of data which are expected to be passed over each interface in order to enable the functional requirements of the individual systems, and the System of Systems as a whole, to be delivered. A separate System of Systems Data Specification [RD18] is in development and deployment projects should consult this for further information in specifying data flows at the system interfaces. See also open point O7 in section 4.1. TMS to ETCS Trackside TMS to ETCS Trackside Functional Requirements The Traffic Management System (TMS) shall enable a user to activate emergency controls within the ETCS Trackside. TMS requirements v1.7.1 CRS-IR-6 To enable a quick response to an emergency. Page 15 of 53

16 The TMS user should be able to stop the movement of trains within their area of control in the event of an emergency. The ETCS Trackside should react to the emergency activation in a predetermined manner. The ETCS Trackside shall provide a complete set of "status of the railway" information which it holds to the Traffic Management System (TMS) when requested by the TMS as part of its initialisation process. CRS-IR-7 Conventional Principles When the TMS is initialised (either after planned work or following a restart), it needs to re-establish the status of the railway. The request will result in the ETCS Trackside sending all the required information as a stream of data. Having completed sending all the information, the ETCS Trackside should confirm that it has all been sent so that the TMS can resume normal operation. The Traffic Management System (TMS) shall enable a user to request the revocation of a Movement Authority (MA) by the ETCS Trackside. CRS-IR-8 ETCS Reference Design process Where required operationally, the signaller may be able to request that a movement authority is shortened if it will not lead to an immediate brake demand on the train. Each route origin will have a unique identity. The request will be made once. The ETCS Trackside will send the appropriate request to shorten the MA and if accepted by the train update the status reported for an MA from the route origin. The ETCS Trackside will not report the success or otherwise of the request since this can be deduced by the change in reported MA or not. It is assumed that if the change to the MA is reported in a suitable period of time that the TMS will send a route cancellation request to the ETCS Trackside to release that portion of the route originally reserved for the train but which is now beyond the end of the MA. The Traffic Management System (TMS) shall enable a user to request that the ETCS Trackside overrides an existing Movement Authority (MA). CRS-IR-9 ETCS Reference Design process In the event that communication is lost with a train, the status of the MA will not be updated. This will prevent routes and points being released. The signaller needs a facility, backed by robust operational rules, to instruct the system to assume that the MA is no longer in use. Page 16 of 53

17 Each route origin will have a unique identity. The request will be made once. The ETCS Trackside will attempt to send an MA update to the train and reset the status of the MA from that route origin. The Traffic Management System (TMS) shall be able to inform the ETCS Trackside of the details of a Temporary Speed Restriction (TSR) when it is to be applied to part of the network. CRS-IR-10 ETCS Reference Design process When a TSR is activated (either automatically or in response to signaller/planner input), the information needs to be made available to the ETCS Trackside. The TMS will supply the information to all affected ETCS Trackside and other systems. In the context of the Interface Requirements Specification a TSR means any speed reduction that needs to be imposed below the normal maximum permitted speed values over a part of the network. This is a broader definition of TSR than that used by the Rule Book and incorporates situations that the Rule Book describes by other terms such as Emergency Speed Restrictions. There needs to be a unified geographical model of the railway network shared by TMS, ETCS and other systems. Each restriction will apply to sections of line in the unified model. The speed restriction data will include a unique identity, the direction(s) to which it is applicable, whether it applies to the whole train or just the front and speed information in the same format as the static speed profile sent to the ETCS Onboard. Upon an initialisation request from the ETCS Trackside all active speed restrictions will be sent by the TMS. Since this is safety critical information, the TMS will repeat the information until acknowledged by the ETCS Trackside or the restriction no longer applies. The Traffic Management System (TMS) shall be able to revoke the application a Temporary Speed Restriction (TSR) by the ETCS Trackside. CRS-IR-11 ETCS Reference Design process When a TSR no longer applies, the ETCS Trackside needs to be instructed not to send it with future Movement Authorities (MAs). The revocation will use the same unique identity which was used to apply the speed restriction. The revocation request may instruct the ETCS Trackside to send updated MA to trains or to allow them to continue without update. The TMS will repeat the message until acknowledged by the ETCS Trackside. The Traffic Management System (TMS) shall enable a user to respond to requests to use SH mode received from the ETCS Trackside. CRS-IR-12 ETCS Reference Design process Page 17 of 53

18 When the signaller receives a request from a specific train to enter SH, they may respond with a rejection, a single authorisation or a multiple authorisation within a time period. The response will be referenced by the NID_ENGINE of the request. The response may be rejection, authorisation of one request or authorisation of all requests within a time period from the current time. The Traffic Management System (TMS) shall inform the ETCS Trackside of the obstruction status of predefined locations on the railway. CRS-IR-13 Interface Definition Document The signaller may operate a control to designate certain predefined locations as obstructed. These may include level crossings, tunnels, or other areas of risk. Each predefined obstruction will have a unique identity. The status of an obstruction may be clear, set (MA associated with degraded route allowed) or set (no MA allowed). Upon an initialisation request from ETCS Trackside the status of all obstruction controls needs to be reported by the TMS. The Traffic Management System (TMS) shall enable a user to instruct the ETCS Trackside to apply ETCS Track Condition parameters. CRS-IR-14 Interface Definition Document, ETCS Reference Design process, TMS v1.7.1 Requirements There may be situations where a track condition needs to be applied such as a traction current limit. The information needs to be made available to the ETCS Trackside. The TMS will supply the information to all affected ETCS Trackside and other systems. There needs to be a unified geographical model of the railway network shared by TMS, ETCS and other systems. Each condition will apply to sections of line in the unified model. The track condition data will include a unique identity, the sections of line to which it applies and the track condition data to be sent to trains when an MA is issued. Upon an initialisation request from ETCS Trackside all active track conditions will be sent. The track condition will be sent once. The Traffic Management System (TMS) shall enable a user to instruct the ETCS Trackside to stop applying ETCS Track Condition parameters. CRS-IR-15 Interface Definition Document, ETCS Reference Design process Page 18 of 53

19 When a track condition no longer applies, the ETCS Trackside needs to be instructed not to send it with future MA. The revocation will use the same unique identity which was used to apply the track condition. The message will be sent once. The Traffic Management System (TMS) shall enable a user to instruct the ETCS Trackside to revoke emergency stop messages. CRS-IR-16 ETCS Reference Design process Where the cancelling of routes, for instance following the operation of an emergency area stop control, leads to trains receiving emergency stop messages, the system needs to be able revoke the messages to allow train movements to resume. Consideration needs to be given as to whether this is dealt with on an individual train basis or for all trains within an area. See Open Point O2. The Traffic Management System (TMS) shall enable a user to send an emergency stop message to a specified train. CRS-IR-17 ETCS Reference Design process To enable the user to make a targeted intervention to stop a particular train without adversely impacting on other train movements in the vicinity, so these other trains can continue to operate safely. The request will identify the NID_ENGINE and TRN of the train. The request will be sent once. Once applied then the revocation message will be required. The Traffic Management System (TMS) shall inform the ETCS Trackside of a change to the Train Running Number of a specified train. CRS-IR-18 ETCS Reference Design process The automatic insertion of new train running numbers, as a result of the implementation of the current plan being managed by the TMS, needs to be communicated to the train. The message will contain a NID_ENGINE and the value of NID_OPERATIONAL to be sent to the train. The Traffic Management System (TMS) shall be able to request the ETCS Trackside to set routes. CRS-IR-19 Conventional Principles Page 19 of 53

20 To enable routes to be reserved for train movements, enabling the issue of Movement Authorities. Route setting requests may be generated automatically by the TMS arising from the current plan, or manually by the user. Route requests will identify the route origin and class of route requested. Each route (including alternative routes) and class of route needs a unique identity. The request will only be made once and the TMS should check that the request is likely to succeed before making it. The Traffic Management System (TMS) shall be able to request the ETCS Trackside to move points to specified positions. CRS-IR-20 Conventional Principles To enable the user (or the TMS automatically) to request that points are made available for route setting or moved to a specified position in which other requests that require the points in a different position are refused. The identity of the points needs to be unique. The request may for the points to be moved normal and held there, to be moved reverse and held there or that the points are free to be moved for route setting. Upon an initialisation request from the ETCS Trackside the status of all point controls needs to be reported. The Traffic Management System (TMS) shall be able to request the ETCS Trackside to cancel routes that have been previously set. CRS-IR-21 Conventional Principles, ETCS Reference Design process To enable the TMS (either acting automatically or in response to user input) to instruct any MA to be revoked from a route origin and the process of releasing the route to start (subject to satisfaction of approach locking conditions). Each route origin will have a unique identity. The request will be made once. The TMS may repeat the request if, after a period of time, it does not detect a response from the ETCS Trackside in the form of a change to the route set status. It is assumed that in the event of the signaller operating an emergency area stop control or the TMS detecting an unauthorised movement, that the TMS will generate a sequence of route cancellation requests. The Traffic Management System (TMS) shall be able to request the ETCS Trackside to enable a predefined shunting area. CRS-IR-22 ETCS Reference Design process Page 20 of 53

21 To enable protection for SH movements within the shunting area to be established and facilitate the automation of authorisation of requests to enter SH for trains within the shunting area. Shunt areas will have unique identities. Upon an initialisation request from IXL the request status of all shunt areas are to be reported. The request will be made once. The success of the request (or otherwise) will be via the shunt area status. The signaller can establish a shunting area subject to there being no conflicting routes. Once a shunting area is active, trains requesting SH will be authorised automatically. The request for a shunting area may cause points to be called for protection. The Traffic Management System (TMS) shall be able to request the ETCS Trackside to cancel an enabled predefined shunting area. CRS-IR-23 ETCS Reference Design process To enable the removal of protection for the shunting area when no longer needed for shunting purposes and make it available for other train movements. Shunt areas will have unique identities. The cancellation will be stored by the ETCS Trackside however there is no mechanism to send messages to trains which are not communicating (e.g. in SH). The success of the request (or otherwise) will be via the shunt area status. Operational processes will be needed to control the correct use and handback of shunting areas. The Traffic Management System (TMS) shall enable a user to operate level crossing controls within the ETCS Trackside. CRS-IR-24 Interface Definition Document Application-Specific To enable level crossings to be operated safely and in sufficient time to avoid delay to trains. These may include instructions to operate the crossing, to confirm that the crossing is clear, to cancel crossing operation. The instructions will be sent once. Some level crossing controls are routed directly from the TMS to the level crossing, whereas others are routed via the ETCS Trackside. This requirement relates to the latter case. The Traffic Management System (TMS) shall enable a user to request an override of specified locking conditions. CRS-IR-25 Interface Definition Document, ETCS Reference Design process Page 21 of 53

22 In the event of train detection failures, the system may not be able to release points or route locking and compare train detection status with reported train locations. The signaller needs to release route locking by overriding train detection faults and to override point locking. The TMS will apply controls, in conjunction with operational rules, to protect against this feature being applied in error. The request will refer to a single train detection section reporting occupied (in order to release route locking) or a set of points and their required position (to override train detection locking). The request will be sent once. The request will be rejected if there is an MA issued over the infrastructure (in the event that a train loses communication, then the MA override will allow the route to be released). The Traffic Management System (TMS) shall provide infrastructure information to the ETCS Trackside when requested by the ETCS Trackside as part of its initialisation process. CRS-IR-26 ETCS Reference Design process When the ETCS Trackside is initialised (either after planned work or following a restart) it needs to re-establish any dynamic controls such as temporary speed restrictions, marked obstructions, possession reminders and "point keys" before it can set routes and issue Movement Authorities. The request will result in the TMS sending all the required information as a stream of data. Having completed sending all the information, the TMS should confirm that it has all been sent so that the ETCS Trackside can resume normal operation. The ETCS Trackside shall inform the Traffic Management System (TMS) when a Movement Authority (MA) has been issued from a route origin. CRS-IR-27 Interface Definition Document, ETCS Reference Design process To enable the signaller to see when a movement authority has been issued which influences whether it is too late for a re-routing decision without affecting the train. The issue of an MA needs to be sent to TMS for display as required. Similarly when an MA is no longer issued (it has been returned by the train - e.g. co-operative shortening - the train has entered the route, or the system can assume it is no longer valid onboard) then the TMS needs to be updated. The information will be identified against a unique route origin. All changes in status need to be reported. Upon an initialisation request from TMS the status of all movement authorities needs to be reported. There does not appear to be a need for the route to which the MA applies or the mode profile to be shared, however the interface should allow for the route identity (e.g. KX123A(M) etc.) to be used instead of just the origin (e.g. KX123). Page 22 of 53

23 The ETCS Trackside shall provide the Traffic Management System (TMS) with a copy of each train position report it receives, referenced by the ETCS Train Running Number (TRN). CRS-IR-28 Interface Definition Document ETCS Reference Design process The signaller may need access to information about the speed and geographical location and mode of operation of a train. Traffic management algorithms may be able to use speed information for planning purposes. The ETCS TRN is supplied by the train as part of the validated train data. The ETCS Trackside needs to translate the NID_ENGINE into TRN before passing data to the TMS. The raw position report is based on a distance and direction from a balise group - either the ETCS Trackside needs to convert this information (combined with the positions of moveable infrastructure the train may have passed over) into a standard network location format or the TMS needs a balise map and undertake the conversion. Upon an initialisation request from TMS the last received position report from all trains needs to be reported. The ETCS Trackside shall provide the Traffic Management System (TMS) with an acknowledgement of each Temporary Speed Restriction (TSR) instruction received. CRS-IR-29 ETCS Reference Design process Since temporary restrictions are safety critical, the TMS needs to know that instructions to apply or revoke have been actioned. The ETCS Trackside will respond with the unique identity of the restriction supplied by TMS confirming the restriction has been applied or removed. The ETCS Trackside shall inform the Traffic Management System (TMS) of each request to enter SH received from a train that is not reporting a valid position inside an enabled shunt area. CRS-IR-30 ETCS Reference Design process If the ETCS Trackside receives a Shunt request from a train which does not have a valid position within a permanent or active temporary shunting area, the signaller can decide whether to authorise SH. The request will be referenced by both the NID_ENGINE and the TRN (if any). The request will be sent to TMS once. The ETCS Trackside shall inform the Traffic Management System (TMS) of its operational status. CRS-IR-31 Interface Definition Document Page 23 of 53

24 To enable the TMS user to maintain an awareness of the operational state of the ETCS Trackside. The user should be advised when an ETCS Trackside, or part thereof, is not available, when it is being initialised (i.e. collecting data from TMS, etc.) or when it is operating. The status should be repeated on a regular basis. Loss of reports indicates the ETCS Trackside is not available. The ETCS Trackside shall inform the Traffic Management System (TMS) of each request for a Movement Authority (MA) received from trains. CRS-IR-32 ETCS Reference Design process When a train undertakes Start of Mission or reaches the point where the existing MA requires the train to brake, the train starts to send MA requests. There may be locations where these requests can be used as a trigger for the TMS to take action automatically or to prompt the user to do so. Each route origin needs a unique identifier. The request will be sent each time an MA request is received from a train approaching defined route origins (Note this may lead to multiple requests for the same route origin). Examples of functions that trigger this could be used for include route setting or the initialisation of level crossings. The ETCS Trackside shall inform the Traffic Management System (TMS) of all changes in status of trackside train detection sections. CRS-IR-33 Conventional Principles TMS and its users need to know the state of train detection sections. The identity of the train detection section needs to be unique. The TM may combine this status with that of moveable infrastructure and set routes to avoid a "flood red" display. Upon an initialisation request from TMS the status of all train detection sections needs to be reported. The ETCS Trackside shall inform the Traffic Management System (TMS) of all changes in status of point ends. CRS-IR-34 Conventional Principles TMS and its users need to know the state of points. The identity of the points needs to be unique. Individual point ends should be reported individually even when under one control. Page 24 of 53

25 The status needs to include the required position, the detected position and whether the points are free for the required position to be changed. Upon an initialisation request from TMS the status of all point ends needs to be reported. The ETCS Trackside shall inform the Traffic Management System (TMS) of all changes in the status of route sections. CRS-IR-35 Conventional Principles TMS and its users need to know which routes have been set and locked. The identity of a route section needs to be the same as the train detection status with the addition of unique identifiers where there is moveable infrastructure in the section. The status is route not set or route set. Upon an initialisation request from TMS the status of all route sections needs to be reported. The ETCS Trackside shall inform the Traffic Management System (TMS) of the currently established flow direction for traffic on each bi-directional line. CRS-IR-36 Conventional Principles On lines which can be used in both directions the TMS user may need information on the direction which has been set. The TMS may also require the information to avoid a "Mexican standoff" conflict situation. The direction status may be over one or multiple routes - it is normally between junctions or locations when trains routinely reverse. All changes in status need to be reported. Upon an initialisation request from TMS all established direction statuses are to be reported. The ETCS Trackside shall inform the Traffic Management System (TMS) of all changes in the status of shunt areas. CRS-IR-37 Interface Definition Document, ETCS Reference Design process TMS and its users need to know which shunt areas are active. Shunt areas will have unique identities. Upon an initialisation request from TMS the status of all shunt areas are to be reported. Shunt Areas can be enabled at the request of the signaller to automate the authorisation of SH. A shunt area prevents routes being set in/out and locks points. Trains in SH do not communicate with the RBC and will not be reporting positions. Page 25 of 53

26 The ETCS Trackside shall inform the Traffic Management System (TMS) of the reported status of level crossings. CRS-IR-38 Interface Definition Document, ETCS Reference Design process TMS and its users need to know the status of level crossings for both normal and degraded operation. Each level crossing will have a unique identity. The information required will include whether the level crossing is operational (available or failed), the status of lights and barriers, etc. All changes in status need to be reported. Upon an initialisation request from TMS the status of all level crossings will be reported. The ETCS Trackside shall inform the Traffic Management System (TMS) of the status of all local control release functions. CRS-IR-39 Conventional Principles TMS and its users need to know whether a local control (e.g. a Ground Frame) is in use or locked in the normal position. Each local control unit will have a unique "release" identity (note that a single control may have several releases for parts of the control). The information required will be whether the local control has been released or whether it is locked in the normal state. All changes in status need to be reported. Upon an initialisation request from TMS the status of all local control releases is to be reported. The ETCS Trackside shall inform the Traffic Management System (TMS) of which routes are set from route origins. CRS-IR-40 Conventional Principles TMS and its users need to know whether a route has been set from a route origin and whether it is approach locked. Each route (including alternative routes) and class of route needs a unique identity. The status of each route can be "not set", "set and not approach locked", "set and approach locked", and "cancelled but approach locked". All changes in status need to be reported. Upon an initialisation request from TMS the status of all routes needs to be reported. Page 26 of 53

27 The ETCS Trackside shall inform the Traffic Management System (TMS) when Train Ready to Start (TRTS) devices have been operated, where these are provided. CRS-IR-86 Conventional Principles TMS and its users need to know when trains are ready to leave (typically from a journey origin point) and require a route to be set and movement authority issued. TRTS devices may be provided for the use of station, depot or yard staff or by train crew. They are typically found at major stations and at some depot exits. Their use supports the timely departure of trains whilst minimising the likelihood of infrastructure being prematurely reserved for the passage of a train which is not yet ready to depart. The TMS may use the operation of a TRTS device as a trigger for an automated response or alert the user to the operation of the device so that the user can take manual action TMS to ETCS Trackside Communication Requirements The interface between the Traffic Management System (TMS) and the ETCS Trackside shall be implemented using EULYNX Interface Specifications or interface specifications that can be migrated to the EULYNX Interface Specifications at a later date. Digital Railway System Authority CRS-IR-41 To enable the cost effective and timely migration to standardised, open interfaces between systems. EULYNX Interface Specifications can be obtained via the EULYNX consortium website The client will provide additional clarity on which optional elements need to be implemented for the generic GB application at a later date. See Open Point O3. TMS to Layered Information Exchange (LINX) This section includes all Interface Requirements that apply between the TMS and rail industry systems where information exchange takes place via LINX TMS to LINX Functional Requirements The Traffic Management System (TMS) shall publish real-time train service information to the Layered Information Exchange (LINX). TMS reference design, TMS requirements v1.7.1 CRS-IR-2 To enable external systems to provide train running information to their customers and staff. Page 27 of 53

28 The TMS will utilise information received from a variety of other business systems to generate train service information including train forecasts, current plan and train consist details. Customer Information Systems (CIS) could use this information to distribute tailored information to CIS displays and other digital customer channels. Real-time train service information is expected to include the following attributes: Unique train identifiers, scheduled calling points for each train, predicted arrival, passing and departure times at timing and calling points en route, train formation information, train orientation information, train loading information, train delay reason, planned calling platform/line. The Traffic Management System (TMS) shall interface with an Incident Management System (IMS) over the Layered Information Exchange (LINX) interface. CRS-IR-3 TMS reference design To enable the TMS to be alerted of an incident in order to prompt the replanning of the service. The IMS will be the master of incident related logs. The IMS should assign a unique log/incident identity to incidents. Incident Management System (IMS) log entries flagged as being relevant to the TMS should be sent to the TMS. These may include actions which the TMS or TMS user are expected to perform in order to support the management of the incident. The TMS should be able to inform the IMS, via LINX, of the outcomes of any actions placed upon it in this way. IMS Log entries that are flagged as being relevant to the TMS should have the following attributes associated with them: Unique TMS log entry identity, Unique IMS log identity, Area of control, User, Incident start time and date, Estimated/actual end time and date, Affected asset (where relevant), Affected train ID (where relevant), Description, Status. The Traffic Management System (TMS) shall interface with Stock and Crew Management systems over the Layered Information Exchange (LINX). CRS-IR-4 TMS requirements v1.7.1 To support the TMS decision making process and to support external systems to identify Stock and Crew conflicts. Stock and crew management systems may manage only stock or crew allocations or both. The TMS should be able to pass schedule and forecast information to, and receive stock and crew allocation data from, external stock and crew management systems. This information should be shared whenever there is a change. The TMS should acknowledge receipt of new or amended stock and crew allocation information to provide confidence that it will be acted upon. This should support the TMS user and TOC/FOC in make informed decisions based on the data provided. This could include train consist, crew availability and competence for the intended activity. Page 28 of 53

29 The Traffic Management System (TMS) shall be able to propose allocation changes to Stock and Crew Management systems, via the Layered Information Exchange (LINX), for agreement. CRS-IR-87 TMS requirements v1.7.1 and TMS Early Contractor Involvement To support the resolution of conflicts in a timely manner. Where the TMS identifies that changing the allocated stock or crew for a particular service would assist with resolving a conflict it should be possible for the TMS, via LINX, to propose an allocation change to the relevant Stock or Crew Management system. The Stock or Crew Management system should accept or reject the proposal, seeking user input as necessary in making the decision, and confirm the outcome, via LINX, to the TMS. The Traffic Management System (TMS) shall subscribe to national planning systems information over the Layered Information Exchange (LINX). CRS-IR-5 TMS requirements v1.7.1 To enable the TMS to acquire the planned timetable which it needs in order to deliver the plan. The Integrated Train Planning System (ITPS) will provide the long term plan (LTP), short term plan (STP) updates and some Very Short Term Plans (VSTP). The TMS also has the capability to create VSTP. The Traffic Management System (TMS) shall interface with a Temporary Speed Restriction (TSR) system over the Layered Information Exchange (LINX). CRS-IR-88 TMS requirements v1.7.1 To enable the TMS to both re-plan the service based on speed restriction information and make relevant speed restriction information available to the ETCS Trackside. The TMS may need to provide amended speed restriction information to the TSR system. The TSR system information should contain the following attributes for each speed restriction: a unique identity, start and end locations of the restriction, projected imposition and removal dates and times for the restriction, the directions in which the restriction applies and the maximum permitted speed within the restriction area for each train type. The Traffic Management System (TMS) shall interface with the Connected Driver Advisory System (C-DAS) over the Layered Information Exchange (LINX) interface. CRS-IR-42 TMS reference design, TMS requirements v1.7.1 To enable C-DAS to be provided with information to enable it to calculate driver advisory information and to enable C-DAS to inform TMS of the train's capabilities, all via LINX. Page 29 of 53

30 Any changes to operational data or train schedules should be made available by the TMS to external systems, including C-DAS. The TMS should respond to a request for updated operational data from a C-DAS system to support the consistency checks required within the C-DAS. The TMS should be able to receive reporting messages from the C-DAS server. The TMS should ignore any messages received from the C-DAS which are not relevant to operations in the TMS area or on the approaches to the TMS area. The TMS should be able to identify failure messages e.g. when the C-DAS onboard stops communicating with the C-DAS trackside. The Traffic Management System (TMS) shall publish train describer information to the Layered Information Exchange (LINX). CRS-IR-89 TMS requirements v1.7.1 To make train describer data available for other systems to consume. Train describer information should be provided in a format compatible with existing TD.net protocols. The train describer information should be updated as trains step between berths. At the boundary of a Traffic Management area, the Traffic Management System (TMS) shall interface with other train describer systems via the Layered Information Exchange (LINX). CRS-IR-85 TMS requirements v1.7.1 To reduce the manual processes associated at the interface between a TMS and adjacent legacy systems. The TMS should be capable of exchanging data with equipment located in yards, sidings and depots that are owned and /or operated by third parties in addition to fringe signal boxes. The legacy systems may need alteration to interface them with LINX but this is seen as the preferable approach as it preserves a standard interface for the TMS which will reduce the need to change the TMS at a later date when the legacy equipment at the fringe is replaced with another TMS. The Traffic Management System (TMS) shall interface with Business Information Systems (BISs) over the Layered Information Exchange (LINX) interface. CRS-IR-43 TMS reference design, TMS requirements v1.7.1 To avoid changes to the TMS when BISs are upgraded. LINX is designed as an information message transport system for information transfer between Network Rail internal systems and other external systems. The TMS will support message flows as a publisher of data and/or a subscriber to data provided by other systems. The LINX catalogue is a live document and interface configuration management will be required over the life of the TMS. BIS systems include, but are not limited to: CIF Manager, GENIUS, Web Gemini, TOPS, TRUST, TSIA, SMART, DRACAS, BPlan, CORPUS, and R2. Page 30 of 53

31 Information provided by the TMS should include Very Short Term Plan (VSTP), Cancellation and Significant Lateness (CaSL) information, current plan, and train paths. The Traffic Management System (TMS) shall have the capacity to support future Business Information Systems (BISs) over the Layered Information Exchange (LINX) interface. CRS-IR-44 TMS reference design It is anticipated that other applications will be developed requiring interfacing with the TMS. The LINX catalogue is a live document and interface configuration management will be required over the life of the TMS. The as yet undefined business systems will require the LINX catalogue to be updated to support the interface. Future BIS could include Station Management Systems, competence management systems for TMS users, rostering systems, maintenance management systems, Temporary Speed Restriction (TSR) management systems, and TAF/TAP applications. The Traffic Management System (TMS) shall publish any change to the state of the railway to the Layered Information Exchange (LINX). CRS-IR-45 TMS requirements v1.7.1 So that external systems have access to the most up to date information on the state of the railway. This will be available to external systems via LINX. Possession information, line blockage information, speed restrictions and infrastructure restrictions should be available to external systems to be utilised. Making all state of the railway information available, even if there is no immediate need for some elements of it, avoids the need for the TMS to be modified at a later date to provide additional items of information when new external systems and applications are developed. The Traffic Management System (TMS) shall subscribe to reference data services via the Layered Information Exchange (LINX). CRS-IR-46 TMS reference design, TMS requirements v1.7.1 So that the TMS has up to date information on the state of the railway to enable it to plan accordingly and perform route compatibility checks between trains and the infrastructure they are proposed to run over. The TMS should have access to the infrastructure capability (for example structure gauge and axle load information), operational geography, train characteristics and performance capabilities and other train planning reference data. These could include Bplan, CORPUS and other external systems. Page 31 of 53

32 The Traffic Management System (TMS) shall subscribe to network availability data services via the Layered Information Exchange (LINX). CRS-IR-47 TMS requirements v1.7.1 To enable the TMS to manage plans to operate trains. The TMS will require real-time information pertaining to restrictions, possessions and blockages to react to changes in the network. Constraints on the network should be combined with planned information to update TMS forecast timings and routes. The Traffic Management System (TMS) shall be able to accept or reject possession plans proposed by external systems via the Layered Information Exchange (LINX). CRS-IR-90 TMS requirements v1.7.1 To enable the TMS user to ensure that proposed possessions are consistent with the agreed access arrangements and will enable the agreed train service to be maintained during the possession period. The TMS user is likely to need the ability to simulate the effects of the proposed possession arrangements in order to reach a decision on whether or not to accept them. The interface between adjacent Traffic Management Systems (TMS) shall be implemented via the Layered Information Exchange (LINX). CRS-IR-84 TMS requirements v1.7.1 To support the consistent automation of tasks across TMS boundaries that might otherwise require manual procedures. This should support the application of Temporary Speed Restrictions (TSRs) across boundaries between ROCs and enable a pair of adjacent TMS to collaboratively resolve a cross-boundary conflict TMS to LINX Communications Requirements None identified in this version of the Interface Requirements Specification. It is expected that requirements will be added to this section in a later version of the Specification. TMS to Voice Communications Systems TMS to Voice Communications Systems Functional Requirements None identified in this version of the Interface Requirements Specification. It is expected that requirements will be added to this section in a later version of the Specification. Page 32 of 53

33 TMS to Voice Communications Systems Communications Requirements The Traffic Management System (TMS) shall interface with Unified Operational Telecommunications system (UOTS) over the computer telephony interface (CTI) link. TMS reference design, TMS requirements v1.7.1 CRS-IR-48 To replicate a subset of the functionality available on the telecommunications HMI. Operation of the CTI link is defined in the Fixed Terminal Subsystem IDD CTI- CSTA 04A05E Version 1.5. The TMS should notify and dynamically update the telecoms system with information on Areas of Control (AoC) assigned to user log on. Rerouting must cover both the presentation of incoming voice communications to the correct user, as well as access to the correct outgoing voice communications services for each user. The TMS should also be able to identify the location (e.g. level crossing) from which an incoming call/alert has been detected. The TMS should be able to identify from Unified Operational Telecoms System (UOTS) any trains or traction units which are not registered with the GSM-R network. The management of unregistered trains is covered in the GSM-R handbook, RS523 Issue 1. After a CTI link failure, the TMS should update the CTI with any changes that occurred during the failure period. TMS to Closed Circuit Television (CCTV) Systems TMS to CCTV Systems Functional Requirements The Traffic Management System (TMS) shall receive closed circuit television (CCTV) live streams from level crossings TMS requirements v1.7.1 CRS-IR-49 To enable the user to monitor remote level crossings where the user is required to visually confirm the level crossing is closed to, and clear of, road users before permitting trains to pass over the level crossing. Incorporation of these live streams into the TMS rather than as stand-alone displays will reduce the number of display monitors at the user s desk. The information should clearly identify the following information for a level crossing: 1) Type; 2) Name; 3) Location; 4) Status. Not all level crossings will have CCTV TMS to CCTV Systems Communications Requirements None identified in this version of the Interface Requirements Specification. It is expected that requirements will be added to this section in a later version of the Specification. Page 33 of 53

34 TMS to Supervisory Control and Data Acquisition (SCADA) Systems TMS to SCADA Functional Requirements The Traffic Management System (TMS) shall obtain traction power section status information via an interface with the Supervisory Control and Data Acquisition (SCADA) system. TMS requirements v1.7.1 CRS-IR-50 To be aware about the electrification status on the railway. The TMS HMI should be able to display the status of the traction power sections within their area of control (AoC). The information should indicate whether a traction power section is energised or not and could also include isolations, nature of isolation, limits of an isolation and the identity of Electric Control Room (ECR) dealing with the isolation TMS to SCADA Communications Requirements The interface protocol between TMS and SCADA is currently an open point (see open point O5 for more information). TMS to Trackside Objects The Traffic Management System (TMS) user shall have the ability to control level crossings where the level crossing controls are not routed via the ETCS Trackside. TMS requirements v1.7.1 CRS-IR-51 Application-Specific To enable the TMS to act as a mimic for level crossing controls. To allow flexibility of control of level crossings The TMS should interface with level crossing systems to control and monitor level crossings where this functionality is available in the level crossing. The TMS should clearly display to the user when they are in control of a level crossing. The TMS should also enable the user to locate the level crossing from which an incoming call/alert has originated. The TMS should also allow the user to control CCTV functions such as activation of wipers. Some level crossing controls are routed directly from the TMS to the level crossing, whereas others are routed via the ETCS Trackside. This requirement relates to the former case. The Traffic Management System (TMS) user shall have the ability to transfer all level crossing functions for a level crossing to local control. CRS-IR-52 TMS requirements v1.7.1 Page 34 of 53

35 Application-Specific To allow flexibility of control of level crossings. The TMS should clearly display to the user when they are not in control of a level crossing (for example, because it is under local control). A level crossing may need to be operated locally for a variety of reasons such as maintenance and engineering works. The local control should be able to receive train positioning data for trains approaching the level crossing. This reduces the dependency on the TMS user for notification that a train is approaching the level crossing. This will require the confidence that the data is valid and up to date. The Traffic Management System (TMS) shall interface with infrastructure based monitoring equipment. CRS-IR-54 TMS requirements v1.7.1 To acquire accurate and relevant status information from infrastructure monitoring systems and infrastructure based train monitoring systems. The TMS should be able to receive relevant infrastructure monitoring information from systems such as signalling power. The TMS should be able to receive information from monitoring system such as Hot Axle Bearing Detector (HABD), PanChex and Wheel Impact Load Detector (WILD) to ascertain train related faults and failures. ETCS Onboard to Key Management System (KMS) ETCS Onboard to KMS Functional Requirements Information shall be passed between the Key Management System and the ETCS Onboard containing a unique encrypted authentication key in accordance with CCS TSI without interruption to service. Interface Description Document CRS-IR-55 So that the data transmitted to and from the ETCS Onboard is securely protected without constraining when an updated authentication key may be provided. The generation of a new authentication key by the GB Key Management Centre and its transmission to an ETCS Onboard should not prevent the relevant train from operating normally if it is already in possession of a valid authentication key. The ETCS Onboard shall be capable of requesting and accepting encrypted authentication keys from the Key Management System. CRS-IR-56 Interface Description Document Page 35 of 53

36 To protect ETCS data communication if an authentication key has been compromised or has reached its end of validity period. Note that the ETCS Onboard should accept encrypted authentication keys received from the Key Management System regardless of whether or not the ETCS Onboard had requested their issue ETCS Onboard to KMS Communications Requirements The GSM-R network shall provide GPRS capability. System of Systems System Definition CRS-IR-57 The provision of GPRS capability enables online key management arrangements to be implemented between the KMS and ETCS Onboards. It will also be beneficial in enabling the GSM-R network to handle the ETCS Trackside to ETCS Onboard communications efficiently. ETCS Onboard to Onboard Voice Communications Systems ETCS Onboard to Onboard Voice Communications Systems Functional Requirements The ETCS Onboard shall be able to export the train running number (in both all numeric and the GB alphanumeric format) and driver ID to the Onboard Voice Communications System. EOSS CRS-IR-58 To eliminate the need for the driver to enter the same items of data into two different systems when undertaking start of mission. GERT8402 may be used as a reference to guide the design of the interface. GERT8402 also contains the GB notified national technical rules regarding the alphanumeric train running number format ETCS Onboard to Onboard Voice Communications Systems Communications Requirements None identified in this version of the Interface Requirements Specification. It is expected that requirements will be added to this section in a later version of the Specification. ETCS Onboard to Class B Train Protection Systems Safety information shall be passed between the GB Class B Protection System and the ETCS Onboard. CRS-IR-59 Page 36 of 53

37 EOSS The train needs to have an operational train protection system during normal operation to comply with the Railway Safety Regulations When operating on ETCS-fitted infrastructure this can be provided by the ETCS Onboard but when operating on non-etcs-fitted infrastructure this is provided by a Class B Protection system. The ETCS Onboard and Class B Protection systems will interact to ensure that only a train protection system compatible with the infrastructure over which the train is operating is active and that the commands and indications associated with that system are made accessible to the driver. The GB Class B (e.g. AWS/TPWS) can operate as a standalone system where seamless transition between Class B and ETCS is achieved. Alternatively, an STM FFFIS fully compliant to CCS TSI, in particular the Subset-035, can be implemented. For new-build vehicles, the option to integrate the driver interface within the DMI may make practical sense in order to optimise the driving cab layout. Cost Benefit Assessment for the integration of Class B displays and controls into the DMI should be conducted as Class B systems could be decommissioned in the future. Safety The GB Class B Protection System shall inform the ETCS Onboard of any failures, warnings or malfunctions that occur within the GB Class B Protection System. CRS-IR-60 EOSS So that the driver is made aware of a failed or malfunctioning of Class B system or ETCS Onboard before, or upon, the train transitioning from ETCS Level (i.e. 0, 1, 2, 3) to Level NTC. This requirement ensures that the AWS / TPWS is available for areas where the ETCS is unavailable and that the ETCS is operating for fitted areas, and it ensures that the driver cannot pass a transition believing incorrectly that protection is being provided. Safety The GB Class B Protection System shall not be suppressed by the ETCS Onboard when the train is operating in Levels NTC. CRS-IR-61 EOSS To ensure that the train has a working train protection system, and thus complies with the Train Protection Regulations, when operating on non-etcsfitted infrastructure. The GB Class B Protection System should be available in all permitted operating modes when the train is operating in Levels NTC. Page 37 of 53

38 The GB Class B Protection System shall be suppressed by the ETCS Onboard when operating in ETCS Levels 1-3. CRS-IR-62 EOSS To ensure that the train only has one working train protection system at a time. Trains may operate in areas in which the infrastructure is fitted with both ETCS and Class B equipment. Where this is the case the train should only respond to instructions from the trackside equipment relevant to the signalling system under which the train is operating in order to prevent spurious warnings or interventions which could distract the driver or impact on the movement of the train. ETCS Onboard to Other Onboard Systems ETCS Onboard to Other Onboard Systems Functional Requirements The ETCS Onboard shall enable data sharing with onboard systems. ENTOSS CRS-IR-63 To avoid multiple entry of the same type of information in the ETCS fitted train. Beyond the mandatory requirements of the CCS TSI and Baseline 3 specifications this is envisaged to include sharing with systems such as GNSS, train doors, train control management systems, etc ETCS Onboard to Other Onboard Systems Communications Requirements None identified in this version of the Interface Requirements Specification. It is expected that requirements will be added to this section in a later version of the Specification. ETCS Trackside to ETCS Onboard ETCS Trackside to ETCS Onboard Functional Requirements At a functional level, the ETCS Trackside to ETCS Onboard interface is entirely specified in the CCS TSI [RD11] and the associated Baseline 3 Release 2 ETCS specifications [RD12] issued by the European Union Agency for Railways. Consequently, no GB specific functional Interface Requirements are permitted for this interface. Page 38 of 53

39 ETCS Trackside to ETCS Onboard Communications Requirements The ETCS Onboard shall be compatible with an ETCS trackside with a system version of 2.1. CRS-IR-64 To achieve technical interoperability on the GB rail network where Baseline 3 Release 2, system version 2.1 has been chosen for future ETCS Trackside implementations. The ETCS Onboard compliant to CCS TSI will be able to manage highest system version implemented on the Trackside and previous system versions for backward compatibility where relevant (e.g. DMI will implement features of the CCS TSI, set of specifications #3). ETCS Trackside to KMS ETCS Trackside to KMS Functional Requirements Information shall be passed between the Key Management System and the ETCS Trackside containing a unique encrypted authentication key in accordance with UNISIG specifications without interruption to service. Interface Definition Document CRS-IR-65 So that the data transmitted to and from the ETCS Trackside is securely protected without constraining when an updated authentication key may be provided. The generation of a new authentication key by the GB Key Management Centre and its transmission to an ETCS Trackside should not prevent the relevant Radio Block Centre from operating normally if it is already in possession of a valid authentication key. When initialised, the ETCS Trackside shall request a full set of authentication keys from the KMS. CRS-IR-66 ETCS Reference Design process To enable the ETCS Trackside to communicate securely with ETCS Onboards. The ETCS Trackside needs to be in possession of a current set of all the required authentication keys before it can start to issue Movement Authorities. The KMS shall send authentication keys to the ETCS Trackside when they are created or in response to a request for them. CRS-IR-67 ETCS Reference Design process Page 39 of 53

40 To enable the ETCS Trackside to communicate securely with ETCS Onboards. The KMS shall instruct the ETCS Trackside to delete authentication keys which are no longer valid. CRS-IR-68 ETCS Reference Design process To maintain security by ensuring that the ETCS Trackside only retains valid keys. Keys may become invalid through expiry of their validity period or as a result of being revoked by the KMS ETCS Trackside to KMS Communications Requirements None identified in this version of the Interface Requirements Specification. It is expected that requirements will be added to this section in a later version of the Specification. ETCS Trackside to Trackside Worker Warning Systems ETCS Trackside to Trackside Worker Warning Systems Functional Requirements The ETCS Trackside shall inform Trackside Worker Warning Systems of all train positions in the area of interest to the Trackside Worker Warning Systems. Trackside Worker Warning Systems specification CRS-IR-69 So that the Trackside Worker Warning System knows the position of the train enabling it to provide warnings and protection to the trackside workers. Further information will be available from the relevant project ETCS Trackside to Trackside Worker Warning Systems Communications Requirements The interface between the ETCS Trackside and Trackside Worker Warning Systems shall be implemented using EULYNX Interface Specifications or interface specifications that can be migrated to EULYNX Interface Specifications at a later date. Digital Railway System Authority CRS-IR-70 To enable the cost effective and timely migration to standardised, open interfaces between systems. EULYNX Interface Specifications can be obtained via the EULYNX consortium website The client will provide additional clarity on which Page 40 of 53

41 C-DAS to LINX Reference NWR-SPE-ESE- optional elements need to be implemented for the generic GB application at a later date. See Open Point O3. This section includes all Interface Requirements that apply between the C-DAS and other rail industry systems where information exchange takes place via LINX C-DAS to LINX Functional Requirements The C-DAS shall obtain details of candidate train services from the Layered Information Exchange (LINX). C-DAS Exported Requirements (CEX-103) CRS-IR-71 So that the data C-DAS uses for advisory information calculations is the same as used by Traffic Management Traffic Management will provide a list of services to LINX that match the headcode being used. Content is Path ID, origin, destination and optional intermediate location. This may not be required if there is an alternative means to disambiguate / resolve headcode which doesn't require driver intervention or intelligence in the C-DAS Railway Undertaking sub-system. The C-DAS shall obtain planning data from the Layered Information Exchange (LINX). CRS-IR-72 C-DAS Exported Requirements (CEX-15) So that C-DAS has the planning data identified as necessary for the safe calculation of advisory, and the provision of non-advisory, information. Planning data can be any or all of Plans (VSTP), Schedules and Schedule Updates. This data is sent from Traffic Management to C-DAS via the LINX interface at start up and dynamically during the service. The data required includes: a. Schedule times at named locations at an appropriate granularity to support regulation on that part of the route. b. Running line for each part of the route covered by the planning data provided, described in relation to the Common Location Reference Frame. c. Timing Tolerances at Timing Points wherever Traffic Management is able to provide them. Timing Tolerances allow C-DAS to optimise speed profiles beyond what is possible if trains are constrained to achieve exact times. Timing Tolerances will always be limited by the published timetable. The C-DAS shall obtain details of all Temporary and Emergency Speed Restrictions from the Layered Information Exchange (LINX). CRS-IR-73 C-DAS Exported Requirements (CEX-114) Page 41 of 53

42 To provide C-DAS with speed restrictions which are consistent with those used by other systems within the SoS It is planned that the source of TSR and ESR data will be a Central Temporary Speed Restriction planning and implementation tool from which other systems will receive Speed Restriction data via LINX. The C-DAS shall obtain infrastructure geography information from the Layered Information Exchange (LINX). CRS-IR-74 C-DAS Exported Requirements (CEX-111) To ensure consistency in Traffic Management areas between C-DAS, Traffic Management and ETCS data by using the same infrastructure and static speed data sources for all systems. The Business System which will provide this data is the IM's Rail Infrastructure Network Model (RINM). It is expected that the RU will acquire this data from the IM infrequently (namely when there has been an update in the source data set) or periodically to ensure the integrity of the dataset is maintained. The C-DAS shall obtain static speed profiles from the Layered Information Exchange (LINX). CRS-IR-75 C-DAS Exported Requirements (CEX-111) To ensure consistency in Traffic Management areas between C-DAS, Traffic Management and ETCS data by using the same infrastructure and static speed data sources for all systems. The Business System which will provide this data is the IM's Rail Infrastructure Network Model (RINM). It is expected that the RU will acquire this data from the IM infrequently (namely when there has been an update in the source data set) or to ensure the integrity of the dataset is maintained. The C-DAS shall obtain train consist and capability information from the Layered Information Exchange (LINX). CRS-IR-76 C-DAS Exported Requirements (CEX-112) To ensure consistency between C-DAS, ETCS and (in Traffic Management areas) Traffic Management, by using the data for the same train type / ETCS Train Categories. The data is expected to be provided by an RU-owned business system using data assembled from consisting systems and the R2 system. The C-DAS Onboard will be expected to acquire this data - or to confirm validity of previously acquired data - at the start of each journey, and following any operation which affects train consist (split, join, freight load/unload) or train Page 42 of 53

43 performance capability (e.g. arising from defects). Reference NWR-SPE-ESE- Mid-journey updates to Train Specific data, or Train Specific data which cannot be made available from business systems will be notified by C-DAS to Traffic Management via LINX. Examples of such data might include changes to consist (as above) or change to orientation for a passenger train. The C-DAS shall obtain the path identifier for each train from the Layered Information Exchange (LINX). CRS-IR-77 C-DAS Exported Requirements (CEX-60a) To support correct routing of C-DAS messages to an individual train throughout its journey. Planning data can be any or all of Plans, Schedules and Schedule Updates, and may include VSTPs. The Path Identifier is allocated by NR's planning systems, and used in all C- DAS communications between a C-DAS Onboard and other systems, e.g. Traffic Management. The C-DAS shall export train forecasts to the Layered Information Exchange (LINX). CRS-IR-78 C-DAS System Definition To inform other systems of the result of C-DAS calculations and consequent train running forecasts, enabling those systems to use this information to refine their predictions. The C-DAS shall export train performance and capability information to the Layered Information Exchange (LINX). CRS-IR-79 C-DAS System Definition To inform other systems of the actual current performance capabilities of the train, enabling those systems to use this information to refine their predictions. Train performance information may be obtained automatically from other onboard systems or entered manually by the driver via the C-DAS HMI C-DAS to LINX Communications Requirements None identified in this version of the Interface Requirements Specification. It is expected that requirements will be added to this section in a later version of the Specification. Page 43 of 53

44 C-DAS to Other Onboard Systems C-DAS to Other Onboard Systems Functional Requirements The C-DAS shall obtain current location, speed and time information from other onboard systems. CRS-IR-80 C-DAS Exported Requirements (CEX-43) Application-Specific To improve the availability of location / speed / time information to the C-DAS Such a facility would be provided by an on-train locator external to the C-DAS Onboard (in contrast to the default locator which is generally (where there's good satellite visibility) internal to the C-DAS Onboard). This facility would be appropriate for use on routes with poor visibility of navigation satellites. It would also be appropriate in a future scenario where an external locator may be able to distinguish the current running line The C-DAS shall obtain train performance information from other onboard systems. CRS-IR-81 Application-Specific To improve the accuracy of forecasting calculations. Some trains may have train control management systems that are capable of exporting information about the current performance capability of the train which could be consumed by C-DAS, for example maximum permitted speed or reduced traction performance if not all motor groups are functioning normally C-DAS to Other Onboard Systems Communications Requirements None identified in this version of the Interface Requirements Specification. It is expected that requirements will be added to this section in a later version of the Specification. ETCS Trackside to ETCS Trackside ETCS Trackside to ETCS Trackside Functional Requirements Adjacent ETCS Trackside systems shall exchange state of the railway information relevant to the boundary between them. CRS-IR-91 To enable the safe and seamless movement of trains across the boundary between two ETCS Trackside systems. Information that will typically be exchanged in this way includes train detection section statuses, point statuses, route locking statuses, cross-boundary route requests, movement authority statuses, applied temporary speed restrictions. The cross-boundary view should be sufficient to enable trains to pass over the boundary at the maximum permitted speed when conditions permit this. Page 44 of 53

45 ETCS Trackside to ETCS Trackside Communications Requirements The interface between two adjacent ETCS Tracksides shall be implemented using EULYNX Interface Specifications or interface specifications that can be migrated to EULYNX Interface Specifications at a later date. Digital Railway System Authority CRS-IR-82 To enable the cost effective and timely migration to standardised, open interfaces between systems. EULYNX Interface Specifications can be obtained via the EULYNX consortium website The client will provide additional clarity on which optional elements need to be implemented for the generic GB application at a later date. See Open Point O3. ETCS Trackside to Trackside CCS Objects ETCS Trackside to Trackside CCS Objects Functional Requirements None identified in this version of the Interface Requirements Specification. It is expected that requirements will be added to this section in a later version of the Specification ETCS Trackside to Trackside CCS Objects Communications Requirements The interface between Trackside CCS Objects shall be implemented using EULYNX Interface Specifications or interface specifications that can be migrated to EULYNX Interface Specifications at a later date. Digital Railway System Authority CRS-IR-83 To enable the cost effective and timely migration to standardised, open interfaces between systems. EULYNX Interface Specifications can be obtained via the EULYNX consortium website The client will provide additional clarity on which optional elements need to be implemented for the generic GB application at a later date. See Open Point O3. ETCS Trackside to Adjacent Interlocking (non-etcs) An ETCS Trackside system and an adjacent non-etcs interlocking shall exchange state of the railway information relevant to the boundary between them. CRS-IR-92 Page 45 of 53

46 To enable the safe and seamless movement of trains across the boundary between the ETCS-fitted and non-etcs-fitted areas (in either direction). Information that will typically be exchanged in this way includes train detection section statuses, point statuses, route locking statuses, cross-boundary route requests, movement authority statuses, signal aspects, applied temporary speed restrictions. The cross-boundary view should be sufficient to enable trains to pass over the boundary at the maximum permitted speed when conditions permit this. Page 46 of 53

47 4. Associated Information Open Points The open points for this generic Interface Requirements Specification are tabulated in Table 1 below. Table 1 Open Points Number Issue Description Identified in Version Closed in Version O1 ETCS National Values source When the radio block centre functions of the ETCS Trackside are initialized they will need to acquire the applicable sets of ETCS National Values for the areas being controlled (e.g. by requesting them by NID_C value). It is unclear where the ETCS Trackside will acquire the ETCS National Values from. 0.1 O2 Revocation of Emergency Stop messages Where ETCS Emergency Stop messages have been used, they will need to be revoked before train movements can resume. Consideration needs to be given as to whether this should be achieved for each train individually (addressing them by train identity) or by removing them for all trains in a particular area simultaneously. 0.1 O3 EULYNX Interface Specifications The EULYNX Interface Specifications are designed to cater for the needs of a range of European Infrastructure Managers and contain both default (mandatory) and optional elements. For some EULYNX Interface Specifications Network Rail has already determined which optional elements are required but, for others, further work is needed to determine this and will be included in a later specification. 0.1 O4 Safety Integrity Levels (SIL) The SIL applicable to any particular function within the System of Systems has not yet been conclusively determined. Consequently, the SIL necessary for any particular data exchange between systems to enable 0.2 Page 47 of 53

48 Number Issue Description Identified in Version Closed in Version those functions to be performed has also not yet been determined. Once SIL has been determined there may be a need for additional requirements for some interfaces to support high integrity data exchange. O5 TMS to SCADA interface There needs to be a common interface protocol to enable multiple TMS to communicate with Network Rail s SCADA system. The detail of this has not yet been defined. 0.2 O6 LINX Service Catalogue The adequacy of the existing LINX service catalogue to support all of the data services required by this specification has not yet been assessed and a review is required to determine whether any additional data services need to be added to the catalogue. 0.2 O7 Detailed definition of interface characteristics This document focuses on identifying the interfaces that are needed and they key data attributes that need to be exchanged, or functions performed, at those interfaces. Detailed definitions of data formats or Form, Fit and Function Interface Specifications for some of these interfaces do not yet exist and will be developed at a later date. This will include detailed data specifications where appropriate. 0.2 Assumptions The assumptions made in connection with this generic Interface Requirements Specification are tabulated in Table 2 below. Table 2 Assumptions Number Issue Assumption Identified in Version Closed in Version A1 Message Brokers That LINX will be used as the message broker for all deployment projects. 0.1 A2 TMS to ETCS Trackside The TMS to ETCS Trackside interface potentially comprises two parts; TMS 0.2 Page 48 of 53

49 Number Issue Assumption Identified in Version Closed in Version Interface to Radio Block Centre (RBC) and TMS to Interlocking. It is assumed that both of these parts are covered by EULYNX Interface Specifications. Dependencies The dependencies associated with this generic Interface Requirements Specification are tabulated in Table 3 below. Table 3 Dependencies Number Issue Dependency None identified Constraints The constraints associated with this generic Interface Requirements Specification are tabulated in Table 4 below. Table 4 Constraints Number Issue Constraint None identified Page 49 of 53

50 APPLICABILITY ASSESSMENT TEMPLATE A.1 Guidance on Populating the Template A deployment project wishing to record the results of their applicability assessment should copy this template into a new deployment project-specific document for population. Insert project name into the relevant box near the top of the template. For each Interface Requirement, insert the word Yes in the Applicable box if the issue or subject addressed by the requirement is relevant to the deployment project in question. If the interface addressed by a requirement is not relevant to the deployment project in question insert the word No in the Applicable box. A.2 Feedback Deployment projects are requested to send copies of their populated Applicability Assessment Templates to the Digital Railway System Requirements and Integration team. This will enable the team to assess the value that the industry is deriving from the Application-Specific requirements and will support future improvements to the generic Interface Requirements Specification. A.3 Template Deployment Project Applicability Assessment of GB Generic Interface Requirements Specification Deployment Project Name Requirement ID Interface Status Applicable Page 50 of 53

51 NEW INTERFACE REQUIREMENTS TEMPLATE B.1 Guidance on Populating the Template A deployment project wishing to draft new Interface Requirements should copy this template into a new deployment project-specific document for population. New requirements should not be added to this appendix of the generic Interface Requirements Specification itself. Text in italics prefixed GN forms guidance for the user of this template and should be deleted by the template user before publishing the new requirement(s) generated. Further guidance may be found in the Customer Requirements Specifications Requirements Management Plan [RD14]. B.2 Feedback Deployment projects are requested to send copies of any additional Interface Requirements generated to the Digital Railway System Requirements and Integration team. This will enable the team to identify future improvements to the generic Interface Requirements Specification. B.3 Template Safety The requirement text goes here. GN: It must be a clear, concise and unambiguous statement of what is required. It must include the word shall. Source statement goes here. Unique-Identifier GN: This is a statement which identifies where the requirement originated to provide traceability of requirement s origin. This could include references to a Concept of Operations, System of Systems Customer Requirements Specification, hazard record, or other document that sets out a high-level expression of what this system needs to achieve. or Application-Specific. GN: This will be Application-Specific unless this template is being used to propose a change to the generic Interface Requirements Specification in accordance with the change process set out in section 1.4. Rationale statement goes here. GN: This explains why the requirement is needed and its application, including why the requirement exists, who it is for, what industry benefit could be achieved, what the constraints are, and any other essential detail. Cross-referencing to other documentation to avoid the need for lengthy explanations is acceptable. Guidance statement goes here. Page 51 of 53

52 GN: The guidance statement contains any supplementary information that may be of value in assisting with the interpretation of the requirement or in determining how the requirement could be satisfied. Page 52 of 53