GNSS Subsystem Requirement Specification for … Subsystem Requirement Specification for ... Cc Indra Espacio Carlos ... GRAIL-WP3-TIF-DEL-3.1.1-GNSS Subsystem Requirement Specification

Project funded by the European GNSS Supervisory Authority 6FP 2nd Call. Area 1A: User Segment, User Community

Contract: GJU/05/2409/CTR/GRAIL

GRAIL: GNSS Introduction in the RAIL sector

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 3.1.2

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

Ref: GRAIL-WP3-TIF-DEL-312

Issue: 1.0 Date: 26/06/07

GNSS Subsystem Requirement Specification for Enhanced ETCS

applications Class: PUB Page 2 / 130

GRAIL: GNSS Introduction in the RAIL sector GSA Contract Number: GJU/05/2409/CTR/GRAIL

DOCUMENT CHANGE LOG

Issue Date Affected Sections Comments

0.1 12/04/2006 All Functional description - 1st Draft

0.2 16/05/2006 Section 1, 2 and 3 Comments from SIEMENS included Comments from ALCATEL included DLR proposal for section 3 included

0.3 23/05/2006 Section 1, 2 and 3 Comments from BOMBARDIER and SIEMENS

0.4 01/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

0.5 10/12/2006 All Review from Coordinator

0.6 29/03/2007 1.3,1.5, 3.2.1, 3.2.2 Comments from SPMJ included

1.0 26/06/2007 All First Approved version


Issue: 1.0 Date: 26/06/07




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


Issue: 1.0 Date: 26/06/07




TABLE OF CONTENTS

1 INTRODUCTION......................................................................................................... 8 1.1 Purpose ........................................................................................................................8 1.2 Intended audience / Classification................................................................................ 8 1.3 Reference Documentation............................................................................................ 8 1.4 Associated documentation ........................................................................................... 8 1.5 Abbreviations and Acronyms........................................................................................ 9 1.6 Glossary of Terms and Definitions.............................................................................. 11

2 SELECTED ENHANCED ETCS APPLICATIONS .................................................... 17 3 TRAIN AWAKENING & COLD MOVEMENT DETECTOR........................................ 18

3.1 Application definition................................................................................................... 18 3.1.1 Enhanced Train Awakening and Cold Movement Detector................................. 18 3.1.2 Nominal Operational scenarios for position qualification/identification................ 19 3.1.3 Degraded Operational scenarios for position qualification/identification ............. 21 3.1.4 Nominal Operational scenarios for RBC ID/phone number................................. 23 3.1.5 Degraded Operational scenarios for RBC ID/phone number qualification/identification .................................................................................................... 24

3.2 System Requirement Specification............................................................................. 25 3.2.1 GNSS Enhanced TA & CMD Functional description........................................... 25 3.2.2 System specification............................................................................................ 27 3.2.3 Status of RBC ID/phone number data affected by Start of mission procedure with Enhanced ETCS applications ............................................................................................. 33 3.2.4 System Architecture ............................................................................................ 34 3.2.5 Requirements for the on-board and trackside modules....................................... 38

3.3 Impact on the SRS ..................................................................................................... 55 3.3.1 Impact of CMD functionality................................................................................. 56 3.3.2 Impact of TA functionality .................................................................................... 56

4 ABSOLUTE POSITIONING....................................................................................... 59 4.1 Application definition................................................................................................... 59 4.1.1 LOCOPROL approach: ....................................................................................... 59 4.1.2 Absolute Positioning Reference Point approach: ................................................ 62 4.1.3 Operational benefits ............................................................................................ 64 4.1.4 Operational scenarios ......................................................................................... 64

4.2 System requirement specification............................................................................... 67 4.2.1 GNSS AP System Functional Description ........................................................... 67


Issue: 1.0 Date: 26/06/07




4.2.2 System architecture............................................................................................. 71 4.2.3 Requirements for the Onboard and trackside modules....................................... 74 4.2.4 Use of Local Augmentation ................................................................................. 92 4.2.5 Use of Digital Route Maps and databases .......................................................... 93 4.2.6 Linking of physical Balises and GNSS absolute positions................................... 94

4.3 Impact on the ERTMS/ETCS class 1 specifications ................................................... 95 4.4 Conclusion.................................................................................................................. 96

5 TRAIN INTEGRITY ................................................................................................... 97 5.1 Application definition................................................................................................... 97 5.1.1 Train Integrity Macro-function.............................................................................. 97 5.1.2 Operational scenarios ......................................................................................... 99

5.2 System requirement specification............................................................................. 104 5.2.1 GNSS TI System Functional Description........................................................... 104 5.2.2 System Architecture .......................................................................................... 106 5.2.3 Requirements for the on-board and trackside modules..................................... 108 5.2.4 Specification for the local augmentation............................................................ 126 5.2.5 Specification for the digital route maps and databases..................................... 126

5.3 Interfaces.................................................................................................................. 126 5.3.1 Definition of internal interfaces .......................................................................... 126 5.3.2 Identification of external interfaces.................................................................... 126

5.4 Impact on ERTMS/ETCS SRS ................................................................................. 128

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


Issue: 1.0 Date: 26/06/07




LIST OF TABLES

Table 1. Requirements for Procedure (Position)............................................................................. 30 Table 2. State of Train position data ............................................................................................... 31 Table 3. Requirements for Procedure (RBC ID/phone number) ..................................................... 33 Table 4. State of RBC ID/phone number data ................................................................................ 34 Table 5. Scenario compatibility table .............................................................................................. 66

LIST OF FIGURES

Figure 1: GNSS Enhanced Odometry Subsystem external interfaces ........................................... 13 Figure 2: User Terminal .................................................................................................................. 16 Figure 3: Possible exploitation scenarios........................................................................................ 19 Figure 4: DFD for CMD and Enhanced Train Awakening module .................................................. 26 Figure 5: Components of a valid position information provided by an enhanced Train Awakening

module ..................................................................................................................................... 27 Figure 6: Start of Mission flow chart with Enhanced ETCS functions. Position .............................. 29 Figure 7 Start of Mission flow chart with Enhanced ETCS functions: RBC ID/phone number........ 32 Figure 8: 1st possible technical implementation ............................................................................. 34 Figure 9: 2nd possible technical implementation (First solution) .................................................... 35 Figure 10: 2nd possible technical implementation (Second solution) ............................................. 35 Figure 11: 3rd possible technical implementation........................................................................... 36 Figure 12: CMD/TA Architecture..................................................................................................... 37 Figure 13: Proposed architecture based in current BTM ................................................................ 38 Figure 14: Impact of CMD/TA functionalities in ERTMS/ETCS specs version 2.2.2 [2].................. 57 Figure 15: Impact of CMD/TA functionalities in ERTMS/ETCS specs version 2.3.0 [3].................. 58 Figure 16: LOCOPROL fusion approach ........................................................................................ 60 Figure 17: LOCOPROL fusion principle.......................................................................................... 61 Figure 18: APRP odometric principle.............................................................................................. 63 Figure 19: Possible migration strategies......................................................................................... 67 Figure 20: Absolute Positioning subsystem .................................................................................... 68 Figure 21: Absolute positioning architecture................................................................................... 72 Figure 22: Entry of the absolute position information...................................................................... 73 Figure 23: Architecture configuration .............................................................................................. 73


Issue: 1.0 Date: 26/06/07




Figure 24: Train integrity macrofunction ......................................................................................... 97 Figure 25: Train integrity margins ................................................................................................... 99 Figure 26: Train integrity subsystem............................................................................................. 104 Figure 27: Context diagram .......................................................................................................... 106 Figure 28: GNSS TI subsystem architecture definition 1 .............................................................. 107 Figure 29: GNSS TI subsystem architecture definition 2 .............................................................. 107


Issue: 1.0 Date: 26/06/07




1 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 applications:

- 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 applications. 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) applications.

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 applications 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


Issue: 1.0 Date: 26/06/07




