GNSS Subsystem Requirement Specification for Enhanced ETCS Applications

Transcription

1 GNSS Subsystem Requirement Specification for Enhanced ETCS Applications Issue 1.0 Date 26/06/2007 Number of pages 130 Classification PUB Document Reference Project Work package Partner Nature Number GRAIL WP3.1 TIFSA DEL Partner reference (optional) Responsible Name/Company Signature Date Author AASI, ALS, ANS, DLR, SIE, TIF 30/03/07 WP Leader Mª José García /TIFSA 30/03/07 Project coordinator A Urech/INECO 30/03/07 GSA Project Officer Stefano Scarda 22/05/07 Project funded by the European GNSS Supervisory Authority 6FP 2 nd Call. Area 1A: User Segment, User Community Contract: GJU/05/2409/CTR/GRAIL

2 Class: PUB Page 2 / 130 DOCUMENT CHANGE LOG Issue Date Affected Sections Comments /04/2006 All Functional description - 1 st Draft /05/2006 Section 1, 2 and 3 Comments from SIEMENS included Comments from ALCATEL included DLR proposal for section 3 included /05/2006 Section 1, 2 and 3 Comments from BOMBARDIER and SIEMENS /12/2006 All Final versions of the: - GRAIL-WP3-ANS-TEC-01- v0.7_cmd_train_awakening_scenarios_ and_descriptions -GRAIL-WP3-TIF-TEC-01-v07_Train Integrity description - GRAIL-WP3-ALS-DEL-3.1.1v04_GNSS Subsystem requirement specification for AP merged together for this deliverable Final revision for the first official delivery /12/2006 All Review from Coordinator /03/ ,1.5, 3.2.1, Comments from SPMJ included /06/2007 All First Approved version

3 Class: PUB Page 3 / 130 DOCUMENT DISTRIBUTION To/cc Organisation Name To GSA Stefano Scarda To INECO Alvaro Urech To TIFSA Mª José García To ANSALDO-CSEE Celso Prados To ALSTOM Michel Rousseau To SIEMENS Klaus Jaschke To DIMETRONIC Beatriz Muñoz To THALES Karl Brocke To BOMBARDIER Georg Mandelka To THALES ALENIA SPACE Livio Marradi To CEDEX Daniel Molina To RSSB Martyn Thomas To DLR Michael Meyer zu Hoerste Cc ADIF Javier Vicente Cc Deimos Space Antonio Fernández Cc ESSP Umberto Guida Cc ESYS Bryan Jenkins Cc IIASL Frans von der Dunk Cc Indra Espacio Carlos Álvarez Cc NSL William Roberts

4 Class: PUB Page 4 / 130 TABLE OF CONTENTS 1 INTRODUCTION Purpose Intended audience / Classification Reference Documentation Associated documentation Abbreviations and Acronyms Glossary of Terms and Definitions SELECTED ENHANCED ETCS APPLICATIONS TRAIN AWAKENING & COLD MOVEMENT DETECTOR Application definition Enhanced Train Awakening and Cold Movement Detector Nominal Operational scenarios for position qualification/identification Degraded Operational scenarios for position qualification/identification Nominal Operational scenarios for RBC ID/phone number Degraded Operational scenarios for RBC ID/phone number qualification/identification System Requirement Specification GNSS Enhanced TA & CMD Functional description System specification Status of RBC ID/phone number data affected by Start of mission procedure with Enhanced ETCS System Architecture Requirements for the on-board and trackside modules Impact on the SRS Impact of CMD functionality Impact of TA functionality ABSOLUTE POSITIONING Application definition LOCOPROL approach: Absolute Positioning Reference Point approach: Operational benefits Operational scenarios System requirement specification GNSS AP System Functional... 67

5 Class: PUB Page 5 / System architecture Requirements for the Onboard and trackside modules Use of Local Augmentation Use of Digital Route Maps and databases Linking of physical Balises and GNSS absolute positions Impact on the ERTMS/ETCS class 1 specifications Conclusion TRAIN INTEGRITY Application definition Train Integrity Macro-function Operational scenarios System requirement specification GNSS TI System Functional System Architecture Requirements for the on-board and trackside modules Specification for the local augmentation Specification for the digital route maps and databases Interfaces Definition of internal interfaces Identification of external interfaces Impact on ERTMS/ETCS SRS APPENDICES APPENDIX A. TRAIN AWAKENING PERFORMANCE ANALYSIS APPENDIX B. IMPROVE ACCURACY WITH LOCAL ELEMENTS APPENDIX C. PACKET TYPE APPENDIX D. CONTINUOUS INTEGRITY STATUS VERSUS BINARY INTEGRITY STATUS APPENDIX E. ALARM TIME THRESHOLDS ACCORDING TO KIND OF TRAIN (FREIGHT, PASSENGER) AND TRAFFIC DENSITY APPENDIX F. DISCLOSURE TIME APPENDIX G: TRAIN LENGTH VARIATION

6 Class: PUB Page 6 / 130 LIST OF TABLES Table 1. Requirements for Procedure (Position) Table 2. State of Train position data Table 3. Requirements for Procedure (RBC ID/phone number) Table 4. State of RBC ID/phone number data Table 5. Scenario compatibility table LIST OF FIGURES Figure 1: GNSS Enhanced Odometry Subsystem external interfaces Figure 2: User Terminal Figure 3: Possible exploitation scenarios Figure 4: DFD for CMD and Enhanced Train Awakening module Figure 5: Components of a valid position information provided by an enhanced Train Awakening module Figure 6: Start of Mission flow chart with Enhanced ETCS functions. Position Figure 7 Start of Mission flow chart with Enhanced ETCS functions: RBC ID/phone number Figure 8: 1st possible technical implementation Figure 9: 2nd possible technical implementation (First solution) Figure 10: 2nd possible technical implementation (Second solution) Figure 11: 3rd possible technical implementation Figure 12: CMD/TA Architecture Figure 13: Proposed architecture based in current BTM Figure 14: Impact of CMD/TA functionalities in ERTMS/ETCS specs version [2] Figure 15: Impact of CMD/TA functionalities in ERTMS/ETCS specs version [3] Figure 16: LOCOPROL fusion approach Figure 17: LOCOPROL fusion principle Figure 18: APRP odometric principle Figure 19: Possible migration strategies Figure 20: Absolute Positioning subsystem Figure 21: Absolute positioning architecture Figure 22: Entry of the absolute position information Figure 23: Architecture configuration... 73

7 Class: PUB Page 7 / 130 Figure 24: Train integrity macrofunction Figure 25: Train integrity margins Figure 26: Train integrity subsystem Figure 27: Context diagram Figure 28: GNSS TI subsystem architecture definition Figure 29: GNSS TI subsystem architecture definition

8 Class: PUB Page 8 / INTRODUCTION 1.1 Purpose This document corresponds to a WP3 deliverable document as planned in the Work Plan and in the Technical Annex of the Contract. An updated version of this document will be prepared near the end of the project including the feedback from the field trials and stakeholder consultation. It aims at defining a GNSS-based subsystem to be used for the selected ETCS Enhanced : - Train Awakening & Cold Movement Detector - Train Integrity - Absolute Positioning. At this stage of the project, a specific architecture has been defined for each of the. However the project is aimed at defining the same User Terminal both for Train Awakening & Cold Movement Detector (TA&CMD) and the Absolute Positioning (AP). This document contains the functional description for the macrofunction and the User Terminal, the system architecture and the requirements for the new on-board and trackside parts, for the three enhanced ETCS selected. 1.2 Intended audience / Classification This document is public. It may be distributed freely, both within and outside the project 1.3 Reference Documentation [1] GRAIL Contract: GJU/05/2409/CTR/GRAIL [2] GRAIL Consortium Agreement [3] Project Management Plan (GRAIL-WP0-INE-DEL-01) Issue 0.2 [4] Project Handbook (GRAIL-WP0-INE-DEL-02) Issue 0.2 [5] ERTMS/ETCS - SSRS - Subset 030 System macro functions overview [6] ERTMS/ETCS - SSRS - Subset 031 On-board subsystem requirement specification 1.4 Associated documentation [7] ERTMS/ETCS - FRS version 4_29 [8] ERTMS/ETCS - Subset 023 Glossary of terms and abbreviations v2.0.0 [9] ERTMS/ETCS - SRS Class 1 Subset 026 issue 2.2.2, [10] ERTMS/ETCS - SRS Class 1 Subset 026 issue 2.3.0, [11] ERTMS/ETCS - Subset 034 FIS for the Train Interface v2.0.0 [12] ERTMS/ETCS - Subset 036 FFFIS for Eurobalise

9 Class: PUB Page 9 / 130 [13] ERTMS/ETCS - Subset 041 Performance Requirements for Interoperability, issue 2.0.0, date 30 March 2000, [14] ERTMS/ETCS - Subset 091 Safety Requirements for the Technical Interoperability of ETCS in Levels 1 & 2 v [15] Functional Requirement Specification TIMS, ERTMS Users Group, Reference EEIG: 00E996, Document version: 1-, [16] ERTMS/97e267: Odometer FFFIS [17] GIRA-WP2-AAS-DEL-21, Issue 10, GIRASOLE Receiver Specification for Railway Applications [18] GADEROS-TIF-WP2-DEL-10, On-board Location Subsystem Requirements Specifications [19] GADEROS-TIF-WP2-DEL-20, Interface Control Document [21] GRAIL-WP3-TIF-DEL GNSS Subsystem Requirement Specification for Enhanced Odometry [22] LOCOPROL- Deliverable D 4.2.1,Site 1 Test Report BSI_RW_ENG_DESG_0096_V1_2 [23] LOCOPROL Site 2 Test Report WP4.2.2 [24] LOCOPROL -Deliverable D 3.5.1:System Architecture Specification WP Abbreviations and Acronyms AP APRP APS BTM CMD DFD D_LRBG DMI DOP E5 EE EGNOS EKF ELM EMC EO EoT Absolute Positioning Absolute Positioning Reference Point Absolute Positioning System Balise Transmission Module Cold Movement Detector Data Flow Diagram Distance between the last relevant balise group and the estimated front end of the train of the active cab Driver Machine Interface Dilution of precision Galileo Frequency Band: MHz Enhanced ETCS European Geostationary Navigation Overlay Service Extended Kalman Filter European Land Mass Electromagnetic Compatibility Enhanced Odometry End of Train

10 Class: PUB Page 10 / 130 ERTMS European Railway Traffic Management System ETCS European Train Control System EVC European Vital computer FFFIS Form Functional Fit Interface Specification FIS Functional Interface Specification FRS Functional Requirement Specification FS Full Supervision mode GJU Galileo Joint Undertaking GNSS Global Navigation Satellite System GPS Global Positioning System HMI Human Machine Interface HoT Head of Train ID Identity Number IMU Inertial Measurement Unit JRU Juridical Recorder Unit K Confidence Interval L1 Galileo Frequency Band: MHz or ERTMS Level 1 L2 GPS Frequency Band and ERTMS Level 2 L3 ERTMS Level 3 LEU Lineside Electric Unit LRBG Last Relevant Balise Group LU Locator unit MA Movement authority MART Mean Active Repair Time NP No Power OS On Sight mode PVHT Position Velocity Heading Time RAMS Reliability, Availability, Maintainability, Safety RBC ID Radio Block Centre Identity Number Rx Receiver SoM Start of Mission SB Service Brake, or in the context modes, Stand By mode SBAS Satellite Based Augmentation System SIL Safety Integrity Level SIS Signal In Space SoL Safety of Life

11 Class: PUB Page 11 / 130 SPS SQ SR SRS TA TBC TBD TBR TI TIU UERE UERRE UT UTC WP Standard Positioning Service Safety Qualifier Staff Responsible mode System Requirements Specification Train Awakening To Be Confirmed To Be Defined To be Revalidated Traction Interface or Train Integrity Train Interface Unit User Equivalent Range Error User equivalent Range Rate Error User Terminal Universal Time Coordinated Work Package 1.6 Glossary of Terms and Definitions Accuracy Accuracy is a statistical value and is defined as the degree of conformance between the position indicated at the Location Unit output and the true position, at a given level of confidence, at any given instant in time, and at any location in the coverage area. The determination of the accuracy depends on the algorithm implemented to obtain the solution: if an EKF is used, then the accuracy is obtained using the covariance values. In case of SPS an estimation of the accuracy can be obtained using Dilution of Precision (DOP) and User Equivalent Range Error (UERE) values, where the local error contribution is included. Rail environment considerations The accuracy requirements of a Location Unit (LU) used in train control systems depend on the position of the train. Generally, a location module must provide a location information referring to a specific track (track number/identity as well as position on this track). For this reason, in case of parallel tracks, when required, the accuracy of the LU must be sufficient to allow the identification of the real track identity within a given probability, which must be derived from the safety requirements of the train control system (refer to integrity risk) Active repair time The active repair time shall be considered in all situations where (active) redundancy is used for back-up in the event of failure. It is beyond the scope of this document to comment on the many techniques that may be used in such a case. The ERTMS RAMS (Reliability, Availability, Maintainability and Safety) specification may indirectly lead to identification of such a time when specifying the maximum time for recognition of a

12 Class: PUB Page 12 / 130 component failure (5 s). It can be expected that any active repair duration shall be in the same range (max 5 s). Any case, usage of Galileo-Safety of Life (SoL) spare parts (active redundancy) is directly the consequence of availability requirements. Because of costs it should be avoided. The main availability gap will be caused by signal loss. Alarm If requested by the specific functional requirements, the Location Unit shall output the alarm information if: information is not ready within the rate interval; information is not to be trusted (cause may be reported as option). Availability Availability is defined as the intrinsic availability of location information fulfilling its performance requirements at the Location Unit output. Rail environment considerations In the current circumstances when the relative unavailability of Signal in Space (SIS) owing to limited visibility shall be accepted as a natural condition for designing a Location Unit with a highlyavailable positioning output at all locations - so for highly-demanding, lack of SIS shall not be a cause of non-availability. In this case, the only usable standard definition for availability is the intrinsic availability. The intrinsic availability is the "Probability that a system or equipment is operating satisfactorily at any point in time when used under stated conditions, where the time considered is operating time and active repair time. Preventive maintenance administrative and logistic times are excluded" (MIL - HDBK-388-1A). The availability of the LU used in train control mainly influences the operational conception and the line performance parameters. For transport and infrastructure operators the operational availability (e.g. delay minutes) is important, which depends on the technical availability of the LU and the operational concept. Besides there is also an effect to safety because unavailability causes the use of fault back modes which are not as safe as the normal operation and therefore the average safety of the system decreases. Confidence interval: TBD Continuity The continuity of the location information is defined as the probability that the location unit will be able to determine its position within the specified accuracy and is able to monitor the integrity of the determined position over the mission time, in all points of the route within the coverage area.

13 Class: PUB Page 13 / 130 Coverage The coverage is defined as the surface area or volume of space where the SIS service is sufficient to permit the user to determine its position with the specified accuracy and to monitor integrity of the determined position. It should be observed that for a Location Unit using a combination of techniques, the coverage may not have the same significance. Depending on the techniques combined, it may appear the case that some lines (areas) are not covered by ONE SPECIFIC TYPE of Location Unit, e.g. when implementing map matching techniques for improving accuracy the map can only be valid for a specific line (area). Then, it can be a requirement that some specific will ask for the Location Unit coverage although the SIS coverage is the ELM (European Land Mass). Enhanced ETCS Odometry: provides processed speed and distance data provided by the fusion of GNSS User Terminal, tachometer and other sensor information. It also includes reset position and synchronization between the ETCS kernel, the BTM, etc, according to the definition made in subset 031[6]. Fix Rate The fix rate is the number of position fixes and the associated integrity checks per unit time. The fix rate is a property of the Location Unit. GNSS Enhanced Odometry Subsystem The GNSS Enhanced Odometry subsystem is composed of all new elements trackside and trainborne (GNSS technology based or not) that are needed for a particular application in ETCS involving GNSS: digital map, specific local elements, user terminal, etc., and whose interfaces are ETCS and GNSS SIS. The definition is supported by the following diagram: SIS GNSS subsystem ETCS Figure 1: GNSS Enhanced Odometry Subsystem external interfaces GNSS Receiver Is the element that has an input from the SIS and an output Position (x, y, z), Velocity, Heading, Time and integrity information.

14 Class: PUB Page 14 / 130 Integrity Integrity relates to the trust that can be placed in the correctness of the information supplied by the Location Unit to the application. Integrity is described by three parameters: Threshold value or alert limit - the maximum allowable error in the measured position before an alarm is triggered. Time-to-alarm - the maximum allowable time between an alarm condition occurring and the alarm being present at the output. Integrity risk, that appears when location is out of tolerance limits (false), but the Location Unit reports "information available" and no "alarm" is triggered within the time to alarm. A Safety Integrity Level (SIL) will be assigned by WP3.4. Rail environment considerations The integrity risk of the GNSS UT is strongly dependent on implementation. GNSS System and GNSS Rx are only two of the components whose integrity risk contributes to the Global UT integrity risk value. For safety relevant railway the integrity risk can be described by the tolerable hazard rate, which is derived from a risk analysis of the application. A safety integrity level shall be then allocated to the UT according to the application. Local Element User Terminal (LE UT): TBD Maintainability Maintainability performance requirements influence: the maintenance and repair policy associated with the GNSS sub-system; the GNSS Enhanced Odometry Subsystem availability requirements. The current most severe requirements are derived from the ETCS Functional Requirement Specification [7]. Maximum time to detect a module failure: 5 seconds Maximum time to replace the module: 5 minutes Maximum time to restart the system: 15 seconds Maximum additional time to substitute a traction unit after a failure requiring maintenance in a workshop: 3 hours. These specific parameters may all be gathered together into a single parameter known as the service interruption threshold, which is the maximum acceptable duration for any unintended or intended interruption of service. The only part of the GNSS Enhanced Odometry Subsystem that affects local maintenance policy is the Location Unit that contains the GNSS receiver, which is the only element that is train-borne. For safety related the service interrupt threshold shall be no longer than the requirement for detection of the Location Unit module failure. Odometry function: provides processed speed and distance data

15 Class: PUB Page 15 / 130 Odometry macro-function (ETCS): provides processed speed and distance data but also includes reset position and synchronization between the ETCS kernel, the BTM, etc, according to the definition made in subset 031 [6]. Satisfactory function The satisfactory function shall be defined as the ability of the Location Unit to produce at the output: all information as requested, within the allowed response time; the information shall be within the tolerance limits. Sensors: INS, specific sensors for the GNSS-ETCS TBD Safety Qualifier It is a module that performs an integrity monitoring of the SIS (including local effects) and the UT functions. Sense of movement: TBD Standstill: TBD Stated condition The stated condition shall refer to the conditions defined for the location function of the Location Unit. Rail environment considerations Specifically referring to rail application, these conditions are: for a Location Unit that combines more techniques for suppressing the negative effects of masking and shadowing due to landscape, the availability of SIS can not be directly inferred. In this condition the temporary absence of SIS shall be tolerated. The maximum tolerated absence duration may result from experimental tests capable of providing the error of the Location Unit when functioning without SAT positioning. It is expected that the tolerable absence duration is strongly dependent on technological factors (such as the quality and algorithms used for K-filter, error models, quality of gyro and accelerometer). The instant operation sequence (instant error when a Location Unit has used the last GNSS supported position) in relation to route shape - worst case when straight -, speed, and acceleration patterns, may also influence the tolerable absence duration of SIS. For Location Units that will use the GNSS alone, the SIS and GNSS receiver are the principal contributors to the availability. For all cases, the other external resources are considered available (power supply, accepted environmental conditions, etc.). Update rate of the speed: TBD

16 Class: PUB Page 16 / 130 User terminal It is the part of the GNSS Enhanced Odometry Subsystem that is on-board the train. It can be composed of GNSS receivers, sensors, functions (translation of co-ordinates, data fusion ), local element user terminal The definition is supported by the following figure: UT Dataprocessing (Coordinates translation ) INS LE UT GNSS receiver Figure 2: User Terminal

17 Class: PUB Page 17 / SELECTED ENHANCED ETCS APPLICATIONS With the introduction of the GNSS technology in the ERTMS/ETCS environment some of the functions that are implemented by the current technology could be enhanced and other that are not well defined or even not implemented by the current technology could be covered. GRAIL, and specially this WP will focus on Train Awakening & Cold Movement Detector, Absolute Positioning and Train Integrity.

18 Class: PUB Page 18 / TRAIN AWAKENING & COLD MOVEMENT DETECTOR 3.1 Application definition Enhanced Train Awakening and Cold Movement Detector According to reference [7], train awakening in a RBC area describes the procedure when train equipment is powered up and a cab is activated. If the train and/or the RBC can determine a safe envelope for the train location, then the train shall be able to start its mission in full supervision after awakening. From the system specification point of view, train awakening is included in the procedure start of mission [9] and [10]. At the beginning of the Start of Mission, the set of data and in particular the stored position of the train and the RBC-ID/phone number may be in one of three states: a) "valid" (the stored values are know to be correct) b) "invalid" (the stored value may be wrong) c) "unknown" (there is no finite value stored) A fourth state of these set of data is considered in [9] and [10]: d) "to be revalidated" (the stored value is valid but becomes to be revalidated only by the fact that ETCS on-board is transiting towards NP mode). As described below, those data will be considered differently from those qualified as invalid Enhanced ETCS using GNSS technologies can be used in the process of qualifying stored data, identifying the RBC, and also can deal with operational scenarios where a train is starting a mission with stored position data qualified as invalid or unknown. Taking advantage of the GNSS capabilities and in particular absolute positioning and absolute movement detection, invalid or unknown initial positions can be qualified as valid. This can allow trains to start a mission in Full Supervision mode in situations where, under nominal procedures, the system would not have enough information to start in a supervised mode. Attending to actions of Enhanced ETCS functions on stored position data, they can be defined as: - Cold Movement Detector: this function detects train movements while equipment is in No Power mode. It compares train position when entering and exiting NP mode, hence no external power supply is needed (in fact in order to simplify powering off procedure, CMD compares position between entering NP mode and last standstill position before entering NP mode). It will be an input to the decision whether stored train position remains valid or not. - Enhanced Train Awakening: this function provides a valid position to the train based on GNSS absolute positioning when stored position is invalid or unknown. If Enhanced Train Awakening cannot provide a valid position, the train must proceed with nominal start of mission procedure described in [9] and [10]. With regard to RBC identification, the above-defined functions can be also used to validate or provide RBC ID/phone number during SoM procedure. These enhanced functions (independently or as a combination) must be incorporated into the nominal SoM procedure and their impact in actual implementations must be analysed. A number of operational scenarios are described in following sections. For the sake of clarity, operational scenarios involving qualification/identification of RBC ID/phone number and position are treated separately. Both functions will be involved along two different processes well identified during SoM procedure.

