European Train Control System: The Management of Packet 44

Transcription

1 European Train Control System: The Management of Packet 44 Synopsis This document mandates the manner in which the packet 44 of the European Train Control System data protocol shall be managed to ensure safety and interworking. Signatures removed from electronic version Submitted by Jonathan Ronda Standards Project Manager Authorised by Anne E Blakeney Acting Controller, s This document is the property of Railway Safety. It shall not be reproduced in whole or in part without the written permission of the Controller, s, Railway Safety. Published by: Railway Safety Evergreen House 160 Euston Road London NW1 2DX Copyright 2003 Railway Safety

2 This page has been left blank intentionally

3 Page 1 of 21 Contents Section Description Page Part A A1 Issue record 2 A2 Implementation of this document 2 A3 Scope of s 2 A4 Responsibilities 2 A5 Health and safety responsibilities 2 A6 Technical content 2 A7 Supply 3 Part B B1 Purpose 5 B2 Application of this document 5 B3 Definitions 6 B4 Introduction 7 B5 ETCS requirements 10 B6 The structure of UK packet B7 Approved values of NID_UKSYSn 14 B8 Registering packet 44 protocols 14 B9 Modifications to published protocols 15 B10 Management support requirements 15 Appendices A The use of NID_C and NID_BG in the United Kingdom 17 B NID_UKSYS Allocations 18 C Example application form for a value of NID_UKSYS 19 Figures B4.4 a) ETCS message structure 8 Tables B4.5 a) Format of eurobalise telegrams 9 B6.1 The structure of UK packet References 21 RAILWAY SAFETY 1

4 Page 2 of 21 A1 Issue record Part A Issue Date Comments One April 2003 Original Document This document will be updated when necessary by distribution of a complete replacement. A2 Implementation of this document The publication date of this document is 5 April This document comes into force on 7 June The dates by which compliance with the requirements of this document is to be achieved are set out in Part B2. Where those dates are later than the date on which this document comes into force, this is to give Railway Group members additional time to plan and commence implementation so as to achieve full compliance by the dates set out in Part B2. This document does not supersede any other s. A3 Scope of Railway Group Standards A4 Responsibilities The overall scope of s is set out in Appendix A of GA/RT6001. The specific scope of this document is set out in Part B2. s are mandatory on all members of the Railway Group* and apply to all relevant activities that fall into the scope of each individual s Railway Safety Case. If any of those activities are performed by a contractor, the contractor s obligation in respect of s is determined by the terms of the contract between the respective parties. Where a contractor is a duty holder of a Railway Safety Case then s apply directly to the activities described in the Safety Case. * The Railway Group comprises Network Rail Infrastructure Limited, Railway Safety, and the train and station operators who hold railway safety cases for operation on or related to infrastructure controlled by Network Rail Infrastructure Limited. Network Rail Infrastructure Limited is known as Network Rail. A5 Health and safety responsibilities A6 Technical content In issuing this document, Railway Safety makes no warranties, express or implied, that compliance with all or any documents published by Railway Safety is sufficient on its own to ensure safe systems of work or operation. Each user is reminded of its own responsibilities to ensure health and safety at work and its individual duties under health and safety legislation. The technical content of this document has been approved by: Jeff Allan, Principal Signalling & Telecomms Engineer, Railway Safety. Enquiries should be directed to Railway Safety Tel: RAILWAY SAFETY

5 Page 3 of 21 A7 Supply Controlled and uncontrolled copies of this document may be obtained from the Industry Safety Liaison Dept, Railway Safety, Evergreen House, 160 Euston Road, London NW1 2DX. RAILWAY SAFETY 3

6 Page 4 of 21 This page has been left blank intentionally 4 RAILWAY SAFETY