[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 v2.2.11

[15] Functional Requirement Specification TIMS, ERTMS Users Group, Reference EEIG:

00E996, Document version: 1-, 12.10.2000

[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-3.1.1-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 WP3.5

1.5 Abbreviations and Acronyms

AP Absolute Positioning

APRP Absolute Positioning Reference Point

APS Absolute Positioning System

BTM Balise Transmission Module

CMD Cold Movement Detector

DFD Data Flow Diagram

D_LRBG Distance between the last relevant balise group and the estimated front end of the train of the active cab

DMI Driver Machine Interface

DOP Dilution of precision

E5 Galileo Frequency Band: 1164-1215 MHz

EE Enhanced ETCS

EGNOS European Geostationary Navigation Overlay Service

EKF Extended Kalman Filter

ELM European Land Mass

EMC Electromagnetic Compatibility

EO Enhanced Odometry

EoT End of Train


Issue: 1.0 Date: 26/06/07




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: 1559-1591 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


Issue: 1.0 Date: 26/06/07




SPS Standard Positioning Service

SQ Safety Qualifier

SR Staff Responsible mode

SRS System Requirements Specification

TA Train Awakening

TBC To Be Confirmed

TBD To Be Defined

TBR To be Revalidated

TI Traction Interface or Train Integrity

TIU Train Interface Unit

UERE User Equivalent Range Error

UERRE User equivalent Range Rate Error

UT User Terminal

UTC Universal Time Coordinated

WP 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


Issue: 1.0 Date: 26/06/07




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.


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 highly-available positioning output at all locations - so for highly-demanding applications, 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 applications 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.


Issue: 1.0 Date: 26/06/07




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 applications 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:

GNSS subsystem ETCSSIS

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.


Issue: 1.0 Date: 26/06/07




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.


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 applications 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 applications 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


Issue: 1.0 Date: 26/06/07




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 applications 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.


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


Issue: 1.0 Date: 26/06/07




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

INS LEUTLEUT

Dataprocessing(Coordinates translation…)Dataprocessing(

GNSSreceiverGNSSreceiver

UT

INS LEUTLEUT

Dataprocessing(Coordinates translation…)Dataprocessing(

GNSSreceiverGNSSreceiver

Figure 2: User Terminal


Issue: 1.0 Date: 26/06/07




2 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.


Issue: 1.0 Date: 26/06/07




3 TRAIN AWAKENING & COLD MOVEMENT DETECTOR

3.1 Application definition

3.1.1 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 applications 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.


Issue: 1.0 Date: 26/06/07




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):

Figure 3: Possible exploitation scenarios

3.1.2 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.

3.1.2.1 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)

3.1.2.2 OP_Scenario_Position 2: SoM with invalid or unknown position. Train not in awakening area

Historic:

CMD areaEnhanced TA area


Issue: 1.0 Date: 26/06/07




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



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


Final state: FS cannot be reached at the end of SoM procedure if RBC cannot validate the position.

3.1.2.3 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:


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



3.1.2.4 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.


Issue: 1.0 Date: 26/06/07




Events:


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


3.1.3 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.

3.1.3.1 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:




3 Enhanced Train Awakening Not available




3.1.3.2 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:


Issue: 1.0 Date: 26/06/07




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



3 Enhanced Train Awakening Not able to provide an exploitable reference




3.1.3.3 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:


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.


Issue: 1.0 Date: 26/06/07




3.1.4 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

3.1.4.1 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:


1 On-board RBC ID/telephone number unknown or invalid


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


Final state: Driver is not requested to enter or validate RBC-ID and phone number

3.1.4.2 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:


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


Final state:


Issue: 1.0 Date: 26/06/07




Driver is not requested to enter or validate RBC-ID and phone number

3.1.4.3 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:


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

3.1.5 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.

3.1.5.1 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:


1 On-board Stored RBC ID/telephone number is unknown or invalid


3 Enhanced Train Awakening Not available

4 On-board RBC ID/telephone number is unknown


Final state: Driver is requested to enter or validate RBC-ID and phone number


Issue: 1.0 Date: 26/06/07




3.1.5.2 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:


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

3.2.1 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.

EnhancedTrain Awakening

& Cold Movement Detection

ETCS On Board

TA Status

Context Diagram

Navigation Data

Digital Map

Correct RBC/ID number Validated RBC ID/number

SiS

TA areasReference

Point

Validated Position (Euroradio-like format)

CMD Info (CM detected Y/N, unable to detect)

Info Request


Issue: 1.0 Date: 26/06/07




Level 1

CMD Module ETCS On Board

CMD Status (On/Off)

Navigation Data

Enhanced TAModule

CM Info TA Status

Correct RBC ID number

SiS

Digital MapReferencePoints

Validated Position (Euroradio-like format)

TA Areas

Validated RBC ID/number

Absolute Position

CM Info

Info Request

Info Request

Figure 4: DFD for CMD and Enhanced Train Awakening module

3.2.1.1 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


Issue: 1.0 Date: 26/06/07




D_LRBG

NID_LRBGQ_DIRLRBG: ReverseQ_DLRBG: Reverse

D_LRBG

NID_LRBGQ_DIRLRBG: ReverseQ_DLRBG: Reverse

Figure 5: Components of a valid position information provided by an enhanced Train Awakening module

3.2.1.2 Information ETCS on-board -> User terminal

The messages will have similar structure to standard ETCS messages and will be defined in D3.3.1.

3.2.1.2.1 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.

3.2.1.2.2 CMD Information request

o ETCS on-board is requesting CMD confirmation.

3.2.1.2.3 Enhanced TA information request

o ETCS on-board is requesting Enhanced TA information.

3.2.1.3 Information User Terminal -> ETCS on-board

3.2.1.3.1 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

3.2.1.3.2 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.

3.2.2 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


Issue: 1.0 Date: 26/06/07




3.2.2.1 Function: Validation/identification of Position

3.2.2.1.1 Requirements for procedure.

Figure 6 shows a tentative flow chart for Start of Mission procedure including Enhancement ETCS applications 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.


Issue: 1.0 Date: 26/06/07




D1Stored position

is ‘valid’

A1 Stored position (if any)

is qualified using CDM

output

CDM Module

S0Cab is active

and mode is SB

Enhanced TA module

D2Enhanced

TA has provided a‘valid’ position

S1 Rest of nominal Start of

Mission Procedure with ‘valid’ position

S2 Rest of nominal Start of

Mission Procedure with

‘unknown’ position

FS mode cannot be reached

FS mode can be

reached

yes

yes

no

no

E1

E2 A2 receives information from

Enhanced TA Module

S_NPCab is powered

on (NP)

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

Requirements

S_NP 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


Issue: 1.0 Date: 26/06/07




ID in Flow Chart

Requirements

moved or not

A1 On-board equipment uses information from Cold Movement Detector to confirm valid stored information

E1 Cold Movement Detector module sends status and information to on-board

S0 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

D1 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

A2 When on-board has invalid or unknown stored position data, it uses information provided by Enhanced Train awakening module.

E2 Enhanced Train Awakening module sends status and position relative to a predefined reference to on-board

D2 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

S1 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

S2 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)

3.2.2.1.2 Status of train position data affected by Start of mission procedure with Enhanced ETCS applications

The status of train position data are affected by the Start of mission procedure assisted by both Cold Movement Detector and Enhanced Train awakening:


Issue: 1.0 Date: 26/06/07




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

3.2.2.2 Function: Validation Validation/identification of RBC ID/phone number

3.2.2.2.1 Requirements for procedure.

Figure 7 shows a tentative flow chart for Start of Mission procedure including Enhancement ETCS applications for validation/identification of RBC ID/phone number.


Issue: 1.0 Date: 26/06/07




D1RBC ID/number

is ‘valid’

Enhanced TA module

D2Enhanced

TA has provided a‘valid’ RBC ID

num

S1 Driver is not requested to enter/validate RBC ID/phone

number

S2 Driver is requested to enter/validate RBC ID/phone

number

Rest of S of M procedure

yes

yes

no

no

E2 A2 receives information from Enhanced TA

Module

A1 Stored RBC ID/Phone number (if any) is qualified using

CMD output

CMD Module

S0Cab is active

and mode is SB

E1

S_NPCab is powered

on (NP)

D1RBC ID/number

is ‘valid’

Enhanced TA module

D2Enhanced

TA has provided a‘valid’ RBC ID

num

S1 Driver is not requested to enter/validate RBC ID/phone

number

S2 Driver is requested to enter/validate RBC ID/phone

number

Rest of S of M procedure

yes

yes

no

no

E2 A2 receives information from Enhanced TA

Module

A1 Stored

(if any)

CMD Module

S0Cab is active

and mode is SB

E1

S_NPCab is powered

on (NP)

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


Issue: 1.0 Date: 26/06/07




ID in Flow Chart

Requirements

S_NP 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

A1 On-board equipment uses information from Cold Movement Detector to confirm valid stored information

E1 Cold Movement Detector module sends status and information to on-board

S0 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

D1 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

A2 When on-board has invalid or unknown RBC ID/phone number, it uses information provided by Enhanced Train awakening module.

E2 Enhanced Train Awakening module sends status and RBC ID/phone number

D2 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.

S1 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

S2 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)

3.2.3 Status of RBC ID/phone number data affected by Start of mission procedure with Enhanced ETCS applications

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


A1: Cold Movement detector sends detection of movement or error status

A1: Cold Movement detector sends "no


Issue: 1.0 Date: 26/06/07




State of RBC ID/phone number data


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

3.2.4 System Architecture

3.2.4.1 Initial Proposals for Train Awakening and CMD Architectures

3.2.4.1.1 1st 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

GNSSreceiver

OtherSensors

Coordinatestranslation

LE UT

SQ

ETCS on board

Kernel

BTMODO

Balise

RBC

Doppler Radar, tacho and other odometric signals

1 Relative position

D_LRBGNID_LRBGQ_DLRBGQ_DIRLRBG

2 Positioninfo

- List of referencepoints- TA areas

Euroradio

UT

GNSSreceiver

OtherSensors


LE UT

SQ

ETCS on board

Kernel

BTMODO

Balise

RBC


1 Relative position

D_LRBGNID_LRBGQ_DLRBGQ_DIRLRBG

2 Positioninfo

- List of referencepoints- TA areas

Euroradio

Figure 8: 1st possible technical implementation

3.2.4.1.2 2nd possible technical implementation

• Translation of coordinates takes place in the ETCS on-board.


Issue: 1.0 Date: 26/06/07




• First solution: List of reference points and Train Awakening areas stored in RBC.

Balise

UT

GNSSreceiver

OtherSensors

Dataprocessing

LE UT

SQ

ETCS on board

Kernel BTMODO

RBC-List of referencepoints- TA areas


1 Absolute position

2 Absolutepositioning

3 List of ref. points andTA areas

4 RelativePosition(standardETCSmessage)

Coordinatestranslation RBC

listEuroradio

Balise

UT

GNSSreceiver

OtherSensors

Dataprocessing

LE UT

SQ

ETCS on board

Kernel BTMODOODO

RBC-List of referencepoints- TA areas


1 Absolute position


3 List of ref. points andTA areas


Coordinatestranslation RBC

listRBClistEuroradio

Figure 9: 2nd possible technical implementation (First solution)

• Second solution: List of reference points and Train Awakening areas in on-board equipment

Balise

UT

GNSSreceiver

OtherSensors

Dataprocessing

LE UT

SQ

ETCS on board

Kernel

BTM

ODO

RBC


1 Absoluteposition



- RBC list-Referencepoitns list- TA areasEuroradio

Balise

UT

GNSSreceiver

OtherSensors

Dataprocessing

LE UT

SQ

ETCS on board

Kernel

BTM

ODOODO

RBC


1 Absoluteposition



- RBC list-Referencepoitns list- TA areasEuroradio

Figure 10: 2nd possible technical implementation (Second solution)


Issue: 1.0 Date: 26/06/07




3.2.4.1.3 3rd possible technical implementation

• Translation of coordinates takes place in the RBC.

• List of reference points stored in the RBC

Balise

UT

GNSSreceiver

OtherSensors

Dataprocessing

LEUT

SQ

ETCS on board

KernelBTMODO

RBC

-List of reference points- TA areas


1 Absolute position


3 RelativePosition(standardETCS message)

Euroradio

Coordinatestraslation

Balise

UT

GNSSreceiver

OtherSensors

Dataprocessing

LEUT

SQ

ETCS on board

KernelKernelBTMBTMODO

RBC

-List of reference points- TA areas


1 Absolute position


3 RelativePosition(standardETCS message)

Euroradio

Coordinatestraslation

Figure 11: 3rd possible technical implementation

3.2.4.2 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.


Issue: 1.0 Date: 26/06/07




CMD status

TA reference

Kernel

GNSS Receiver

GNSS Algorithm

ETCS ONBOARD

Train awakening zones map

CMD and TA request. CMD trigger

GNSS UT

CMD status

TA reference

Kernel

GNSS Receiver

GNSS Algorithm

ETCS ONBOARD

Train awakening zones map

CMD and TA request. CMD trigger

GNSS UT

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:


Issue: 1.0 Date: 26/06/07




Receiver

Transmitter

DecoderSerial connection, e.g. RS485

HF connection (coax-cable)

BUS, e.g. MVB

BTM

func

tion

BTM

(o

n bo

ard

equi

pem

t)

Data connection (coax-cable)

ETCS EVC

Antenna

BaliseAirgap, interface A

Receiver

Possibility 1

Possibility 2

GN

SS

-su

bsys

tem

Antenna

Figure 13: Proposed architecture based in current BTM

3.2.5 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 applications), 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 non-visibility, 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 applications such as railway navigation applications, 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.