19 Class: PUB Page 19 / 130 Different exploitation scenarios can be foreseen in the application of these functions. Meanwhile CMD function will be activated all over along the track, Enhanced Train awakening functions would be restricted to limited areas where reference points were stored in GNSS subsystem according to infrastructure definition. Figure 3 shows a possible exploitation scenario where Enhanced TA is restricted to those more commonly identified awakening areas (platforms, siding tracks and shunting areas): Enhanced TA area CMD area Figure 3: Possible exploitation scenarios Nominal Operational scenarios for position qualification/identification Based on the definition above and on the specification proposed in 3.2.2, the following operational scenarios are proposed for qualification of stored position or identification of an unknown position OP_Scenario_Position 1: SoM with invalid or unknown position. Train in awakening area Historic: The train is performing a Start of mission procedure and it has a stored position unknown or invalid. Train into an awakening area Events: Step Actor Action or event 1 On-board Stored position is unknown or invalid 2 Cold Movement Detector No action 3 Enhanced Train Awakening Train is located into a train awakening area and this module is able to send a valid location to the on-board with regard a predefined reference. 4 On-board Position is valid 5 On-board/RBC/Driver Proceed with SoM procedure Final state: FS can be reached at the end of SoM procedure (combined with a Track Ahead procedure) OP_Scenario_Position 2: SoM with invalid or unknown position. Train not in awakening area Historic:

20 Class: PUB Page 20 / 130 The train is performing a Start of mission procedure and it has a stored position unknown or invalid. The train is not into an awakening area Events: Step Actor Action or event 1 On-board Stored position is unknown or invalid 2 Cold Movement Detector No action 3 Enhanced Train Awakening Train is not located into a train awakening area. This module is not able to send a valid location to the on-board 4 On-board Position is unknown 5 On-board/RBC/Driver Proceed with SoM procedure Final state: FS cannot be reached at the end of SoM procedure if RBC cannot validate the position OP_Scenario_Position 3: SoM with valid or to be revalidated position. No cold movement Historic: The train is performing a Start of mission procedure and it has a stored position initially qualified as valid ( To be revalidated when entering NP mode). The train has not been moved since last connection. (This scenario includes the case of a train returning to the same spot after moving in NP or IS mode, if finally this particularity in included in Cold Movement Detector functionality) Events: Step Actor Action or event 1 On-board Stored position is qualified as valid (or To be revalidated when entering NP mode) 2 Cold Movement Detector No movement is detected 3 Enhanced Train Awakening No actions 4 On-board Stored position qualified as valid 5 On-board/RBC/Driver Proceed with SoM procedure Final state: FS can be reached at the end of SoM procedure (combined with a Track Ahead procedure) OP_Scenario_Position 4: SoM with valid or to be revalidated position. Cold movement Historic: The train is performing a Start of mission procedure and it has a stored position initially qualified as valid ( To be revalidated when entering NP mode). The train has been moved since last connection.

21 Class: PUB Page 21 / 130 Events: Step Actor Action or event 1 On-board Stored position is qualified as valid (or To be revalidated when entering NP mode) 2 Cold Movement Detector Movement is detected 3 On-board Stored position qualified as invalid 4 Scenario 1 or 2 Final state: FS can be reached at the end of SoM procedure (combined with a Track Ahead procedure) Degraded Operational scenarios for position qualification/identification Either Cold Movement Detector or Enhanced Train Awakening information is not available or correctly exploitable. Two levels of degraded information are considered. No information: system failure, SIS not available, etc. Low performance: CMD and/or Enhanced TA systems work properly but due to quality of SIS, positioning is provided with a level of inaccuracy that could affect the SoM procedure Degraded OP_Scenario_Position 1a: SoM with invalid or unknown position. Train in awakening area. Enhanced Train Awakening is not available (system failure or SIS not available) Historic: Enhanced Train Awakening information is not available Events: Step Actor Action or event 1 On-board Stored position is unknown or invalid 2 Cold Movement Detector No action 3 Enhanced Train Awakening Not available 4 On-board Position is unknown 5 On-board/RBC/Driver Proceed with SoM procedure Final state: FS cannot be reached at the end of SoM procedure if RBC cannot validate the position Degraded OP_Scenario_Position 1b: SoM with invalid or unknown position. Train in awakening area. Enhanced Train Awakening is available but positioning is calculated with unacceptable error range Historic:

22 Class: PUB Page 22 / 130 Enhanced Train Awakening information is available, but due to external conditions (low quality of SIS, etc) error range in positioning is unacceptable. Some criteria for qualifying error range: Uncertainty in position is intersecting other adjacent Train Awakening zone Uncertainty in position does not allow to identify orientation of the train in relation to the direction of reference Uncertainty in position does not allow to identify direction of train movement in relation to the orientation of reference Events: Step Actor Action or event 1 On-board Stored position is unknown or invalid 2 Cold Movement Detector No action 3 Enhanced Train Awakening Not able to provide an exploitable reference 4 On-board Position is unknown 5 On-board/RBC/Driver Proceed with SoM procedure Final state: FS cannot be reached at the end of SoM procedure if RBC cannot validate the position Degraded Scenario_Position 3_4: SoM with valid (or to be revalidated when entering NP) position. Cold Movement Detector is not available Historic: The train is performing a Start of mission procedure and it has a stored position initially qualified as valid (or to be revalidated when entering NP). Cold Movement Detector is not available Events: Step Actor Action or event 1 On-board Stored position is qualified as valid (or to be revalidated when entering NP) 2 Cold Movement Detector Not available 3 On-board Stored position qualified as unknown 4 Scenario 1 or 2 Final state: FS can be reached at the end of SoM procedure (combined with a Track Ahead procedure), if train is into an Awakening area and Enhanced Train Awakening information is available.

23 Class: PUB Page 23 / Nominal Operational scenarios for RBC ID/phone number Based on the definition above and on the specification proposed in 3.2.2, the following operational scenarios are proposed for qualification or identification of the RBC, which is managing the area where the train is starting its mission OP_Scenario_RBC_number 1: SoM with invalid or unknown RBC ID/phone number. Historic: The train is performing a Start of mission procedure and it has a stored RBC ID/telephone number unknown or invalid. Events: Step Actor Action or event 1 On-board RBC ID/telephone number unknown or invalid 2 Cold Movement Detector No action 3 Enhanced Train Awakening This module is able to locate the train into the predefined area of influence of a given RBC. 4 On-board RBC ID/telephone number known and valid 5 On-board/RBC/Driver Proceed with SoM procedure Final state: Driver is not requested to enter or validate RBC-ID and phone number OP_Scenario_RBC_number 2: SoM with known and valid RBC ID/phone number. No cold movement Historic: The train is performing a Start of mission procedure and it has a stored RBC ID/phone number initially qualified as valid. The train has not been moved since last connection. (This scenario includes the case of a train returning to the same spot after moving in NP or IS mode, if finally this particularity in included in Cold Movement Detector functionality) Events: Step Actor Action or event 1 On-board Stored RBC ID/telephone number is qualified as valid (or to be revalidated when entering NP) 2 Cold Movement Detector No movement is detected 3 Enhanced Train Awakening No actions 4 On-board Stored RBC ID/telephone number qualified as valid 5 On-board/RBC/Driver Proceed with SoM procedure Final state:

24 Class: PUB Page 24 / 130 Driver is not requested to enter or validate RBC-ID and phone number OP_Scenario_RBC_number 3: SoM with known and valid (or to be revalidated when entering NP) RBC ID/phone number. Cold movement Historic: The train is performing a Start of mission procedure and it has a stored RBC ID/phone number initially qualified as valid. The train has been moved since last connection. Events: Step Actor Action or event 1 On-board Stored RBC ID/telephone number is qualified as valid (or to be revalidated when entering NP) 2 Cold Movement Detector Movement is detected 3 On-board Stored RBC ID/telephone number qualified as invalid 4 Scenario 1, steps 3 5 if TA available. Degraded scenario 1, steps 3 5 if TA not available. Final state: Driver is not requested to enter or validate RBC-ID and phone number Degraded Operational scenarios for RBC ID/phone number qualification/identification Either Cold Movement Detector or Enhanced Train Awakening information is not available or correctly exploitable Degraded OP_Scenario_RBC_number 1: SoM with invalid or unknown RBC ID/phone number. Enhanced Train Awakening is not available Historic: Enhanced Train Awakening information is not available Events: Step Actor Action or event 1 On-board Stored RBC ID/telephone number is unknown or invalid 2 Cold Movement Detector No action 3 Enhanced Train Awakening Not available 4 On-board RBC ID/telephone number is unknown 5 On-board/RBC/Driver Proceed with SoM procedure Final state: Driver is requested to enter or validate RBC-ID and phone number

25 Class: PUB Page 25 / Degraded Scenario_ RBC_number 2_3: SoM with valid RBC ID/phone number. Cold Movement Detector is not available Historic: The train is performing a Start of mission procedure and it has a stored position initially qualified as valid(or to be revalidated when entering in NP). Cold Movement Detector is not available Events: Step Actor Action or event 1 On-board Stored RBC ID/telephone number is qualified as valid (or to be revalidated when entering in NP) 2 Cold Movement Detector Not available 3 On-board Stored RBC ID/telephone number qualified as unknown 4 Scenario 1, steps 3 5 if TA available. Degraded scenario 1, steps 3 5 if TA not available. Final state: Driver is not requested to enter or validate RBC-ID and phone number if Enhanced Train Awakening information is available. 3.2 System Requirement Specification GNSS Enhanced TA & CMD Functional description Figure 4 shows the Data flow diagram (DFD) representing the above described CMD and Enhanced TA functionalities and data exchange. Info Request CMD Info (CM detected Y/N, unable to detect) SiS Navigation Data EnhancedTrain Awakening & Cold Movement Detection Validated Position (Euroradio-like format) TA Status Validated RBC ID/number Correct RBC/ID number ETCS On Board TA areas Reference Point Digital Map Context Diagram

26 Class: PUB Page 26 / 130 Info Request Info Request SiS Navigation Data CMD Module CMD Status (On/Off) CM Info Validated Position (Euroradio-like format) Enhanced TA Module TA Status ETCS On Board Absolute Position TA Areas Reference Points Digital Map Correct RBC ID number Validated RBC ID/number CM Info Level 1 Figure 4: DFD for CMD and Enhanced Train Awakening module General Functions CMD: Detection of train movement during No Power mode (in order to avoid special procedures when ETCS On-board is powering off, cold movement will be triggered every time that the train is at standstill and hence, cold movement detection will be carried out between exiting NP mode and standstill position previous to exiting NP mode) Validation of stored data: During switching-on process, stored data, if any, are validated or not depending whether cold movement has been detected. Providing valid RBC ID/telephone number: Under request by ERTMS/ETCS on-board equipment, Enhancement train awakening module provides if possible RBC ID and telephone number Providing valid position: Under request by ERTMS/ETCS on-board equipment, Enhancement train awakening module provides if possible a valid train position. A valid train position reported by the Enhanced train awakening module includes (see figure below): o Identification of a reference point: It is a reference balise to be used as LRBG for the distance o Position of train: This information shall be provided as a distance along the track from LRBG and orientation of position of train with regard to orientation of LRBG o Orientation of train: Orientation of train with regard to orientation of LRBG

27 Class: PUB Page 27 / 130 D_LRBG NID_LRBG Q_DIRLRBG: Reverse Q_DLRBG: Reverse Figure 5: Components of a valid position information provided by an enhanced Train Awakening module Information ETCS on-board -> User terminal The messages will have similar structure to standard ETCS messages and will be defined in D CMD standstill trigger. o This message will trigger CMD module for supervising cold movement. In order to avoid special procedures during kernel power off and NP transition, CMD module will be triggered to calculate a position every time train is in standstill CMD Information request o ETCS on-board is requesting CMD confirmation Enhanced TA information request o ETCS on-board is requesting Enhanced TA information Information User Terminal -> ETCS on-board CMD Status Upon ETCS on-board CMD requesting, User terminal is sending CMD status with one of the following values: Unable to provide information, Cold Movement detected, No cold Movement detected Enhanced TA information Upon ETCS on-board CMD requesting, User terminal will send Train Awakening relevant information concerning distance and orientation with regard to a defined reference, as well as RBC ID/phone number System specification System specifications and procedures are described in two separated sections corresponding to these two functions: Validation/identification of Position Validation/identification of RBC ID/phone number

28 Class: PUB Page 28 / Function: Validation/identification of Position Requirements for procedure. Figure 6 shows a tentative flow chart for Start of Mission procedure including Enhancement ETCS for validation/identification of position. CMD function shall be capable to detect and record whether the engine has been moved or not during a defined period of time and when ERTMS/ETCS on-board equipment has been switched off (i. e. once it is on No Power mode). When on-board equipment is powered again, it shall use, if available, the memorized information about cold movement in order to update the status of information stored on-board. After cab activation and transition to Stand By mode, nominal Start of mission procedure shall take place with inclusion of TA functionalities.

29 Class: PUB Page 29 / 130 S_NP Cab is powered on (NP) CDM Module E1 A1 Stored position (if any) is qualified using CDM output S0 Cab is active and mode is SB D1 Stored position is valid no yes Enhanced TA module E2 A2 receives information from Enhanced TA Module D2 Enhanced TA has provided a valid position yes no S2 Rest of nominal Start of Mission Procedure with unknown position S1 Rest of nominal Start of Mission Procedure with valid position FS mode cannot be reached FS mode can be reached Figure 6: Start of Mission flow chart with Enhanced ETCS functions. Position Table 1 indicates requirements related to actions, decisions, etc in the proposed flow chart flow chart ID in Flow Chart S_NP Requirements The ERTMS/ETCS on-board equipment is being switched off (i.e. it in No Power mode). The CMD shall be capable to detect and record whether the engine has been

30 Class: PUB Page 30 / 130 ID in Flow Chart A1 E1 S0 D1 A2 E2 D2 S1 S2 moved or not Requirements On-board equipment uses information from Cold Movement Detector to confirm valid stored information Cold Movement Detector module sends status and information to on-board The Start of Mission procedure is made as nominal procedure in ref.[2] until stored position is used. This procedure shall be engaged when the ERTMS/ETCS on-board equipment is in Stand-By mode with a desk open After receiving information from Cold Movement Detector, valid stored position can be revalidated or invalidated. If position remains valid, the process shall go to S1. Depending on driver actions, RBC can finally provide a FS MA If position is invalidated, the system will require information from Enhanced Train Awakening module When on-board has invalid or unknown stored position data, it uses information provided by Enhanced Train awakening module. Enhanced Train Awakening module sends status and position relative to a predefined reference to on-board On-board receives information from Enhanced Train Awakening module. If Enhanced TA can provide a valid position to on-board, the process shall go to S1. Depending on driver actions, RBC can finally provide a FS MA If Enhanced TA cannot provide a valid position to on-board, the process shall go to S2 and independently of driver actions, RBC will no provide a FS MA If after qualification of stored position by Enhanced ETCS Applications this is considered as valid, RBC will be able to provide a FS MA to train If after qualification of stored position by Enhanced ETCS Applications this is considered as invalid, position data will be deleted on-board and considered as unknown. RBC will not be able to provide a FS MA to train Table 1. Requirements for Procedure (Position) Status of train position data affected by Start of mission procedure with Enhanced ETCS The status of train position data are affected by the Start of mission procedure assisted by both Cold Movement Detector and Enhanced Train awakening:

31 Class: PUB Page 31 / 130 State of Train position data Transition conditions Unknown Invalid Valid TBR A1: Cold Movement detector sends detection of movement or error A1: Cold Movement detector sends "no movement detected" A2: Enhancement Train awakening module provides valid position A2: Enhanced Train awakening is not able to provide a valid position Table 2. State of Train position data Function: Validation Validation/identification of RBC ID/phone number Requirements for procedure. Figure 7 shows a tentative flow chart for Start of Mission procedure including Enhancement ETCS for validation/identification of RBC ID/phone number.

32 Class: PUB Page 32 / 130 S_NP Cab is powered on (NP) (if any) CMD Module E1 A1 Stored RBC ID/Phone number (if any) is qualified using CMD output S0 Cab is active and mode is SB D1 RBC ID/number is valid no yes Enhanced TA module E2 A2 receives information from Enhanced TA Module D2 Enhanced TA has provided a valid RBC ID num no yes S2 Driver is requested to enter/validate RBC ID/phone number S1 Driver is not requested to enter/validate RBC ID/phone number Rest of S of M procedure Figure 7 Start of Mission flow chart with Enhanced ETCS functions: RBC ID/phone number Table 3 indicates requirements related to actions, decisions, etc in the proposed flow chart flow chart

33 Class: PUB Page 33 / 130 ID in Flow Chart S_NP A1 E1 S0 D1 A2 E2 D2 S1 S2 Requirements The ERTMS/ETCS on-board equipment is being switched off (i.e. it in No Power mode). The CMD shall be capable to detect and record whether the engine has been moved or not On-board equipment uses information from Cold Movement Detector to confirm valid stored information Cold Movement Detector module sends status and information to on-board The Start of Mission procedure is made as nominal procedure in ref.[2] until stored position is used. This procedure shall be engaged when the ERTMS/ETCS on-board equipment is in Stand-By mode with a desk open After receiving information from Cold Movement Detector, valid stored RBC ID/phone number can be revalidated or invalidated. If RBC ID/phone number remains valid, the process shall go to S1. If RBC ID/phone number is invalidated, the system will require information from Enhanced Train Awakening module When on-board has invalid or unknown RBC ID/phone number, it uses information provided by Enhanced Train awakening module. Enhanced Train Awakening module sends status and RBC ID/phone number On-board receives information from Enhanced Train Awakening module. If Enhanced TA can provide a valid RBC ID/phone number to on-board, the process shall go to S1. If Enhanced TA cannot provide a valid RBC ID/phone number to on-board, the process shall go to S2. If after qualification/identification of RBC ID/phone number by Enhanced ETCS Applications these are considered as valid, driver is not requested to enter/validate RBC ID/phone number If after qualification/identification of RBC ID/phone number by Enhanced ETCS Applications these are considered as invalid or unknown, drive is requested to enter/validate RBC ID/phone number Table 3. Requirements for Procedure (RBC ID/phone number) Status of RBC ID/phone number data affected by Start of mission procedure with Enhanced ETCS The status of RBC ID/phone number data are affected by the Start of mission procedure assisted by both Cold Movement Detector and Enhanced Train awakening: State of RBC ID/phone number data Transition conditions Unknown Invalid Valid TBR A1: Cold Movement detector sends detection of movement or error status A1: Cold Movement detector sends "no

34 Class: PUB Page 34 / 130 State of RBC ID/phone number data Transition conditions Unknown Invalid Valid TBR movement detected" A2: Enhancement Train awakening module provides valid RBC ID/ Phone number A2: Enhanced Train awakening is not able to provide information Table 4. State of RBC ID/phone number data System Architecture Initial Proposals for Train Awakening and CMD Architectures st possible technical implementation Translation of coordinates takes place in the On-board GNSS Subsystem (User Terminal) UT has the list of reference points and areas where Enhanced TA is allowed UT Coordinates translation Other Sensors LE UT - List of reference points - TA areas SQ GNSS receiver 1Relativeposition D_LRBG NID_LRBG Q_DLRBG Q_DIRLRBG ETCS on board Kernel ODO BTM Euroradio Doppler Radar, tacho and other odometric signals 2 Position info Balise RBC Figure 8: 1st possible technical implementation nd possible technical implementation Translation of coordinates takes place in the ETCS on-board.

35 Class: PUB Page 35 / 130 First solution: List of reference points and Train Awakening areas stored in RBC. UT Data processing SQ 1 Absolute position ETCS on board ODO Kernel BTM Other Sensors LE UT GNSS receiver Coordinates translation Euroradio RBC list 4 Relative Position (standard ETCS message) Doppler Radar, tacho and other odometric signals 2 Absolute positioning Balise RBC -List of reference points - TA areas 3 List of ref. points and TA areas Figure 9: 2nd possible technical implementation (First solution) Second solution: List of reference points and Train Awakening areas in on-board equipment UT Other Sensors Data processing LE UT SQ GNSS receiver 1 Absolute position ETCS on board ODO Kernel Coordinates translation Euroradio BTM -RBC list -Reference poitns list - TA areas 2 Relative Position (standard ETCS message) Doppler Radar, tacho and other odometric signals Balise RBC Figure 10: 2nd possible technical implementation (Second solution)