7 Page 5 of 21 B1 Purpose B2 Application of this document Part B This document mandates the manner in which the packet 44 of the European Train Control System data protocol shall be managed to ensure safety and interworking. B2.1 To whom the requirements apply This document contains requirements that are applicable to Railway Safety and duty holders of the following categories of Railway Safety Case: a) infrastructure controller b) train operator. B2.2 Compliance requirements The document applies to the uses of packet 44 that meet at least one of the following criteria: a) Use during commercial service, at the trackside or on a train, over any line operated by the infrastructure controller b) Use that does not concern commercial service; but the management of the application requires the infrastructure controller and the train operator(s) receiving and transmitting data to cooperate, for example on the chainage of a balise, or the combination of data packets within a single balise group. B2.2.1 Infrastructure The requirements of this document are applicable to all uses of packet 44 as set out in section B2.2 and shall be complied with by the infrastructure controller no later than 7 June B2.2.2 Trains The requirements of this document are applicable to all uses of packet 44 as set out in section B2.2 and shall be complied with by train operators no later than 7 June B2.2.3 Railway Safety The requirements of this document (sections B8 and B10.2) shall be complied with by Railway Safety no later than 7 June B2.2.4 General compliance requirements After the compliance date[s], or after the date by which compliance is achieved (if earlier), Railway Group members shall not deviate from the requirements set out in this document. Where it is considered not reasonably practicable to comply with the requirements set out in this document, authorisation not to comply shall be sought in accordance with GA/RT6001, GA/RT6004 or GA/RT6006. B2.3 Exclusions from the application of this document B2.3.1 Transmission facilities that are not part of the ETCS This document does not apply to data transmission by means that are not part of the European Train Control System (ETCS). The data transmission arrangements that are included in the ETCS are set out in the Commission Decision 2001/260/EC. B2.3.2 Packet 44 applications that concern one Railway Group member This document does not apply to applications of packet 44 which concern only one Railway Group member. Such use of packet 44 shall meet the following criteria: RAILWAY SAFETY 5

8 Page 6 of 21 a) be exclusive to the needs of the Railway Group member concerned (for example surveying points, depot functions) b) be physically and managerially independent of other Railway Group members c) have no implications for: i) trains operating in commercial service ii) traffic control of the infrastructure controller s network Applications of packet 44 which fall into the above category, and where eurobalise is the chosen form of transmission, shall not be included in eurobalises which are subject to the requirements of this document. For these applications, the Railway Group member concerned shall have obtained from the mandated authority, the Union Internationale des Chemins de Fer (UIC), a specific user identity. B2.3.3 The Tilt Authorisation and Speed Supervision system The Tilt Authorisation and Speed Supervision (TASS) system is excluded from the specific requirements set out in section B6.5, because it predates this document. If the protocol for this application is modified in the future then it shall be made to conform to all the requirements of this document. B2.4 Related requirements in other documents The documents listed in the Commission Decision 2001/260/EC, and any subsequent amendments that are in future be promulgated in the Official Journal of the European Union, set out the requirements of the ETCS environment within which packet 44 is used. B3 Definitions Commercial service Any train service, except those for which the operator's obligations concern the public and non-railway organisations only as neighbours or intruders, and which do not operate in the presence of any other service. European Rail Traffic Management System The European Rail Traffic Management System (ERTMS) is a system consisting of the European Train Control System (ETCS), Global System for Mobile Communications - Railway (GSM-R), European Traffic Management Layer (ETML) and the set of interoperability operating rules. Message An identifiable string of data from a known source whose composition follows a strictly applied syntax. It is composed of packets of data. It can be composed of more than one telegram. Packet Data with a particular functional objective that is defined by the packet identity. Packets cannot be split between one or more successive telegrams. Parameter An element of a message which has a value. Specific transmission module A specific transmission module (STM) is a part of the ETCS that processes packet 44 messages onboard a train. It can be an integral part of an ETCS module or an external module that meets standardised interface requirements to the ETCS. Specific transmission modules can provide a data transmission channel that is not part of the ETCS. Telegram An identifiable string of data from a single spot transmission device. 6 RAILWAY SAFETY