Issue: 1.0 Date: 26/06/07




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 applications (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.

3.2.5.1 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.

3.2.5.2 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.

3.2.5.3 Functional requirements


Issue: 1.0 Date: 26/06/07




REQ-GNSSUT-EE-TA-010 Title Purpose

Description

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.

Notes

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

Description

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

Notes REQ-GNSSUT-EE-TA-030 Title The “Cold Movement Detector” Sub-function Purpose

Description

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. .

Notes REQ-GNSSUT-EE-TA-031 Title The “Cold Movement Detector” absolute position compute

Description

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)

Notes REQ-GNSSUT-EE-TA-040 Title The “Enhanced Train Awakening” Sub-function Purpose

Description

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.

Notes


Issue: 1.0 Date: 26/06/07




REQ-GNSSUT-EE-TA-050 Title Configuration Data

Description 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

Notes REQ-GNSSUT-EE-TA-060 Title Input Data

Description

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. Notes REQ-GNSSUT-EE-TA-070 Title Output Data

Description

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

Notes REQ-GNSSUT-EE-TA-080 Title Train Awakening status Definition

Description

The Train Awakening status information shall assume the following values: TA Status = valid TA Status = invalid TA Status = unknown.

Notes

REQ-GNSSUT-EE-TA-081 Title Train “Cold Movement detector status Definition

Description

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

Notes


Issue: 1.0 Date: 26/06/07




REQ-GNSSUT-EE-TA-090 Title RBC identification

Description 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

Notes

3.2.5.4 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

Description

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.

Notes


Issue: 1.0 Date: 26/06/07




REQ-GNSSUT-EE-TA-110 Title GPS Single frequency without Integrity “rural nominal scenario”

Description

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):

BandL1

UERE Mixed

Residual Ionosphere error 737,20 659,74 590,83 529,99 430,47 357,17 324,74 324,74 324,74OD & TS error 535,72 535,72 535,72 535,72 535,72 535,72 535,72 535,72 535,72Residual Troposphere error 135,10 75,30 51,45 39,18 26,92 20,97 17,61 15,58 13,50Thermal noise,interf.,Multipath ra 68,91 68,61 68,51 68,47 68,43 68,43 68,41 68,41 68,41Multipath bias error 33,50 33,50 33,50 33,50 33,50 33,50 33,50 33,50 33,50Satellite BGD error 50,00 50,00 50,00 50,00 50,00 50,00 50,00 50,00 50,00Code-Carrier Ionospheric diverge 15,94 15,94 15,94 15,94 15,94 15,94 15,94 15,94 15,94Total 925,93 858,20 804,55 760,26 693,97 650,82 633,50 633,45 633,40Total+10% margin 1018,52 944,02 885,00 836,28 763,36 715,90 696,85 696,79 696,74

GPS Satellite Single

BPSK GPS NAV

Frequency without IntegrityModulation Message Environment RF FE Configuration

5° 10° 15° 20° 90°

1-sigma error [cm]

RV Aereonautical

30° 40° 50° 60°

UERE budget: GPS Single Frequency (L1) without integrity in “rural environment”

TBD UERRE budget: GPS Single Frequency (L1) without integrity in “rural environment”

Notes

REQ-GNSSUT-EE-TA-120 Title GPS Dual frequencies without Integrity “rural nominal scenario”

Description

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):

BandL1

UERE Mixed


RV Aereonautical

GPS Satellite doubleFrequency without Integrity

Modulation Message Environment RF FE Configuration

15° 20°

BPSK GPS NAV

90°

1-sigma error [cm]

30° 40° 50° 60°5° 10°

UERE budget: GPS Dual Frequencies without integrity in “rural environment”

TBD

UERRE budget: GPS Dual Frequencies without integrity in “rural environment” Notes


Issue: 1.0 Date: 26/06/07




REQ-GNSSUT-EE-TA-130 Title GPS Single frequency with Integrity “rural nominal scenario”

Description

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” Notes

REQ-GNSSUT-EE-TA-140 Title GPS Dual frequencies with Integrity “rural nominal scenario”

Description

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” Notes


Issue: 1.0 Date: 26/06/07




REQ-GNSSUT-EE-TA-150 Title Galileo Single Frequency on L1 with integrity “rural nominal scenario”

Description

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”

UERRE budget (200ms): Galileo Single Frequency (L1) in “rural environment”

Notes TUS Identifier N°15


Issue: 1.0 Date: 26/06/07




REQ-GNSSUT-EE-TA-160 Title Galileo Single Frequency on E5b with integrity “rural nominal scenario”

Description

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”



Issue: 1.0 Date: 26/06/07




REQ-GNSSUT-EE-TA-170 Title Galileo Dual Frequencies with integrity “rural nominal scenario”

Description

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”


REQ-GNSSUT-EE-TA-180 Title GPS Single frequency without Integrity “urban nominal scenario”

Description

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”

Notes


Issue: 1.0 Date: 26/06/07




REQ-GNSSUT-EE-TA-190 Title GPS Dual frequencies without Integrity “urban nominal scenario”

Description

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” Notes

REQ-GNSSUT-EE-TA-200 Title GPS Single frequency with Integrity “urban nominal scenario”

Description

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” Notes

REQ-GNSSUT-EE-TA-210 Title GPS Dual frequencies with Integrity “urban nominal scenario”

Description

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” Notes


Issue: 1.0 Date: 26/06/07




REQ-GNSSUT-EE-TA-220 Title Galileo Single Frequency on L1 with integrity “urban nominal scenario”

Description

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”

Notes

REQ-GNSSUT-EE-TA-230 Title Galileo Single Frequency on E5b with integrity “urban nominal scenario”

Description

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”

Notes

REQ-GNSSUT-EE-TA-240 Title Galileo Dual Frequencies with integrity “urban nominal scenario”

Description

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” Notes


Issue: 1.0 Date: 26/06/07




3.2.5.5 Performance requirements

REQ-GNSSUT-EE-TA-250 Title Position accuracy

Description

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 Notes Typical distance between tracks (Spanish high speed line): 4,7 m

REQ-GNSSUT-EE-TA-260 Title Maximum response time Description 120 s from GNSS first fix (the first valid position)

Notes 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

Description 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.

Notes REQ-GNSSUT-EE-TA-290 Title Continuity

Description The Integrity Function implemented in the frame of the EE GNSS-UT continuity shall be better than TBD

Notes REQ-GNSSUT-EE-TA-300 Title Reference Time

Description 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.

Notes


Issue: 1.0 Date: 26/06/07




REQ-GNSSUT-EE-TA-310 Title Output solution rate

Description 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).

Notes

REQ-GNSSUT-EE-TA-320 Title Environmental requirements

Description The Performance of the Integrity Function implemented in the frame of the EE GNSS-UT shall be independent from environmental influences topography and buildings.

Notes

REQ-GNSSUT-EE-TA-330 Title Data storage

Description

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. Notes


Issue: 1.0 Date: 26/06/07




3.2.5.6 Test requirements

REQ-GNSSUT-EE-TA-340 Title Test scenarios identification

Description

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

Notes 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.


Issue: 1.0 Date: 26/06/07




3.2.5.7 Input / Output definition

REQ-GNSSUT-EE-TA-430 Title Communication

Description The Cold Movement Detector and Enhanced Train Awakening applications communication versus ETCS On-board shall be a bi-directional communication.

Notes

REQ-GNSSUT-EE-TA-435 Title CMD standstill trigger from ETCS on-board to User terminal

Description

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)

Notes

REQ-GNSSUT-EE-TA-440 Title CMD Information request from ETCS on-board to User terminal

Description

ETCS on-board is requesting CMD confirmation. Message should have similar structure to standard ETCS messages. The required information with an Euroradio-like 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)

Notes

REQ-GNSSUT-EE-TA-450 Title Enhanced TA information request from ETCS on-board to User terminal

Description

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)

Notes


Issue: 1.0 Date: 26/06/07




REQ-GNSSUT-EE-TA-460 Title CMD Status information request from User terminal to ETCS on-board

Description

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

Notes

REQ-GNSSUT-EE-TA-470 Title Enhanced TA information request from User terminal to ETCS on-board

Description

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)

Notes

REQ-GNSSUT-EE-TA-480 Title Configuration Parameters Description TBC Notes


Issue: 1.0 Date: 26/06/07




REQ-GNSSUT-EE-TA-490 Title Data Base

Description

- 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 Notes

3.2.5.8 Other requirements

REQ-GNSSUT-EE-TA- 500

Title Error estimation and calibration if needed

Description The GNSS TA and CMD system shall provide information only when the confidence interval of the measurements is acceptable

Notes Degraded operation may be defined

REQ-GNSSUT-EE-TA- 510

Title Power on self test and TA and CMD information

Description 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

Notes

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


Issue: 1.0 Date: 26/06/07




3.3.1 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 7 .

3.3.2 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.


Issue: 1.0 Date: 26/06/07




E1 : Driver has entered/ revalidated ‘’valid’’ Driver-ID

FS mode

E26 : SR mode authorised by RBC

S1 The on-board requests the driver to enter/re-validate Driver-ID

S0 Cab is active and mode is SB

D1: Stored level is 2/3 and

RBC-ID + phone number are

“invalid or valid”

Yes

No

A31Onboard contacts RBC

No

Yes

A32Onboard informs Driver

D31Session with RBC

can be opened

Yes

No

A33Onboard reports

‘’valid” position to RBC

D32Stored position

is ‘’valid’’

A34 Onboard reports ‘’invalid or unknown’’

position to RBC

Yes

No

A35RBC reports to Onboard

‘’valid” position

D33RBC is able to confirm position

No

Yes


‘train rejected’’

D22RBC accepts train

A23 RBC reports to Onboard ‘’train accepted’’

A24 Onboard deletes stored position data

A39 Onboard terminates session and deletes stored

position data

A40 Onboard informs Driver

S2 Onboard requests Driver to

enter/re-validate level

S3 Onboard requests Driver

to enter/re-validate RBC-ID + phone

number

2/3

E5 : Data entered by Driver

No

D2 Session is opened

S4 Onboard requests Driver if he

wants to continue without session opened

E7 : Driver selects No

E8 : Driver selects Yes

Yes

S10 Waiting for Driver selection

0/1

A1 Onboard requests Driver to select the STM corresponding

to the mission

STM

E6 : Driver has selected the STM

NL mode

E10 : Driver selects NL

See procedure

‘’SH initiated by Driver’’

E12 : Driver selects SH

E13 : SH refused by RBC

E11 Driver selects Train Data Entry

S12 Onboard requests Driver to enter/revalidate train data

2/3

0/1/STM

D10 Level

E16 Train data are validated

D11Session is opened

S11 Onboard sends train data to RBC and wait for ack