36 Class: PUB Page 36 / rd possible technical implementation Translation of coordinates takes place in the RBC. List of reference points stored in the RBC UT Other Sensors Data processing LE UT SQ GNSS receiver ETCS on board 1 Absolute position Kernel ODO BTM Euroradio 3 Relative Doppler Radar, tacho Position and other odometric signals (standard ETCS 2 Absolute message) positioning Balise RBC Coordinates traslation -List of reference points - TA areas Figure 11: 3rd possible technical implementation Train Awakening and CMD Architecture. Selected implementation After analysing different architecture proposals, first possible technical implementation was selected: Translation of coordinates takes place in the On-board GNSS Subsystem (User Terminal) UT has the list of reference points and areas where Enhanced TA is allowed As explained in the definition, CMD function detects train movements when equipment is in No Power mode; Enhanced Train Awakening function provides a valid position to the train based on GNSS absolute positioning when stored position is invalid or unknown. Based on these definitions and in the system specification described in the precedent section, the following system architecture is proposed: - UT measured and compares the absolute position of the train when entering and exiting NP mode (triggered by on-board equipment. Using those information and according to the defined accuracy, the UT is able to provide the CMD status - UT is able to localize the train within a predefined Train Awakening area. According to this information and using a preloaded Train Awakening area, the UT will send upon request referenced information on train position and RBC under whose responsibility is the train.

37 Class: PUB Page 37 / 130 GNSS Receiver GNSS UT Train awakening zones map GNSS Algorithm CMD and TA request. CMD trigger CMD status TA reference Kernel ETCS ONBOARD Figure 12: CMD/TA Architecture This architecture implies the following operational requirements: - CMD functions compares train position when entering and exiting NP mode, hence no external power supply is needed - For Enhanced TA function, translation of coordinates takes place in the On-board GNSS Subsystem (User Terminal) - UT has the list of reference points and areas where Enhanced TA is allowed according to a predefined format - UT has a list of RBC ID s and Phone numbers that control the TA areas Overall architecture must be similar for all the Enhanced ETCS Applications. The proposed architecture interface with the on-board ETCS/ERTMS equipment is based in current BTM. Two possibilities have been recommended according to interfacing point:

38 Class: PUB Page 38 / 130 GNSSsubsystem Possibility 1 Receiver Antenna BTM (on board equipemt) Possibility 2 BTM function ETCS EVC BUS, e.g. MVB Decoder Serial connection, e.g. RS485 Receiver Data connection (coax-cable) Transmitter HF connection (coax-cable) Antenna Airgap, interface A Balise Figure 13: Proposed architecture based in current BTM Requirements for the on-board and trackside modules In this section there are reported the main functional and performance requirements allocated to the Cold Movement detector and Train Awakening function. These requirements will be denoted with the acronym REQ-GNSSUT-EE-TA-xx. Some basic issues that should be taken into consideration in defining the specification and design of the UT are recalled here: 1. It is well known that precise navigation based only on GNSS sensors suffers from losses of GNSS Signal lock (especially in land ), while the vehicle travels in the interference/multipath generating environment, or under the canyon, bridges, overpasses, etc. To increase availability and continuity of UT outputs during GNSS periods of nonvisibility, other means or sensors could be used to propagate the position solution and to provide a speed and travelled distance measurement; inertial measurement sensors are one possibility. Based on the complementary error behaviour of GNSS and IMU sensors, higher performance levels are possible. But the gain in accuracy, availability, integrity and continuity depends also on the architecture of integration and data fusion. For ground such as railway navigation, the integration of an IMU with a GNSS receiver at user terminal level, consists in the combination of measurements generated by the independent sensors (accelerations, angular rate, position and velocity) using a data fusion techniques, such as Kalman filter technique. Inertial Navigation Sensors and GNSS have several complementary properties: the inertial sensors have small errors over short times but drift over the long period, while the GNSS solution is able to maintain a more constant level of accuracy. The GNSS system can provide absolute position, velocity and time estimates with bounded errors (this means that it is underbounded by a sphere or that it is possible to define a sphere radius containing at 95% of probability the error value). Those outputs need to be then transformed into a travelled distance measurement. The sample rate is not very high, typically a few Hertz, which is often too low for control purposes.

39 Class: PUB Page 39 / 130 Inertial sensors, on the other hand, can provide measurements at higher sampling rates, but in the integration process the error is not bounded. The fact that Inertial Navigation Sensors and GNSS have these complementary properties can be used advantageously, if the two systems are integrated. 2. Use of local elements (TBD): positioning accuracy can be improved locally by providing users with differential corrections. A differential reference station comprises a fixed receiver that measures pseudo-range to the satellites. Since the location of such a ground-station is precisely known, the differential correction can be calculated, enabling removal of most of the error component common to all users in the coverage area. Enhanced integrity information can also be provided on a local basis through utilisation of Local Integrity Monitors. These can deliver enhancements with respect to all aspects of integrity provision, namely Time to Alarm, Alarm Limits and Risk of Missed Detections. On the other hand Local Elements can also include the use of pseudolites that is fixed transmitters that provide a satellite-like signal usable by the user receiver as an additional signal and measurement source. This feature allows overcoming the GNSS lack of visibility in areas with obstructed line of sight to the GNSS satellites. It is important to remark that the basic considerations recalled in the specification of Enhanced Odometer application are still valid. Indeed, in both (Enhanced ETCS and EO), the GNSS-EE-UT Navigation Equipment is in charge of providing an additional (with respect to the traditional tachometer) source of position and velocity information to the ETCS Kernel in order to determine train speed and distance. In case of Enhanced ETCS, some additional functions are foreseen, according to the specific application The performance Environment The performance allocated to the UT will be defined according to the following main lines: Position Accuracy, that means the Train capability to self-determine its own Position Speed Accuracy, that means the Train capability to self-determine its own Speed Safety: provide the elements to verify that the ERTMS Safety Integrity Level (SIL4) can be maintained also introducing GNSS UT on board the train GNSS TA UT Requirements In this section we have summarized the main functional and performance requirements allocated to the User terminal, with a particular emphasis dedicated to the GNSS Receiver considering its crucial role in the GNSS UT Equipment Functional requirements

40 Class: PUB Page 40 / 130 REQ-GNSSUT-EE-TA-010 Title Purpose The Cold Movement detector and Train Awakening Function implemented in the frame of the EE GNSS-UT shall be a dedicated Function able to provide real-time data to the ETCS Kernel with the purpose to allow the train to start its mission in full Supervision mode in situations where, under nominal procedures (stored data are invalid or unknown), the system would not have enough information. Train awakening in a RBC area describes the procedure when train equipment is powered up and a cab is activated. If the train and/or the RBC can determine a safe envelope for the train location, then the train shall be able to start its mission in full supervision after awakening. REQ-GNSSUT-EE-TA-020 Title Sub-functions The Cold Movement detector and Train Awakening Function attending to actions of Enhanced ETCS functions on stored position data, shall contain the following sub-functions: Cold Movement Detector Enhanced Train Awakening REQ-GNSSUT-EE-TA-030 Title The Cold Movement Detector Sub-function Purpose The Cold Movement Detector sub-function detects train movements while the ETCS on-board equipment is in No Power mode. It compares train position when entering and exiting NP mode, hence no external power supply is needed. It will be an input to the decision whether stores train position remains valid or not.. REQ-GNSSUT-EE-TA-031 Title The Cold Movement Detector absolute position compute The Cold Movement detector shall calculate and stored the absolute position of the train when: - Receiving the trigger message from ETCS onboard (Position_1) - Receiving the request message from ETCS onboard (Position_2) REQ-GNSSUT-EE-TA-040 Title The Enhanced Train Awakening Sub-function Purpose The Enhanced Train Awakening sub-function shall provide a valid position to the train based on GNSS absolute positioning when stored position is invalid or unknown. If Enhanced Train Awakening cannot provide a valid position, the train must proceed with nominal start of mission procedure.

41 Class: PUB Page 41 / 130 REQ-GNSSUT-EE-TA-050 Title Configuration Data The Cold Movement detector and Train Awakening Function implemented in the frame of the EE GNSS-UT receiver shall use the following configuration data: TBD REQ-GNSSUT-EE-TA-060 Title Input Data The Cold Movement detector and Train Awakening Function implemented in the frame of the EE GNSS-UT receiver has in charge to acquire data from GNSS SIS Other navigation sensors (if available, TBC) GNSS-EE-UT Navigation function Data base and to provide time tagged TBD information. REQ-GNSSUT-EE-TA-070 Title Output Data The Cold Movement detector and Train Awakening Function implemented in the frame of the EE GNSS-UT has in charge to provide the following information: Train Cold Movement detector and Train Awakening status information TBD REQ-GNSSUT-EE-TA-080 Title Train Awakening status Definition The Train Awakening status information shall assume the following values: TA Status = valid TA Status = invalid TA Status = unknown. REQ-GNSSUT-EE-TA-081 Title Train Cold Movement detector status Definition The Train Cold Movement detector status information shall assume the following values: CMD Status = No Cold Movement detected, If Position_1 = Position_2, CMD_Status= Cold movement detected, If Position 1 <> Position_2, CMD Status = Unable to provide information

42 Class: PUB Page 42 / 130 REQ-GNSSUT-EE-TA-090 Title RBC identification With regard to RBC identification, the Train Cold Movement detector and Train Awakening above defined functions can be also used to validate or provide RBC ID/phone number during SoM procedure GNSS scenarios requirements Since the GNSS subsystem performances strongly depend on the environment, the train awakening performance will be specified for precise configurations. Two main environments will be considered: A rural environment with a good satellite visibility and low probability of indirect paths (typical cases to be defined to describe the rural environment) An urban environment corresponding to an area with less satellite visibility and height probability of indirect paths (typical cases to be defined to describe the urban environment). For each environment, performances are given in the following section. REQ-GNSSUT-EE-TA-100 Title GNSS nominal scenarios definition The GNSS nominal scenarios available in the frame of GNSS UT TA application performance specification are those defined in the following table: E5a L2 E5b E5AltBoc E6A E6BC L1A L1BC L1C/A GPS Single frequency without Integrity GPS Dual frequency without integrity GPS Single frequency with Integrity GPS Dual frequency with integrity Galileo Single Frequency with integrity Galileo Dual Frequency with integrity The previous table is applicable for both rural and urban scenarios. Details on scenarios are provided in the following requirements.

43 Class: PUB Page 43 / 130 REQ-GNSSUT-EE-TA-110 Title GPS Single frequency without Integrity rural nominal scenario The GPS Single Frequency on L1 rural nominal scenario defined in the frame of GNSS UT TA application performance specification shall be complaint with the UERE/UERRE table reported in the following (TBC and TBD): GPS Satellite Single Frequency without Integrity Band Modulation Message Environment RF FE Configuration L1 BPSK GPS NAV RV Aereonautical UERE Mixed Residual Ionosphere error 737,20 659,74 590,83 529,99 430,47 357,17 324,74 324,74 324,74 OD & TS error 535,72 535,72 535,72 535,72 535,72 535,72 535,72 535,72 535,72 Residual Troposphere error 135,10 75,30 51,45 39,18 26,92 20,97 17,61 15,58 13,50 Thermal noise,interf.,multipath ra 68,91 68,61 68,51 68,47 68,43 68,43 68,41 68,41 68,41 Multipath bias error 33,50 33,50 33,50 33,50 33,50 33,50 33,50 33,50 33,50 Satellite BGD error 50,00 50,00 50,00 50,00 50,00 50,00 50,00 50,00 50,00 Code-Carrier Ionospheric diverge 15,94 15,94 15,94 15,94 15,94 15,94 15,94 15,94 15,94 Total 925,93 858,20 804,55 760,26 693,97 650,82 633,50 633,45 633,40 Total+10% margin 1018,52 944,02 885,00 836,28 763,36 715,90 696,85 696,79 696,74 1-sigma error [cm] UERE budget: GPS Single Frequency (L1) without integrity in rural environment TBD UERRE budget: GPS Single Frequency (L1) without integrity in rural environment REQ-GNSSUT-EE-TA-120 Title GPS Dual frequencies without Integrity rural nominal scenario The GPS Dual Frequencies rural nominal scenario defined in the frame of GNSS UT TA application performance specification shall be complaint with the UERE/UERRE table reported in the following (TBC and TBD): GPS Satellite double Frequency without Integrity Band Modulation Message Environment RF FE Configuration L1 BPSK GPS NAV RV Aereonautical UERE Mixed Residual Ionosphere error 184,30 164,94 147,71 132,50 107,62 89,29 81,19 81,19 81,19 OD & TS error 133,93 133,93 133,93 133,93 133,93 133,93 133,93 133,93 133,93 Residual Troposphere error 33,77 18,82 12,86 9,79 6,73 5,24 4,40 3,90 3,38 Thermal noise,interf.,multipath ra 68,91 68,61 68,51 68,47 68,43 68,43 68,41 68,41 68,41 Multipath bias error 33,50 33,50 33,50 33,50 33,50 33,50 33,50 33,50 33,50 Satellite BGD error 50,00 50,00 50,00 50,00 50,00 50,00 50,00 50,00 50,00 Code-Carrier Ionospheric diverge 15,94 15,94 15,94 15,94 15,94 15,94 15,94 15,94 15,94 Total 248,33 232,55 220,20 210,13 195,25 185,73 181,95 181,93 181,92 Total+10% margin 273,17 255,80 242,22 231,14 214,78 204,31 200,14 200,13 200,11 1-sigma error [cm] UERE budget: GPS Dual Frequencies without integrity in rural environment TBD UERRE budget: GPS Dual Frequencies without integrity in rural environment

44 Class: PUB Page 44 / 130 REQ-GNSSUT-EE-TA-130 Title GPS Single frequency with Integrity rural nominal scenario The GPS Single Frequency on L1 rural nominal scenario defined in the frame of GNSS UT TA application performance specification shall be complaint with the UERE/UERRE table reported in the following (TBC and TBD): TBD UERE budget: GPS Single Frequency (L1) with integrity in rural environment TBD UERRE budget: GPS Single Frequency (L1) with integrity in rural environment REQ-GNSSUT-EE-TA-140 Title GPS Dual frequencies with Integrity rural nominal scenario The GPS Dual Frequencies rural nominal scenario defined in the frame of GNSS UT TA application performance specification shall be complaint with the UERE/UERRE table reported in the following (TBC and TBD): TBD UERE budget: GPS Dual Frequencies with integrity in rural environment TBD UERRE budget: GPS Dual Frequencies with integrity in rural environment

45 Class: PUB Page 45 / 130 REQ-GNSSUT-EE-TA-150 Title Galileo Single Frequency on L1 with integrity rural nominal scenario The Galileo Single Frequency on L1 rural nominal scenarios defined in the frame of GNSS UT TA application performance specification shall be complaint with the UERE/UERRE table defined in the TUSREQ document and reported in the following: UERE budget: Galileo Single Frequency (L1) in rural environment TUS Identifier N 15 UERRE budget (200ms): Galileo Single Frequency (L1) in rural environment

46 Class: PUB Page 46 / 130 REQ-GNSSUT-EE-TA-160 Title Galileo Single Frequency on E5b with integrity rural nominal scenario The Galileo Single Frequency on E5b rural nominal scenarios defined in the frame of GNSS UT TA application performance specification shall be complaint with the UERE/UERRE table defined in the TUSREQ document and reported in the following: UERE budget: Galileo Single Frequency (E5b) in rural environment UERRE budget (200ms): Galileo Single Frequency (E5b) in rural environment TUS Identifier N 16

47 Class: PUB Page 47 / 130 REQ-GNSSUT-EE-TA-170 Title Galileo Dual Frequencies with integrity rural nominal scenario The Galileo Dual Frequencies rural nominal scenario defined in the frame of GNSS UT TA application performance specification shall be complaint with the UERE/UERRE table defined in the TUSREQ document and reported in the following: UERE budget: Galileo Dual Frequencies in rural environment UERRE budget (200ms):Galileo Dual Frequencies in rural environment TUS Identifier N 19 REQ-GNSSUT-EE-TA-180 Title GPS Single frequency without Integrity urban nominal scenario The GPS Single Frequency on L1 urban nominal scenario defined in the frame of GNSS UT TA application performance specification shall be complaint with the UERE/UERRE table reported in the following (TBC and TBD): TBD UERE budget: GPS Single Frequency (L1) without integrity in urban environment TBD UERRE budget: GPS Single Frequency (L1) without integrity in urban environment

48 Class: PUB Page 48 / 130 REQ-GNSSUT-EE-TA-190 Title GPS Dual frequencies without Integrity urban nominal scenario The GPS Dual Frequencies urban nominal scenario defined in the frame of GNSS UT TA application performance specification shall be complaint with the UERE/UERRE table reported in the following (TBC and TBD): TBD UERE budget: GPS Dual Frequencies without integrity in urban environment TBD UERRE budget: GPS Dual Frequencies without integrity in urban environment REQ-GNSSUT-EE-TA-200 Title GPS Single frequency with Integrity urban nominal scenario The GPS Single Frequency on L1 urban nominal scenario defined in the frame of GNSS UT TA application performance specification shall be complaint with the UERE/UERRE table reported in the following (TBC and TBD): TBD UERE budget: GPS Single Frequency (L1) with integrity in urban environment TBD UERRE budget: GPS Single Frequency (L1) with integrity in urban environment REQ-GNSSUT-EE-TA-210 Title GPS Dual frequencies with Integrity urban nominal scenario The GPS Dual Frequencies urban nominal scenario defined in the frame of GNSS UT TA application performance specification shall be complaint with the UERE/UERRE table reported in the following (TBC and TBD): TBD UERE budget: GPS Dual Frequencies with integrity in urban environment TBD UERRE budget: GPS Dual Frequencies with integrity in urban environment

49 Class: PUB Page 49 / 130 REQ-GNSSUT-EE-TA-220 Title Galileo Single Frequency on L1 with integrity urban nominal scenario The Galileo Single Frequency on L1 urban nominal scenarios defined in the frame of GNSS UT TA application performance specification shall be complaint with the UERE/UERRE table defined in the TUSREQ document and reported in the following: TBD UERE budget: Galileo Single Frequency (L1) in urban environment TBD UERRE budget (200ms): Galileo Single Frequency (L1) in urban environment REQ-GNSSUT-EE-TA-230 Title Galileo Single Frequency on E5b with integrity urban nominal scenario The Galileo Single Frequency on E5b urban nominal scenarios defined in the frame of GNSS UT TA application performance specification shall be complaint with the UERE/UERRE table defined in the TUSREQ document and reported in the following: TBD UERE budget: Galileo Single Frequency (E5b) in urban environment TBD UERRE budget (200ms): Galileo Single Frequency (E5b) in urban environment REQ-GNSSUT-EE-TA-240 Title Galileo Dual Frequencies with integrity urban nominal scenario The Galileo Dual Frequencies urban nominal scenario defined in the frame of GNSS UT TA application performance specification shall be complaint with the UERE/UERRE table defined in the TUSREQ document and reported in the following: TBD UERE budget: Galileo Dual Frequencies in urban environment UERRE budget (200ms):Galileo Dual Frequencies in urban environment

50 Class: PUB Page 50 / Performance requirements REQ-GNSSUT-EE-TA-250 Title Position accuracy The Integrity Function implemented in the frame of the EE GNSS-UT shall provide a position accuracy of 1 m (see technical analysis in Appendix AAPPENDIX and B) This value shall be considered as a target value depending on the GNSS UT operational conditions as follows: GNSS Availability Accuracies (m) GPS Egnos Galileo with integrity Urban Rural Single freq. No Dual freq No Single freq. Yes Dual freq Yes Single freq on L1BC Single freq on E5b Dual freq on L1BC/E5b No no no Typical distance between tracks (Spanish high speed line): 4,7 m REQ-GNSSUT-EE-TA-260 Title Maximum response time 120 s from GNSS first fix (the first valid position) See Technical analysis in Appendix A Total time shall be < 3 minutes, according to agreement of 7/11/2006 (Madrid meeting). REQ-GNSSUT-EE-TA-280 Title Availability The Accuracies specified above shall be met for 95% of the time, in any place within the service volume, when operating in the Nominal SIS Constellation state. REQ-GNSSUT-EE-TA-290 Title Continuity The Integrity Function implemented in the frame of the EE GNSS-UT continuity shall be better than TBD REQ-GNSSUT-EE-TA-300 Title Reference Time The Integrity Function implemented in the frame of the EE GNSS-UT shall time stamp integrity information data according to the GNSS-EE-UT reference time.

51 Class: PUB Page 51 / 130 REQ-GNSSUT-EE-TA-310 Title Output solution rate The Output of the Integrity Function implemented in the frame of the EE GNSS-UT shall be provided at a 1 Hz rate or higher (TBC). REQ-GNSSUT-EE-TA-320 Title Environmental requirements The Performance of the Integrity Function implemented in the frame of the EE GNSS-UT shall be independent from environmental influences topography and buildings. REQ-GNSSUT-EE-TA-330 Title Data storage The Integrity Function implemented in the frame of the EE GNSS-UT shall store (provide the Juridical recorder TBC) the following set of data (TBC), and these data shall be time stamped ( reference to be agreed ) : - Configuration parameter at each change of configuration performed by the train staff. - All the alarms generated by the subsystem - All the sub-system change of status - The real time status corresponding to a given time window (TBD) ending at the last sample sent to the on-board equipment.

52 Class: PUB Page 52 / Test requirements REQ-GNSSUT-EE-TA-340 Title Test scenarios identification The Train Cold Movement detector and Train Awakening function shall be tested at least in the following scenarios: Nominal Operational scenarios for position qualification/identification o OP_Scenario_Position 1: SoM with invalid or unknown position. Train in awakening area o OP_Scenario_Position 2: SoM with invalid or unknown position. Train not in awakening area o OP_Scenario_Position 3: SoM with valid (or to be revalidated) position. No cold movement o OP_Scenario_Position 4: SoM with valid (or to be revalidated) position. Cold movement Degraded Operational scenarios for position qualification/identification o Degraded OP_Scenario_Position 1a: SoM with invalid or unknown position. Train in awakening area. Enhanced Train Awakening is not available (system failure or SIS not available) o Degraded OP_Scenario_Position 1b: SoM with invalid or unknown position. Train in awakening area. Enhanced Train Awakening is available but positioning is calculated with unacceptable error range o Degraded Scenario_Position 3_4: SoM with valid (or to be revaidated) position. Cold Movement Detector is not available Nominal operational scenarios for RBC ID/phone number o OP_Scenario_RBC_number 1: SoM with invalid or unknown RBC ID/ Phone Number o OP_Scenario_RBC_number 2: SoM with known and valid (or to be revalidated when entering NP) RBC ID/ Phone Number. No cold movement o OP_Scenario_RBC_number 3: SoM with known and valid (or to be revalidated when entering NP) RBC ID/ Phone Number. Cold movement Degraded operational scenarios for RBC ID/phone number o Degraded OP_Scenario_RBC_number 1: SoM with invalid or unknown RBC ID/phone number. Enhanced Train Awakening is not available o Degraded Scenario_ RBC_number 2_3: SoM with valid (or to be revalidated ) RBC ID/phone number. Cold Movement Detector is not available The CMD function will be activated all over along the track, Enhanced Train awakening functions would be restricted to limited areas where reference points were stored in GNSS subsystem according to infrastructure definition.

53 Class: PUB Page 53 / Input / Output definition REQ-GNSSUT-EE-TA-430 Title Communication The Cold Movement Detector and Enhanced Train Awakening communication versus ETCS On-board shall be a bi-directional communication. REQ-GNSSUT-EE-TA-435 Title CMD standstill trigger from ETCS on-board to User terminal ETCS on-board is powered off. This message shall trigger CMD module for supervising cold movement. Message should have similar structure to standard ETCS messages. The required information with a Euroradio-like format is: NID_PACKET Unique identifier number for CMD standstill trigger L_PACKET Message length T_TRAIN Time Stamp from kernel NID_ENGINE On-board ETCS identity (optional TBD) REQ-GNSSUT-EE-TA-440 Title CMD Information request from ETCS on-board to User terminal ETCS on-board is requesting CMD confirmation. Message should have similar structure to standard ETCS messages. The required information with an Euroradiolike format is: NID_MESSAGE Unique identifier number for CMD information request L_MESSAGE Message length T_TRAIN Time Stamp from kernel NID_ENGINE On-board ETCS identity (optional TBD) REQ-GNSSUT-EE-TA-450 Title Enhanced TA information request from ETCS on-board to User terminal ETCS On-board is requesting Enhanced TA information. Message should have similar structure to standard ETCS messages. The required information with an Euroradio-like format is: NID_MESSAGE Unique identifier number for Enhanced TA information request (one ID is applicable to request position information and other to request RBC ID/phone number) L_MESSAGE Message length T_TRAIN Time Stamp from kernel NID_ENGINE On-board ETCS identity (optional TBD)

54 Class: PUB Page 54 / 130 REQ-GNSSUT-EE-TA-460 Title CMD Status information request from User terminal to ETCS on-board Upon ETCS on-board CMD requesting, User terminal is sending CMD status. The required information with an Euroradio-like format is: NID_MESSAGE Unique identifier number for CMD Status L_MESSAGE Message length T_TRAIN Time Stamp from UT NID_ENGINE On-board ETCS identity (optional TBD) Q_CMD Cold movement information 0 Unable to provide information 1 Cold Movement detected 2 No cold Movement detected REQ-GNSSUT-EE-TA-470 Title Enhanced TA information request from User terminal to ETCS on-board Upon ETCS on-board CMD requesting, User terminal shall send Train Awakening relevant information concerning distance and orientation with regard to a defined reference, as well as RBC ID/phone number. The required information from the Enhanced TA module with an Euroradio-like format is: NID_MESSAGE Unique identifier number for Enhanced TA information L_MESSAGE Message length T_TRAIN Time Stamp from UT NID_ENGINE On-board ETCS identity (optional TBD) Q_TA_STATUS Status of Enhanced TA module and provided information 0 Invalid information (error status of TA module) 1 Valid 2 Unknown (out of TA area or unable to provide information) Q_SCALE Distance scale (ETCS values) NID_LRBG Identity of the reference point (known by RBC) D_LRBG Distance between reference point and front end of the train (distance between Antenna position and front end must be an internal parameter to UT) Q_DIRLRBG Orientation of train in relation to reference point (ETCS values) Q_DLRBG Side of the reference point where front end is NID_C Identity number of country or region (ETCS values) NID_RBC RBC ETCS identity number (ETCS values) NID_RADIO RBC Radio subscriber number/phone number (ETCS values) REQ-GNSSUT-EE-TA-480 Title Configuration Parameters TBC

55 Class: PUB Page 55 / 130 REQ-GNSSUT-EE-TA-490 Title Data Base - UT has the list of reference points and areas where Enhanced TA is allowed according to a predefined format - UT has a list of RBC ID's and Phone numbers that control the TA areas TBC Other requirements REQ-GNSSUT-EE-TA- 500 Title Error estimation and calibration if needed The GNSS TA and CMD system shall provide information only when the confidence interval of the measurements is acceptable Degraded operation may be defined REQ-GNSSUT-EE-TA- 510 Title Power on self test and TA and CMD information Start-up self test to ensure that the system is working according to the specifications. The system shall inform the kernel of the successful completion of the tests and of its nominal accuracy 3.3 Impact on the SRS The proposed enhance ERTMS functionalities (CMD and Enhanced TA) have an impact in ERTMS/ETCS System Requirements Specifications. Flow charts presented in Figure 6 and Figure 7 and requirements described in Table 1 and Table 3 must be incorporated to nominal Start of mission procedure described in [9] and [10]. Several possibilities could be addressed depending on SRS version and CMD-TA functionality Trackside Subsystem The selected solution has no impact on the Trackside Subsystem. Onboard Subsystem The selected solution has only impact on the start of mission procedure of the onboard equipment. Therefore the operation of the Start of Mission has to be changed. This has influence on the architecture and the data flow between the kernel and connected subsystems. Beside the changing start of mission procedure there is no impact on the specification of the SRS. The Impact of the CMD functionality and the TA functionality are described in the following

56 Class: PUB Page 56 / Impact of CMD functionality CMD functionality shall be incorporated before the nominal start of mission procedure according to EEIG Change Request 514. This is applicable for both versions of SRS as shown in Figure 6 and Figure Impact of TA functionality Two different options are defined for the incorporation of Enhanced Train Awakening function in nominal Start of mission flow chart (Figure 6 and Figure 7 ). - Option 1: o Train Position Data: Incorporation of Enhanced Train Awakening in the decision D32 of nominal Start of Mission flow chart of both references [2] and [3]. o RBC ID/phone number: Incorporation of Enhanced Train Awakening in the decision D1 of nominal Start of Mission flow chart of both references [2] and [3] During switching on process, stored data has been qualified by CMD A session with RBC is opened If needed on-board requires position information from Enhanced TA module Nominal SoM procedure proceeds - Option 2 : o Train Position Data: Incorporation of Enhanced Train Awakening information in S21 (Send MA request to RBC and wait) of nominal Start of Mission flow chart of both references [2] and [3]. In this case, when on-board reaches step S21 with unknown stored position, it requires information from Enhanced TA module in order to send a defined position report. This approach, although less conventional that the previous on, could have a lower impact in actual implementations. o RBC ID/phone number: Incorporation of Enhanced Train Awakening in the decision D1 of nominal Start of Mission flow chart of both references [2] and [3] as in previous option.

57 Class: PUB Page 57 / 130 S0 Cab is active and mode is SB From S14 S1 The on-board requests the driver to enter/re-validate Driver-ID E1 : Driver has entered/ revalidated valid Driver-ID D1: Stored level is 2/3 and Yes RBC-ID + phone A31 number are Onboard contacts RBC invalid or valid No CMD STM A1 Onboard requests Driver to select the STM corresponding to the mission S2 Onboard requests Driver to enter/re-validate level 2/3 0/1 S3 Onboard requests Driver to enter/re-validate RBC-ID + phone number D31 Session with RBC can be opened Yes D32 Stored position is valid No No Yes A32 Onboard informs Driver A33 Onboard reports valid position to RBC TA for RBC ID E6 : Driver has selected the STM E5 : Data entered by Driver E7 : Driver selects No S4 Onboard requests Driver if he wants to continue without session opened A34 Onboard reports invalid or unknown position to RBC D33 RBC is able to confirm position No Yes A35 RBC reports to Onboard valid position TA for position option 1 E8 : Driver selects Yes No D2 Session is opened D22 RBC accepts train Yes No A38 RBC reports to Onboard train rejected NL mode E10 : Driver selects NL Yes S10 Waiting for Driver selection A23 RBC reports to Onboard train accepted A39 Onboard terminates session and deletes stored position data E11 Driver selects Train Data Entry A24 Onboard deletes stored position data A40 Onboard informs Driver See procedure SH initiated by Driver E12 : Driver selects SH E13 : SH refused by RBC S12 Onboard requests Driver to enter/revalidate train data E16 Train data are validated Go to S2 D10 Level 2/3 E17 Driver selects 0/1/STM Yes D11 Session is opened No S14 Wait for Driver selection E15 : Driver selects Override See procedure override EOA E20 : Driver selects Start and Level is STM S11 Onboard sends train data to RBC and wait for ack E14 Train data ack by RBC S20 Waiting for Driver selection of Start E24 : Driver selects Start and Level is 2/3 E21 : Driver selects E22 : Driver selects Start and Level is 0 Start and Level is 1 E26 : SR mode authorised by RBC S21 Send MA request to RBC and wait E27 : OS/SH MA received from RBC TA for position option 2 S22 S23 S24 STM mode proposed to UN mode proposed to SR mode proposed to Driver Driver Driver E30 : Driver ack E31 : Driver ack E32 : Driver ack S25 OS/SH mode proposed to Driver E33 : Driver ack E29 : FS MA received from RBC SE/SN mode dependent on selected STM UN mode SR mode OS/SH mode FS mode Figure 14: Impact of CMD/TA functionalities in ERTMS/ETCS specs version [2]

58 Class: PUB Page 58 / 130 CMD TA for RBC ID TA for position option 1 TA for position option 2 Figure 15: Impact of CMD/TA functionalities in ERTMS/ETCS specs version [3]

59 Class: PUB Page 59 / ABSOLUTE POSITIONING 4.1 Application definition In the ETCS, the usual practice for Odometry consists of a tachometer attached to an axle or traction component and whose errors are reset periodically by a reference Eurobalise group, known as Last Relevant Balise Group (LRBG). The location of the LRBG is known with a tolerance of about + 5 m + 5% s and is used to reset the odometer error to this value as well as the definition of specific locations. This practice is still used in the enhanced odometry mode In comparison with this enhanced odometry mode, where the basic information is the speed measurement (Doppler shift measured by the GNSS receiver), the absolute positioning mode provides a way to have a direct access on the positioning without integration of the speed. As a consequence, one of the main advantages of absolute positioning is the possibility to have a confidence interval on the travelled distance, which is independent of the travelled distance and dependent only of the GNSS measurement accuracy, satellites geometry, integrity technique and transformation from GNSS absolute 3D position to 1D along track distance. Another main objective of absolute positioning is the possibility to generate location information with an integrity level compatible for SIL4 application (as demonstrated in particular in Locoprol project see associated documents [22], [24]and [23]). Nevertheless, ETCS is intrinsically based on a train location referenced to balises in the track. Consequently, translation process is mandatory in order to integrate this concept into ETCS. A common coordinate system for trackside and trainborne is therefore necessary and one solution to achieve that is the use of a digital map containing balises ID and position in the GNSS referential (in fact balises or reference points or other elements that may be useful for train positioning). A first issue to be addressed is therefore the physical location of the database: in the GNSS subsystem or in the ETCS subsystem and the associated management process. Independently of this digital map, a second one could be used for the positioning algorithm within the GNSS subsystem (Locoprol approach: 1D algorithm using a vectorial modelisation of the track). As a consequence, the GNSS subsystem shall include these possibilities as well as the management mechanisms. This position information, with high integrity level, can be used in two different ways: - As input to the ETCS odometry (Locoprol approach) - As input to the ETCS BTM (fixed reference points approach). Both approaches are detailed below: LOCOPROL approach: In the Locoprol approach (see also associated documents [22], [24]and [23]), the position information provided by the GNSS subsystem is used as input of a fusion process that makes a real time comparison of 2 safe position estimations: - The first one is the travelled distance computed on the basis of the absolute positioning - The second one is the travelled distance computed by integration of speed. In this way, one can consider that the GNSS is the primary sensor and the other sensors will be used either in the area where satellite visibility is insufficient or in the vicinity of a balise where speed integration provides a more accurate estimate.

60 Class: PUB Page 60 / 130 On the other hand, in complement of the absolute positioning, the speed data (as defined in the enhanced odometry) can be used as one of the other sensors when available. It is possible to gain precision by taking advantage of the best-computed data available from both systems while keeping the required safety level (the confidence intervals computed by the two systems, with the same integrity level, are compared and the best one - the smallest - can be retained to gain precision). Track digital map: - track Satellite based positioning Fail Safe Position, Speed Fusion ETCS trainborne application Classical odometry ETCS Onboard subsystem Classical Sensors (e.g. Wheel sensor) Figure 16: LOCOPROL fusion approach Consequently, in this approach, we can consider any GNSS measurement ( absolute position) as a reference point from which an odometry reset can be performed if it results into a better position estimation. The following figure illustrates this solution:

61 Class: PUB Page 61 / 130 Estimated Traveled Distance (Relative to LRBG) Odo_Upper_bound Fusion_upper_bound Fusion_Rear Odo_Rear Real Distance B1 Figure 17: LOCOPROL fusion principle Remarks on the figure above: Balises are represented by symbols B1, B2. They become the origin of the X axis when a re-location is made; - The upper red line represents the estimated distance (relative to LRBG) of the front end position of the train as calculated by the classical odometry; The lower cyan line represents the estimated distance (relative to LRBG) of the rear end position of the train as calculated by the classical odometry;

62 Class: PUB Page 62 / 130 The vertical difference between the red and cyan lines represents the length of the confidence interval (including the length of the train) as calculated by the classical odometry; The upper green points represent the estimated distances (relative to LRBG) of the front ends of the confidence intervals as calculated by the GNSS Sub-system ( absolute positioning); The lower green points represent the estimated distances (relative to LRBG) of the rear ends of the confidence intervals as calculated by the GNSS Sub-system ( absolute positioning); The vertical difference between the green points represents the length of the confidence interval (including the length of the train) as calculated by the GNSS Sub-system ( absolute positioning); - The black dotted lines represent the result of the fusion process; The fusion rule for the upper points is: the best front end point, between a red and a green point taken vertically, is the one with the smallest distance relative to LRBG; The fusion rule for the lower points is: the best rear end point, between a cyan and a green point taken vertically, is the one with the greatest distance relative to LRBG; The fusion process can only start after a re-location on a first balise group occurs. A that moment the starting reference point will be known as well as the direction of movement in the track; - Measurements made by classical odometry and GNSS are not synchronous. Measurements are re-synchronized during the fusion process. The estimated safety distance is computed relative to the last relevant balise group crossed. It is the reason why at some places the distances are reduced to near zero (in this case the length of the train if not taken into consideration in the reasoning). At these points the precision is very good with the classical odometry (the position of the balise is known with a very good precision and the error on position is very small). As we move away from the balise the inaccuracy on the position increases and the curves diverge. On the other hand, the GNSS sub-system computer delivers a position confidence interval (PCI) which is relatively constant over the time - in the same environment - and when it relocates over a balise the precision is not improved. The PCI is just offset relatively to the balise. So, near a balise, classical odometry provides better precision than GNSS odometry and as we move away from the balise, the GNSS odometry, at some point, becomes better than the classical one. The fusion process analyses continuously which is the best and switch on it. It has to be noted that, in Locoprol, the fusion process is used for odometric corrections only. It allows to increase the distances between trackside balises and do not generate virtual reference points Absolute Positioning Reference Point approach: It could be envisaged different levels of use of Absolute Positioning Reference Points (APRP): 1. Simple odometric use for virtual re-location only.

63 Class: PUB Page 63 / 130 A balise triggering is used to induce a re-location based on GNSS absolute positioning and odometric measurements. Should the GNSS confidence interval be better than the odometric one, the GNSS one will be used. If it is not the case, the odometric one will be used. The drawback of this method is that at the moment of the triggering, GNSS measurements could not be good enough (i.e. bad DOP) but a few moments before they were and that advantage is lost (which is not the case with the Locoprol approach). The figure below shows the APRP odometric principle: Estimated Traveled Distance (Relative to LRBG) Odo_Upper_bound Fusion_upper_bound Fusion_Rear Odo_Rear Real Distance B1 B2 Figure 18: APRP odometric principle

64 Class: PUB Page 64 / Higher level of use where virtual re-location points are recognized by the RBC and replace physical balises for the positioning report (at long term all the physical balises could be replaced by APRP). Several interoperability and performance problems will arise for trains not equipped with GNSS and the absolute positioning system (APS), e.g. missing linking and information about locations and related reactions. Another serious problem to solve is the precision to which the position of the APRP will be determined with the correct integrity level Operational benefits The Operational benefits of both approaches could be in the improved performance of the railway operation. These could be: Reduction of number of Balises bordering shunting area (requires shunting engines to be equipped with the APS without exception), Shortening of the overlapping, Increase of the distance between the trackside installed Balises - when the Balises only have the function of Odometry correction Operational scenarios This chapter describes the operational scenarios and the related migration strategy Scenario 1: captive lines In this the ideal configuration, we can assume that the complete wayside and all trains will be fitted with new functionalities: Wayside can be equipped with some digital map management; trains fitted with UT (User terminal) implementing both enhanced odometry and enhanced ETCS (including absolute positioning). Interoperability is not required because trains are dedicated to this line and no external trains are allowed to run on the line. In this scenario, no migration strategy is needed and specific solution can be adopted for the communication between wayside and trainborne if not included in ETCS specifications. As far as existing equipment has to be replaced, a kind of local migration strategy is needed, which not must take care of ETCS. Trainborne equipment could be limited to UT without any need for additional sensor if GNSS coverage is guaranteed at 100% (naturally or through local augmentation). On lines with very low traffic a GNSS reception hole can be used, too Scenario 2: lines requesting some interoperability In this case, the line is supposed to be run by other trains not necessarily fitted with absolute positioning functionalities. In the first case, the train will work in normal ETCS level 2 or 3 mode without GNSS absolute odometry.

65 Class: PUB Page 65 / 130 This scenario can be also considered as a migration phase between the commissioning of the line and the first trains and the fitment of the whole train park. In this scenario, a possible migration is as follow: - Line commissioning in ETCS level 2 with digital map management and limited amount of balises. - Commissioning of first trains or engines with GNSS absolute positioning functionality. - Management of the trains during migration phase with 2 different levels of performance. - End of migration, all trains are fitted. A single, high level of performance is reached. If trains are not captive to this line, it will be difficult to guarantee complete GNSS coverage: additional sensor(s) will be necessary. There is a specific strategy needed to handle not equipped trains, if they are coming to this area. It is possible to create a kind of fallback strategy so a train without GNSS absolute positioning can run with a reduced performance or the use of a portable solution (which could be difficult to prove safety) Scenario 3: lines requesting full interoperability The scenario 3 is similar to scenario 2 but all trains must be managed with same level of performance. During the migration phase, the wayside will be equipped with standard balises implementation. The train fitted with GNSS will be able to run in enhanced odometry mode or in absolute positioning mode. Once the full train park is equipped, all UT will be switched to absolute positioning and the trackside will be simplified (removal of passives balises) Scenario 4: lines requesting full interoperability with GNSS-based linking The scenario 4 is similar to scenario 3 so that all trains must be managed with same level of performance. To improve this level of performance, the linking is extended to the GNSS absolute positioning. To exploit the possibilities of the GNSS absolute positioning to improve the performance the mechanism of linking is extended to the digital map of the GNSS UT. There are different possibilities: 1) The digital map adds information to the linking, but the physical Balises form the basic network of linking. The performance of trains with UT is a little bit higher than without UT. 2) The digital map has second net of linking between the absolute positioning reference positions. So the trains with UT and digital map can run in higher performance. This is only recommended if most of the trains have an UT. 3) The network of linking between physical Balises and absolute positioning reference positions is mixed. This will probably lead to problems with the safety case of trains without UT. 4) The only network of linking is in the digital map. There are no references to physical Balises. This situation is the last step before scenario Scenario 5: fitted trains running on unfitted lines In this scenario, trains fitted with UT are authorized to run on lines not fitted or not:

66 Class: PUB Page 66 / Fitted line: integrating digital map management and reduced amount of balises - Not fitted line: no digital map management and standard balise implementation. The fitted train will use its UT in enhanced odometry mode (without digital map) if track is unfitted or if train is not able to get the corresponding digital map. The fitted train must be able to switch between the 2 modes enhanced odometry or absolute positioning. At least the fitted train must detect that he is outside of the area of the valid map and switch to the enhanced odometry mode. So this mode will be used as fallback mode on equipped tracks if the map is not valid Scenario 6: Migration to final step In this scenario, the final solution is supposed to be ETCS without any balises: Fixed balises have been replaced by systematic fitting of trains with absolute positioning. Active balises have been cancelled through adaptation of ETCS. In this very long term scenario, all trains are fitted with GNSS based odometry only, trackside have been completed by local augmentation (and ERTMS specifications evolved consequently). Trains are no more fitted with Eurobalise reader/btm. The complete safety mechanism of linking is implemented in the UT and the digital map. Trains without UT are not allowed to use these lines (A portable solution can be used to solve this problem) Compatibility table: The following table shows the compatibility between the different levels of equipment: Wayside Trainborne Trackside Standard Trackside GNSS (digital map management, reduced amount of Balises, without GNSS linking) Trackside GNSS (digital map management, reduced amount of Balises, with linked GNSS) UT fitted Yes, Enhanced odo or absolute positioning if digital map is available Yes, Absolute positioning only little improved performance Yes, Absolute positioning, improved performance Non UT fitted Standard odo Yes, but with little degraded performance Yes, but with degraded performances Trackside without balises Yes, absolute positioning No Table 5. Scenario compatibility table Migration strategies The following figure shows the different migration strategies

67 Class: PUB Page 67 / 130 «Open» Full Interoperability lines Trackside with digital map management Trainborne with UT in enhanced odometry Trackside with digital map management Trainborne with UT in enhanced odometry + absolute positioning Trackside with digital map management Captive lines or lines with limited interoperabilit y Trackside with digital map management and reduced amount of Trainborne with UT (enhanced odometry +absolute positioning) Trackside with digital map management and reduced amount of Trainborne with UT (enhanced odometry +absolute positioning) Trainborne with UT in enhanced odometry + absolute positioning with existing ETCS specif. with new ETCS specif. (digital map management through Euroradio) Level 2 Level 3 Short term Middle term Long term Figure 19: Possible migration strategies The migration can be started by using the cold movement detection and the train awakening support. These are included in the short-term measures. Due to the fact, that they are not different for the captive lines or the fully interoperable ones, they are not shown in this diagram. 4.2 System requirement specification GNSS AP System Functional

68 Class: PUB Page 68 / 130 Travelled Distance, Speed, acceleration Confidence Interval Balise trigger SiS Navigation data GNSS Absolute Positioning Status ID-Balise ETCS On- Board APRP Message Telegram Database update Context Diagram Confidence Interval SiS Navigation data GNSS Receiver 1 GNSS Raw data Travelled Distance, Speed, acceleration Integrity data GNSS Algorithm 2 Integrity data Integrity Monitoring 4 Database Management 3 Integrity data Balise Trigger APRP Message Telegram List of balises, track modelisation ID Balise Database update Database validation List of balises, track modelisation Database ETCS On- Board Integrity Status Level 1 Figure 20: Absolute Positioning subsystem Function Specification for the GNSS Subsystem The GNSS subsystem shall perform the following functions in the frame of the absolute positioning application: - Compute train position:

69 Class: PUB Page 69 / 130 This function shall compute the real time train position in terms of travelled distance from the last LRBG or the last APRP This position shall be obtained on the basis of the data provided by the GNSS receiver(s) and possibly on the basis of the track map information contained in the internal database. This function shall include integrity monitoring. This function shall determine the confidence interval on the position corresponding to the required high integrity level. This function shall provide a position data compatible with SIL4 application without need of any fusion in the area for which visibility is sufficient. - Data translation in ETCS reference: The positioning data obtained in the GNSS referential will be translated into a travelled distance from: the LRBG on the basis of: o The trigger received from the ETCS subsystem when crossing a balise o The ID of the balise received from the ETCS o The location of this balise in the GNSS referential (part of the internal database). the last APRP on the basis of: o The trigger generated by the UT when crossing an APRP o The ID of the APRP stored in the UT o The location of this APRP in the GNSS referential. (Note: obviously, in this case the position of the APRPs and the distance between them will be known by the RBC. The travelled distance from the APRP (front end and rear end of the confidence interval) are transmitted to the ETCS as well as the balise ID corresponding to the APRP). - Compute train speed: This function shall compute the real time train speed module and shall determine the confidence interval on the speed corresponding to the required integrity level. The GNSS subsystem shall provide speed information corresponding to two level of safety integrity: A speed with a low level of integrity: The same principle as Enhanced Odometry: GNSS receiver is considered at the same level that other odometry sensors and provides a speed data. ETCS uses this speed for some tasks. A speed with a high level of integrity: This function shall provide a speed data compatible with SIL4 application without need of any fusion in the area for which visibility is sufficient. This speed shall be obtained on the basis of the data provided by the GNSS receiver(s), the track map information contained in the internal database and the real time train position provided by Compute train position function.

70 Class: PUB Page 70 / 130 Having the track map allows comparing the direction of the absolute velocity computed by the GNSS with the direction of the expected train vector; this would need a transformation from GNSS coordinate frame into track map coordinate frame and projection of the GNSS velocity components on the track vector and can provide an additional integrity check. Track map format however must be defined. - Compute time: - This function takes SIS in input and provides the Universal Time Coordinated (UTC) in output. - Provide APRP information to ETCS: The ETCS on-board shall be able to process data coming from UT about APRP information (telegram equivalent to balise telegram to BTM) so that the odometry will make fusion. - Integrity Monitoring function: This function monitors the integrity of the SIS (including the local effect such as alternate and multipath effects) as well as the integrity of the UT itself. According to the availability, the quality and the integrity of the Signal in Space, the output of this function will determine the integrity and the quality associated to the output of UT. This function shall monitor the integrity of the database internal to the UT. - Data base management: This function updates the data stored in database; it will communicate with the EVC to receive the missing versions of the digital map (Interface to be defined by this specification). The GNSS subsystem shall manage the database that contains at least the list of balises (ID and location) as well as the vectorized modelisation of the track (Format to be defined by this specification). The GNSS sub-system shall manage the initialisation at start-up, in particular shall verify the validity of the database through a communication with the EVC. This interface definition depends on the system database architecture and management process (Interface to be defined by this specification). The GNSS subsystem shall manage the downloading of the database. This interface definition depends on the system database architecture and management process. The database shall contain the necessary information for the balises linking (necessary in APRP approach) External interface description Interfaces of the GNSS subsystem are the following: These interfaces will depend on the agreed architecture. Inputs: - ID-balise - Balise trigger (TBD) - Database download - Outputs: - GNSS Raw Data