9 Page 7 of 21 User identity The user identity of a packet 44 application is that user who is responsible for the management of the protocol of that application. This is defined by the parameter NID_XUSER in the data message. B4 Introduction (This section of the document provides a descriptive overview of the system. The mandatory requirements of the document are provided in sections B5 to B10 inclusive) B4.1 Background B4.1.1 Within ERTMS the ETCS provides communication channels between trackside and trainborne equipment. These channels are subject to the requirements of the European Union s interoperability directives. Other systems also require communication channels. A facility has been included in the ETCS to pass messages other than those required by the ETCS. Packet 44 is the means to transmit data for national applications between train and track and vice versa, using the data transmission facilities included within the ETCS. It is available for use by all Railway Group members. Such data messages are identified by being contained in data packets which include the packet identifier (NID_PACKET) 44. These packet 44 applications are not subject to the requirements of interoperability legislation. Therefore, when they are identified by ETCS the data is not processed by the interoperable elements of ETCS, but by a specific transmission module. Specific transmission modules are either independent units connected to the interoperable ETCS onboard equipment (external STM), or independent hardware and/or software modules incorporated within the ETCS hardware (internal STM). Within each packet 44, there is an identifier (NID_XUSER) to indicate the organising body responsible for the management of that packet. The value of this identifier is allocated by the mandated authority, the International Union of Railways (UIC, Union Internationale des Chemins de Fer), in accordance with the Commission Decision 2001/260/EC. The document Values of Variables Controlled by UIC version 2.01, which is published by the UIC, contains lists of values of all the ETCS variables which require allocation by the UIC. This document shows that the value of NID_XUSER allocated to Railway Safety to be in binary, that is 9 in decimal. A Railway Group member with a use for packet 44 that is exclusive to its own needs (for example surveying points, depot functions) as set out in section B2.3.2 is able to apply to the UIC for another value of the parameter NID_XUSER. B4.2 Safety and interworking matters The effective use of packet 44 requires that each application is defined and implemented with rigour and discipline. The safety and interworking of packet 44 requires attention to the following: a) compliance with the ETCS message syntax b) compliance with the packet 44 message syntax, as defined in this document c) compliance with all ETCS and packet 44 parameter definitions to avoid interference between applications d) safety during data changes, as set out in GE/RT8039 e) whole life system management. RAILWAY SAFETY 7

10 Page 8 of 21 B4.3 Parameter values All values stated in this document are in decimal unless otherwise stated. B4.4 ETCS message structure The ETCS message structure applied to each type of data transmission included in the ETCS is shown in figure B4.4a). MESSAGE HEADER 1 P H 1 st Packet Data 2 P H 2 nd Packet Data n P H n th Packet Data n+1 P H (n+1) th Packet Data E Figure B4.4 a): ETCS message structure NOTES: 1. n = n th Packet sequence within the message comprised of its header (PH) and its data. A packet can have any specified identity. 2. E = the End of Information identifier, Packet 255. (Not required for radio transmission.) 3. A message can contain zero packets, for example the message header and the end of message identifier only, or one or more packets. 4. Where the form of transmission is by Eurobalise, the message can be composed of one or more telegrams, one each from successive balises. B4.5 Eurobalise telegram structure The ETCS balise telegram structure is set out in the documents listed in the Commission Decision 2001/260/EC. This is repeated here in table B4.5 a) together with the parameters making up the message. NID_C identifies the network upon which the train is operating. When complemented by NID_BG the two together provide a unique balise group identity. Values of NID_C are allocated to railway administrations of individual member states by the UIC. The use of these parameters, NID_C and NID_BG, require national management. The requirements on these in respect of packet 44 are set out in section B5.3. The message structures for transmission by loop or radio media are similar, but there are no parameters requiring national management. 8 RAILWAY SAFETY

11 Page 9 of 21 FIELD NO. PARAMETER LENGTH (BITS) REMARKS 1 Q_UPDOWN 1 Defines the direction of the information: Down-link telegram (train to track) (0) Up-link telegram (track to train) (1) 2 M_VERSION 7 Version of the ERTMS/ETCS language 3 N_PIG 3 Position in the group. Defines the position of the balise in the balise group 4 N_TOTAL 3 Total number of balises in the balise group 5 M_DUP 2 Used to indicate whether the information of the balise is a duplicate of the balise before or after this one 6 M_MCOUNT 8 Telegram counter (M_MCOUNT) - 8 bits. To enable detection of a change of balise group message during passage of the balise group 7 NID_C 10 Country or region (for ERTMS compatibility) 8 NID_BG 14 Identity of the balise group 9 Q_LINK 1 Marks the balise group as linked (Q_LINK = 1) or unlinked (Q_LINK = 0) Variable Information Variable Successive packets of data. Last none 8 Packet 255. Table B4.5 a): Format of Eurobalise telegrams NOTES: 1. Number of bits in the balise header equals The Eurobalise telegram ends with packet 255 End of Information. RAILWAY SAFETY 9