S20 Waiting for Driver selection of ‘’Start’’

Yes

E14 Train data ack by RBC

S21Send MA request to RBC

and wait

S24 SR mode proposed to

Driver

S25OS/SH mode proposed to

Driver

S23UN mode proposed to

Driver

S22 STM mode proposed to

Driver

OS/SH mode

SR mode

UN mode

SE/SN mode dependent on selected STM

E24 : Driver selects ‘’Start’’

and Level is 2/3 E20 : Driver selects ‘’Start’’ and Level is STM E21 : Driver selects

‘’Start’’ and Level is 0 E22 : Driver selects ‘’Start’’ and Level is 1

E30 : Driver ack E31 : Driver ack E32 : Driver ack

E27 : OS/SH MA received from RBC

E33 : Driver ack

E29 : FS MA received from RBC

S14Wait for Driver

selection

See procedure ‘’override

EOA’’

No E15 : Driver selects

‘’Override’’

Go to S2

From S14

E17 Driver selects…

CMD

TA for RBC ID

TA for positionoption 2


E1 : Driver has entered/ revalidated ‘’valid’’ Driver-ID

FS mode

E26 : SR mode authorised by RBC

S1 The on-board requests the driver to enter/re-validate Driver-ID

S0 Cab is active and mode is SB

D1: Stored level is 2/3 and

RBC-ID + phone number are

“invalid or valid”

Yes

No

A31Onboard contacts RBC

No

Yes

A32Onboard informs Driver

D31Session with RBC

can be opened

Yes

No

A33Onboard reports

‘’valid” position to RBC

D32Stored position

is ‘’valid’’

A34 Onboard reports ‘’invalid or unknown’’

position to RBC

Yes

No


‘’valid” position

D33RBC is able to confirm position

No

Yes


‘train rejected’’

D22RBC accepts train

A23 RBC reports to Onboard ‘’train accepted’’

A24 Onboard deletes stored position data

A39 Onboard terminates session and deletes stored

position data

A40 Onboard informs Driver

S2 Onboard requests Driver to

enter/re-validate level

S3 Onboard requests Driver

to enter/re-validate RBC-ID + phone

number

2/3

E5 : Data entered by Driver

No

D2 Session is opened

S4 Onboard requests Driver if he

wants to continue without session opened

E7 : Driver selects No

E8 : Driver selects Yes

Yes

S10 Waiting for Driver selection

0/1

A1 Onboard requests Driver to select the STM corresponding

to the mission

STM

E6 : Driver has selected the STM

NL mode

E10 : Driver selects NL

See procedure

‘’SH initiated by Driver’’

E12 : Driver selects SH

E13 : SH refused by RBC

E11 Driver selects Train Data Entry

S12 Onboard requests Driver to enter/revalidate train data

2/3

0/1/STM

D10 Level

E16 Train data are validated

D11Session is opened

S11 Onboard sends train data to RBC and wait for ack

S20 Waiting for Driver selection of ‘’Start’’

Yes

E14 Train data ack by RBC

S21Send MA request to RBC

and wait

S24 SR mode proposed to

Driver

S25OS/SH mode proposed to

Driver

S23UN mode proposed to

Driver

S22 STM mode proposed to

Driver

OS/SH mode

SR mode

UN mode

SE/SN mode dependent on selected STM

E24 : Driver selects ‘’Start’’

and Level is 2/3 E20 : Driver selects ‘’Start’’ and Level is STM E21 : Driver selects

‘’Start’’ and Level is 0 E22 : Driver selects ‘’Start’’ and Level is 1

E30 : Driver ack E31 : Driver ack E32 : Driver ack

E27 : OS/SH MA received from RBC

E33 : Driver ack

E29 : FS MA received from RBC

S14Wait for Driver

selection

See procedure ‘’override

EOA’’

No E15 : Driver selects

‘’Override’’

Go to S2

From S14

E17 Driver selects…

CMD

TA for RBC ID



Figure 14: Impact of CMD/TA functionalities in ERTMS/ETCS specs version 2.2.2 [2]


Issue: 1.0 Date: 26/06/07




CMD

TA for RBC ID



CMD

TA for RBC ID



Figure 15: Impact of CMD/TA functionalities in ERTMS/ETCS specs version 2.3.0 [3]


Issue: 1.0 Date: 26/06/07




4 ABSOLUTE POSITIONING


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:

4.1.1 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.


Issue: 1.0 Date: 26/06/07




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).

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:

Classical Sensors (e.g. Wheel sensor)

Track digital map: - track Satellite based

positioning

Classical odometry

Fail Safe Position, Speed

Fusion ETCS trainborne application

ETCS Onboard subsystem


Issue: 1.0 Date: 26/06/07




Real Distance

Estimated Traveled Distance(Relative to LRBG)

Odo_Rear

Odo_Upper_bound

Fusion_upper_bound

B1

Fusion_Rear

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;


Issue: 1.0 Date: 26/06/07




• 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.

4.1.2 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.


Issue: 1.0 Date: 26/06/07




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:

Real Distance

Estimated Traveled Distance(Relative to LRBG)

Odo_Rear

Odo_Upper_bound

Fusion_upper_bound

B1

Fusion_Rear

B2

Figure 18: APRP odometric principle


Issue: 1.0 Date: 26/06/07




2. 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.

4.1.3 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.

4.1.4 Operational scenarios

This chapter describes the operational scenarios and the related migration strategy.

4.1.4.1 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 applications (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.

4.1.4.2 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.


Issue: 1.0 Date: 26/06/07




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)

4.1.4.3 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).

4.1.4.4 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 6.

4.1.4.5 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:


Issue: 1.0 Date: 26/06/07




- 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.

4.1.4.6 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:

Trainborne

Wayside

“UT” fitted “Non UT” fitted

Trackside “Standard” Yes, Enhanced odo or absolute positioning if digital map is available

Standard odo

Trackside “GNSS” (digital map management, reduced amount of Balises, without

GNSS linking)

Yes, Absolute positioning only little improved

performance

Yes, but with little degraded performance

Trackside “GNSS” (digital map management, reduced

amount of Balises, with linked GNSS)

Yes, Absolute positioning, improved

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


Issue: 1.0 Date: 26/06/07




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

4.2.1 GNSS AP System Functional Description

Trackside with digital map management and

reduced amount of

Trainborne with UT (enhanced odometry

+absolute positioning)

“Captive” lines or lines with limited interoperability

Trackside with digital map management

Trainborne with UT in enhanced odometry

« Open » Full Inter-operability lines


Trainborne with UT in enhanced odometry + absolute positioning

with existing ETCS specif.

Trackside with digital map management and

reduced amount of

Trainborne with UT (enhanced odometry

+absolute positioning)

with new ETCS specif. (digital map management through

Euroradio)


Trainborne with UT in enhanced odometry + absolute positioning

Short term Middle term Long term

Level 2 Level 3


Issue: 1.0 Date: 26/06/07




GNSS Absolute

PositioningSiS ETCS On-

Board

Navigation data

Context Diagram

ID-Balise

Balise trigger

Status

Travelled Distance, Speed, acceleration

Confidence Interval

APRP Message Telegram

Database update

GNSS Receiver

1

GNSSAlgorithm

2

SiS

ETCS On-Board

Navigation data

Level 1

Database

Balise Trigger

Integrity Status

Database Management

3Integrity

Monitoring4

Integrity data

Integrity data

Integrity data

Database update

List of balises, track modelisation

Database validation

Travelled Distance, Speed, acceleration

Confidence Interval

APRP Message Telegram

ID Balise

List of balises, track modelisation

GNSS Raw data

Figure 20: Absolute Positioning subsystem

4.2.1.1 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:


Issue: 1.0 Date: 26/06/07




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.


Issue: 1.0 Date: 26/06/07




• 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)

4.2.1.2 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


Issue: 1.0 Date: 26/06/07




- 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.

4.2.2 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


Issue: 1.0 Date: 26/06/07




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.

Figure 21: Absolute positioning architecture

Balise ID Abs.Positioning 1D High integrity (in ETCS referential)

Speed 1D High integrity

GNSS Subsytem

Balises database

Track map

BTM Odometry

Database management

Other sensors

ETCS Subsytem

APRP ID


Issue: 1.0 Date: 26/06/07




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:

Figure 23: Architecture configuration

• As can be seen from the figure above, UT shall include the following functions:

GNSS absolute positioning System

GNSS absolute positioning System

Balise_ID High integrity Abs.Positioning (in ETCS referential)

High integrity speed

UT

Balises database

Track map

BTM Odometry

Database management

Other sensors

GNSS Receiver

GNSS Algorithm

ETCS ONBOARD

Integrity monitoring

APRP ID GNSS raw data


Issue: 1.0 Date: 26/06/07




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.

4.2.3 Requirements for the Onboard and trackside modules

Specific concept is the same provided in section 3.2.5. Definitions are given in section 1.6

4.2.3.1 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 applications, and considering also that right now no differences have been highlighted between EE and EO applications, we propose to refer to the WP 3.1.1 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.

4.2.3.2 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. 4.2.3.2.1 Functional requirements


Issue: 1.0 Date: 26/06/07




REQ-GNSSUT-EE-AP-010 Title Purpose

Description 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.

Notes The integrity level shall be compatible with SIL4 applications. REQ-GNSSUT-EE-AP-020 Title Functions

Description

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

Notes REQ-GNSSUT-EE-AP-030 Title Coordinate System Definition

Description

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) (*).

Notes (*) 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

Description

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. Notes The degraded operational mode shall be intended as a dead reckoning mode. REQ-GNSSUT-EE-AP-050


Issue: 1.0 Date: 26/06/07




Title Unlocked GNSS Signals

Description 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.

Notes REQ-GNSSUT-EE-AP-060 Title Data acquisition/Reacquisition

Description 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.

Notes REQ-GNSSUT-EE-AP-070 Title Data fusion

Description 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.

Notes The data fusion can be implemented or not, according to UT internal architecture definition.

REQ-GNSSUT-EE-AP-080 Title Error Log

Description 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.

Notes REQ-GNSSUT-EE-AP-090 Title Availability

Description 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.

Notes REQ-GNSSUT-EE-AP-100 Title Continuity

Description The Absolute Positioning Function implemented in the frame of the EE GNSS-UT continuity shall be better than TBD

Notes REQ-GNSSUT-EE-AP-110 Title Output solution rate

Description The Output of the Absolute Positioning Function implemented in the frame of the EE GNSS-UT shall be provided at a 10 Hz.

Notes


Issue: 1.0 Date: 26/06/07




«Train Position Computation» Sub-Function Specifications

REQ-GNSSUT-EE-AP-120 Title “Train Position Computation Function” Definition

Description

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.

Notes REQ-GNSSUT-EE-AP-130 Title “Train Position Computation Function” Methodology

Description

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.