71 Class: PUB Page 71 / Travelled distance: The distance travelled starting from the beginning of a segment; This position will be usable for an application SIL4 and given in ETCS reference - Speed (high integrity) - Speed (low integrity) - ETCS Time stamp (not available from the GNSS subsystem. UTC or GNSS time stamp can be provided) - GNSS time - Speed Confidence interval (high integrity) (TBD) - Speed confidence interval (low integrity) not available - Acceleration optional TBD - Status - APRP message telegram. It should be equivalent to a balise telegram to a BTM. To be completed with detailed database management dataflow Remarks on speed expression: The high integrity speed is usually expressed in the form of two values: the upper bound of the speed confidence interval and the lower bound of the speed confidence interval. The confidence interval is just the difference of the two values; The low integrity speed can be expressed in a similar way System architecture As explained in the introduction, the UT is able to provide positioning information that can be used different way within the ETCS subsystem. The proposed architecture is based on the following assumptions: - The UT provides a SIL4 positioning information, which is not the result of speed integration but corresponds to a GNSS absolute positioning. - The referential translation is performed in the GNSS subsystem. This translation is implemented by use of a database containing the balise ID and the balise location in the GNSS reference frame. - In pure odometric approach, the UT can generate error corrections either based on variable points, as soon as GNSS measurements are better than the odometric ones, or on fixed arbitrary points which are triggered by the UT itself and based on reference points contained in the UT database. - The reference translations performed in the GNSS subsystem can be triggered by signals coming from the ETCS and based on the detection of physical balises. Two cases can be considered: Case with balise ID not contained in the UT database: the signal can be used to reset the along track distance using the information coming with the balise telegram. The GNSS will compute a balise position along the track based on the time tagged information. To do this it shall be able to retrieve the position confidence interval (PCI) corresponding to the balise time tag (it is supposed that this information is

72 Class: PUB Page 72 / 130 available in the UT for some time). The uncertainty on the balise position will correspond to the PCI computed at that moment. The drawback of this approach is clearly that the new PCIs computed relative to the last balise will include the uncertainty on the balise position; Case with balise ID contained in the UT database: this signal can be used to reset the along track distance using the information coming with the balise telegram and the information contained in the balise database (stored in the UT with a good accuracy). The UT will retrieve the balise location from the transmitted ID and compute the new PCIs relative to this balise; - In pure APRP approach the reference translations performed in the GNSS subsystem are triggered by the UT itself. A APRP database is stored in the UT and contains an association of APRPs locations. The trigger generated by the UT itself is based on APRPs contained in the UT database. It can be used to reset the along track distance. The UT will compute the new PCIs relative to the last APRP. The UT shall send to the ETCS the APRP information to be able to compute a correct positioning report. - The GNSS subsystem contains a track map (to be defined) that contains at least a vectorised modelisation of the track (to be defined later on). - The interface between the GNSS subsystem and the ETCS subsystem will be in such a level that both implementations (fixed or variable reference points) are possible within the ETCS subsystem. In the first case the information will be used as input of the BTM, on the second one, as input of the odometry macro function. GNSS Subsytem Balises database Track map Database management Balise ID Abs.Positioning 1D High integrity (in ETCS referential) Speed 1D High integrity APRP ID BTM Odometry Other sensors ETCS Subsytem Figure 21: Absolute positioning architecture

73 Class: PUB Page 73 / 130 GNSS absolute positioning System GNSS absolute positioning System Figure 22: Entry of the absolute position information In consideration of this architecture, one main issue is the database. The database format, the database management architecture and process will influence the interface between the GNSS subsystem and the ETCS subsystem but also the modification within the ETCS Subsystem. Based on the previous assumptions, the following architecture has been retained: UT GNSS Receiver GNSS Algorithm Balises database Integrity monitoring Track map Database management GNSS raw data Balise_ID APRP ID High integrity Abs.Positioning (in ETCS referential) High integrity speed BTM ETCS ONBOARD Odometry Other sensors Figure 23: Architecture configuration As can be seen from the figure above, UT shall include the following functions:

74 Class: PUB Page 74 / 130 o GNSS receiver; o Track map; o GNSS absolute positioning algorithm (position and speed); o Integrity monitoring; o Balise / APRP database. UT inputs that are required from ETCS onboard are: o Balise trigger & ID when physical balises are used; o Database management data. UT outputs to ETCS onboard that are required are: o APRP information when APRP approach is used; o GNSS raw data (raw measurements + decoded navigation messages) o High integrity absolute positioning in the ETCS reference frame; o High integrity speed; o Database management data. This structure has the advantage to cover the different cases of absolute positioning described above and to minimize the impact on the (proprietary) ETCS equipment on board Requirements for the Onboard and trackside modules Specific concept is the same provided in section Definitions are given in section Enhanced ETCS GNSS-UT Requirements In the following sections we have reported the main functional and performance requirements allocated to the EE GNSS User terminal for the Absolute Positioning function. For the GNSS Receiver requirements, considering its crucial role in the GNSS UT Equipment for both EE and EO, and considering also that right now no differences have been highlighted between EE and EO, we propose to refer to the WP for Receiver high-level specification. In comparison with this enhanced odometry mode, where the basic information is the speed measurement, the absolute positioning mode provides a way to have a direct access on the positioning without integration of the speed GNSS-UT for Enhanced ETCS application: Absolute Positioning Requirements In this section we have reported the main functional and performance requirements allocated to the EE GNSS User terminal for the Absolute Positioning Function. The Absolute Positioning Function requirements will be denoted with the acronym REQ-GNSSUT-EE-AP-xx Functional requirements

75 Class: PUB Page 75 / 130 REQ-GNSSUT-EE-AP-010 Title Purpose The Absolute Positioning Function implemented in the frame of the EE GNSS-UT shall provide the ETCS on-board with a position information, with a high integrity level, in a referential usable by an onboard ETCS subsystem. The integrity level shall be compatible with SIL4. REQ-GNSSUT-EE-AP-020 Title Functions The Absolute Positioning Function implemented in the frame of the EE GNSS-UT shall perform the following sub-functions: o Compute train position o Perform the Data translation in ETCS reference o Compute train speed o Compute time o Perform Integrity Monitoring o Manage the Data base. o Provide APRP information to ETCS REQ-GNSSUT-EE-AP-030 Title Coordinate System Definition The Absolute Positioning Function implemented in the frame of the EE GNSS-UT receiver shall use a coordinate system common to trackside and trainborne, achievable using of a digital map containing track topologies, reference points ID in the ETCS system and geodetic positions both in the track coordinates system (track ID, track meter) and in the GNSS coordinates system (e.g. WGS 84) (*). (*) Balises or reference points or other elements that may be useful for train positioning. The functions defined above are specified in the following sections. REQ-GNSSUT-EE-AP-040 Title Absolute Positioning Function Operative Mode The Absolute Positioning Function implemented in the frame of the EE GNSS-UT system should include (at least) the following Operative Mode to foreseen different corresponding operational conditions: Internal check/consistency Mode Initialization Mode; Acquisition Mode; Full Operational Mode; Degraded operational mode. Transitions between those modes shall be defined. The degraded operational mode shall be intended as a dead reckoning mode. REQ-GNSSUT-EE-AP-050

76 Class: PUB Page 76 / 130 Title Unlocked GNSS Signals When the GNSS RX do not provide navigation data (SIS loss), the Absolute Positioning Function implemented in the frame of the EE GNSS-UT shall be able to provide appropriate information containing the degraded conditions. REQ-GNSSUT-EE-AP-060 Title Data acquisition/reacquisition The Absolute Positioning Function implemented in the frame of the EE GNSS-UT shall be able to automatically restart after a GNSS SIS or navigation data reacquisition. REQ-GNSSUT-EE-AP-070 Title Data fusion The Absolute Positioning Function implemented in the frame of the EE GNSS-UT shall implement data fusion to blend GNSS data with other sensors data using configuration data, to calculate the output information. The data fusion can be implemented or not, according to UT internal architecture definition. REQ-GNSSUT-EE-AP-080 Title Error Log The Absolute Positioning Function implemented in the frame of the EE GNSS-UT shall be able to store in a dedicated file all the error messages. REQ-GNSSUT-EE-AP-090 Title Availability The Accuracies specified in the following shall be met for 99% of the time, in any place within the service volume, when operating in the Nominal SIS Constellation state. REQ-GNSSUT-EE-AP-100 Title Continuity The Absolute Positioning Function implemented in the frame of the EE GNSS-UT continuity shall be better than TBD REQ-GNSSUT-EE-AP-110 Title Output solution rate The Output of the Absolute Positioning Function implemented in the frame of the EE GNSS-UT shall be provided at a 10 Hz.

77 Class: PUB Page 77 / 130 «Train Position Computation» Sub-Function Specifications REQ-GNSSUT-EE-AP-120 Title Train Position Computation Function Definition The Train Position Computation Function defined in the frame of Absolute Positioning Function implemented in EE GNSS-UT shall compute the real time train position in terms of travelled distance from the last reference point. The last reference point shall be a LRBG or A APRP depending on the kind of trigger, according to Apsolute positioning function implementation. REQ-GNSSUT-EE-AP-130 Title Train Position Computation Function Methodology The Train Position Computation Function defined in the frame of Absolute Positioning Function implemented in EE GNSS-UT shall compute the train position on the basis of the data provided by the GNSS receiver(s) and on the basis of the track map information contained in the internal database. REQ-GNSSUT-EE-AP-140 Title Train Position Computation Function Integrity The Train Position Computation Function defined in the frame of Absolute Positioning Function implemented in EE GNSS-UT shall include integrity monitoring capability according to the performance requirements defined in the following. REQ-GNSSUT-EE-AP-150 Title Train Position Computation Function Confidence Interval The Train Position Computation Function defined in the frame of Absolute Positioning Function implemented in EE GNSS-UT shall determine the confidence interval on the position corresponding to the required high integrity level as defined in the following. REQ-GNSSUT-EE-AP-160 Title Train Position Computation Function in SIL4 application The Train Position Computation Function defined in the frame of Absolute Positioning Function implemented in EE GNSS-UT shall provide a position data compatible with SIL4 application. Data Translation Sub-Function Specifications REQ-GNSSUT-EE-AP-170 Title Data translation in ETCS reference Function Definition The Data translation in ETCS reference Function defined in the frame of Absolute Positioning Function implemented in EE GNSS-UT shall translate the positioning data from the GNSS reference frame into a travelled distance reference frame.

78 Class: PUB Page 78 / 130 REQ-GNSSUT-EE-AP-180 Title Data translation in ETCS reference Function Trigger The reference translations performed in the GNSS subsystem can be triggered following two different approaches: 1. by signals coming from the ETCS and based on the detection of physical balises (LRBG approach) 2. by the information contained in the UT itself (APRP approach). The second approach is implemented in the UT and specified in the following. REQ-GNSSUT-EE-AP-190 Title Pure APRP Data Base The APRP database shall be stored in the UT and shall contain an association of APRPs locations defined as follows: a track map (TBD) containing at least a vectorised modelisation of the track (TBD). TBC. REQ-GNSSUT-EE-AP-200 Title Pure APRP Trigger Methodology The trigger generated by the UT itself shall be based on APRPs contained in the UT database. It can be used to reset the along track distance. The UT will compute the new PCIs relative to the last APRP. The UT shall send to the ETCS the APRP information to be able to compute a correct positioning report. PCI is the Position Confidence Interval. Train speed Computation Sub-Function Specifications REQ-GNSSUT-EE-AP-210 Title Train speed Computation Function Definition The Train speed Computation Function defined in the frame of Absolute Positioning Function implemented in EE GNSS-UT shall compute the real time train speed module and shall determine the confidence interval on the speed corresponding to the required integrity level.

79 Class: PUB Page 79 / 130 REQ-GNSSUT-EE-AP-220 Title Train speed Computation Function Algorithm The Train speed defined in the frame of Absolute Positioning Function implemented in EE GNSS-UT shall be obtained on the basis of the data provided by the GNSS receiver(s), the track map information contained in the internal database and the real time train position provided by Compute train position function. Time Computation Sub-Function Specifications REQ-GNSSUT-EE-AP-230 Title Time Computation Function Definition The Time Computation Function defined in the frame of Absolute Positioning Function implemented in EE GNSS-UT shall compute the Universal Time Coordinated (UTC) time using SIS information. Integrity Monitoring Sub-Function Specifications REQ-GNSSUT-EE-AP-240 Title Integrity Monitoring Function Definition The Integrity Monitoring Function defined in the frame of Absolute Positioning Function implemented in EE GNSS-UT shall monitor: 1. the integrity of the SIS (including the local effect such as alternate and multipath effects) 2. as well as the integrity of the UT itself. REQ-GNSSUT-EE-AP-250 Title Integrity Monitoring Function and Data Base Monitoring The Integrity Monitoring Function defined in the frame of Absolute Positioning Function implemented in EE GNSS-UT shall monitor the integrity of the database internal to the UT. Data base Management Sub-Function Specifications REQ-GNSSUT-EE-AP-260 Title Data base Management Function Purpose The Data base Management Function defined in the frame of Absolute Positioning Function implemented in EE GNSS-UT shall update the data stored in data base. REQ-GNSSUT-EE-AP-270 Title Data base Management Function Communication The Data base Management Function defined in the frame of Absolute Positioning Function implemented in EE GNSS-UT shall communicate with the EVC (or RBC via a proprietary channel) to receive the missing versions of the digital map. The interface will be defined in a dedicated section.

80 Class: PUB Page 80 / 130 REQ-GNSSUT-EE-AP-280 Title Data base Management Function start-up The GNSS UT shall manage the initialisation at start-up of the Data base, in particular shall verify the validity of the database through a communication with the EVC. This interface definition depends on the system database architecture and management process. REQ-GNSSUT-EE-AP-290 Title Data base Management Function download The GNSS UT shall manage the downloading of the data base. This interface definition depends on the system database architecture and management process. Provide APRP information to ETCS Sub-Function Specifications REQ-GNSSUT-EE-AP-300 Title APRP information upload The GNSS UT shall be able to provide to ETCS the APRP information in a format compatible to the balise telegram sent to the BTM Digital Map Specifications REQ-GNSSUT-EE-AP-310 Title Digital map Content The digital map defined in the frame of Absolute Positioning Function shall contain at least the following data: Balise Data Set Absolute Positioning Reference Point Data Set Track topology TBC REQ-GNSSUT-EE-AP-320 Title Balise Data Set definition The Balise Data Set shall contain at least the following information: balises ID balise position in the GNSS reference frame balise position in the trackside reference frame TBC

81 Class: PUB Page 81 / 130 REQ-GNSSUT-EE-AP-330 Title Absolute Positioning Reference Point Data Set definition The Absolute Positioning Reference Point Data Set shall contain at least the following information: o Physical Balise Information (TBC) o Optional information, e.g. the announcement of a level transition (TBC) o Additional information, e.g. the announcement and name of the next station, a tunnel or bridge (TBC) o Data need for the adjustment of the Odometry (TBC) GNSS Scenarios definition and Requirements Since the GNSS subsystem performances strongly depend on the environment, the absolute positioning performance will be specified for precise configurations. Two main environments will be considered: A rural environment with a good satellite visibility and low probability of indirect paths (typical cases to be defined to describe the rural environment) An urban environment corresponding to an area with less satellite visibility and height probability of indirect paths (typical cases to be defined to describe the urban environment). For each environment, performances are given when local augmentation is used and when no local augmentation is used. REQ-GNSSUT-EE-AP-340 Title GNSS nominal scenarios definition The GNSS nominal scenarios available in the frame of GNSS UT AP application performance specification are those defined in the following table: E5a L2 E5b E5AltBoc E6A E6BC L1A L1BC L1C/A GPS Single frequency without Integrity GPS Dual frequency without integrity GPS Single frequency with Integrity GPS Dual frequency with integrity Galileo Single Frequency with integrity Galileo Dual Frequency with integrity The previous table is applicable for both rural and urban scenarios. Details on scenarios are provided in the following requirements.

82 Class: PUB Page 82 / 130 REQ-GNSSUT-EE-AP-350 Title GPS Single frequency without Integrity rural nominal scenario The GPS Single Frequency on L1 rural nominal scenario defined in the frame of GNSS UT AP application performance specification shall be compliant with the UERE/UERRE table reported in the following (TBC and TBD): GPS Satellite Single Frequency without Integrity Band Modulation Message Environment RF FE Configuration L1 BPSK GPS NAV RV Aereonautical UERE Mixed Residual Ionosphere error 737,20 659,74 590,83 529,99 430,47 357,17 324,74 324,74 324,74 OD & TS error 535,72 535,72 535,72 535,72 535,72 535,72 535,72 535,72 535,72 Residual Troposphere error 135,10 75,30 51,45 39,18 26,92 20,97 17,61 15,58 13,50 Thermal noise,interf.,multipath ra 68,91 68,61 68,51 68,47 68,43 68,43 68,41 68,41 68,41 Multipath bias error 33,50 33,50 33,50 33,50 33,50 33,50 33,50 33,50 33,50 Satellite BGD error 50,00 50,00 50,00 50,00 50,00 50,00 50,00 50,00 50,00 Code-Carrier Ionospheric diverge 15,94 15,94 15,94 15,94 15,94 15,94 15,94 15,94 15,94 Total 925,93 858,20 804,55 760,26 693,97 650,82 633,50 633,45 633,40 Total+10% margin 1018,52 944,02 885,00 836,28 763,36 715,90 696,85 696,79 696,74 1-sigma error [cm] UERE budget: GPS Single Frequency (L1) without integrity in rural environment TBD UERRE budget: GPS Single Frequency (L1) without integrity in rural environment REQ-GNSSUT-EE-AP-360 Title GPS Dual frequencies without Integrity rural nominal scenario The GPS Dual Frequencies rural nominal scenario defined in the frame of GNSS UT AP application performance specification shall be compliant with the UERE/UERRE table reported in the following (TBC and TBD): GPS Satellite double Frequency without Integrity Band Modulation Message Environment RF FE Configuration L1 BPSK GPS NAV RV Aereonautical UERE Mixed Residual Ionosphere error 184,30 164,94 147,71 132,50 107,62 89,29 81,19 81,19 81,19 OD & TS error 133,93 133,93 133,93 133,93 133,93 133,93 133,93 133,93 133,93 Residual Troposphere error 33,77 18,82 12,86 9,79 6,73 5,24 4,40 3,90 3,38 Thermal noise,interf.,multipath ra 68,91 68,61 68,51 68,47 68,43 68,43 68,41 68,41 68,41 Multipath bias error 33,50 33,50 33,50 33,50 33,50 33,50 33,50 33,50 33,50 Satellite BGD error 50,00 50,00 50,00 50,00 50,00 50,00 50,00 50,00 50,00 Code-Carrier Ionospheric diverge 15,94 15,94 15,94 15,94 15,94 15,94 15,94 15,94 15,94 Total 248,33 232,55 220,20 210,13 195,25 185,73 181,95 181,93 181,92 Total+10% margin 273,17 255,80 242,22 231,14 214,78 204,31 200,14 200,13 200,11 1-sigma error [cm] UERE budget: GPS Dual Frequencies without integrity in rural environment TBD UERRE budget: GPS Dual Frequencies without integrity in rural environment

83 Class: PUB Page 83 / 130 REQ-GNSSUT-EE-AP-370 Title GPS Single frequency with Integrity rural nominal scenario The GPS Single Frequency on L1 rural nominal scenario defined in the frame of GNSS UT AP application performance specification shall be compliant with the UERE/UERRE table reported in the following (TBC and TBD): TBD UERE budget: GPS Single Frequency (L1) with integrity in rural environment TBD UERRE budget: GPS Single Frequency (L1) with integrity in rural environment REQ-GNSSUT-EE-AP-380 Title GPS Dual frequencies with Integrity rural nominal scenario The GPS Dual Frequencies rural nominal scenario defined in the frame of GNSS UT AP application performance specification shall be compliant with the UERE/UERRE table reported in the following (TBC and TBD): TBD UERE budget: GPS Dual Frequencies with integrity in rural environment TBD UERRE budget: GPS Dual Frequencies with integrity in rural environment

84 Class: PUB Page 84 / 130 REQ-GNSSUT-EE-AP-390 Title Galileo Single Frequency on L1 with integrity rural nominal scenario The Galileo Single Frequency on L1 rural nominal scenarios defined in the frame of GNSS UT AP application performance specification shall be compliant with the UERE/UERRE table defined in the TUSREQ document and reported in the following: UERE budget: Galileo Single Frequency (L1) in rural environment TUS Identifier N 15 UERRE budget (200ms): Galileo Single Frequency (L1) in rural environment

85 Class: PUB Page 85 / 130 REQ-GNSSUT-EE-AP-400 Title Galileo Single Frequency on E5b with integrity rural nominal scenario The Galileo Single Frequency on E5b rural nominal scenarios defined in the frame of GNSS UT AP application performance specification shall be compliant with the UERE/UERRE table defined in the TUSREQ document and reported in the following: UERE budget: Galileo Single Frequency (E5b) in rural environment UERRE budget (200ms): Galileo Single Frequency (E5b) in rural environment TUS Identifier N 16

86 Class: PUB Page 86 / 130 REQ-GNSSUT-EE-AP-410 Title Galileo Dual Frequencies with integrity rural nominal scenario The Galileo Dual Frequencies rural nominal scenario defined in the frame of GNSS UT AP application performance specification shall be compliant with the UERE/UERRE table defined in the TUSREQ document and reported in the following: UERE budget: Galileo Dual Frequencies in rural environment UERRE budget (200ms):Galileo Dual Frequencies in rural environment TUS Identifier N 19 REQ-GNSSUT-EE-AP-420 Title GPS Single frequency without Integrity urban nominal scenario The GPS Single Frequency on L1 urban nominal scenario defined in the frame of GNSS UT AP application performance specification shall be compliant with the UERE/UERRE table reported in the following (TBC and TBD): TBD UERE budget: GPS Single Frequency (L1) without integrity in urban environment TBD UERRE budget: GPS Single Frequency (L1) without integrity in urban environment

87 Class: PUB Page 87 / 130 REQ-GNSSUT-EE-AP-430 Title GPS Dual frequencies without Integrity urban nominal scenario The GPS Dual Frequencies urban nominal scenario defined in the frame of GNSS UT AP application performance specification shall be compliant with the UERE/UERRE table reported in the following (TBC and TBD): TBD UERE budget: GPS Dual Frequencies without integrity in urban environment TBD UERRE budget: GPS Dual Frequencies without integrity in urban environment REQ-GNSSUT-EE-AP-440 Title GPS Single frequency with Integrity urban nominal scenario The GPS Single Frequency on L1 urban nominal scenario defined in the frame of GNSS UT AP application performance specification shall be compliant with the UERE/UERRE table reported in the following (TBC and TBD): TBD UERE budget: GPS Single Frequency (L1) with integrity in urban environment TBD UERRE budget: GPS Single Frequency (L1) with integrity in urban environment REQ-GNSSUT-EE-AP-450 Title GPS Dual frequencies with Integrity urban nominal scenario The GPS Dual Frequencies urban nominal scenario defined in the frame of GNSS UT AP application performance specification shall be compliant with the UERE/UERRE table reported in the following (TBC and TBD): TBD UERE budget: GPS Dual Frequencies with integrity in urban environment TBD UERRE budget: GPS Dual Frequencies with integrity in urban environment