12 Page 10 of 21 B5 ETCS requirements B5.1 Application of ETCS principles Railway Group members shall apply the ETCS principles set out in this section to their use of packet 44. B5.2 Transmission media Balise, loop or radio transmission shall be used for United Kingdom (UK) applications of ETCS packet 44, in accordance with the Commission Decision 2001/260/EC, where required by the Directives for Interoperability 1996/48/EC and 2001/16/EC. It is permissible for the infrastructure controller to apply this requirement to other uses of packet 44. B5.3 Use of ETCS message headers and message structures The Commission Decision 2001/260/EC shall be applied to all parameters in the ETCS header of UK packet 44 telegrams, whether from track-to-train or train-to track, as is applicable to radio, balise and loop transmission. B5.4 Values for NID_C and NID_BG The infrastructure controller shall have in place, and manage, a process that sets out how the UIC allocated values are to be used for NID_C, the country identifier for balise groups, and NID_BG, the balise group identifier, for packet 44 applications. These values shall be consistent with the national requirements for the application of ETCS. Railway Group members shall not deviate from the values allocated by the infrastructure controller. Appendix A sets out the values allocated at the publication of this document. B5.5 ETCS parameters and packet 44 applications Where a packet 44 application requires a parameter that is already specified for the purposes of ETCS, and its specification is also that required for the packet 44 application, then the ETCS parameter shall normally be proposed. It is permissible for the applicant to propose and justify an alternative packet 44 parameter as set out in section B8. Where the proposal is accepted, the application safety case shall include the measures taken to ensure that parameters of the same meaning, but generated independently, cannot acquire incompatible values. Reasons to adopt an alternative packet 44 parameter include, but are not limited to, differences in the attributes set out in section B6.2, for example bit structure, dynamic range and resolution. B5.6 ETCS messages and packet 44 applications Where a packet 44 application includes a message that is already specified for the purposes of ETCS, and its specification is also that required for the packet 44 application, then the ETCS message shall normally be proposed. It is permissible for the applicant to propose and justify an alternative packet 44 message as set out in section B8. Where the proposal is accepted, the application safety case shall include the measures taken to ensure that parameters of the same meaning, but generated independently, cannot acquire incompatible values. Reasons to adopt an alternative packet 44 message include, but are not limited to, the arrangements to manage the application through its life cycle. B6 The structure of UK packet 44 B6.1 Structure When NID_PACKET equals 44 and NID_XUSER equals 9, Railway Group members shall ensure that the content of the packet from NID_PACKET onwards conforms to that set out in table B RAILWAY SAFETY

13 Page 11 of 21 PARAMETER LENGTH (BITS) VALUE(S) COMMENT Binary Decimal NID_PACKET Identifies packet Q_DIR Identifies the direction of movement 10 2 for which the packet is valid L_PACKET NID_XUSER NID_UKSYS 8 Total length of packet, including header (number of bits). Identifies Railway Safety in their role as custodian of Railway Group Standards, and indicates that this to control the application. Identifies the UK application. NID_UKSYS2 8 NID_UKSYSn 8 T_UKSTART 8 T_UKSTART2 8 T_UKSTARTn 8 T_UKFINISH 8 T_UKFINISH2 8 T_UKFINISHn 8 Variable Not to be used. Allocated to TASS. Allocated to TASS. Allocated to TASS. Allocated to TPWS-E. Not yet allocated. Not yet allocated. Not yet allocated. next 8 bits = NID_UKSYS2. Same function as NID_UKSYS, but only present if NID_UKSYS = = Same function as NID_UKSYS, but only present if NID_UKSYS(n-1) = = Not restricted. next 8 bits = T_UKSTART2. Same function as T_UKSTART, but only present if T_UKSTART = = Same function as T_UKSTART, but only present if T_UKSTART(n-1) = = Not restricted. next 8 bits = T_UKFINISH2. Same function as T_UKFINISH, but only present if T_UKFINISH = = Same function as T_UKFINISH, but only present if T_UKFINISH(n-1) = = Other data, as specified by NID_UKSYS. Table B6.1: The structure of UK packet 44 RAILWAY SAFETY 11