Notes REQ-GNSSUT-EE-AP-140 Title “Train Position Computation Function” Integrity

Description 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.

Notes REQ-GNSSUT-EE-AP-150 Title “Train Position Computation Function” Confidence Interval

Description

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.

Notes REQ-GNSSUT-EE-AP-160 Title “Train Position Computation Function” in SIL4 application

Description 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.

Notes

“Data Translation” Sub-Function Specifications

REQ-GNSSUT-EE-AP-170 Title “Data translation in ETCS reference Function” Definition

Description 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.

Notes


Issue: 1.0 Date: 26/06/07




REQ-GNSSUT-EE-AP-180 Title “Data translation in ETCS reference Function” Trigger

Description

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). Notes The second approach is implemented in the UT and specified in the following. REQ-GNSSUT-EE-AP-190 Title “Pure APRP” Data Base

Description

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.

Notes REQ-GNSSUT-EE-AP-200 Title “Pure APRP” Trigger Methodology

Description

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.

Notes PCI is the Position Confidence Interval.

“Train speed Computation” Sub-Function Specifications

REQ-GNSSUT-EE-AP-210 Title “Train speed Computation Function” Definition

Description

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.

Notes


Issue: 1.0 Date: 26/06/07




REQ-GNSSUT-EE-AP-220 Title “Train speed Computation Function” Algorithm

Description

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.

Notes

“Time Computation” Sub-Function Specifications

REQ-GNSSUT-EE-AP-230 Title “Time Computation Function” Definition

Description 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.

Notes

“Integrity Monitoring” Sub-Function Specifications

REQ-GNSSUT-EE-AP-240 Title “Integrity Monitoring Function” Definition

Description

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. Notes REQ-GNSSUT-EE-AP-250 Title “Integrity Monitoring Function” and Data Base Monitoring

Description 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.

Notes

“Data base Management” Sub-Function Specifications

REQ-GNSSUT-EE-AP-260 Title “Data base Management Function” Purpose

Description 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.

Notes REQ-GNSSUT-EE-AP-270 Title “Data base Management Function” Communication

Description

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.

Notes


Issue: 1.0 Date: 26/06/07




REQ-GNSSUT-EE-AP-280 Title “Data base Management Function” start-up

Description

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.

Notes REQ-GNSSUT-EE-AP-290 Title “Data base Management Function” download

Description The GNSS UT shall manage the downloading of the data base. This interface definition depends on the system database architecture and management process.

Notes

“Provide APRP information to ETCS” Sub-Function Specifications

REQ-GNSSUT-EE-AP-300 Title “APRP information” upload

Description 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.

Notes

4.2.3.3 Digital Map Specifications

REQ-GNSSUT-EE-AP-310 Title Digital map Content

Description

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

Notes REQ-GNSSUT-EE-AP-320 Title Balise Data Set definition

Description

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

Notes


Issue: 1.0 Date: 26/06/07




REQ-GNSSUT-EE-AP-330 Title Absolute Positioning Reference Point Data Set definition

Description

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)

Notes

4.2.3.4 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.




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

Description

The GNSS nominal scenarios available in the frame of “GNSS UT AP application” performance specification are those defined in the following table:







The previous table is applicable for both rural and urban scenarios. Details on scenarios are provided in the following requirements.

Notes


Issue: 1.0 Date: 26/06/07




REQ-GNSSUT-EE-AP-350 Title GPS Single frequency without Integrity “rural nominal scenario”

Description

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):

BandL1

UERE Mixed



BPSK GPS NAV


5° 10° 15° 20° 90°

1-sigma error [cm]

RV Aereonautical

30° 40° 50° 60°



Notes

REQ-GNSSUT-EE-AP-360 Title GPS Dual frequencies without Integrity “rural nominal scenario”

Description

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):

BandL1

UERE Mixed


RV Aereonautical



15° 20°

BPSK GPS NAV

90°

1-sigma error [cm]

30° 40° 50° 60°5° 10°


TBD



Issue: 1.0 Date: 26/06/07




REQ-GNSSUT-EE-AP-370 Title GPS Single frequency with Integrity “rural nominal scenario”

Description

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


REQ-GNSSUT-EE-AP-380 Title GPS Dual frequencies with Integrity “rural nominal scenario”

Description

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



Issue: 1.0 Date: 26/06/07




REQ-GNSSUT-EE-AP-390 Title Galileo Single Frequency on L1 with integrity “rural nominal scenario”

Description

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:





Issue: 1.0 Date: 26/06/07




REQ-GNSSUT-EE-AP-400 Title Galileo Single Frequency on E5b with integrity “rural nominal scenario”

Description

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:





Issue: 1.0 Date: 26/06/07




REQ-GNSSUT-EE-AP-410 Title Galileo Dual Frequencies with integrity “rural nominal scenario”

Description

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:




REQ-GNSSUT-EE-AP-420 Title GPS Single frequency without Integrity “urban nominal scenario”

Description

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


Notes


Issue: 1.0 Date: 26/06/07




REQ-GNSSUT-EE-AP-430 Title GPS Dual frequencies without Integrity “urban nominal scenario”

Description

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


REQ-GNSSUT-EE-AP-440 Title GPS Single frequency with Integrity “urban nominal scenario”

Description

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


REQ-GNSSUT-EE-AP-450 Title GPS Dual frequencies with Integrity “urban nominal scenario”

Description

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



Issue: 1.0 Date: 26/06/07




REQ-GNSSUT-EE-AP-460 Title Galileo Single Frequency on L1 with integrity “urban nominal scenario”

Description

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


Notes

REQ-GNSSUT-EE-AP-470 Title Galileo Single Frequency on E5b with integrity “urban nominal scenario”

Description

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


TBD


Notes

REQ-GNSSUT-EE-AP-480 Title Galileo Dual Frequencies with integrity “urban nominal scenario”

Description

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




Issue: 1.0 Date: 26/06/07




4.2.3.5 Performance requirements

REQ-GNSSUT-EE-AP-490

Title Train position confidence interval accuracy - no local augmentation used

Environment Urban (U) / Rural (R)area

Description

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:


Single freq. No ±40 ±24 Dual freq No


Single freq on L1BC ±30 ±18 Single freq on E5b Dual freq on L1BC/E5b ±20 ±12

no no no Notes


Title Train position confidence interval accuracy - local augmentation used


Description

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:


Single freq. No ±10 ±6 Dual freq No


Single freq on L1BC ±8 ±5 Single freq on E5b Dual freq on L1BC/E5b ±8 ±5

No no no Notes


Issue: 1.0 Date: 26/06/07





Title Velocity confidence interval accuracy - no local augmentation used


Description

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 on L1BC ±0.4 ±0.24 Single freq on E5b Dual freq on L1BC/E5b ±0.33 ±0.2

no no no Notes


Title Velocity confidence interval accuracy - local augmentation used


Description

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 on L1BC ±0.4 ±0.24 Single freq on E5b Dual freq on L1BC/E5b ±0.33 ±0.2

no no no Notes


Title Availability

Description 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

Notes 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


Issue: 1.0 Date: 26/06/07





Title Position and velocity confidence interval integrity

Description The GNSS UT position and velocity confidence interval integrity shall be TBC

Notes


Title Absolute Position Function Continuity

Description The GNSS UT Absolute Position Function continuity shall be TBC

Notes


Title Data translation in ETCS reference

Description TBD

Notes


Title Compute time

Description TBD

Notes


Title Data base management

Description TBD

Notes


Title Provide APRP information to ETCS

Description TBD

Notes

4.2.3.6 Input / Output definition


Issue: 1.0 Date: 26/06/07




REQ-GNSSUT-EE-AP-400 Title Input Data

Description

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. Notes REQ-GNSSUT-EE-AP-410 Title Output Data

Description

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

Notes

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)

4.2.4 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


Issue: 1.0 Date: 26/06/07




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)

4.2.5 Use of Digital Route Maps and databases

One possible database architecture is as described in the figure below (TBC):

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).

Replicated database

RBC Subsystem

ETCS on-board

EURORADIOGNSS Sub-system

Track map

Balises database

Track map

Balises database

Master database

GSM-R

Proprietary


Issue: 1.0 Date: 26/06/07




- 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.

4.2.6 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.


Issue: 1.0 Date: 26/06/07




4.3 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 applications 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


Issue: 1.0 Date: 26/06/07




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) balise-groups 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 4.5.3 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.


Issue: 1.0 Date: 26/06/07




5 TRAIN INTEGRITY


5.1.1 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 applications 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 v2.2.2 §3.6.5.2 [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] §3.6.5.2.4 and figure 15)

Figure 24: Train integrity macrofunction

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

GNSS TI Subsystem

ETCS Onboard

ETCS Trackside

position report incl. Q_LENGTH, L_TRAININIT

outputs definedin section 3

inputs defined in section 3


Issue: 1.0 Date: 26/06/07




- 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


Issue: 1.0 Date: 26/06/07




Max train lengthMargin_1:+-10m for 750m long

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 5.2.

5.1.2 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


Issue: 1.0 Date: 26/06/07




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.


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.



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


Issue: 1.0 Date: 26/06/07





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)

after this, there are several possibilities:

option 1

6 train detection systems (track circuit or axle counters...)

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


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

As soon as the train integrity is confirmed, all sections are released and MA extended for train B (in FS mode)

9' - Continue in step 10


Issue: 1.0 Date: 26/06/07




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.



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


The route is not released

9 Train A

Train B

RBC

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)


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"


Issue: 1.0 Date: 26/06/07





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


Issue: 1.0 Date: 26/06/07




5.2 System requirement specification

5.2.1 GNSS TI System Functional Description

GNSSTrain Integrityassessment

SiS ETCSOn Board

Navigation data

Context Diagram

Alarms

Train Length

Train Integrity

Train Length confirmation

Trigger

Configuration parameters

JRU

Integrity Status

Additional info (*)

Train length confidence interval

(*) Additional info for: DMI, JRU, ... Change of

Status

GNSS Position

Measurement

Data Processing

2

SiS

ETCS

Navigation data

Rear Position Data

Level 1

Front Position Data

Train Length

Change of

Status

Configuration parameters

JRU

Trigger

Train Length confirmation

Integrity Status

Train length confidence interval

Additional info (*)

Figure 26: Train integrity subsystem


Issue: 1.0 Date: 26/06/07




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).


Issue: 1.0 Date: 26/06/07




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 5.3.2 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.

5.2.2 System Architecture

The context for the Train integrity assessment sub-system is illustrated by the figure below

Figure 27: Context diagram

Train integrity assessment sub-system shall be made of 2 devices:

ETCS

Front train integrity

assessment device

End of train device

Mechanical interface

Radio communication

Train staff or Driver

Juridical recorder


Issue: 1.0 Date: 26/06/07




• 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)

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.