88 Class: PUB Page 88 / 130 REQ-GNSSUT-EE-AP-460 Title Galileo Single Frequency on L1 with integrity urban nominal scenario The Galileo Single Frequency on L1 urban nominal scenarios defined in the frame of GNSS UT AP application performance specification shall be compliant with the UERE/UERRE table defined in the TUSREQ document and reported in the following: TBD UERE budget: Galileo Single Frequency (L1) in urban environment TBD UERRE budget (200ms): Galileo Single Frequency (L1) in urban environment REQ-GNSSUT-EE-AP-470 Title Galileo Single Frequency on E5b with integrity urban nominal scenario The Galileo Single Frequency on E5b urban nominal scenarios defined in the frame of GNSS UT AP application performance specification shall be compliant with the UERE/UERRE table defined in the TUSREQ document and reported in the following: TBD UERE budget: Galileo Single Frequency (E5b) in urban environment TBD UERRE budget (200ms): Galileo Single Frequency (E5b) in urban environment REQ-GNSSUT-EE-AP-480 Title Galileo Dual Frequencies with integrity urban nominal scenario The Galileo Dual Frequencies urban nominal scenario defined in the frame of GNSS UT AP application performance specification shall be compliant with the UERE/UERRE table defined in the TUSREQ document and reported in the following: TBD UERE budget: Galileo Dual Frequencies in urban environment UERRE budget (200ms):Galileo Dual Frequencies in urban environment

89 Class: PUB Page 89 / Performance requirements REQ-GNSSUT-EE-AP-490 Title Train position confidence interval accuracy - no local augmentation used Environment Urban (U) / Rural (R)area The GNSS UT system shall provide the train position confidence interval related to the "safe front-end" position of the train according to the following GNSS UT operational conditions: GNSS Availability Accuracies (m) GPS Egnos Galileo with integrity Urban Rural Single freq. No ±40 ±24 Dual freq No Single freq. Yes Dual freq Yes Single freq on L1BC ±30 ±18 Single freq on E5b Dual freq on L1BC/E5b ±20 ±12 no no no REQ-GNSSUT-EE-AP-500 Title Environment Train position confidence interval accuracy - local augmentation used Urban (U) / Rural (R)area The GNSS UT system shall provide the train position confidence interval related to the "safe front-end" position of the train according to the following GNSS UT operational conditions: GNSS Availability Accuracies (m) GPS Egnos Galileo with integrity Urban Rural Single freq. No ±10 ±6 Dual freq No Single freq. Yes Dual freq Yes Single freq on L1BC ±8 ±5 Single freq on E5b Dual freq on L1BC/E5b ±8 ±5 No no no

90 Class: PUB Page 90 / 130 REQ-GNSSUT-EE-AP-510 Title Velocity confidence interval accuracy - no local augmentation used Environment Urban (U) / Rural (R)area The GNSS UT system shall compute the real time train speed confidence interval according to the following GNSS UT operational conditions: GNSS Availability Accuracies (m/s) GPS Egnos Galileo with integrity Urban Rural Single freq. No ±0.56 ±0.33 Dual freq No Single freq. Yes Dual freq Yes Single freq on L1BC ±0.4 ±0.24 Single freq on E5b Dual freq on L1BC/E5b ±0.33 ±0.2 no no no REQ-GNSSUT-EE-AP-520 Title Environment Velocity confidence interval accuracy - local augmentation used Urban (U) / Rural (R)area The GNSS UT system shall compute the real time train speed confidence interval according to the following GNSS UT operational conditions: GNSS Availability Accuracies (m/s) GPS Egnos Galileo with integrity Urban Rural Single freq. No ±0.56 ±0.33 Dual freq No Single freq. Yes Dual freq Yes Single freq on L1BC ±0.4 ±0.24 Single freq on E5b Dual freq on L1BC/E5b ±0.33 ±0.2 no no no REQ-GNSSUT-EE-AP-530 Title Availability The Accuracies specified above shall be met for 99% of the time, in any place within the service volume, when operating in the Nominal SIS Constellation state Availability is defined here as the percentage of time that UT can provide a sufficient position/velocity accuracy respecting the required integrity when a minimum number of satellites are visible

91 Class: PUB Page 91 / 130 REQ-GNSSUT-EE-AP-540 Title Position and velocity confidence interval integrity The GNSS UT position and velocity confidence interval integrity shall be TBC REQ-GNSSUT-EE-AP-550 Title Absolute Position Function Continuity The GNSS UT Absolute Position Function continuity shall be TBC REQ-GNSSUT-EE-AP-560 Title Data translation in ETCS reference TBD REQ-GNSSUT-EE-AP-570 Title Compute time TBD REQ-GNSSUT-EE-AP-580 Title Data base management TBD REQ-GNSSUT-EE-AP-590 Title Provide APRP information to ETCS TBD Input / Output definition

92 Class: PUB Page 92 / 130 REQ-GNSSUT-EE-AP-400 Title Input Data The Absolute Positioning Function implemented in the frame of the EE GNSS-UT receiver has in charge to acquire data from GNSS SIS Other navigation sensors (if available, TBC) GNSS-EE-UT Navigation function Digital Map Data ID-balise Balise trigger TBC and to provide time tagged location information. REQ-GNSSUT-EE-AP-410 Title Output Data The Absolute Positioning Function implemented in the frame of the EE GNSS-UT has in charge to provide location information containing at least the following data: GNSS Raw Data Travelled distance : The distance travelled starting from the beginning of a segment; This position will be given in ETCS reference Speed (high integrity) Speed (low integrity), TBC ETCS Time stamp: GNSS time Speed Confidence interval (high integrity) Speed confidence interval (low integrity) Acceleration optional TBD Status APRP data (when in APRP mode) TBC GNSS Raw Data: among the typical packet types listed in appendix A, packets 0xA3, 0xA4 and 0x40 correspond to raw data required (when using different GNSS receivers, equivalent raw data is required). Output data can be gathered in several groups according to their functions: - GNSS raw data; - Odometric, time and status data; - APRP data - Database management data (to be defined later) Use of Local Augmentation Local augmentation, D-GNSS and fusion with other sensors can be required to improve the accuracy of the GNSS-subsystem. The following possibilities can be analysed further: o D-GNSS for increase precision, accuracy and availability o Pseudolites for improve the availability in areas like tunnels and stations where the GNSS satellites can not be seen o Different sensors like inertial platforms, eddy current sensors or Radar to increase precision, accuracy and availability

93 Class: PUB Page 93 / 130 o EGNOS or other SBAS to improve precision and reliability (and integrity when GPS and/or Galileo are used) o Communication systems like GSM-R or DECT to improve the digital map o Etc. (TBC) Use of Digital Route Maps and databases One possible database architecture is as described in the figure below (TBC): Proprietary RBC Subsystem Track map Balises database Master database GSM-R GNSS Sub-system EURORADIO Track map Balises database ETCS on-board Replicated database A centralized master database located on the trackside. A local database located onboard that is a replicated version of the master database. This replication can address the whole database or a part of it (to be defined). The database will contain at least 2 layers: - Layer 1: the vectorial modelisation of the track. - Layer 2: the balises and the reference points location (ID and location in GNSS referential). This architecture includes the following process that will influence the interfaces: - The downloading of the database or the suitable part of it according to the train mission - The verification of the integrity/validity of the database (comparison between the master and the replication).

94 Class: PUB Page 94 / The updating of the database (completely, partially or only the variation using some traceability management tool). Different scenarios are possible: Scenario1: the database is internal to the GNSS subsystem and therefore doesn t imply any modification of the interfaces (GNSS subsystem- ETCS subsystem or ETC onboard- ETCS trackside). The management of the database (downloading and integrity/validity check) will be performed through dedicated procedures. Scenario 2: the database management is taken over by the GNSS-Subsystem and the ETCS subsystem but through a dedicated trackside trainborne radio interface (not part of the standardized air gap). In this scenario, only the interface between the GNSS subsystem and the ETCS onboard subsystem will be affected. Scenario 3: the database management is taken over by the GNSS-Subsystem and the ETCS subsystem but through the standardized air gap (Euroradio+ GSM-R). In this scenario, both interface GNSS subsystem-etcs onboard and ETCS onboard-etcs trackside will be affected. The introduction of the absolute positioning into ETCS has probably to follow theses scenario (with few impact to major impact on ETCS specification). As a consequence, the GNSS subsystem shall be able to implement all functionalities associated to those 3 scenarios. In particular, the interfaces definition will be influenced by the following points: - Definition of the database architecture. - Definition of the format of the database - Definition of the downloading process - Definition of the validity check process - Definition of the updating process Linking of physical Balises and GNSS absolute positions One of the basic safety features of ETCS is the linking between the Balises. Using a GNSS absolute positioning it is needed to emulate a kind of linking for the GNSS absolute positions. There are three general possibilities for the linking: first to integrate physical Balises and GNSS absolute positions with respect to their linking; second to overlay in the same track area a network of linked physical Balises and a network of GNSS absolute positions and third to use separate track areas for physical Balises and GNSS absolute positions. From interoperability point of view only the second possibility is acceptable. The third solution can be used, if the area with GNSS absolute positions is used only by trains, which are equipped with a GNSS absolute position unit. GNSS absolute positions can be used without linking, but due to the reduced safety level the practical relevance will be lower.

95 Class: PUB Page 95 / Impact on the ERTMS/ETCS class 1 specifications To allow any upcoming technology for being implemented within ETCS, its impact on or the need to change the ETCS SRS has to be minimal, better so non-existing. The approach to use the APS and the overall GNSS subsystem as part of the on board system facilitates for this as long as the overall positioning meets the ETCS requirements as stated within SRS. In the SRS it is specified, that the trackside determines the train position for Level 1 and 2. In Level 1 there is no possibility for the train to report its position due to the missing radio link. In Level 2 the train reports its position to the trackside additionally. In Level 3 it is foreseen that the train reports its position exclusive to the trackside via GSM-R. The position is determined by use of the Odometer and the detected Last Relevant Balise Group. The Odometer is not in scope of the SRS. The format of the Position report is defined in the SRS. So the Position report constructed with help of GNSS must fulfil the specification of the SRS. Trackside Subsystem a) balise There is no impact on the balises. The communication between trackside and train is not influenced by the new technology. If the number of balises can be reduced depends on the number of non equipped trains using the line. Functional there will be no change for the balises. b) lineside electronic unit (LEU) As the balise the LEU is not involved into the exchange of positioning data. (like balise) c) radio communication network (GSM-R) The SRS defines the messages for a position report. So if the Position of the GNSS is changed into a SRS conform format, there is no impact for the GSM-R. d) Radio Block Centre (RBC) In Level 1 the RBC receives no information from the train. If the train generates its own Position by GNSS, a radio communication has to be set up to exchange this information. In Level 1 and 2 the trackside also determines the position of the trains. Due to the fact, that the RBC is not specified in the SRS in detail, the new technology causes a change in the functionality of the RBC but no change in the specification. e) Euroloop The Euroloop is used for Semi-continuous communication between track and train in ETCS Level 1. It is used to send new information to the train as soon as it is available instead of using only balises. The selected solution has no impact on the Euroloop. f) Radio infill unit The Radio infill unit is, as the Euroloop, used to send infill information from the track to the train in Level 1. The selected solution has no impact on the Radio infill unit. Onboard Subsystem a) ERTMS/ETCS on-board equipment The selected solution has a deep impact on the ERTMS/ETCS on-board equipment. Depending on the chosen architecture, this influences the functionality of the on-board

96 Class: PUB Page 96 / 130 equipment or the interfaces between the on-board equipment and the connected Subsystems. There has to be a fusion of the absolute Position from GNSS and the position of the relevant balise-group. The GNSS-Position has although be compared with the Position detected by the Odometer. The Information of the Odometer is needed by the on-board equipment for speed supervision. In all Levels the on-board equipment has to be able to receive messages from balises. The linking consistency of the detected (virtual) balisegroups has to be checked. 1. Interface Odometry Kernel (proprietary) The Interface should not be changed because the Information of the Odometer is not only used for positioning but also for speed measurement. 2. Interface GNSS Kernel (proprietary) There should be no direct interface between GNSS and the Kernel. The absolute Position of GNSS should first be prepared and formatted to the SRS format (Relation to balise group). 3. Specification a) the on-board part of the GSM-R radio system; No impact, the messages in the SRS already define a position report. b) specific transmission modules for existing national train control systems. No impact Justification: Subset 026 Part 4 Section describes the Active Functions of the Onboard-Unit. Subset 026 Part 3 Section 3.6 describes the localization principles of ETCS. 4.4 Conclusion It is possible to use GNSS for the absolute positioning in ETCS. Due to the required interoperability this Absolute Positioning Subsystem cannot replace the Balise Transmission Subsystem completely. Only additional or optional information can be transmitted via the APS, but not the safety-critical data. The question of linking has to be analysed more in detail as well as digital map, which is required.

97 Class: PUB Page 97 / TRAIN INTEGRITY 5.1 Application definition Train Integrity Macro-function Train integrity is the level of belief in the train being complete and not having left coaches or wagons behind. Train integrity function monitors the integrity of the train. The train Integrity assessment sub-system function is - To provide the signalling system with a real time status of the train completeness, in order to alert the system when a train is broken in several parts following the breaking of one or several couplers between wagons or cars of this train. - To provide the signalling system with a train length confirmation. Nowadays, train integrity is determined by means of trackside components (track circuits, axle counters, etc). For ETCS levels 1 and 2, the train integrity determination is performed in this way. However, in level 3 of ETCS, both train location and train integrity determinations are performed on-board. The goal is to remove or minimise the track components. In Level 3, the Position Report to the RBC shall contain the integrity information and how this integrity is achieved. A train integrity system shall ensure that the train is complete before it transmits its location. This information can be delivered from an external device of the train to the onboard equipment or if not available replaced by a manual operation by the driver. According to [9] SRS v [9] the train integrity information that ETCS on-board send to trackside shall consist of a) Train integrity status information b) Safe train length information (only valid if train integrity is confirmed at the same time) The safe train length information shall be recalculated for every position report using the same last value of min safe rear end position until a new min safe rear end position is established on-board taking into account the time to detect train integrity. (Refer to [9] and figure 15) GNSS TI Subsystem outputs defined in section 3 inputs defined in section 3 ETCS Onboard position report incl. Q_LENGTH, L_TRAININIT Figure 24: Train integrity macrofunction ETCS Trackside There are several solutions for determining the integrity of the train on-board: - Monitoring of train length by satellite positioning at front and rear end of the train with radio transmission

98 Class: PUB Page 98 / Combined satellite and inertial navigation system for positioning of front and rear end with radio transmission - Main brake pipe air pressure monitor and radio transmitter at rear of train, radio receiver on the leading car combined with satellite positioning. With Galileo a GNSS based train integrity technology is getting closer, due to the unique features that Galileo comes with (Safety of Life service, GNSS integrity,...). GNSS can provide a solution to the Train Integrity by placing a GNSS antenna at the rear of the train (the rear cabin or the last wagon) attached to a radio transmitter. The cabin in service knows the position of the front-end of the train (by means of a GNSS Location subsystem or other means), and receives the position of the rear end of the train from the GNSS receiver. So, comparing the difference of the two positions with the train length, the integrity of the train can be derived. To make this comparison the train integrity is seen as the consideration of two margins: - Max Train Length = nominal length + Margin _1 - Train Length measurement: characterized by Margin_2 - Margin_1 is a fixed value depending on train type and length, taking into account the natural variation of the coupling - Margin_2 is a variable value depending on SIS (DOP), associated to the confidence interval of the GNSS based measurement. - => Max. Train Length = nominal length + Margin_1 + Margin_2 Solution1: The GNSS subsystem is able to provide a train integrity status for the GNSS channel. The value of the status shall be as follow: Train complete, Train not complete or Train completeness unknown. Where the value unknown is to be used when the train completeness status is not certain, but during a limited time, e.g. due to the nature of the phenomenon used for its computation. This solution supposed that uncertainty due to GNSS SIS can be bounded and that a threshold can be fixed without compromising the function availability If measured length is higher than max train length (with fixed value for Margin_2)=> loss of integrity In case of bad satellite visibility, if the confidence interval is higher than the threshold, the train is declared not complete and the system is switched in degraded mode. This situation is acceptable if one can demonstrate that probability of occurrence is low in nominal conditional. Solution 2: The GNSS technology is not able to fix such threshold. In this case, the only way in order not to compromise function availability is to provide in real time not only the integrity status but also the fail safe length confidence interval of the train. In case of very poor satellite visibility, the performance is degraded but the function is still available. The value of the data shall be as follows: Train status (complete or not) Fail safe train rear position

99 Class: PUB Page 99 / 130 Margin_1:+-10m for 750m long Max train length Figure 25: Train integrity margins Other possibility is to confirm the train integrity when the rear of the train has passed the same location as the front, making sure that the train is complete and that the track can be cleared (same principle as an axle counter but using communications between the EOT and the HOT devices). In these two approaches using GNSS, the Train Integrity macrofunction will be performed by the ETCS on-board (determine the safe train length to be sent to trackside) and by the GNSS TI Subsystem (elaborate TI status, in case of "binary integrity status") or (elaborate TI status and calculate the train length confidence interval, in case of "continuous integrity status"). The discussion on these two solutions is presented in Appendix D. For the selected approach refer to section Operational scenarios Train integrity would be used in the following exploitation scenarios: 1) L3 lines without any detection systems and operated with a moving block system. Train integrity function is a requirement for this type of lines 2) Low traffic lines with axle counters. A train integrity function performed on-board would allow removing the axle counters from the track. Besides train integrity checks for this kind of lines would be necessary only at the entry and exit to/from a station. 3) ERTMS/ETCS lines with L3 and other levels. In this type of lines the train integrity function will be performed by trackside but an on-board train integrity check will be needed when running in L3. The trackside equipment remains for fallback situations (when running in L3) and for normal operation in other level than L3. For any of these 3 situations and based on the description above and on the functionality described in the FRS v.4.29 [7] the following scenarios are proposed. More scenarios can be foreseen, for example RBC hand-over and any other situation where an action should take place after the train has passed a location with its full length. Scenario 1 It is the nominal case without train integrity loss. TI Status= ok Scenario 2 It is a degraded case where function is no more available but train is complete: transition to degraded mode after loss of function. TI_Status= unknown

100 Class: PUB Page 100 / 130 Scenario 3 It is the nominal case with train integrity loss: so transition to degraded mode after integrity loss detection. TI_Status= TI lost Scenario 4 It is the nominal case with a train integrity system failure. TI-Status = failure state. SCENARIO 1 Train A with confirmed train integrity has passed a track section. Train B approaches that section. Step Actor Action or event 1 Train A The train is running to the end of its MA 2 Train A The train has passed completely point S1 3 onboard A The onboard sends the position report to the RBC including a confirmation of train integrity 4 RBC The RBC releases the route (S1 and up to the track sections up to the rear safe of the train) 5 Interlocking/ traffic Control centre The route is released 6 RBC The RBC issues a MA to train A 7 RBC The RBC requests to set a new route 8 Interlocking/ train Control centre Interlocking sends confirmation that the route is set and locked to the RBC. 9 RBC The RBC establishes that the route is locked and not occupied and sends a movement authority to train B SCENARIO 2 Train A with failed train integrity (TI_status= TI unknown) has passed a track section ending in S1. The controller checks the completeness of the train (by driver, by train detection system or other operational staff). Train B approaches that section. Step Actor Action or event 1 Train A The train is running to the end of its MA 2 Train A The train has passed completely point S1 3 Onboard A The onboard sends the position report to the RBC but train integrity is not confirmed

101 Class: PUB Page 101 / 130 Step Actor Action or event 4 RBC The RBC reports a train integrity failure to the Traffic Control centre 5 Traffic Control Centre The traffic control centre checks the train has passed S1 completely (checks or orders to check) option 1 6 train detection systems (track circuit or axle counters...) after this, there are several possibilities: The train integrity is confirmed 7 onboard A The onboard sends the position report to the RBC including a confirmation of train integrity (if confirmed by driver) 8 RBC The RBC confirms that the route has been cleared (The RBC releases the route (S1 and up to the track sections up to the rear safe of the train)) 9 Interlocking/ train Control centre The route is released (S1 and up to the track sections up to the rear safe of the train) 10 RBC The RBC issues a FS MA ahead of S1 to train A 11 Train B Train B is approaching the track section 12 RBC The RBC requests to set a new route 13 Interlocking/ train Control centre The RBC receives confirmation that the route is set and locked 14.1 RBC The RBC establishes that the route is locked and not occupied and sends a movement authority to train B 14.2 RBC The RBC issues a track ahead free request or the RBC sends a OS MA or the RBC sends a SR authorisation to train B (in case of TI confirmed by driver a national procedure may be defined) option 2 6' train A if there are not train detection systems, train A continues till next station. Sections are not released behind 7' driver driver or other operational staff check the integrity of train A in the station 8' Interlocking /train control centre 9' - Continue in step 10 As soon as the train integrity is confirmed, all sections are released and MA extended for train B (in FS mode)

102 Class: PUB Page 102 / 130 SCENARIO 3 Train A with failed train integrity (TI status= TI lost) has passed a track section ending in S1. The controller cannot check the completeness of the train (by driver, by train detection system or other operational staff). Train B approaches that section. Step Actor Action or event 1 Train A The train is running to the end of its MA 2 Train A The train has not passed completely point S1. Train A is split. 3 Onboard A The onboard sends the position report to the RBC with train integrity lost 4 RBC The RBC reports a train integrity failure to the Traffic Control centre 5 Traffic Control Centre The traffic control centre can not check the train has passed S1 completely (checks or orders to check) 6 driver, train detection system (track circuit or axle counters...) or other operational staff The train integrity is not confirmed 7 RBC The RBC can not confirm that the route has been cleared 8 Interlocking/ train Control centre 9 Train A Train B RBC The route is not released National procedure to be defined, for example: - Stop the train and/or the following trains - Transition to L2 - Transition to SR or OS modes... SCENARIO 4 Train A is running and the train integrity system fails. (TI device is in Failure state) Step Actor Action or event 1 Train A The train is running 2 Onboard A Onboard a receives TI system failure 3 Onboard A The onboard sends the position report to the RBC with Train integrity information set to "no train integrity available"

103 Class: PUB Page 103 / 130 Step Actor Action or event 4 National procedure to be defined, for example: - Stop the train and/or the following trains - Transition to L2 - Transition to SR or OS modes... Note: The TI status will be sent to the onboard by the TI system when requested. In that way, when there's a lack of GNSS signal in space the operation will not be degraded. Only in the case of failure of the TI system the onboard should receive the TI status even if it has not been requested. In case of loss of visibility, when the onboard asks the TI subsystem for the TI status it will receive TI unknown. The last TI information may have been TI ok x seconds ago. It is the responsibility of the onboard to decide whether to send to trackside a position report with TI not available or to send TI confirmed by monitoring device with a larger safe train length. Note: In ERTMS the position report that the onboard sends to the RBC contains the variable Q_LENGTH, which identifies the train integrity information available. The related safe train length information is given by L_TRAININT if Q_LENGTH is "1" or "2" Q_LENGTH= 0, no train integrity info available 1, train integrity confirmed by integrity monitoring device 2, train integrity confirmed by driver 3, train integrity lost