14 Page 12 of 21 NOTES: 1. Parameters 5 and above are application dependent. 2. Each variable is quoted in the third column in binary, with the most significant bit (msb) first and the least significant bit (lsb) last; for example, an eight bit variable is given in the form b7, b6, b5, b4, b3, b2, b1, b0. These are given in groups of four bits, for ease of reading and for ease of comparison with hexadecimal notation. 3. The fourth column contains the decimal equivalent of the binary number in the third column. 4. The values of NID_PACKET, Q_DIR, L_PACKET, and NIDXUSER are set out in the documents listed in the Commission Decision 2001/260/EC. 5. Three dots in any of these columns are used to indicate that all intervening values have the same meaning allocated as the preceding and succeeding values. B6.2 Written descriptions Specifications of packet 44 parameters and messages shall be written in the format used in the specifications set out in Commission Decision 01/260/EC. In each case, the supporting parameters shall be specified by their bit structure, dynamic range and resolution. B6.3 Length of packet 44 The length of the UK packet 44 shall be calculated from the maximum logical length of packet 44 including all header bits, as determined by L_PACKET. The transmission arrangements determine the maximum number of bits available, from which shall be deducted as applicable: a) i) the ETCS balise header, or ii) the ETCS loop header, or iii) the ETCS radio header, whose length, track-to-train and train-to-track, is variable. b) the packet 255. The length of these headers is set out in Commission Decision 01/260/EC. The length of the UK packet 44 header as set out in this document is a minimum of 56 bits. B6.4 Description of variables in the packet 44 header Railway Group members shall assign the meanings below to the parameters making-up the packet 44 header defined in table B6.1. No other meaning shall be specified. Where NID_PACKET and NID_XUSER are within the scope of this document, the other parameters in the header shall also comply with the requirements of this document. The parameters in the header shall have only the values allowed by this document. a) NID_PACKET This parameter identifies the application as not controlled by ETCS when it equals 44. The application shall be voluntarily subject to interoperability considerations. b) Q_DIR When the data is received by balise transmission, this indicates the block direction to which the data applies. The meanings are: 12 RAILWAY SAFETY

15 Page 13 of 21 i) decimal value 0, reverse ii) iii) iv) decimal value 1, normal decimal value 2, both decimal value 3, not used. c) L_PACKET This is the length of the packet, including the header, in bits d) NID_XUSER NID_XUSER is allocated by the mandated authority as set out in section B It provides the user identity of a packet 44 message Applications of packet 44 shall have the value of NID_XUSER equal to '9', unless the exclusions set out in section B2.2.3 apply e) NID_UKSYS, UKSYS2 to UKSYSn Railway Safety shall allocate the NID_UKSYS parameter. After the value 254 has been allocated, the value 255 shall be used to indicate that the parameter NID_UKSYS2 is in use; and so on through the NID_UKSYSn. This parameter is defined in this manner so that the number of uses is unlimited. This parameter identifies the use and the Railway Group members involved. Each use shall be supported by a detailed specification of the messages and parameters concerned. Railway Safety shall publish these details as set out in section B8.4. The specific values of NID_UKSYS =1, 2 and 3 are allocated to the TASS application. B6.5 Packet validity data T_UKSTART, T_UKSTART2 to T_UKSTARTn T_UKFINISH, T_UKFINISH2 to T_UKFINISHn Railway Group members shall provide these parameters as part of the message to ensure that data changes are carries out safely. This technique allows a commissioning date to be amended without the need to re-programme balises. The variables indicate that the contents of the current packet are not be used before T_UKSTART, which represents a date including time, or after T_UKFINISH, which also represents a date including time. The following values of these parameters shall have the meanings given: a) the value 255 shall be reserved to indicate that the value overflows to the next byte b) when T_UKSTART equals 0, the packet and its data shall be considered inservice unless T_UKFINISH has become valid c) when T_UKFINISH equals 0, the packet and its data shall be considered outof-service until T_UKSTART has become valid d) when T_UKSTART and T_UKFINISH equal 0 no changes shall be pending and the packet and its data shall be considered valid. The TASS system in the version in service at the date of publication, that is where NID_UKSYS = 1, 2, or 3, is exempted from this requirement, as set out in section B These parameters represent a time code, not a real date and time, with each consecutive value of the variable indicating the next occasion on which changes RAILWAY SAFETY 13