=> (1), (2) and (3) could be subject to standardization

Figure 29: GNSS TI subsystem architecture definition 2

GNSS subsystem (train integrity) ETCS

SIS

TRAIN

GNSS subsystem front (train integrity)

ETCS

TRAIN

GNSS subsystem rear (train integrity)

SIS

Front part

Rear part

(1)

(2)

(1)

(2)

(3)


Issue: 1.0 Date: 26/06/07




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.

5.2.3 Requirements for the on-board and trackside modules

Specific concept and definitions are the same provided in section 3.2.5.

5.2.3.1 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


Issue: 1.0 Date: 26/06/07




(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-of-train 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


Issue: 1.0 Date: 26/06/07




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


Issue: 1.0 Date: 26/06/07




5.2.3.2 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)

5.2.3.3 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 applications (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.

5.2.3.3.1 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 3.2.5 of this document.

5.2.3.3.2 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 applications, and considering also that right now no differences have been highlighted between EE and EO applications, we propose to refer to the D 3.1.1 for Receiver high-level specification [21].


Issue: 1.0 Date: 26/06/07




5.2.3.3.3 Functional requirements

REQ-GNSSUT-EE-TI-010 Title Purpose

Description 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.

Notes 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

Description

The Integrity Function implemented in the frame of the EE GNSS-UT receiver shall use the following configuration data: Train Length Lmax

Notes

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

Description 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.

Notes REQ-GNSSUT-EE-TI-040 Title Input Data

Description

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. Notes REQ-GNSSUT-EE-TI-050 Title Output Data

Description

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

Notes


Issue: 1.0 Date: 26/06/07




REQ-GNSSUT-EE-TI-060 Title Train length confirmation

Description 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

Notes REQ-GNSSUT-EE-TI-070 Title Devices Definition

Description

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).

Notes REQ-GNSSUT-EE-TI-080 Title EoT Definition

Description The EoT unit shall be capable of determining the absolute rear position of the train and transmitting that information to the HoT unit.

Notes REQ-GNSSUT-EE-TI-090 Title HoT Definition

Description The HoT unit shall be designed to receive data messages from the EoT unit and shall be capable of displaying the alarms defined in 5.3.2.

Notes REQ-GNSSUT-EE-TI-100 Title Devices Communication

Description Train integrity sub-system devices “Head and end equipment” shall communicate over a dedicated radio.

Notes This requirement derives from the lack of wiring within most of the trains REQ-GNSSUT-EE-TI-110 Title Train integrity status Definition

Description

The Train integrity status information shall assume the following values: TI Status= ok TI Status= unknown TI Status= TI lost TI Status = failure state

Notes


Issue: 1.0 Date: 26/06/07




REQ-GNSSUT-EE-TI-120 Title Train integrity devices status Definition

Description

To provide the train staff with real time status of the train integrity assessment sub-system, 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

Notes

REQ-GNSSUT-EE-TI-130 Title TI results

Description The results of the GNSS TI (TI monitoring and train length confirmation) shall be presented to the EVC and subsequently to the DMI.

Notes

REQ-GNSSUT-EE-TI-140 Title Train integrity status Scenarios

Description 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 5.1.2

Notes REQ-GNSSUT-EE-TI-150 Title Train length confidence interval calculation

Description The train length confidence interval shall be recalculated for every TI status message that it is sent to the ETCS onboard.

Notes REQ-GNSSUT-EE-TI-160 Title Integrity Function Operative Mode

Description

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. Notes The degraded operational mode shall be intended as a dead reckoning mode. REQ-GNSSUT-EE-TI-170 Title Unlocked GNSS Signals

Description 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.

Notes This is the degraded operational mode


Issue: 1.0 Date: 26/06/07




REQ-GNSSUT-EE-TI-180 Title Data acquisition/Reacquisition

Description 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.

Notes REQ-GNSSUT-EE-TI-190 Title Data fusion

Description 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.

Notes REQ-GNSSUT-EE-TI-200 Title Error Log

Description 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.

Notes

REQ-GNSSUT-EE-TI-210 Title Isolation

Description 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)

Notes

5.2.3.3.4 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.




For each environment, performances are given in the following section.


Issue: 1.0 Date: 26/06/07




REQ-GNSSUT-EE-TI-220 Title GNSS nominal scenarios definition

Description

The GNSS nominal scenarios available in the frame of “GNSS UT TI application” performance specification are those defined in the following table:







The previous table is applicable for both rural and urban scenarios.

Details on scenarios are provided in the following requirements.

Notes

REQ-GNSSUT-EE-TI-230 Title GPS Single frequency without Integrity “rural nominal scenario”

Description

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):

BandL1

UERE Mixed



BPSK GPS NAV


5° 10° 15° 20° 90°

1-sigma error [cm]

RV Aereonautical

30° 40° 50° 60°



Notes


Issue: 1.0 Date: 26/06/07




REQ-GNSSUT-EE-TI-240 Title GPS Dual frequencies without Integrity “rural nominal scenario”

Description

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):

BandL1

UERE Mixed


RV Aereonautical



15° 20°

BPSK GPS NAV

90°

1-sigma error [cm]

30° 40° 50° 60°5° 10°


TBD


REQ-GNSSUT-EE-TI-250 Title GPS Single frequency with Integrity “rural nominal scenario”

Description

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


REQ-GNSSUT-EE-TI-260 Title GPS Dual frequencies with Integrity “rural nominal scenario”

Description

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



Issue: 1.0 Date: 26/06/07




REQ-GNSSUT-EE-TI-270 Title Galileo Single Frequency on L1 with integrity “rural nominal scenario”

Description

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:





Issue: 1.0 Date: 26/06/07




REQ-GNSSUT-EE-TI-280 Title Galileo Single Frequency on E5b with integrity “rural nominal scenario”

Description

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:





Issue: 1.0 Date: 26/06/07




REQ-GNSSUT-EE-TI-290 Title Galileo Dual Frequencies with integrity “rural nominal scenario”

Description

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:




REQ-GNSSUT-EE-TI-300 Title GPS Single frequency without Integrity “urban nominal scenario”

Description

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


Notes


Issue: 1.0 Date: 26/06/07




REQ-GNSSUT-EE-TI-310 Title GPS Dual frequencies without Integrity “urban nominal scenario”

Description

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


REQ-GNSSUT-EE-TI-320 Title GPS Single frequency with Integrity “urban nominal scenario”

Description

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


REQ-GNSSUT-EE-TI-330 Title GPS Dual frequencies with Integrity “urban nominal scenario”

Description

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



Issue: 1.0 Date: 26/06/07




REQ-GNSSUT-EE-TI-340 Title Galileo Single Frequency on L1 with integrity “urban nominal scenario”

Description

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


Notes

REQ-GNSSUT-EE-TI-350 Title Galileo Single Frequency on E5b with integrity “urban nominal scenario”

Description

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


TBD


Notes

REQ-GNSSUT-EE-TI-360 Title Galileo Dual Frequencies with integrity “urban nominal scenario”

Description

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



5.2.3.3.5 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.


Issue: 1.0 Date: 26/06/07




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

Description

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:


Single freq. No Dual freq No


Single freq on L1BC Single freq on E5b Dual freq on L1BC/E5b

No no no Notes REQ-GNSSUT-EE-TI-380 Title Availability

Description 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

Notes Availability defined does not include radio link/battery availability. (TBC)


Issue: 1.0 Date: 26/06/07




REQ-GNSSUT-EE-TI-390 Title Continuity

Description

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.

Notes

Notes 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 Notes 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. Notes 3. The continuity of the signal have been assured without additional facilities or funding.

REQ-GNSSUT-EE-TI-400 Title Reference Time

Description 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.

Notes

REQ-GNSSUT-EE-TI-410 Title Output solution rate

Description 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).

Notes 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

Description The information to train staff shall be refreshed periodically. Refresh time shall be of 1 second maximum

Notes

REQ-GNSSUT-EE-TI-430 Title train length confirmation rate

Description The GNSS subsystem shall provide the ETCS subsystem with a confirmation status within X seconds from the Train data entry (TBC).

Notes


Issue: 1.0 Date: 26/06/07




REQ-GNSSUT-EE-TI-440 Title Environmental requirements

Description The Performance of the Integrity Function implemented in the frame of the EE GNSS-UT shall be independent from environmental influences topography and buildings.

Notes

REQ-GNSSUT-EE-TI-450 Title Data storage

Description

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. Notes

5.2.3.4 RAMS requirements

REQ-GNSSUT-EE-TI-460 Title Reliability Requirements Description TBD Notes

REQ-GNSSUT-EE-TI-470 Title Safety Requirements

Description

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 )

Notes


Issue: 1.0 Date: 26/06/07




REQ-GNSSUT-EE-TI-480 Title Maintainability Requirements

Description