104 Class: PUB Page 104 / System requirement specification GNSS TI System Functional Train Integrity Train length confidence interval Additional info (*) Trigger SiS Navigation data GNSS Train Integrity assessment Integrity Status Train Length ETCS On Board Train Length confirmation (*) Additional info for: DMI, JRU,... Configuration parameters Alarms Change of Status Context Diagram JRU SiS Navigation data GNSS Position Measurement Train length confidence interval Additional info (*) Rear Position Data Front Position Data Data Processing 2 Trigger Integrity Status Train Length ETCS Train Length confirmation Configuration parameters Change of Status JRU Level 1 Figure 26: Train integrity subsystem

105 Class: PUB Page 105 / 130 Functions: 1. Train integrity assessment 1.1 Elaborate the TI status (TI ok, TI lost, TI unknown) and safe train length confidence interval 1.2 Displaying status and providing alarms to train staff (maintenance or info for the driver). 1.3 Computing and managing Juridical data 1.4 Providing train s tail red light indication 2. Train length confirmation at SoM The data flow between the GNSS subsystem and the ETCS subsystem is as follows: Inputs (ETCS subsystem to GNSS subsystem): - Trigger to update TI info (if TI is event-driven) or parameters (cycle information,...) [See output rate requirement] and configurable (TBC) - Train length Outputs (GNSS subsystem to ETCS subsystem): - TI status (ok-train complete, lost-train not complete, Failure state/unknown, TI info unknown) - Train length confidence interval (referred to the position of the rear of the train) - Train length confirmation - Info for the juridical recorder (List of parameter at each change of configuration performed by the train staff, alarms, sub-system change of status...tbd) - Info for train staff/driver (Train integrity status for train operation purposes, status of the GNSS train integrity sub-system, status of end of train device battery, status of Head to End devices communication, visual and acoustical alarms...) Functions The GNSS train integrity subsystem shall perform the following functions when the train is performing its mission. 1. Train integrity assessment 1.1 Computing of train integrity status and safe train length confidence interval and supply of these data to the ETCS equipment. The sub-system shall evaluate in real time whether the train is complete or not. For availability reasons, this evaluation could be made through two different and independent evaluation channels, each channel using a different source for this detection: one of the two channels shall be the GNSS. Each channel shall provide the completeness data with high integrity level (compatible with SIL 4 application).

106 Class: PUB Page 106 / 130 The result of each evaluation channel shall be supplied through distinct I/O channels to the signalling equipment. GRAIL only deals with the GNSS channel The real time data shall be computed and provided to the ETCS equipment. 1.2 Displaying status and providing alarms in real time to train staff. The train integrity assessment sub-system shall provide an interface with the train staff or train driver. TBD The information shall be understandable by the train staff. In particular, the language to be used shall be the national language 1.3 Computing and managing Juridical data The HoT train integrity assessment device shall provide an interface with the Juridical recorder. This interface shall provide the Juridical recorder with the set of data defined in section and these data shall be time stamped (reference to be agreed). 1.4 Providing train s tail red light indication The end of train device shall provide a red light indication corresponding to the exiting red lamp located at the tail of the train (detailed requirements to be made available by the customer). 2. Providing train length confirmation The subsystem will be able to confirm the train length that has been entered by the driver during train initialisation phase System Architecture The context for the Train integrity assessment sub-system is illustrated by the figure below Radio communication Train staff or Driver Juridical recorder ETCS Front train integrity assessment device End of train device Mechanical interface Figure 27: Context diagram Train integrity assessment sub-system shall be made of 2 devices:

107 Class: PUB Page 107 / 130 One installed through a mechanical interface (e.g. coupler if existing) of the last wagon or last car of the train (EoT device) One installed within the first vehicle of the train, usually a locomotor, where the signalling equipment is also located. (HoT device) Head and End equipment shall communicate over a dedicated radio, as there is no wiring available within most of the trains. Consequently, in regards of the train integrity function, the GNSS sub-system can be defined in 2 different ways: Definition 1: the GNSS TI subsystem is composed of both the front part (HoT) and the rear part (EoT) SIS ETCS (1) GNSS subsystem (train integrity) Front part Rear part (2) TRAIN Figure 28: GNSS TI subsystem architecture definition 1 => (1) and (2) could be subject to standardization Definition 2: The GNSS TI subsystem is composed of two separate subsystems: the front and the rear linked by an open interface. SIS TRAIN (2) ETCS (1) GNSS subsystem front (train integrity) (3) GNSS subsystem rear (train integrity) => (1), (2) and (3) could be subject to standardization Figure 29: GNSS TI subsystem architecture definition 2

108 Class: PUB Page 108 / 130 The present requirement specification currently addresses the definition 1. Interface (3) is out of the scope of GRAIL although some requirements are drafted in the next sections. The GNSS TI system architecture shall be according to existing ETCS train onboard architecture with access to onboard functions, e.g. JRU, brakes: Profibus, TIU, Etc. The GNSS TI system shall coexist with but not interfere with or automatically override other TI systems Requirements for the on-board and trackside modules Specific concept and definitions are the same provided in section Operational requirements (a) GNSS TI able to work up to train length of 1500 m (TBC) (b) GNSS TI able to work up to speeds specified by ETCS (c) Independence from environmental influences topography and buildings (d) Operating environment. The EoT and HoT shall be designed to meet the requirements of this section 3.3 under the environmental conditions specified in the ERTMS/ETCS class 1 documents. Some Environment specific requirements may apply: Head of train Device Humidity Temperature Pollutants & contaminant Mechanical EMC Transport & storage End of Train Device Humidity Temperature Water & precipitation Pollutants & contaminant Mechanical EMC Transport & storage

109 Class: PUB Page 109 / 130 (e) GNSS TI system may not affect standard train systems, e.g. brakes. (f) TI system shall not be affected by operational errors (operational rules have to be defined, not to collide with functional requirements) (g) Handling / Installation. (1) Ensure that the end-of-train device is attached to the last vehicle and detect any erroneous attachment. 1 (2) Ensure that the end-of-train device has enough power for the mission (battery, alarm so many hours before it needs recharging,...) (3) Easy way of attaching it (time needed, weight of device,..). Equipment weight should be as low as possible. Provisional Maximum weight should be XXX kg (to be confirmed with customer). (4) Equipment should be designed to resist to handling by railways staff. In particular, the EOT devices must resist to xx-meter fall on a concrete surface, and to a fall on ground from a vehicle running at a speed of xx km/h (TBD). (5) EoT device should be theft proof /difficult to steal (h) Initialization. Means shall be provided to arm the HoT and EoT units to ensure the EoT responds to a command only from a properly associated front unit. For the addressing process between EoT and HoT various solutions can be chosen: (1) Unique code. (1a) Each EoT shall have a unique and permanent identification code that is transmitted along with the position message to the front-of-train unit. (Codes maybe managed by the Railway Administration). (1b) The HoT device shall have a means for entry of the unique identification code of the EoT unit being used. (1c)The HoT unit shall be designed so that it will process a message only from the EoT unit with the same code as entered into the HoT unit. (2) Coupled EoT-HoT. Ensure that the EoT device connects to its couple HoT device. 1 (i) Specific requirements for use: operational procedures. (1) The GNSS TI subsystem shall be armed and operable from the time the train departs from the point where the device is installed until the train reaches its destination. Procedures shall be defined for degraded situations such as loss of communication, etc. (2) The rear unit batteries, if used, shall be sufficiently charged at the initial terminal or other point where the device is installed and throughout the train's trip to ensure that the end-of-train device will remain operative until the train reaches its destination. (3) En route failure of device on freight or other non-passenger train/ on a passenger train. National procedures to be defined for different situations/ types of trains. (Example- If a GNSS TI subsystem device fails en route (i.e., losses of communication (front to rear the speed of the train on which it is installed shall be limited to... km/h until the ability of the device to...is restored. A loss of communication between the front and rear units is an en route failure only if the loss of communication is for a period greater than xx minutes and xxx seconds.) (4) Inspection and testing. (4a) After each installation of either the front or rear unit of an end-oftrain device, or both, on a train and before the train departs, the driver/train staff/other shall determine that the identification code entered into the HoT is identical to the unique identification code on the EoT unit OR that the end of train unit is the one coupled to the HoT of train. (4b) After each installation of either the HoT or EoT unit, or both, on a train and before the train departs, the 1 This is also a safety related requirement as it could lead to a safety issue

110 Class: PUB Page 110 / 130 functional capability of the device shall be determined, after charging the train, by TBD (example: comparing the difference in positions (rear and front) with the length of the train. The end-of-train device shall not be used if the difference between the two readings exceeds...m). (4c) The telemetry equipment shall be tested for accuracy and calibrated if necessary according to the manufacturer's specifications and procedures at least every xxx days. This test shall include testing radio frequencies and modulation of the device. The date and location of the last calibration or test as well as the name of the person performing the calibration or test shall be legibly displayed on a weather-resistant sticker or other marking device affixed to the outside of both the HoT unit and the EoT unit; however, if the HoT unit is an integral part of the locomotive or is inaccessible, then the information may recorded on... instead, provided that the serial number of the unit is recorded. (4d) Prior to each shipment and during each crew change point along the route inspections will be conducted to ascertain that EoT and Hot devices are operational. (5) Training. An emergency response training and safety briefings shall be developed by TBD. (Railway Operators/...) (6) Red Lamp. If using a combination of rear-lamp and TI concepts then each railway requirements for red-lamps will apply. (Display, position, inspection...) (j) Power Supply. When autonomous power supply is required (e.g. Battery) it should allow the train integrity assessment sub-system to work continuously during more than TBD h. (k) Need for fallback systems. (1) Axle counters for tunnels TB studied. (2) Local elements TB studied (l) Communication related requirements (part of internal interface 3) (1) Communication between front and end of train devices shall be designed for the maximum train length. (2) The frequency to be used shall be agreed with the customer or the official national body in charge of allocating radio frequencies (3) Loss of communication for short duration (some seconds) can be accepted (4) Communication shall work in tunnels and cuttings (5) Configure matching between EoT and HoT devices. The sub-system shall provide the means to allow the train staff to configure it. In particular, the matching between the front and the end equipment shall be covered if different front and end devices are used from time to time on different trains. (6) Communication shall be designed to avoid cross-talk between equipment of different trains, and also to avoid that the HoT device of one trains gets the data from another end of train device than the one hooked at the end of the same train (this last one can be done by logical addressing) (7) It is not required specifically to have a fail-safe communication between HoT and EoT devices. The safety requirement to fulfill is described in the corresponding chapter of this document. (8) The availability of the front-to-rear communications link shall be checked automatically at least every xx minutes (9) Reporting rate. Multiple data transmissions from the rear unit shall occur immediately after a variation of the rear position ±...m and at intervals of not greater than... seconds when the variation of the rear position over the x-second interval is less than ±...m. TBD

111 Class: PUB Page 111 / Performance requirements for TI macrofunction (a) Alarm time thresholds according to kind of train (freight, passenger) and traffic density shall be defined. Refer to Appendix E. Adequate tolerable maximum disclosure time: A disclosure time of x seconds means that the train was complete x seconds prior to disclosure. Proposed values for the disclosure time extracted from [15] are included in Appendix F. (b) The ETCS on-board will send to trackside a position report with train integrity lost if it has received a TI report lost from the UT. (c) The ETCS on-board will send to trackside a position report with train integrity ok when (1) A position report is requested from trackside AND (2) no TI report =lost has been received from the UT AND (3) at least one of the TI reports received from the UT in a maximum interval equal to the disclosure time has TI ok. The safe train length shall be calculated according to the TLCI corresponding to that TI report. (d) The ETCS on-board will send to trackside a position report with train integrity not available when (1) A position report is requested from trackside AND (2) All the TI reports received from the UT are "TI unknown" (e) ETCS on-board shall be able to memorize at least 20 TI reports from the UT. (TBC) Specification for the user terminal This section defines the functional and performance requirements of the GNSS User Terminal Train Integrity function. It is also important to remark that the basic considerations recalled in the specification of Enhanced Odometer application are still valid. Indeed, in both (EETCS and EO), the GNSS-EE- UT Navigation Equipment is in charge of providing an additional (with respect to the traditional tachometer) source of position to the ETCS Kernel. In case of Enhanced ETCS, some additional functions are foreseen, according to the specific application Specific concepts and definitions Specific concept and definitions are the same provided in the GNSS-EE-UT of EO application [21] and are sumarized in sections 1.6 and of this document Enhanced ETCS GNSS-UT Requirements In the following sections we have reported the main functional and performance requirements allocated to the EE GNSS User terminal for the Train Integrity function. The integrity function requirements will be denoted with the acronym REQ-GNSSUT-UT-TI-xx. For the GNSS Receiver requirements, considering its crucial role in the GNSS UT Equipment for both EE and EO, and considering also that right now no differences have been highlighted between EE and EO, we propose to refer to the D for Receiver highlevel specification [21].

112 Class: PUB Page 112 / Functional requirements REQ-GNSSUT-EE-TI-010 Title Purpose The Integrity Function implemented in the frame of the EE GNSS-UT shall be a dedicated Function able to provide real-time data to the ETCS Kernel with the purpose to monitor the integrity of the train. Train integrity is the level of belief in the train being complete and not having left coaches or wagons behind. REQ-GNSSUT-EE-TI-020 Title Configuration Data The Integrity Function implemented in the frame of the EE GNSS-UT receiver shall use the following configuration data: Train Length Lmax The Maximum Train Length is obtained as sum of nominal length plus a Margin value (Lmax); TBD if Lmax is a fixed value or depends on train type and length. TBD if needs to be introduced by driver. See APPENDIX D. CONTINUOUS INTEGRITY STATUS VERSUS BINARY INTEGRITY STATUS REQ-GNSSUT-EE-TI-030 Title Handling by train driver The system shall perform self-test at start up, continuously and on manual request.. A manual override of the aforementioned results (through the DMI) shall be possible, but recorded by the JRU. REQ-GNSSUT-EE-TI-040 Title Input Data The Integrity Function implemented in the frame of the EE GNSS-UT receiver has in charge to acquire data from GNSS SIS Other navigation sensors (if available, TBC) GNSS-EE-UT Navigation function and to provide time tagged integrity information. REQ-GNSSUT-EE-TI-050 Title Output Data The Integrity Function implemented in the frame of the EE GNSS-UT has in charge to provide train integrity information containing at least the following data: Train integrity status information train length confidence interval Train integrity Devices Status Train length confirmation

113 Class: PUB Page 113 / 130 REQ-GNSSUT-EE-TI-060 Title Train length confirmation Data regarding train length shall be entered via the DMI and crosschecked with the TI system s data. Results shall be shown on the DMI REQ-GNSSUT-EE-TI-070 Title Devices Definition Train integrity sub-system shall be made of 2 devices: One installed through a mechanical interface (e.g. coupler if existing) of the last wagon or last car of the train (EoT) One installed within the first vehicle of the train, usually a locomotor, where the signaling equipment is also located. (HoT) The GNSS TI subsystem is composed of both the front part (HoT) and the rear part(eot). REQ-GNSSUT-EE-TI-080 Title EoT Definition The EoT unit shall be capable of determining the absolute rear position of the train and transmitting that information to the HoT unit. REQ-GNSSUT-EE-TI-090 Title HoT Definition The HoT unit shall be designed to receive data messages from the EoT unit and shall be capable of displaying the alarms defined in REQ-GNSSUT-EE-TI-100 Title Devices Communication Train integrity sub-system devices Head and end equipment shall communicate over a dedicated radio. This requirement derives from the lack of wiring within most of the trains REQ-GNSSUT-EE-TI-110 Title Train integrity status Definition The Train integrity status information shall assume the following values: TI Status= ok TI Status= unknown TI Status= TI lost TI Status = failure state

114 Class: PUB Page 114 / 130 REQ-GNSSUT-EE-TI-120 Title Train integrity devices status Definition To provide the train staff with real time status of the train integrity assessment subsystem, the Train integrity devices status information shall include at least: Status of end of train device battery, possibly of front device battery Status of front to end devices communication Any fault of either the front or the end device REQ-GNSSUT-EE-TI-130 Title TI results The results of the GNSS TI (TI monitoring and train length confirmation) shall be presented to the EVC and subsequently to the DMI. REQ-GNSSUT-EE-TI-140 Title Train integrity status Scenarios The Train integrity status information provided as output from the Integrity Function implemented in the frame of the EE GNSS-UT shall be defined according to the scenarios in section REQ-GNSSUT-EE-TI-150 Title Train length confidence interval calculation The train length confidence interval shall be recalculated for every TI status message that it is sent to the ETCS onboard. REQ-GNSSUT-EE-TI-160 Title Integrity Function Operative Mode The Integrity Function implemented in the frame of the EE GNSS-UT system should include (at least) the following Operative Mode to foreseen different corresponding operational conditions: Internal check/consistency Mode Initialization Mode; Acquisition Mode; Full Operational Mode; Degraded operational mode. Transitions between those modes shall be defined. The degraded operational mode shall be intended as a dead reckoning mode. REQ-GNSSUT-EE-TI-170 Title Unlocked GNSS Signals When the GNSS RX do not provide navigation data (SIS loss), the Integrity Function implemented in the frame of the EE GNSS-UT shall be able to provide appropriate information containing the degraded conditions. This is the degraded operational mode

115 Class: PUB Page 115 / 130 REQ-GNSSUT-EE-TI-180 Title Data acquisition/reacquisition The Integrity Function implemented in the frame of the EE GNSS-UT shall be able to automatically restart after a GNSS SIS or navigation data reacquisition. REQ-GNSSUT-EE-TI-190 Title Data fusion The Integrity Function implemented in the frame of the EE GNSS-UT shall implement data fusion to blend GNSS data with other sensors data using configuration data, to calculate the integrity information. REQ-GNSSUT-EE-TI-200 Title Error Log The Integrity Function implemented in the frame of the EE GNSS-UT shall be able to store in a dedicated file all the error messages. REQ-GNSSUT-EE-TI-210 Title Isolation If the GNSS TI system fails the GNSS TI system will isolate itself from the train system and notify the driver through the DMI (TI monitoring by driver could be used for this and other degraded situations) GNSS Scenarios definition and Requirements Since the GNSS subsystem performances strongly depend on the environment, the train integrity performance will be specified for precise configurations. Two main environments will be considered: A rural environment with a good satellite visibility and low probability of indirect paths (typical cases to be defined to describe the rural environment) An urban environment corresponding to an area with less satellite visibility and height probability of indirect paths (typical cases to be defined to describe the urban environment). For each environment, performances are given in the following section.

116 Class: PUB Page 116 / 130 REQ-GNSSUT-EE-TI-220 Title GNSS nominal scenarios definition The GNSS nominal scenarios available in the frame of GNSS UT TI application performance specification are those defined in the following table: E5a L2 E5b E5AltBoc E6A E6BC L1A L1BC L1C/A GPS Single frequency without Integrity GPS Dual frequency without integrity GPS Single frequency with Integrity GPS Dual frequency with integrity Galileo Single Frequency with integrity Galileo Dual Frequency with integrity The previous table is applicable for both rural and urban scenarios. Details on scenarios are provided in the following requirements. REQ-GNSSUT-EE-TI-230 Title GPS Single frequency without Integrity rural nominal scenario The GPS Single Frequency on L1 rural nominal scenario defined in the frame of GNSS UT TI application performance specification shall be complaint with the UERE/UERRE table reported in the following (TBC and TBD): GPS Satellite Single Frequency without Integrity Band Modulation Message Environment RF FE Configuration L1 BPSK GPS NAV RV Aereonautical UERE Mixed Residual Ionosphere error 737,20 659,74 590,83 529,99 430,47 357,17 324,74 324,74 324,74 OD & TS error 535,72 535,72 535,72 535,72 535,72 535,72 535,72 535,72 535,72 Residual Troposphere error 135,10 75,30 51,45 39,18 26,92 20,97 17,61 15,58 13,50 Thermal noise,interf.,multipath ra 68,91 68,61 68,51 68,47 68,43 68,43 68,41 68,41 68,41 Multipath bias error 33,50 33,50 33,50 33,50 33,50 33,50 33,50 33,50 33,50 Satellite BGD error 50,00 50,00 50,00 50,00 50,00 50,00 50,00 50,00 50,00 Code-Carrier Ionospheric diverge 15,94 15,94 15,94 15,94 15,94 15,94 15,94 15,94 15,94 Total 925,93 858,20 804,55 760,26 693,97 650,82 633,50 633,45 633,40 Total+10% margin 1018,52 944,02 885,00 836,28 763,36 715,90 696,85 696,79 696,74 1-sigma error [cm] UERE budget: GPS Single Frequency (L1) without integrity in rural environment TBD UERRE budget: GPS Single Frequency (L1) without integrity in rural environment

117 Class: PUB Page 117 / 130 REQ-GNSSUT-EE-TI-240 Title GPS Dual frequencies without Integrity rural nominal scenario The GPS Dual Frequencies rural nominal scenario defined in the frame of GNSS UT TI application performance specification shall be complaint with the UERE/UERRE table reported in the following (TBC and TBD): GPS Satellite double Frequency without Integrity Band Modulation Message Environment RF FE Configuration L1 BPSK GPS NAV RV Aereonautical UERE Mixed Residual Ionosphere error 184,30 164,94 147,71 132,50 107,62 89,29 81,19 81,19 81,19 OD & TS error 133,93 133,93 133,93 133,93 133,93 133,93 133,93 133,93 133,93 Residual Troposphere error 33,77 18,82 12,86 9,79 6,73 5,24 4,40 3,90 3,38 Thermal noise,interf.,multipath ra 68,91 68,61 68,51 68,47 68,43 68,43 68,41 68,41 68,41 Multipath bias error 33,50 33,50 33,50 33,50 33,50 33,50 33,50 33,50 33,50 Satellite BGD error 50,00 50,00 50,00 50,00 50,00 50,00 50,00 50,00 50,00 Code-Carrier Ionospheric diverge 15,94 15,94 15,94 15,94 15,94 15,94 15,94 15,94 15,94 Total 248,33 232,55 220,20 210,13 195,25 185,73 181,95 181,93 181,92 Total+10% margin 273,17 255,80 242,22 231,14 214,78 204,31 200,14 200,13 200,11 1-sigma error [cm] UERE budget: GPS Dual Frequencies without integrity in rural environment TBD UERRE budget: GPS Dual Frequencies without integrity in rural environment REQ-GNSSUT-EE-TI-250 Title GPS Single frequency with Integrity rural nominal scenario The GPS Single Frequency on L1 rural nominal scenario defined in the frame of GNSS UT TI application performance specification shall be complaint with the UERE/UERRE table reported in the following (TBC and TBD): TBD UERE budget: GPS Single Frequency (L1) with integrity in rural environment TBD UERRE budget: GPS Single Frequency (L1) with integrity in rural environment REQ-GNSSUT-EE-TI-260 Title GPS Dual frequencies with Integrity rural nominal scenario The GPS Dual Frequencies rural nominal scenario defined in the frame of GNSS UT TI application performance specification shall be complaint with the UERE/UERRE table reported in the following (TBC and TBD): TBD UERE budget: GPS Dual Frequencies with integrity in rural environment TBD UERRE budget: GPS Dual Frequencies with integrity in rural environment