16 Page 14 of 21 are made to any system data. For example, in the case of track-to-train transmission, new data in balises includes the date code for the end of validity of the previous data and the start of validity of the new data. When the new data is due to take effect the trainborne equipment, being programmed with the corresponding function, rejects the previous date code and accepts the new date code. The onboard equipment (interpreting transmissions from the track to the train), or trackside equipment (interpreting transmissions from the train to the track) shall implement the finish and start date functions and include the necessary complementary software. It is permissible for the specific meaning assigned to the values of these parameters to be system dependent, as defined by NID_UKSYS. B6.6 Message parameters B6.6.1 Registration Where NID_XUSER=9, Railway Group members shall register the message structures and message parameters of each application of packet 44 with Railway Safety as set out in section B8. B6.6.2 Version Management Railway Group members shall include with their message parameters data that ensures that successive versions of each application are identifiable. Version management of packet 44 applications shall take into account the possibility of version change in the host ETCS. B7 Approved values of NID_UKSYSn The values of NID_UKSYS allocated at the date of publication are set out in Appendix B. Railway Group members shall apply only the protocol published by Railway Safety as set out in section B8.4 to each application of NID_UKSYS. B8 Registering packet 44 protocols B8.1 Proposing a new protocol to Railway Safety All applications of packet 44 shall be registered with Railway Safety. It is permissible for Railway Group members to make a joint proposal. The Railway Group member leading a proposal shall use a form of the style and containing the same content as set out in Appendix C of this document to provide the information required. Before preparing a proposal to register an application of packet 44 with Railway Safety and so be allocated a new value of NID_UKSYS, Railway Group members shall consider all functions already defined for which a value of NID_UKSYS has been allocated. In their application to Railway Safety for a value of NID_UKSYS, Railway Group members shall explain the functions required for their new application, and shall explain how they differ from applications already approved. B8.2 Consultation with other Railway Group members Railway Safety shall verify that the proposal complies with the principles and requirements of this document. Railway Safety shall then consult with Railway Group members by means of the consultation process applied to draft Railway Group Standards. Railway Group members shall consider whether there is commonality with their existing and future applications of packet 44, and whether there are safety or functional implications for the applications in use. Railway Group members shall advise Railway Safety of any modifications that are considered to be beneficial to the proposal. 14 RAILWAY SAFETY

17 Page 15 of 21 B8.3 Conclusion of the consultation Railway Safety shall inform the applicant of the outcome of the proposal and their justification. It is permissible for the applicant, if in disagreement with the decision, to appeal to the Chief Executive, Railway Safety and ultimately to the Rail Regulator. The procedure to be followed is set out in GA/RT6001. Railway Group members shall not bring a proposal into use until the proposal is formally accepted by Railway Safety. B8.4 Packet 44 register Railway Safety shall maintain a register of all uses of packet 44. Railway Safety shall make available on request this register to any Railway Group member wishing to apply packet 44. The register shall include: a) in each case, the identity of the users b) the owner of the means of data transmission c) a reference system for packet 44 parameters that uniquely identifies each parameter as set out in section B6.2 d) each message in which the parameters are used as set out in section B6.2 e) a statement of the compatibility of successive versions of the application. Railway Safety shall manage the register of packet 44 uses to identify and make known to the Railway Group members the inter-dependencies that could be present. B8.5 Decommissioning of a packet 44 application Railway Group members shall advise Railway Safety of the decommissioning of a use of packet 44. B9 Modifications to published protocols B10 Management support requirements Submissions to amend packet 44 protocols shall be made by Railway Group members in accordance with the procedure set out in section B8. It is permissible for Railway Safety to exempt users from the amendments, for example by establishing a new allocation of NID_UKSYS. B10.1 Systems principles Railway Group members shall manage their applications of packet 44 using formal methods applied by the discipline of systems engineering. The objectives shall be to: a) maintain the independence of data processing of safe functions from the data processing of the functions that are not safety critical b) maintain the independence of packet 44 applications, except as constrained by decisions made as set out in sections B5.4 and B5.5 c) maintain the consistency of definitions of messages and parameters across applications d) manage the dependence upon ETCS specifications e) maintain simple and efficient system architectures. RAILWAY SAFETY 15