(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.

Notes

5.2.4 Specification for the local augmentation

TBD

5.2.5 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

5.3.1 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.

5.3.2 Identification of external interfaces

With reference to the context diagram described in section 5.2.2, the GNSS Train integrity sub-system has the following external interfaces:

Interface GNSS subsystem to train


Issue: 1.0 Date: 26/06/07




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


Issue: 1.0 Date: 26/06/07




• 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 applications 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


Issue: 1.0 Date: 26/06/07




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.


Issue: 1.0 Date: 26/06/07




no impact

Justification: Subset 026 Part 2 Section 2.6.5.1.4 describes the localization of the train integrity function for level 1.

Subset 026 Part 2 Section 2.6.6.1.4 describes the localization of the train integrity function for level 2.

Subset 026 Part 2 Section 2.6.7.2.4 describes the ETCS onboard functions for level 3.

Subset 026 Part 3 Section 3.6.5.2 describes completely the procedure of report of Train Rear End position for level 3.

Subset 026 Part 7 Section 7.4.3.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


Issue: 1.0 Date: 26/06/07


applications 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:


Issue: 1.0 Date: 26/06/07




This yields the histogram sideways.

Legend

hist2

phist2Predicted

Measured

Predicted histogram isbased on the measuredRMS error of 5.0 m overthe 20 days.

0.0 5.0 10.0 15.0Error Distance (1-meter bins)

0.000

0.050

0.100

0.150

0.200

Prop

ortio

n of

Mea

sure

men

ts

HISTOGRAM OF HORIZONTAL ERRORS Garmin 12XL (Micropulse antenna)

20 days data Fix every 2 seconds

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.

95%

63%

50%0.

83 1.00

(RM

S)

1.73

(CEP)

(Multiply by RMS to get Distance)

Probability = 1-exp(-(Distance/RMS)2)

0.00.10.20.30.40.50.60.70.80.91.0

Prob

abili

ty th

at p

oint

is le

ss th

an D

ista

nce

0.00 1.00 1.50 2.00 2.50 3.00Distance/RMS

0.50

DISTANCE/RMS VS. PROBABILITY

NOTE: Measuredposition error may be very large for a small percentage of the time.

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.


Issue: 1.0 Date: 26/06/07




E-N

M

ean/

58% E-N

R

MS

/68

% E-N

95

%

Hor

izon

tal

C

EP

/50

Hor

izon

tal

M

ean/

54H

oriz

ont

al

Hor

izon

tal

95

%

E-N Mean/58% 1.00 1.25 2.46 1.48 1.57 1.77 3.06

E-N RMS/68% 0.80 1.00 1.96 1.18 1.25 1.41 2.44

E-N 95% 0.41 0.51 1.00 0.60 0.64 0.72 1.24

HorizontalCEP/50% 0.68 0.85 1.67 1.00 1.06 1.20 2.08

Horizontal Mean/54% 0.64 0.80 1.56 0.94 1.00 1.13 2.01

Horizontal RMS/63% 0.57 0.71 1.39 0.83 0.89 1.00 1.73

Horizontal 95% 0.33 0.41 0.81 0.48 0.50 0.58 1.00

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.

Elevation angle (degrees) Error Source (UERE/14) 5 10 15 20 30 40 50 60 90 Residual

Ionosphere error 8 7 6 6 5 4 3 3 3

SISA 87 87 87 87 87 87 87 87 87 Residual

Troposphere error 135 75 51 39 27 21 18 16 14

thermal noise, interfer., multipath 52 50 41 37 37 37 37 37 37

Multipath bias error 31 31 31 31 31 31 31 31 31 Satellite BGD error 0 0 0 0 0 0 0 0 0

Code-Carrier Ionospheric

divergence error 0 0 0 0 0 0 0 0 0

total (1-sigma error [cm]) 172 129 114 107 103 102 101 101 100

total+10% margin (1-sigma error [cm]) 189 142 125 118 113 112 111 111 110

E5b-L1 Rural Vehicle (RV) HMI Probability Computation

To verify the GALILEO horizontal accuracy performance, we have been the following test:


Issue: 1.0 Date: 26/06/07




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.

mRMS NE 64.141.0*4 ==− 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:

22 _ NEderror +=


Issue: 1.0 Date: 26/06/07




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:

22

⎟⎟⎟

⎠

⎞

⎜⎜⎜

⎝

⎛+

⎟⎟⎟

⎠

⎞

⎜⎜⎜

⎝

⎛=

∑∑n

N

n

Ed nnn

error

The following table reports the results:

distance error (m) n samples Mean Std

1° bound (m)

% of samples in bound

2° bound (m)

% of samples in bound

100 0.20445 0.10686 0.5 99.132 0.6 99.908

300 0.11826 0.06172 0.3 99.33 0.35 99.904

600 0.08374 0.04385 0.2 98.864 0.25 99.902


Issue: 1.0 Date: 26/06/07




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:

timeaveragingtimeCCFSFtimenacquisitiotime ++= 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.


Issue: 1.0 Date: 26/06/07




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 = 0.685 m

North = 1.495

Up = 1.2116.

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.


Issue: 1.0 Date: 26/06/07




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


Issue: 1.0 Date: 26/06/07


applications Class: PUB Page B 1


APPENDIX B . IMPROVE ACCURACY WITH LOCAL ELEMENTS LOCAL ELEMENTS TECHNIQUES There are two different techniques to improve the accuracy of a GNSS receiver with using the local elements:

Differential GNSS

Relative Positioning

This section contains a brief description of the two techniques and highlights main advantages and disadvantages.

Differential GNSS In this technique, the Local Element is a reference station with known coordinates equipped with a GNSS receiver and able to estimate the errors on the pseudorange and pseudorange rate of each satellite in view.

Using the GSM-R infrastructures, it broadcasts the estimated corrections of the SIS signals at GNSS Rx. Using these information, the Rx is able to improve accuracy of Position and Velocity estimation.

With this technique, the errors due to Satellite clock, Satellite ephemeredes, Ionospheric and troposheric delay decrease if receiver and Reference Station are at a distance less than 100 km.

With this technique is possible to achieve a horizontal accuracy of ~ 1 m.

Relative Positioning In this approach the Local Element is a reference station at known coordinates. The LE broadcasts this time-tagged information to the Rx.

The GPS carrier phase estimated by the GNSS Rx receiver is compared with the carrier phase measured at reference station (relative positioning).


Issue: 1.0 Date: 26/06/07


applications Class: PUB Page B 2


The measurements of carrier are ambiguous so they require a complex ambiguity resolution algorithm.

In literature there are different algorithms to resolve the ambiguity resolution of carrier measurements, but typically they have high level of complexity..

With this technique is possible to achieve a horizontal accuracy of ~ 1 – 10 cm.

Conclusions The following table summarizes the main characteristics of the two techniques described above:

System Differential GNSS Relative Positioning

Type Code corrections Carrier measure

RTK Real Time Kinematic

Description Correction of the noise on SIS pseudorange

Relative positioning respect reference station

Horizontal Accuracy ~ 1 m ~ 1 - 10 cm

Operative distance < 100 Km < 100 Km

Implementation Easier algorithm implementation Fragile and complex ambiguity of carrier cycle resolution algorithm

END OF APPENDIX B


Issue: 1.0 Date: 26/06/07


applications Class: PUB Page C 1


APPENDIX C. PACKET TYPE

The following table reports a typical packets list available from the GPS receiver:

Packet ID

Packet direction Packet data fieldlength (bytes)

Packet description

0xA1 Receiver -> T.E. (TM) 47 Navigation Solution 1 Hz 0xA2 Receiver -> T.E. (TM) 47 Corrected Navigation Solution 1 Hz 0xA3 Receiver -> T.E. (TM) 372 Raw data with rate of 1 Hz 0xA4 Receiver -> T.E. (TM) 148 EGNOS Navigation Message with rate of 1

Hz 0xAC Receiver -> T.E.

(TC response) 4 Acknowledge response to all set TCs and

request TCs (only negative ack) 0xC0 T.E. -> Receiver (TC) 0 SW reset packet (No ACK follows this

packet) 0xC1 T.E. -> Receiver (TC) 0 Terminate Bootstrap 0xC2 T.E. -> Receiver (TC) 0 Start Acquisition 0xC4 T.E. -> Receiver (TC) 0 Store Fixed Data 0x21 T.E. -> Receiver (TC) 7-0

7 Set/Request Periodic Output options Periodic Output options

0x23 T.E. -> Receiver (TC) 25-1 25

Set/Request MCF setting MCF setting

0x30 T.E. -> Receiver (TC) 38-2 38

Set/Request Almanac Received Almanac

0x31 T.E. -> Receiver (TC) 38-2 38

Set/Request Almanac Health Received Almanac Health

0x32 T.E. -> Receiver (TC) 8-0 8

Set/Request Iono (GPS) Received Iono (GPS)

0x33 T.E. -> Receiver (TC) 15-1 15

Set/Request UTC Received UTC

0x36 T.E. -> Receiver (TC) 3-1 3

Set/Request Oscillator Offset Received Oscillator Offset

0x37 T.E. -> Receiver (TC) 18 Set Current PVT 0x40 T.E. -> Receiver (TC) 2

131 Request Navigation Message Navigation Message

0x90 T.E. -> Receiver (TC) 1032 Flash upload

END OF APPENDIX C


Issue: 1.0 Date: 26/06/07


applications Class: PUB Page D 1


APPENDIX D. CONTINUOUS INTEGRITY STATUS VERSUS BINARY INTEGRITY STATUS

The train length is comprised between a maximum length (Lmax) and minimum length (Lmin). This takes account of different parameters among which the possible elongation / contraction of the train.

The calculated train length confidence interval (TLCI) will be normally comprised between Lmax and Lmin. The two boundaries of TLCI will be denoted by TLCImax and TLCImin (TLCI = [TLCImin, TLCImax]).

If for any reason TLCImax is greater than Lmax, this means that the train length would be greater than the maximum physical length and would raise an integrity problem even if the TLCI has a common intersection with [Lmin, Lmax] interval.

Working in a “binary mode”, as soon as TLCImax is greater than Lmax then the integrity is not OK and the rear of the train remains at the last known correct position, as shown below:

Lmax LminTLCImax TLCImin


Lmax LminTLCImin

Ok

Not Ok

Not Ok

Figure D.1: « Binary » mode

Working in a “continuous mode”, it is possible to maintain the rear of the train at the position of TLCImax, which is moving, as long as there is an intersection between [TLCImin, TLCImax] and Lmin, Lmax], as shown below:




Figure D.2: continuous mode The example below shows the difference between the two working modes using a scenario where the train is entering an area experiencing a rapid degradation of the DOP due to the loss of visible satellites and compatible with a realistic evolution.

Assumptions:

Nominal train length (L): 1000 m;

Max train length (Lmax): 1020 m;

Min train length (Lmin): 980 m;

Train speed: 16.67 m/s (constant);

TLCI values are arbitrary calculated values.


Issue: 1.0 Date: 26/06/07




LminLmax

t= 0

LminLmaxt= 1

LminLmaxt= 2

LminLmaxt= 3

I=[992, 1024]

I=[996, 1028]

I=[992, 1032]

LminLmaxt= 4

I=[986, 1036]

LminLmaxt= 5

I=[984, 1040]

LminLmaxt= 6

I=[980, 1044]

LminLmax

I=[972, 1052]t= 7

LminLmax

I=[964, 1060]t= 8

LminLmax

I=[960, 1068]t= 9

LminLmax

I=[960, 1076]t= 10

I=[992, 1012]

LminLmax

I=[960, 1080]t= 11

Travelled distance

Drawing legend:

Drawing is not scaled;

Train is moving from left to right, the front end of the train being on the right (small black arrow right pointing);

Each line represents one second of elapsed time;

At t = 0, Lmax is at 0 m of travelled distance;

TLCI is represented in green when common to the [Lmin, Lmax] interval, and in red when greater than Lmax;

The red dotted vertical line is the rear of the train that remains at the last know correct position in “binary mode”;

[TLCImin, TLCImax] values are indicated on each line. . Hereunder is the computed example corresponding to the figure above for a period of eleven seconds:


Issue: 1.0 Date: 26/06/07




t TLCI Pos

Lmax PosLmin Pos TLCI Binary integrity Continuous

Integrity �

(s) TLCImax TLCImin � Max Min Status Pos rear Pos rear

(Units) (m) (m) (m) (m) (m) (m) (m) (m) (m) (m)

0 1012 992 20 0 40 8 28 OK 8 8 0

1 1024 992 32 16,67 56,67 12,67 44,67 NOK 12,67 12,67 0

2 1028 996 32 33,34 73,34 25,34 57,34 NOK 12,67 25,34 12,67

3 1032 992 40 50,01 90,01 38,01 78,01 NOK 12,67 38,01 25,34