118 Class: PUB Page 118 / 130 REQ-GNSSUT-EE-TI-270 Title Galileo Single Frequency on L1 with integrity rural nominal scenario The Galileo Single Frequency on L1 rural nominal scenarios defined in the frame of GNSS UT TI application performance specification shall be complaint with the UERE/UERRE table defined in the TUSREQ document and reported in the following: UERE budget: Galileo Single Frequency (L1) in rural environment TUS Identifier N 15 UERRE budget (200ms): Galileo Single Frequency (L1) in rural environment

119 Class: PUB Page 119 / 130 REQ-GNSSUT-EE-TI-280 Title Galileo Single Frequency on E5b with integrity rural nominal scenario The Galileo Single Frequency on E5b rural nominal scenarios defined in the frame of GNSS UT TI application performance specification shall be complaint with the UERE/UERRE table defined in the TUSREQ document and reported in the following: UERE budget: Galileo Single Frequency (E5b) in rural environment UERRE budget (200ms): Galileo Single Frequency (E5b) in rural environment TUS Identifier N 16

120 Class: PUB Page 120 / 130 REQ-GNSSUT-EE-TI-290 Title Galileo Dual Frequencies with integrity rural nominal scenario The Galileo Dual Frequencies rural nominal scenario defined in the frame of GNSS UT TI application performance specification shall be complaint with the UERE/UERRE table defined in the TUSREQ document and reported in the following: UERE budget: Galileo Dual Frequencies in rural environment UERRE budget (200ms):Galileo Dual Frequencies in rural environment TUS Identifier N 19 REQ-GNSSUT-EE-TI-300 Title GPS Single frequency without Integrity urban nominal scenario The GPS Single Frequency on L1 urban nominal scenario defined in the frame of GNSS UT TI application performance specification shall be complaint with the UERE/UERRE table reported in the following (TBC and TBD): TBD UERE budget: GPS Single Frequency (L1) without integrity in urban environment TBD UERRE budget: GPS Single Frequency (L1) without integrity in urban environment

121 Class: PUB Page 121 / 130 REQ-GNSSUT-EE-TI-310 Title GPS Dual frequencies without Integrity urban nominal scenario The GPS Dual Frequencies urban nominal scenario defined in the frame of GNSS UT TI application performance specification shall be complaint with the UERE/UERRE table reported in the following (TBC and TBD): TBD UERE budget: GPS Dual Frequencies without integrity in urban environment TBD UERRE budget: GPS Dual Frequencies without integrity in urban environment REQ-GNSSUT-EE-TI-320 Title GPS Single frequency with Integrity urban nominal scenario The GPS Single Frequency on L1 urban nominal scenario defined in the frame of GNSS UT TI application performance specification shall be complaint with the UERE/UERRE table reported in the following (TBC and TBD): TBD UERE budget: GPS Single Frequency (L1) with integrity in urban environment TBD UERRE budget: GPS Single Frequency (L1) with integrity in urban environment REQ-GNSSUT-EE-TI-330 Title GPS Dual frequencies with Integrity urban nominal scenario The GPS Dual Frequencies urban nominal scenario defined in the frame of GNSS UT TI application performance specification shall be complaint with the UERE/UERRE table reported in the following (TBC and TBD): TBD UERE budget: GPS Dual Frequencies with integrity in urban environment TBD UERRE budget: GPS Dual Frequencies with integrity in urban environment

122 Class: PUB Page 122 / 130 REQ-GNSSUT-EE-TI-340 Title Galileo Single Frequency on L1 with integrity urban nominal scenario The Galileo Single Frequency on L1 urban nominal scenarios defined in the frame of GNSS UT TI application performance specification shall be complaint with the UERE/UERRE table defined in the TUSREQ document and reported in the following: TBD UERE budget: Galileo Single Frequency (L1) in urban environment TBD UERRE budget (200ms): Galileo Single Frequency (L1) in urban environment REQ-GNSSUT-EE-TI-350 Title Galileo Single Frequency on E5b with integrity urban nominal scenario The Galileo Single Frequency on E5b urban nominal scenarios defined in the frame of GNSS UT TI application performance specification shall be complaint with the UERE/UERRE table defined in the TUSREQ document and reported in the following: TBD UERE budget: Galileo Single Frequency (E5b) in urban environment TBD UERRE budget (200ms): Galileo Single Frequency (E5b) in urban environment REQ-GNSSUT-EE-TI-360 Title Galileo Dual Frequencies with integrity urban nominal scenario The Galileo Dual Frequencies urban nominal scenario defined in the frame of GNSS UT TI application performance specification shall be complaint with the UERE/UERRE table defined in the TUSREQ document and reported in the following: TBD UERE budget: Galileo Dual Frequencies in urban environment UERRE budget (200ms):Galileo Dual Frequencies in urban environment Performance requirements The UT will decide on the TI Status in the following way: TI status = system failure: when the UT or any part of it doesn't work, that is when start-up or diagnostics tests have failed. TI status= TI info unknown: when the UT works but there is no SIS available.

123 Class: PUB Page 123 / 130 TI Status= TI ok: when there is an intersection between [TLCmin, TLCmax] and [Lmin, Lmax]. TI Status= TI lost: when there is not an intersection between [TLCmin, TLCmax] and [Lmin, Lmax]. Lmax depends on the length, coupling, train type, etc. and is difficult to assign a fix value, though it is not safety critical. A study of possible values is included in Appendix G. REQ-GNSSUT-EE-TI-370 Title Train Length Accuracy The Integrity Function implemented in the frame of the EE GNSS-UT shall provide the Train Length information with the following accuracies, depending on the GNSS UT operational conditions as follows: GNSS Availability Accuracies (m) GPS Egnos Galileo with integrity Urban Rural Single freq. No Dual freq No Single freq. Yes Dual freq Yes Single freq on L1BC Single freq on E5b Dual freq on L1BC/E5b No no no REQ-GNSSUT-EE-TI-380 Title Availability The Accuracies specified above shall be met for 99% of the time for main lines and 95% of the time for low density lines, in any place within the service volume, when operating in the Nominal SIS Constellation state Availability defined does not include radio link/battery availability. (TBC)

124 Class: PUB Page 124 / 130 REQ-GNSSUT-EE-TI-390 Title Continuity The probability of GNSS UT discontinuity predicted over the next critical operation period (15 sec TBC) shall not exceed the specified value of 8.0e-5 (TBC) assuming the SoL core system performance requirements (without receiver contribution) of 8.0e-6 on 15 sec. 1. A discontinuity of service occurs when the service is available at instant To and if one of the following unpredictable events occurs («OR»): * loss of PVT solution * loss of HMI probability computation function * the predicted probability of HMI in any 150 s changes so that it exceed a specified value * No Integrity Message is received by the Receiver at the given epoch 2. Continuity requirement is related to the probability that the system's signal will meet accuracy and integrity requirements continuously for a specified period. Service volume is the area of coverage for which the system's signal will meet availability requirements. 3. The continuity of the signal have been assured without additional facilities or funding. REQ-GNSSUT-EE-TI-400 Title Reference Time The Integrity Function implemented in the frame of the EE GNSS-UT shall time stamp integrity information data according to the GNSS-EE-UT reference time. REQ-GNSSUT-EE-TI-410 Title Output solution rate The Output of the Integrity Function implemented in the frame of the EE GNSS-UT shall be provided at a 1 Hz rate or higher (TBC). The GNSS TI data update to the EVC shall be performed automatically in cycles (favourable for heavily used routes) or event-driven by the EVC or on manual request (Configurable). TBC REQ-GNSSUT-EE-TI-420 Title Displaying The information to train staff shall be refreshed periodically. Refresh time shall be of 1 second maximum REQ-GNSSUT-EE-TI-430 Title train length confirmation rate The GNSS subsystem shall provide the ETCS subsystem with a confirmation status within X seconds from the Train data entry (TBC).

125 Class: PUB Page 125 / 130 REQ-GNSSUT-EE-TI-440 Title Environmental requirements The Performance of the Integrity Function implemented in the frame of the EE GNSS-UT shall be independent from environmental influences topography and buildings. REQ-GNSSUT-EE-TI-450 Title Data storage The Integrity Function implemented in the frame of the EE GNSS-UT shall store (provide the Juridical recorder TBC) the following set of data (TBC), and these data shall be time stamped (reference to be agreed ) : - Configuration parameter at each change of configuration performed by the train staff. - All the alarms generated by the subsystem - All the sub-system change of status - The real time status corresponding to a given time window (TBD) ending at the last sample sent to the on-board equipment RAMS requirements REQ-GNSSUT-EE-TI-460 Title Reliability Requirements TBD REQ-GNSSUT-EE-TI-470 Title Safety Requirements A probability of wrong side failure (failure not detectable neither by the sub-system itself, nor by the signalling equipment) of XX/hour is required for each train integrity assessment channel of the sub-system. These figures must be proved by a careful safety analysis. These objectives are applicable to the interface between the Train integrity assessment subsystem and the ETCS subsystem. Consequently, all failures of the sub-system must be considered, including but not limited to: Failures related to the end of train equipment Failures related to the front equipment Failures related to the radio transmission between Front and End of train devices Failures related to any external system used to evaluate the train integrity status (e.g. GNSS system )

126 Class: PUB Page 126 / 130 REQ-GNSSUT-EE-TI-480 Title Maintainability Requirements (1) For the Front Equipment: Mean Active Repair Time (MART): TBD (2) For the End of train device: Mean Active Repair Time (MART): TBD. (3) The packaging of the front equipment shall allow quick and easy replacement of the unit. (4) The unit mounting shall be a trade-off between time and inopportune disassembling protection. (5) If maintenance tasks are required, they must be defined in a maintenance manual Specification for the local augmentation TBD Specification for the digital route maps and databases Comparing the difference between two positions and the train length does not allow deriving the integrity easily if the track is not a straight line (which is very frequently the case). A track database could be necessary to know the correct track length between two positions. TBD 5.3 Interfaces Definition of internal interfaces With reference to the context diagram described in section 5.2.2, the Train integrity assessment sub-system has one internal interface: Interface (3) (TBD) The interface between the front device and the end of train device must be designed in such a way that : The communication medium (radio communication) does not need to be fail safe The refresh rate for data over communication is of X second maximum (TBD) The way to transmit data of both measurement channels between the end of train device and the HoT device is done in such a way that it allows guaranteeing the safety at the system level. Considering this second point, and in particular, precautions have to be taken to guarantee the detection of Hardware failure in both Front and end of train devices, such as freeze of memory Identification of external interfaces With reference to the context diagram described in section 5.2.2, the GNSS Train integrity subsystem has the following external interfaces: Interface GNSS subsystem to train

127 Class: PUB Page 127 / 130 This interface between the EOT part of the equipment is a mechanical interface as there is no electrical interface available on most of the wagons. The end of train device shall be mounted on the coupler of the last wagon (if existing) or another location to be defined (e.g. usual place of the red light). It must be mounted in such a way that it will either detect if an additional vehicle is coupled to the former last vehicle, or it shall stop working in such a case. The attachment and connection of the end of train device shall be possible within a short period of time (e.g 1 or 2 minutes) when wearing gloves. The HoT device of the GNSS subsystem shall be installed in the front locomotor of the train. It shall be possible to : either to have a permanent installation of the HoT device. In that case, the HoT equipment can be powered by the train power supply. or for a non-permanent installation, for the duration of a train mission. In that case, the Hot equipment shall be self-powered. The same applies for the antennas required by the sub system. Interface GNSS subsystem to ETCS The HoT train device shall interface with the ETCS onboard equipment located in the same locomotive. It shall provide the ETCS subsystem with train integrity status and calculated train length confidence interval via digital I/0 interfaces. During the start of mission it shall also provide train length confirmation. It shall also provide a sub-system status to the ETCS equipment, and optionally directly to the driver via a man machine interface as part of the front device of the sub system. At the minimum, the status of the communication between HoT and EoT device shall be provided to the signalling equipment (communication OK/not OK). Other status related to the correct operation of the sub-system shall be provided to the train driver. Interface GNSS subsystem to Train staff and/or train Driver The Hot train integrity assessment device shall provide an interface with the train staff or train driver. This interface shall be used: To configure the train integrity assessment sub-system when a train is composed, in particular considering the matching of the HoT and the end equipment. To provide the train driver with real time train integrity status for train operation purposes: driver must be informed using visual and acoustical information when train integrity is lost. To provide the train staff with real time status of the train integrity assessment sub-system, including but not limited to : Status of end of train device battery, possibly of front device battery Status of front to end devices communication

128 Class: PUB Page 128 / 130 Any fault of either the front or the end device To provide the train staff with real time visual and acoustical alarms when the following events occur: end of train device or possibly front device battery level is low (threshold should programmable and corresponds to remaining hours of working) Communication between front and end devices is lost Communication between front and end devices is restored Sub-system failure Interface GNSS subsystem to Juridical recorder The HoT device shall provide an interface with the juridical recorder through the EVC. This interface shall provide the Juridical Recorder with the following set of data (non-exhaustive list), and these data shall be time stamped (reference to be agreed): Configuration parameter at each change of configuration performed by the train staff. All the alarms generated by the subsystem All the sub-system change of status The device shall also be able to memorise the values of the real time status provided to the signalling equipment corresponding to a given time window (TBD) ending at the last sample sent to the signalling equipment. 5.4 Impact on ERTMS/ETCS SRS In the SRS the detection of Train integrity is not planned to be a function of an onboard System in ETCS Level 1 and 2. In Level 1 even no possibility is foreseen for the train to send the integrity information to the trackside. Only for Level 3 the detection of train integrity is defined as a function of an onboard subsystem. But train integrity is defined as an external function. The ETCS Onboard Unit has to receive the information and send it to the radio block centre. It has to be expected, that the impact of the selected solution on the components of the SRS ETCS is rather small. The impact of the selected solution on the components of the SRS ETCS is described below: Trackside Subsystem a) balise There is no impact on the balises. The train integrity information is send from the train to the trackside via the radio communication network. b) lineside electronic unit (LEU) There is no impact on the LEU. The train integrity information is send via the radio communication network. c) radio communication network (GSM-R) In ETCS Level 3 the transfer of the integrity information via GSM-R is foreseen in the SRS. In Level 2 the transfer is not foreseen but possible due to the fact that a communication between track and train via GSM-R exists. The message has to be defined. In Level 1 a

129 Class: PUB Page 129 / 130 permanent communication between the train and the trackside does not exist. To integrate the monitoring of the train integrity in Level 1 a communication from train to track has to be implemented. d) Radio Block Centre (RBC) In ETCS Level 3 the transfer of the integrity information from the train to the RBC via GSM- R is foreseen in the SRS. So there has to be a function in the RBC for using the information anyway. For ETCS Level 1 and 2 it is not specified that the train sends the integrity information to the trackside. In this case the change has an impact on the RBC, but the detailed specification of the RBC is outside the scope of the ETCS SRS. e) Euroloop The Euroloop is used for Semi-continuous communication between track and train in ETCS Level 1. It is used to send new information to the train as soon as it is available instead of using only balises. The selected solution has no impact on the Euroloop. f) Radio infill unit The Radio infill unit is, as the Euroloop, used to send infill information from the track to the train in Level 1. The selected solution has no impact on the Radio infill unit. Onboard Subsystem a) ERTMS/ETCS on-board equipment 1. ETCS version management Impact! Every change within the subset s will entail to a new version. 2. Interface Odometry Kernel (proprietary) Impact only to the supplier 3. Interface GNSS Kernel (proprietary) Impact only to the supplier 4. Specification Subset 076 System Tests Impact! So far Subset 076 specifies only tests up to Level 2. Test for Level 3 Train integrity must be specified. Subset-091 Safety Requirements for Technical Interoperability Impact! Safety Requirements only available up to Level 2 and have to be specified for Train integrity. Subset-088 ETCS Application Levels 1 & 2 - Safety Analysis Impact! Safety Analysis only available up to Level 2. b) the on-board part of the GSM-R radio system; no impact c) specific transmission modules for existing national train control systems.

130 Class: PUB Page 130 / 130 no impact Justification: Subset 026 Part 2 Section describes the localization of the train integrity function for level 1. Subset 026 Part 2 Section describes the localization of the train integrity function for level 2. Subset 026 Part 2 Section describes the ETCS onboard functions for level 3. Subset 026 Part 3 Section describes completely the procedure of report of Train Rear End position for level 3. Subset 026 Part 7 Section Packet 0 and 1 contains the variables to report train integrity. Unfortunately most of descriptions don t consider Level 3. A serious use of train integrity functions will likely demand new descriptions. At least notes must be inserted. END OF MAIN DOCUMENT

131 Class: PUB Page A 1 APPENDIX A. TRAIN AWAKENING PERFORMANCE ANALYSIS PURPOSE The purpose of this technical note is the estimation of the time need to a GALILEO/GPS-EGNOS receiver to obtain 2 meters of horizontal accuracy. This number has been defined from the GRAIL consortium in the frame of Train Awakening application. INTRODUCTION Train awakening application in a RBC area, describes the procedure when train equipment is powered up and a cab is activated. If the train and/or the RBC can determine a safe envelope for the train location, then the train shall be able to start its mission in full supervision after awakening. To ensure the security of this application the RBC shall be able to estimate the position of a train on a line with high accuracy. The note contains different analyses: A theoretical analysis based and Galileo performance A GPS-EGNOS analysis based on true data THE THEORY An example of a live test executed with a GPS receiver is showed in the sideways figure. It could be note that the results appear like a cloud around the real position, so to increase the position accuracy we had analyze the position error averaging the x and y samples. The distribution of GPS fixes of a position may be approximated by a bivariate normal distribution with no correlation between the two variables. For simplicity, one might assume the same variance in each direction. With those approximating assumptions, the error distribution can be described by a very simple equation, which is known as a Rayleigh distribution:

132 Class: PUB Page A 2 This yields the histogram sideways. HISTOGRAM OF HORIZONTAL ERRORS Garmin 12XL (Micropulse antenna) Proportion of Measurements Legend Measured hist2 Predicted phist2 Predicted histogram is based on the measured RMS error of 5.0 m over the 20 days days data Fix every 2 seconds Error Distance (1-meter bins) This plot is useful in relating the RMS error, the median (50% error bound or CEP error), and the 95% error bound (ΔHPRE95) to the Rayleigh distribution used for modeling GPS error. Probability that point is less than Distance DISTANCE/RMS VS. PROBABILITY Probability = 1-exp(-(Distance/RMS) 2 ) 63% 50% (CEP) 95% (RMS) 1.73 NOTE: Measured position error may be very large for a small percentage of the time Distance/RMS (Multiply by RMS to get Distance) CEP (Circular Error Probable) is also the median error. Based on the Rayleigh distribution, the table below can be used to estimate one error statistic from another. To estimate an error statistic on the top from an error statistic on the left, multiply by the corresponding number in the table. In the table, "E-N" indicates easting or northing error (the error in longitude or latitude in length units) and "Horizontal" indicates horizontal position error.

133 Class: PUB Page A 3 E-N Mean/58 % E-N RMS/68 % E-N 95% Horizont al CEP/50 Horizont al Mean/54 Horizont al Horizont al 95% E-N Mean/58% E-N RMS/68% E-N 95% HorizontalCEP/50% Horizontal Mean/54% Horizontal RMS/63% Horizontal 95% TRAIN AWAKENING PERFORMANCE USING A GALILEO RECEIVER The results presented in the following have been derived from Simulations performed using Galileo Requirements (TUSREQ) as reference: TUSREQ-1801: the horizontal accuracy of a Safety of Life double frequency receiver shall be 4 m at 95%. The simulations have been performed using a TUS tool developed in AASI able to estimate the PVT accuracy of a receiver with recursive least square algorithm using as input the user equivalent ranging error (UERE) table. In this case we have used the UERE table referred to a dual frequency with integrity receiver in rural vehicle environment as defined in TUSREQ and reported in the following. Error Source Elevation angle (degrees) (UERE/14) Residual Ionosphere error SISA Residual Troposphere error thermal noise, interfer., multipath Multipath bias error Satellite BGD error Code-Carrier Ionospheric divergence error total (1-sigma error [cm]) total+10% margin (1-sigma error [cm]) E5b-L1 Rural Vehicle (RV) HMI Probability Computation To verify the GALILEO horizontal accuracy performance, we have been the following test:

134 Class: PUB Page A 4 10 days of duration GALILEO constellation period with time step of 5 minutes latitude, longitude steps of 5 degrees Results are shown in the following figure: The result of this simulation is that a receiver with the UERE defined in the TUSREQ provides an horizontal accuracy of 3.2 m at 95 %. Anyway, in the following analysis we have used 4 m at 95 % of horizontal accuracy as defined in TUSREQ document. The RMS error on E-N frame is given by. RMS E N = 4 * 0.41 = 1. 64m Starting from RMSE-N, we are able to generate the distribution of GPS fixes of a position through a bivariate normal distribution with the RMS error above mentioned. On the basis of the previous specification, same simulations have been carried out. This figure shows the E-N samples with the color defined normalized at the maximum of the distribution of the distance. From the E-N samples we estimate the distance error according to the following equation: 2 d error = E + _ N 2

135 Class: PUB Page A 5 From the distance error, we perform the histogram shown in this figure. The distribution of the distance error evaluated averaging the E-N on n samples is given by: d n error = n 2 E n + n 2 N n The following table reports the results: n distance error (m) samples Mean Std 1 bound (m) % of samples in bound 2 bound (m) % of samples in bound

136 Class: PUB Page A 6 Concluding: the accuracy is less than 1 m using 100 samples of E-N measurements. The minimum time need to obtain the previos accuracy value is given by the following equation: time = acquisition time + CCFSF time + averaging time where: Acquisition time is the maximum time to estimate the first PVT solution (cold start mode, that is without any information of time, constellation almanac and position); CCSF time is the convergence time need to the code carrier smoothing filter convergency Averaging time is the time need to accumulate and estimate the averaging position (if the frequency of the PVT solution is of 1Hz are necessary 100 sec). Concluding: An accuracy of 0.7m at 7σ can be obtained using 100 sec of data at 1Hz. Train AWAKENING Performance using a GPS Receiver In this paragraph are presented the results obtained using true data generated from a commercial receiver. The receiver specification provides an horizontal position accuracy of 1.8 m CEP with GPS L1 signal; CEP is the mean circular error probable otherwise that the 50% of error. Note that these values are nominal values; they dependent on ionospheric and/or tropospheric conditions, on multipath effects and on interference environment.

137 Class: PUB Page A 7 In the near figure there are shown the errors on the east north and up coordinates of the performed test (commercial receiver with the antenna on the roof of Milano AASI facility). The standard deviations obtained are the following: East = m North = Up = Averaging the east and north data on 100 samples we obtain the error distance distribution reported in the figure: only the 83.8 % of solution are under 2 meters of bound.

138 Class: PUB Page A 8 The following results are referred to simulation performed using the nominal performance (1.8 CEP contained in the receiver specification). The difference between true data and simulated data is important: the environment plays a crucial role in the receiver performance. The simulated result is similar to the true data increasing of 10 the declared performance (see the figure). END OF APPENDIX A