18 Page 16 of 21 B10.2 Whole life coordination with the ETCS When amendments to ERTMS/ETCS European specifications are advised, because packet 44 is a facility within this system, Railway Safety shall review this document and ensure that it remains consistent with those specifications. Modification to this document shall not prejudice the applications of packet 44 in force. B10.3 Competency The management arrangements of Railway Group members using packet 44 applications shall employ personnel assessed as being competent, in accordance with GK/RT0101. B10.4 Records Records to monitor the performance and robustness of the protocol, as well as the service performance shall be applied to systems which depend upon packet 44 as set out in GI/RT7001, GK/RT0210 and GM/RT RAILWAY SAFETY

19 Page 17 of 21 Appendix A The use of NID_C and NID_BG (The content of this appendix is informative) The infrastructure controller is responsible for allocating to Railway Group members each Eurobalise group a unique identity made up from a combination of NID_C and NID_BG. The management of these two parameters is a national responsibility. The UIC document "European Train Control System - Value of Variables Controlled by the UIC", v2.01, allocates values of NID_C equal to: a) (decimal 1), and b) (decimal 2) The table below provides details of the values allocated to NID_C and NID_BG at the date of publication. NID_C = (decimal 1) NID_BG Binary NID_BG Decimal Allocated to: not yet allocated not yet allocated TASS TASS not yet allocated not yet allocated TASS TASS not yet allocated not yet allocated NID_C = (decimal 2) NID_BG Binary NID_BG Decimal Allocated to: not yet allocated not yet allocated RAILWAY SAFETY 17

20 Page 18 of 21 Appendix B NID_UKSYS allocations (The content of this appendix is mandatory) The table below provides details of the values allocated to NID_UKSYS at the date of publication. For later revisions, Railway Group members shall consult Railway Safety. NID_UKSYS Binary NID_UKSYS DECIMAL VALUE APPLICATION TASS Sub-packet TASS Sub-packet TASS Sub-packet TPWS-E 18 RAILWAY SAFETY

21 Page 19 of 21 Appendix C Example application form to obtain a value of NID_UKSYS Completed forms are to be submitted to: Controller, s Railway Safety 5 th Floor Evergreen House 160 Euston Road London NW1 2DX 1. Applicant s details (company, location address, telephone number). 2. Description of system functionality. Please provide a structured definition of the functionality. 3. Description of version compatibility, as set out in section List the message(s) proposed to provide the functions, as set out in section List the parameters required for each message, as set out in section 6.2. RAILWAY SAFETY 19

22 Page 20 of 21 6 Provide the specification of each parameter, as set out in section Provide details of similar applications providing justification for issue of new protocol (where applicable). 8. Provide details of project organisation eg single organisation / multi-organisation alliance / system authority. Nominated responsible manager: Signature Print name Date Position 20 RAILWAY SAFETY

23 Page 21 of 21 References GA/RT6001 GA/RT6004 GA/RT6006 GE/RT8039 GI/RT7001 GK/RT0101 GK/RT0210 GM/RT2185 s and other Railway Group Documents s Change Procedures Temporary Non-Compliance with s Derogations from s Automatic Train Protection (document currently in draft) Management of Safety Related Records of Elements of the Infrastructure Competence Standards for Signalling and Telecommunications Staff Asset Management for the Safety of Signalling and Operational Telecommunication Systems and Equipment Train Safety Systems The Catalogue of s and the s CD-ROM give the current issue number and status of documents published by Railway Safety. Other References Commission Decision 01/260/EC European Train Control System - Value of Variables Controlled by the UIC v2.01 RAILWAY SAFETY 21