4 1036 986 50 66,68 106,68 50,68 100,68 NOK 12,67 50,68 38,01

5 1040 984 56 83,35 123,35 63,35 119,35 NOK 12,67 63,35 50,68

6 1044 980 64 100,02 140,02 76,02 140,02 NOK 12,67 76,02 63,35

7 1052 972 80 116,69 156,69 84,69 164,69 NOK 12,67 84,69 72,02

8 1060 964 96 133,36 173,36 93,36 189,36 NOK 12,67 93,36 80,69

9 1068 960 108 150,03 190,03 102,03 210,03 NOK 12,67 102,03 89,36

10 1076 960 116 166,7 206,7 110,7 226,7 NOK 12,67 110,7 98,03

11 1080 960 120 183,37 223,37 123,37 243,37 NOK 12,67 123,37 110,7

Legend:

Column #1: Elapsed time Column #2: Value of TLCImax Column #3: Value of TLCImin Column #4: Length of TLCI Column #5: Position of Lmax from the origin of the X-axis Column #6: Position of Lmin from the origin of the X-axis Column #7: Position of TLCImax from the origin of the X-axis Column #8: Position of TLCImin from the origin of the X-axis Column #9: Integrity status in binary mode Column #10: Position of the rear of the train in “binary mode” Column #11: Position of the rear of the train in “continuous mode” Column #12: Difference between column #11 and #12

Conclusion:

It can be clearly seen, from the figure above and the numeric example, the operational benefit obtained in “continuous mode”, given the initial assumptions. After only eleven seconds the position of the rear of the train in “continuous” mode is ≈ 110 m ahead of the position of the rear of the train in “binary” mode (see last line of the computed example) in a rapid degrading visibility environment as encountered in the reality.

END OF APPENDIX D


Issue: 1.0 Date: 26/06/07


applications Class: PUB Page E 1


APPENDIX E. ALARM TIME THRESHOLDS ACCORDING TO KIND OF TRAIN (FREIGHT, PASSENGER) AND TRAFFIC DENSITY

Definition

Description

Headway Smallest technically possible interval between trains for the trouble-free execution of two train journeys.

Braking deceleration Least attainable service brake under all conditions

virtual block length By transmitting the positioning signal to the radio block centre it is always possible to determine which point on the route the train has safely cleared. The following train can already be granted another movement authority up to this point. The route is thus no longer cleared in fixed track sections.

General assumption

It is assumed train 1 reports its integrity at the time T1. The place of the end of train is the red signal for the subsequent train.

The time with which the subsequent train can approach undisturbed this red signal is looked for.

The place of this moment is at the beginning of the braking curve on this red signal (incl. train response time).

It is assumed, in case of train integrity loss a backward moving is excluded.

Consideration 1

It is assumed, that one kind of train is on the track.

For the calculation of the reaction time it is necessary to find headway out.

Analysis of Headway:

Description value

train speed [km/h] 300

Train speed [m/s] vTrain 83,33

braking deceleration [m/s2] aTrain 0,46

trainlength [m] lTrain 400

Table E.1 train parametres

calculation / assumption time [s] question/ comment

Set-up time route 6 assumption

Train passage time trainlength lTrain / vTrain 4,8


Issue: 1.0 Date: 26/06/07





virtual block length [s] 20 Assumption; this value is free alterable

braking curve length without response time L = vTrain

2/2 aTrain [m] 7548,31 m

“Train passage time for braking curve " in Headway

(flatland) t = L/v [s] 90,58

overlap 2,4 assumption

response time EVC 2 assumption

brake application time 15 assumption

Margin line gradient 5 assumption

Transmission time GSM-R 5 assumption

Margin STM 10 assumption

response time RBC 10 assumption

Signaled headway 165

margin 9 assumption; this value is free alterable

Operational headway 180

Table E.2 calculation headway Evaluation: With an operational headway of 180 s within 20 s (virtual block length) the train incompleteness has to disclosure. A headway of 180 s is common in train operations.

Consideration 2

It is assumed, that train1 is slow and train 2 is fast.

For the calculation of the reaction time it is necessary to find headway out.

Analysis of Headway:

Description value

train speed T1 [km/h] 100

Train speed T1 [m/s] vTrain1 27,78

braking deceleration [m/s2] aTrain 0,46

Trainlength T1 [m] lTrain1 5000

train speed T2 [km/h] 300

Train speed T2 [m/s] vTrain2 83,33

trainlength T2 [m] lTrain 400

Table E.3 train parameters


Issue: 1.0 Date: 26/06/07





Set-up time route 6 assumption

Train passage time trainlength T 1 lTrain1 / vTrain1 180

virtual block length [s] 20 Assumption; this value is free alterable

braking curve length without response time T2 L2 = vTrain2

2/2 aTrain2 [m] 7548,31 m

“Train passage time for braking curve " in Headway

(flatland) T2 t = L2/v [s] 90,58

overlap 2,4 assumption

response time EVC 2 assumption

brake application time 15 assumption

Margin line gradient 5 assumption

Transmission time GSM-R 5 assumption

Margin STM 10 assumption

response time RBC 10 assumption

Signaled headway 340

margin 14 assumption; this value is free alterable

Operational headway 360

Table E.4 calculation headway mixed traffic Evaluation: In mixed traffic we have a strong increase of operational headway.

Summary and Conclusions

If we consider that train 1 reports its integrity to a definite time, the end of train 1 is the red signal for the subsequent train. By transmitting this positioning to the radio block centre it is always possible to determine which point on the route the train has safely cleared. The following train can already be granted another movement authority up to this point. In this respect the headway is a operational parameter, whose observance an undisturbed service allows.

END OF APPENDIX E


Issue: 1.0 Date: 26/06/07


applications Class: PUB Page F 1


APPENDIX F. DISCLOSURE TIME

Lines Trains

High-speed lines

V> 200km/h

Main lines high traffic density

Main Lines low traffic density

Branch lines

Passenger trains

Trains with electrical connection

< 4s < 4s < 4s < 4s

Freight trains Trains with no electrical

connection < 4s < 30s < 30s < 30s

<100s*

* When acceptable on certain lines

Table F.1. Tolerable maximum disclosure time The disclosure time can be considered as a trackside requirement to be implemented when programming the cycle for position report parameters in L3.

The numbers in the table are orientative and shall be re-evaluated for each particular line.

END OF APPENDIX F


Issue: 1.0 Date: 26/06/07


applications Class: PUB Page G 1


APPENDIX G: Train length variation

This appendix gives estimation about the variation of the train length between minimum worst case and maximum worst case. This variation – defined as a percentage value – will be used for the threshold for the detection of a train separation.

Note: This appendix should deliver and document the used assumptions as well as the magnitude of estimations.

Introduction Train Integrity detected by the use of GNSS is done as follows: Two devices containing a GNSS-receiver are located at the both ends of the train. The distance of the unit located at the train front end (Head of Train device - HoT) and the one located at the rear train End (End of Train device - EoT) are capturing the absolute position. The direct distance between them is given as train length sTrain. This sTrain is measured at the time t0 as sTraint0, which is normally the end of the brake test. This value has to be used a reference. If the distance s grows over a threshold, which is to be defined by the percentage value ΔTrainLength, a train separation has been detected and the suitable procedure must be triggered. The following section is intended to give estimation for ΔTrainLength, which is reasonable.

Approach

For one wagon is estimated, how much the length differs caused by buffers and loose couplings. For the long train is additional calculated how much curves in the yard lead to underestimations.

Assumptions Assumption1: The minimum worst case sTrainLengthMin is assumed to be with completely compressed buffers and the wagons standing without any free distance, i.e. “buffer at buffer”.

Assumption 2: The maximum worst case sTrainLengthMax is assumed to be with completely expanded buffers and the wagons standing with a free distance between the buffers.

Assumption 3: The maximum delta worst case is assumed to be with completely expanded buffers and the wagons standing with a free distance scoupling between the buffers.

Assumption 4: The maximum train length is reached on a straight track.

Assumption 5: The minimum worst case is reached in curve with a radius of rcurve = 2000m.

Assumption 6: The shortest vehicle has length swaggon = 9.64m (length over buffers). Types Fc084, Fc088 or Fcs090.

Assumption 7: The longest relevant train has length sTrain = 700m (length incl. loco).

Estimations Estimation 1: The maximum compression of buffers is sBuffer = 0.15m. This value is taken from standard buffers, high performance buffers may have higher values, but they are normally not reached by shunting maneuvers, because they are designed for accidents.


Issue: 1.0 Date: 26/06/07




Estimation 2: The maximum a free distance of the coupling between the buffers scoupling = 0,2m. This is taken from standard screw couplings. Central buffer couplings have a smaller range.

Calculation for one vehicle The vehicle has length swaggon = 10m (length over buffers). The ΔWaggonLength = 2 * sBuffer + scoupling = 2 * 0.15m + 0.2m = 0.5m

This results in:

ΔWaggonLength = 5.19%

Calculation for maximum long train If a 700m long train in a yard with 2000m curve radius is measured the distance between the HoT and EoT is measured to sTrainLengthMin = 694m, which is ΔCurve = 0.86%

The maximum is:

ΔTrainLength = ΔWaggonLength + ΔCurve = 5.19% + 0.86% = 6.05&

For a 700m long train a distance of 6,05% is 42,35m which is at 80km/h a time of 1,9s.

A threshold of over 6,05% will not lead to false alarms due to the normal dynamic train length variation

Minimum operational Headway

headway > Braking time train 2 + Train passage train length + train passage DL length + delays

At this point Train 1 does not have any new information about its integrity so the safe train length is enlarged

DL

L1L2

headway

braking distance

L maxTLCI min

TLCImax


Issue: 1.0 Date: 26/06/07




Assumptions: according to the above DL should be greater than 6,05%L. For the first iteration DL=L has been chosen.

Delays are taken from Appendix B

note: DL includes Lmax and the GNSS error

Case 1:

train 1: 300 km/h, 400m, 0,46m/s2

train 2: 300 km/h, 400m, 0.46 m/s2

headway > 90,58 + 4,8 + 4,8 + 75 = 175,18

operational headway = 3' => acceptable (TBC)

Case 2:

train 1: 100km/h, 1500m, 0,46m/s2

train 2: 300 km/h, 400m, 0,46m/s2

headway> 90,58 + 54 + 54 + 75 = 273.58

operational headway= 5'

Delays from Appendix B should be validated.

If the headways obtained are not acceptable from the operational point of view, calculation should be done for another safe value Lmax.

END OF APPENDIX G

END OF THE DOCUMENT

Documents

GNSS Subsystem Requirement Specification for … Subsystem Requirement Specification for ... Cc Indra Espacio Carlos ... GRAIL-WP3-TIF-DEL-3.1.1-GNSS Subsystem Requirement Specification