gnss automated virtualized test environment for rail

ID: GATE4RAIL-RDL-4-001-000 D4.1 Geo-distributed Simulation and Verification Infrastructure Modules and Interfaces, functional and Operational Requirements

GNSS Automated Virtualized Test Environment for RAIL (GATE4Rail)

Deliverable 4.1 - Geo-distributed Simulation and Verification Infrastructure Modules and Interfaces, Functional and Operational

Requirements

Document manager: Cosimo STALLO RDL

Programme: S2R-OC-IP2-02-2018- Research and Innovation Action

Project Name: GNSS Automated Virtualized Test Environment for RAIL

Project Acronym: GATE4RAIL

Contract Number: 826324

Project Coordinator: RADIOLABS

WP leader: RDL

Document Id. N°: GATE4RAIL-RDL-4-001-000 Revision 01

Deliverable: D4.1 Date: 24/12/2019

Document classification Public

Approval Status

Prepared by: Cosimo Stallo, Ricardo Campo Cascallana, Susana Herranz de Andrés, Daniel Molina, Pietro Salvatori

Approved by (WP Leader): Pietro Salvatori (RDL)

Approved by (Technical and Project Manager)

Cosimo Stallo (RDL)

Approved by (Coordinator): Alessandro NERI (RDL)

Ref. Ares(2020)2047575 - 14/04/2020

http://www.inaf.it/it/sedi/sede-centrale-nuova/direzione-scientifica/relazioni-internazionali/nuovo-logo-horizon-2020/view

ID: GATE4RAIL-RDL-4-001-000 D4.1 Geo-distributed Simulation and Verification Infrastructure Modules and

Interfaces, functional and Operational Requirements

Date: 24/12/2019 Page: 2/43

CONTRIBUTING PARTNERS

Name Company/Organization Role/Title

Cosimo Stallo RDL Author

Ricardo Campo Cascallana CEDEX Author

Susana Herranz de Andrés CEDEX Author

Daniel Molina Marinas CEDEX Author

José Bueno Perez CEDEX Author

María Pedauyé Rueda INECO Reviewer

Beatriz Sierra Barba INECO Reviewer

Giuseppe Rotondo GUIDE Reviewer

Olivier Desenfans M3SB Reviewer

DISTRIBUTION LIST

Name Company/Organization Role/Title

Alessandro NERI RDL Project Coordinator

Lea PATIES Shif2Rail JU Programme Officer

Gorazd MARINIC Shif2Rail JU GATE4Rail Project Officer

This project has received funding from the Shift2Rail Joint Undertaking (JU) under grant agreement No

826324. The JU receives support from the European Union’s Horizon 2020 research and innovation

programme and the Shift2Rail JU members other than the Union. Any dissemination of results reflects only

the author’s view and JU is not responsible for any use that may be made of the information it contains.

REVISION TABLE

Version Date Modified pages Modified Sections Comments

0.0 24/12/2019 ALL ALL First Release

0.1 23/03/2020 See modifications at Paragraph 1.6 Revision after S2R comments

implementation



Date: 24/12/2019 Page: 3/43

Content

Executive Summary .......................................................................................................................................................... 5

1 Scope......................................................................................................................................................................... 6

1.1 Purpose and Applicability ................................................................................................................................. 6

1.2 Reference Documents ...................................................................................................................................... 6

1.3 Related Documents .......................................................................................................................................... 6

1.4 Terms, Acronyms and Abbreviation ................................................................................................................. 7

1.5 Disclaimer excluding JU responsibility .............................................................................................................. 8

1.6 Description of Changes from the Previous Revision ......................................................................................... 9

2 Reference Architecture for using GNSS in ERTMS/ETCS ........................................................................................ 10

2.1 Introduction and Background ......................................................................................................................... 10

2.2 State of Art of GNSS-based ERTMS/ETCS Architectures ................................................................................. 10

2.2.1 Virtual Balise Reader with GNSS Receiver Type I ................................................................................... 11

2.2.2 Virtual Balise Reader with GNSS Receiver Type 2 .................................................................................. 12

2.2.3 Use of SBAS in ERTMS/ETCS ................................................................................................................... 13

2.3 State of the art summary ................................................................................................................................ 14

3 GATE4Rail Simulation and Verification Infrastructure High Level Architecture ..................................................... 15

3.1 Option 1 .......................................................................................................................................................... 15

3.2 Option 2 .......................................................................................................................................................... 16

3.3 Option 3 .......................................................................................................................................................... 17

4 GATE4Rail platform evolution services-oriented ................................................................................................... 18

5 Simulation and Verification Infrastructure goals .................................................................................................... 19

5.1 Target user needs ........................................................................................................................................... 19

5.1.1 System design: operational needs .......................................................................................................... 20

6 System Requirements ............................................................................................................................................. 21

6.1 Functional GATE4Rail simulation and verification infrastructure Requirements ........................................... 24

6.2 Operational GATE4Rail simulation and verification infrastructure Requirements ........................................ 26

7 GATE4Rail simulation and verification infrastructure demonstrator module decomposition .............................. 26

7.1 Module #1: Emulated Moving Train ............................................................................................................... 29

7.2 Module #2: Mission Control System & Train Dynamics ................................................................................. 29

7.3 Module #3: GNSS Signals Generation ............................................................................................................. 29

7.4 Module #4: GNSS Augmentation and On Board Unit Module ....................................................................... 30

7.5 Module #5: Virtual Balise Trigger module ...................................................................................................... 30

8 Functional Decomposition ...................................................................................................................................... 32



Date: 24/12/2019 Page: 4/43

8.1 Module #1 ....................................................................................................................................................... 32

8.2 Module #2 ....................................................................................................................................................... 35

8.3 Module #3 ....................................................................................................................................................... 36

8.4 Module #4 ....................................................................................................................................................... 38

8.5 Module #5 ....................................................................................................................................................... 41

Conclusions ..................................................................................................................................................................... 42

LIST OF FIGURES

Figure 2-1: Possible Architectures based on Option 1 for using GNSS/SBAS in ERTMS/ETCS [ReD-3] .......................... 12

Figure 2-2: Possible Architectures based on Option 2 for using GNSS/SBAS in ERTMS/ETCS [ReD-3] .......................... 13

Figure 3-1: Option 1 is based on using ERTMS functionality to send Augmentation information to the VBR............... 16

Figure 3-2: Option 2 is based on 3G/4G/5G communications with no modifications in the standardized ERTMS/ETCS

on-board and trackside functionalities ........................................................................................................................... 17

Figure 3-3: Option 3 based on GSM-R/GPRS with no modifications in the standardized ERTMS/ETCS on-board and

trackside functionality .................................................................................................................................................... 17

Figure 4-1: GATE4Rail Functional architecture ............................................................................................................... 19

Figure 7-1: GATE4Rail general architecture .................................................................................................................... 27

Figure 7-2: Overall GATE4Rail Logic Scheme .................................................................................................................. 28

Figure 7-3: Overall GATE4Rail Logic Scheme by ERTMS/ETCS and GNSS laboratories of the Consortium partners [RD-3]

........................................................................................................................................................................................ 31

LIST OF TABLES

Table 1: Reference Documents ......................................................................................................................................... 6

Table 2: Related Documents ............................................................................................................................................. 6

Table 3: Terms, Acronyms and Abbreviation.................................................................................................................... 7

Table 4: GATE4Rail user requirements ........................................................................................................................... 22

Table 5: GATE4Rail system requirements ....................................................................................................................... 22

Table 6: GATE4Rail functional requirements at system level ......................................................................................... 24

Table 7: GATE4Rail operational requirements at system level ...................................................................................... 26

Table 8: Module #1 Function decomposition ................................................................................................................. 32

Table 9: Module #2 Function decomposition ................................................................................................................. 35

Table 10: Module #3 Function decomposition ............................................................................................................... 36





Date: 24/12/2019 Page: 5/43

Executive Summary GATE4Rail intends to provide a geo-distributed test architecture capable of simulating railway scenarios for ERTMS

applications based in GNSS by integrating different simulation blocks and by defining their interfaces in order to cover

the global simulation chain. The main objective is to integrate GNSS-related issues into ERTMS test labs.

The present deliverable is the first one of WP4– ‘Geo-distributed Verification Infrastructure Set-up’, and its objective

is to identify the high level functional and operational requirements of the geographically distributed simulation and

verification infrastructure, in terms of main blocks and interfaces among the different geo-distributed modules of the

infrastructure connecting GNSS labs (GUIDE, M3SB and RDL) and ETCS/ERTMS labs (CEDEX).

The document shows the GATE4Rail simulation and verification infrastructure high level architecture taking advantage

from the well-consolidated experience derived from past and ongoing projects on GNSS application in the rail domain

(as H2020 GSA ERSAT-EAV, ERSAT GGC, STARS and RHINOS).

Different options of GATE4Rail simulation and verification infrastructure are shown, considering the minimization of

impact of GNSS introduction into ERTMS trackside and On Board functionalities.

The main result of the deliverable, the user, functional, performance and operational requirements of the test-bed

together with the module decomposition and their functional analysis will be input for the detailed design and

development of test-bed as foreseen in D4.2.

The requirements derived in this document will drive the GATE4Rail test-bed design allowing to:

test and verify the performance of a fail-safe, multi-sensor train positioning system by applying GNSS

technology to the current ERTMS/ETCS core, maintaning he backward compatibility with existing ERTMS

systems and the key ERTMS interoperability requirements (related to TD2.4 - X2Rail-2, WP3 – Fail Safe Train

Positioning);

to reuse the methodology described in D5.1 and D5.2 to update the test environment and test repetition

with the final goal of Zero on Site Testing (related to TD2.6- X2Rail-3, WP5 – Zero On site Testing).



Date: 24/12/2019 Page: 6/43

1 Scope

1.1 Purpose and Applicability This deliverable deals with the GATE4Rail verification and simulation infrastructure platform user, functional and

operational requirements and its high level architecture with main modules. For each of the constituent modules the

main functions are identified and the interfaces between each laboratory main module are defined.

The document shows the GATE4Rail simulation and verification infrastructure high level architecture taking into

account the impact of the introduction of GNSS into ERTMS and the work already carried out in other GSA H2020

(ERSAT GGC, ERSAT EAV, STARS, RHINOS) and S2R projects (VITE), as reported in Section 2.

Different options of GATE4Rail simulation and verification infrastructure are shown in Section 3, considering the

minimization of impact of GNSS introduction into ERTMS trackside and On Board functionalities.

The document also shows the future evolution of GATE4Rail platform oriented to services in Section 4, while the main

goals of this test-bed are described in Section 5. User, general, functional and operational test-bed requirements are

defined in Section 6. Section 7 reports the module decomposition of the GATE4Rail demonstrator while its functional

analysis is illustrated in Section 0.

This document is applicable for design of GATE4Rail simulation and verification infrastructure design and proof-of-

concept deployment and testing.

1.2 Reference Documents

Table 1: Reference Documents

Document Number Document Description

RD-1 GATE4Rail Grant Agreement Number 826324 — IP/ITD/CCA1 — IP2

RD-2 GATE4Rail Consortium Agreement v1.1

RD-3 GATE4Rail Technical Proposal (Part 1-3)

1.3 Related Documents In Table 2 are listed the documents related to GATE4Rail project that have been used to develop this document.

Table 2: Related Documents

Document Number Document Description

ReD-1 GATE4Rail – Deliverable D2.1- Railway Scenarios and Requirements

ReD-2 GATE4Rail - Deliverable D2.2- Railway and GNSS Test Cases

ReD-3 STARS – Deliverable D5.3 -EGNSS Target Performances to meet railway safety requirements

ReD-4 NGTC D7.7 Results of the Safety Analysis ETCS Application Level 2 – Virtual Balise Detection

using GNSS v.01 12/10/2016.

ReD-5 NGTC D7.7 Results of the Safety Analysis Appendix C - ETCS Application Level 2 – Virtual

Balise Detection using GNSS – Principles, Procedures and Positioning System Performance



Date: 24/12/2019 Page: 7/43

Requirements v.08 12/10/2016.

ReD-6

NGTC D7.7 Results of the Safety Analysis Appendix F - ETCS Application Level 2 – Virtual

Balise Detection using GNSS – Safety Analysis Part 2, Preliminary Assessment of the Virtual

Balise Subsystem for THR Apportionment, v.06 12/10/2016.

ReD-7 UNISIG, SUBSET-026 v3.6.0, “ERTMS/ETCS System Requirements Specification”

ReD-8 GATE4Rail - Deliverable D4.2- Geo-distributed Simulation and Verification Infrastructure

Design

ReD-9

Cosimo Stallo, Senior Member IEEE, Alessandro Neri, Pietro Salvatori, Roberto Capua,

Francesco Rispoli “GNSS Integrity Monitoring for Rail Applications: 2-Tiers method”, IEEE

Transactions on Aerospace and Electronic Systems, Volume 55, Pag. 1850-1863, August

2019.

1.4 Terms, Acronyms and Abbreviation In Table 3 are listed all Terms, Acronyms and Abbreviation used inside this document.

Table 3: Terms, Acronyms and Abbreviation

Terms, Acronyms

and Abbreviation Description

AIMN Augmentation and Integrity Monitoring Network

API Application Programming Interface

ATPL Along Track Protection Level

C/N0 Carrier to Noise Ratio

CAPEX CAPital EXpenditure

COTS Commercial Over The Shelf

CTPL Cross Track Protection Level

DGNSS Differential GNSS

DGPS Differential GPS

ECEF Earth Centric Earth Fixed

EDAS EGNOS Data Access Service

EGNOS European Geostationary Navigation Overlay System

ERTMS European Railway Traffic Management System

ETCS European Train Control System

EVC European Vital Computer

GIS Geographic Information System

GNSS Global Navigation Satellite System

GPS Global Positioning System



Date: 24/12/2019 Page: 8/43

IMU Inertial Measurement Unit

I/Q In Phase / Quadrature

KPI Key Performance Indicator

LDS Location Determination System

LRBG Last Relevant Balise Group

MA Movement Authority

MLS Microwave Landing System

MOPS Minimal Operational Performances Specification Document reference DO229

OBU On Board Unit

OPEX Operating Expense

PoC Proof of Concept

PL Protection Level

PVT Position Velocity Time

PVT_C PVT Constrained

PVT_U PVT Unconstrained

RAIM Receiver Autonomous Integrity Monitoring

RAMS Reliability, Availability, Maintainability, Safety

RBC Radio Block Center

RF Radio Frequency

RS Reference Station

RTK Real Time Kinematic

S2R Shift to Rail

SIL Safety Integrity Level

SIS Signal In Space

SWOT Strenghts, Weaknesses, Opportunities e Threat

TD Technical Demonstrator

VB Virtual Balise

VBG Virtual Balise Group

VBR Virtual Balise Reader

1.5 Disclaimer excluding JU responsibility Any dissemination of results must indicate that it reflects only the author’s view and that the JU is not responsible for

any use that may be made of the information it contains (see RD-1, § 29.5).



Date: 24/12/2019 Page: 9/43

1.6 Description of Changes from the Previous Revision # modification note

1 Minor formal, editorial and orthographic corrections:

Delivery Date

Title Name

ID of the document, updated to version 1

2 Section 1.5 added disclaimer section

3 Section 2.1 updated to provide a short background of the work and the deliverable within the project

4 Section 2.2 and subsections renumbered for better formatting

5 Removal of section 2.1.1.4

6 Section 2.3 added for linking the existing background with the project new proposals

7 Section 3. Added a new paragraph to better explain the GATE4Rail contributions with regards to the previous background.

8 Figure 7-1 updated to include the information links between the different modules

9 Figure 7-3 to include the information links between the laboratories



Date: 24/12/2019 Page: 10/43

2 Reference Architecture for using GNSS in ERTMS/ETCS

2.1 Introduction and Background Satellite positioning is amongst the game-changing functions detailed in a long-term perspective for the evolution of

ERTMS to reduce the cost in terms of CAPEX and OPEX, as well as increasing performances and availability, without

incurring major impact on the current ETCS implementation.

In past research projects, several applications for GNSS-based ERTMS have been defined, for example for improving

the positioning accuracy of the ERTMS odometry or for replacing Eurobalises with Virtual Balises.

Thus, Satellite Positioning has been identified as a main contributor to:

1. potential reduction cost in deployment and maintenance of balises, through a VB concept using GNSS for VBGs detection;

2. improved performance due to more accurate odometry, where GNSS is used as an additional sensor to improve ETCS odometry performance; or an ETCS odometry function based on GNSS and other sensors (such as IMUs).

In this framework, GATE4Rail project contributes to the GNSS deployment in railways by the identification of the railway scenarios and test cases performed in WP2 [ReD-1, ReD2], considering both rail operations and GNSS signal reception, that could be performed in the geo-distributed architecture to be defined and designed during the project, capable of testing ERTMS trackside and on-board signalling systems using GNSS for train positioning and towards reducing the on-site testing. In this context, the present deliverable corresponds to the first task of WP4– ‘Geo-distributed Verification Infrastructure Set-up’, which is devoted to identify the detailed functional and operational requirements of the geo-distributed simulation and verification infrastructure modules and to identify the main interfaces among them for connecting GNSS and rail laboratories, together with the data to be exchanged. The test-bed design will be mainly based on the reuse of existing tools and modules already available in each laboratory, but it will require the interfaces definition among the different laboratories and adaptation of some modules or their development (Module 5) for building a geo-distributed simulation and verification infrastructure. The content of this document will be input for the detailed design and development of test-bed as foreseen in D4.2.

The requirements derived in this document will drive the GATE4Rail test-bed design allowing to:

test and verify the performance of a fail-safe, multi-sensor train positioning system by applying GNSS

technology to the current ERTMS/ETCS core, maintaning he backward compatibility with existing ERTMS

systems and the key ERTMS interoperability requirements (related to TD2.4 - X2Rail-2, WP3 – Fail Safe Train

Positioning);

to reuse the methodology described in D5.1 and D5.2 to update the test environment and test repetition

with the final goal of Zero on Site Testing (related to TD2.6- X2Rail-3, WP5 – Zero On site Testing).

2.2 State of Art of GNSS-based ERTMS/ETCS Architectures This paragraph presents the main ERTMS/ETCS GNSS-based architectures that have been selected in other previous

R&D projects [ReD-3], and they can be a starting point for supporting the activities of definition of a simulation and

verification infrastructure architecture for evaluating the performance of GNSS in different rail operational scenarios

and under various GNSS environments.

Based on an approach which aims at minimizing the impact on the two existing main systems ERTMS /ETCS and GNSS

augmented with SBAS/LDGNSS, the possible architectures to use GNSS technology in ERTMS/ETCS system have been



Date: 24/12/2019 Page: 11/43

limited to ones that take into account the particular functionalities and peculiarities in railway environments of both

systems, for example:

the train determines its exact 1D position with respect to a location reference called LRBG;

the train reports its position to the trackside system in reference to the LRBG;

the trackside system transmits to the train the MA based on the LRBG;

the trackside system transmits to the train the info describing the track conditions always taking the LRBG as

location reference;

a GNSS receiver processes GNSS SIS in order to estimate PVT and provide pseudorange and carrier phase

measurements (together with other performance metrics, as estimated standard deviations, carrier to noise

ratio, pseudorange residuals);

EGNOS/LDGNSS transmits augmentation and integrity data which are valid for a GNSS receiver that implements

a well-defined position and integrity equations;

EGNOS signal reception in challenging environments (urban, suburban etc.) is degraded in terms of availability.

These aspects reflect in the two possible GNSS-based (including SBAS) ERTMS/ETCS architectures, as deeply reported

in [ReD-3], considering that both the ETCS on-board and trackside constituents are based on the reference

architecture defined in SUBSET-026-2 [ReD-7].

2.2.1 Virtual Balise Reader with GNSS Receiver Type I The VBR architecture “Option 1”, identified in [ReD-3], has four functional blocks:

GNSS receiver type I

GNSS Algorithm tailored for railway (named “R-GNSS Algorithm”)

Virtual Balise Detector

Track Database Manager

The “R-GNSS Algorithm” is the functional block specifically designed to take advantage of the track database. The

“GNSS receiver type I” provides in output pseudoranges (and other raw data) which are used by “R-GNSS Algorithm”

tailored for railway that could perform a direct map-matching, based on pseudorange, in the Position domain. Direct

computation of ATPL and CTPL is performed from the “R-GNSS Algorithm” using PVT algorithm constrained to 1D

railway line based on the received augmentation information. The augmentation information can be received by the

VBR from three possible channels:

EGNOS SIS from on-board antenna / receiver;

EGNOS augmentation from EDAS through the “Augmentation dissemination” (EGNOS augmentation information is received though the space segment on EGNOS standard ground segment network. Then, it is forwarded to the “Augmentation Dissemination” functional block responsible for forwarding the information to the on-board through the RBC);

EGNOS augmentation from SBAS enabled GNSS receiver through the “Augmentation dissemination” and installed at the RBC constituent (EGNOS augmentation is received from the space segment through the “Augmentation Dissemination”, which is equipped with a standard receiver. Then, this information is forwarded to the on-board through the RBC).

Finally, cross checking between ERTMS/ETCS info such as odometry on one hand, and GNSS / SBAS info at

pseudorange level on the other, is possible. The advantages of such cross checking for mitigating local feared events

through RAIM algorithms have to be investigated.



Date: 24/12/2019 Page: 12/43

Figure 2-1: Possible Architectures based on Option 1 for using GNSS/SBAS in ERTMS/ETCS [ReD-3]

2.2.2 Virtual Balise Reader with GNSS Receiver Type 2 The VBR architecture “Option 2”, identified in [ReD-3] consists in four functional blocks:

GNSS receiver type II

Position mapping and monitoring checks

Virtual Balise Detector

Track Database Manager The augmentation information can be obtained by the VBR from three possible channels:

EGNOS SIS from on-board antenna / receiver (as it is);

EGNOS augmentation from EDAS through the “Augmentation dissemination”;

EGNOS augmentation from SBAS enabled GNSS receiver through the “Augmentation dissemination” installed at the RBC constituent.

Note that with regard to the on-board constituent, the VBR architecture options described have been based on the

ERTMS/ETCS reference architecture defined in the context of the NGTC project [ReD-34].

The “GNSS receiver type II” processes GNSS SIS and outputs unconstrained 3D PVT and the related PL to the functional

block “Position mapping and monitoring checks”. It should also be compliant to the MOPS for the railway environment

(still to be defined).

The “GNSS receiver type II” does not receive any signalling information (e.g. odometry, track database). However, it

does receive GNSS information and augmentation (e.g. augmentation provided via RBC or from on-board GNSS

antenna / receiver).

The GNSS receiver might incorporate internal hybridization techniques in order to achieve the expected

performances. The “Position mapping and monitoring checks” functional block takes care of mapping the

unconstrained 3D PVT to a 1D constrained PVT by using track database information in order to feed it to the VBD. The



Date: 24/12/2019 Page: 13/43

algorithm that describes the methodology to map the 3D PVT into 1D PVT and the relative PL into ATPL and CTPL

should also be defined in the MOPS for the railway environment.

Moreover, this functional block implements fault detection and exclusion RAIM algorithms to identify when local

effects may lead to unbounded position errors. The “VBD” and “Track Database Manager” are two functional blocks

that are identical for the aforementioned reference architectures.

Figure 2-2: Possible Architectures based on Option 2 for using GNSS/SBAS in ERTMS/ETCS [ReD-3]

2.2.3 Use of SBAS in ERTMS/ETCS In the context of ERTMS/ETCS railway applications, although the augmentation of GNSS by SBAS is considered in order to increase integrity of the position information coming from GNSS on its own, the achieved integrity level regarding position information delivered by GNSS complemented with SBAS is still not enough for SIL 4 level required by ERTMS/ETCS context ([ReD-5], [ReD-6]). Then, a track-side position report verification block is included in the ETCS trackside (RBC constituent) in order to verify train position validity with other means thus increasing train position integrity together with availability to satisfy the requirements. Moreover, given unavailability of EGNOS GEO satellites signal in challenging conditions such as urban environments or some regional areas, an additional functional block named “Augmentation dissemination” shall be present at the RBC. In fact, some first measurements relative to availability of EGNOS SIS reception on-board the train lead to an approach that distributes this information to each train individually over the ETCS radio airgap through the RBC. The augmentation information required by the “Augmentation dissemination” functional block can be obtained either by SBAS enabled GNSS receivers installed at the RBC, or by the SBAS ground centre facility via an EDAS interface compliant with CENELEC standard EN 50159. The augmentation information is transferred to each train by means of EuroRadio communication protocol. In particular, it is important to remark that regarding EGNOS augmentation information, which can be received by the VBR using the three afore-mentioned means, there are some significant issues:

a) EGNOS SIS from on-board antenna / receiver is subject to continuous interruption of signal reception depending on the local environment conditions, as well as safety and security issues during the SIS



Date: 24/12/2019 Page: 14/43

transmission; b) The EDAS interface with RBC (in the case of EGNOS augmentation from EDAS with the RBC constituent) has

to be adapted to meet safety and security needs for the railway domain; c) EGNOS augmentation from SBAS enabled GNSS receiver through the “Augmentation dissemination”, installed

at the RBC constituent, is subject to safety and security issues during the SIS transmission.

2.3 State of the art summary In the previous section, the main results from project [ReD-3] have been presented. At that moment, the system

architecture related to the communication channel for the augmentation information to be sent to the train was

through the RBC with new ETCS messages. In GATE4Rail it is intended to have a more generic approach where all the

possible solutions could fit in, as it will be shown in next section.



Date: 24/12/2019 Page: 15/43

3 GATE4Rail Simulation and Verification Infrastructure High Level Architecture This section is devoted to describe the system boundaries of the GATE4Rail virtualized and geo-distributed

infrastructure mainly born to simulate the performance of GNSS in the rail context, aiming at minimizing the impact

of the GNSS on the ETCS/ERTMS on-board and trackside subsystems as defined in the SUBSET-026-2 [ReD-7].

As it was described in the previous section, the main interface that remains undefined at standardization level is the

internal interface between the VBR and the ETCS OBU. By the other side, the augmentation information, depending

on its nature, offer different possibilities for transmission, some of them specified in standards, but some not, as it

will be described later.

However, both interfaces are intimately related since the augmentation information is essential for the Virtual Balise

Reader. Therefore they must be considered in parallel taking also into account its possible impact in the standardized

ERTMS/ETCS architecture defined in the SUBSET-026-2 §2.5.3.

It implies some options to be investigated and analysed in the GATE4Rail infrastructure design, with a different impact

on the current ETCS/ERTMS on-board and trackside.

In particular, three possible alternative solutions have been identified to transmit augmentation information to VBR:

Option 1 is based on using ERTMS functionalities to send augmentation information to the VBR;

Option 2 is based on 3G/4G/5G communications with no modification in the standardized ERTMS/ETCS on-

board and trackside functionalities.

Option 3 based on GSM-R/GPRS with no modification in the standardized ERTMS/ETCS on-board and trackside

functionalities.

These three options will be investigated and deeply analysed in [ReD-8] for the final design and implementation of

the GATE4Rail demonstrator.

3.1 Option 1 The first option is a solution based on the use of the existing ERTMS/ETCS radio communication system (GSM-R) and

included in the ERTMS/ETCS language based on variables, packets and Euroradio messages.

As shown in Figure 3-1, no modifications are required in the radio communication link compared to the current

ERTMS/ETCS implementation.

In the trackside part, the constituent “Augmentation data from EGNOS/Local AIMN” has to provide augmentation

information to the RBC to parse it into ERTMS/ETCS variables, packets and Euroradio messages.

In the ERTMS/ETCS on-board equipment, the Augmentation information received through the Euroradio messages

has to be transmitted to the VBR. This option has a big impact on ERTMS/ETCS trackside and On Board functionalities.



Date: 24/12/2019 Page: 16/43

Figure 3-1: Option 1 is based on using ERTMS functionality to send Augmentation information to the VBR

3.2 Option 2 The second option is a solution based on the use of a new communication channel (3G/4G/5G) w.r.t. the standardized

ERTMS/ETCS on-board and trackside functionalities.

The Augmentation information is received directly by the VBR. The VBR has to integrate a (3G/4G/5G) dedicated

modem to provide the needed information for the PVT estimates.

In the ERTMS/ETCS on-board equipment and trackside functionalities no modifications are required considering this

option for the test-bed architecture.

ERTMS/ETCS OB

ERTMS/ETCS Trackside

TrainGNSS VBR ERTMS/ETCS OB

GNSS SIS

EGNOS SISGNSS

receiver

PVT EngineTrack Maps

3D -> 1DProtection Level

RBC

Atmosphere

3G/4G/5G modem

Aug. Info. from Trackside

Other PNT Sensors

EGNOS

Local AIMN

Module#3

Module#4#5

Module#1#2

Module#1#2

GSM-R modem

EVC

RBC

SIS Data Virtual Balise Reader ETCS OBU

Augmentation data received from EGNOS/Local AIMN.

Option 1:Integration of Augmentation

information in ERTMS functionality

GSM-R (Euroradio)

GPRS

Option 1:Aug. Info.

Triggerof Virtual Balise

Information

Odometry information



Date: 24/12/2019 Page: 17/43

Figure 3-2: Option 2 is based on 3G/4G/5G communications with no modifications in the standardized ERTMS/ETCS on-board and trackside functionalities

3.3 Option 3 The second option is based on the use of a new communication channel (GSM-R/GPRS) w.r.t. the standardized

ERTMS/ETCS on-board and trackside functionalities and existing communication channels.

Figure 3-3: Option 3 based on GSM-R/GPRS with no modifications in the standardized ERTMS/ETCS on-board and trackside functionality

ERTMS/ETCS OB



GNSS SIS

EGNOS SISGNSS

receiver



RBC

Atmosphere

3G/4G/5G modem


Other PNT Sensors

EGNOS

Local AIMN

Module#3

Module#4#5

Module#1#2

Module#1#2

GSM-R modem

GSM-R (Euroradio)

Option 2:3G/4G/5G

EVC

RBC




Information


ERTMS/ETCS OB



GNSS SIS

EGNOS SISGNSS

receiver




Information

RBC

RBC

Atmosphere


GSM-R / GPRS modem

Other PNT Sensors

EGNOSAugmentation data received from EGNOS/Local AIMN. Local AIMN

Module#3

Module#4#5

Module#1#2

Module#1#2

GSM-R modem

GSM-R (Euroradio)

EVC

Option 3:GSM-R / GPRS





Date: 24/12/2019 Page: 18/43

The Augmentation information is received directly by the VBR. The VBR has to integrate a (GSM-R/GPRS) dedicated

modem to provide the information needed for the PVT estimate.

In the ERTMS/ETCS on-board equipment on-board and trackside functionalities no modifications are required

considering this option for the test-bed architecture.

This option has the advantage that GSM-R radio communication network is guaranteed in all ETCS Level 2 and Level 3

lines.

4 GATE4Rail platform evolution services-oriented This section is focused on the definition of the possible evolution of the GATE4Rail simulation and verification

infrastructure services-oriented.

The architecture definition, taking into account the different modules already developed inside the different

ERTMS/ETCS and GNSS laboratories of the Consortium partners [RD-3], is oriented to trace a modular and flexible

platform able to simulate the performance of GNSS in the rail context in a virtualized and geo-distributed

environment.

Figure 4-1 shows the high level functional architecture of GATE4Rail simulation and verification infrastructure and its

evolution.

In a complete future version, an end-user could have the possibility to access to the simulation infrastructure through

a web service, set-up the different simulation scenarios (choosing one of the pre-configured scenarios or building new

ones) and launch simulations with automated tests execution and automated test results evaluation.

The core of the infrastructure is covered by an orchestrator that calls the APIs of the different functions implemented

through different modules of the architecture belonging to Consortium partners (they will be described in Section 7).

They are:

Train Dynamic simulation tool, Track simulation tool, EVC. They are implemented through the modules 1 and

2 included in CEDEX laboratory, starting from the current versions and including their evolutions;

GNSS AIMN and GNSS OBU. They are implemented through the module 3 included in M3S laboratory (at level

of GNSS signals and raw data measurements generation) and module 4 included in RDL laboratory (at level of

GNSS raw data processing), taking into account current versions and their evolutions;

Other PNT sensors (for example IMU). They are implemented through module 4 (including current version and

its evolution);

VB PVT/PL computation. It is implemented through module 4 (current version and its evolution);

VB trigger. It is implemented through module 5 included in RDL laboratory (current version and its evolution).

Moreover, the orchestrator will allow to the end-user to launch simulations considering local and global hazards in

the set-up of GNSS conditions in the ERTMS/ETCS scenarios of interest, and in this way to verify the behaviour of GNSS

in rail in very rare situations.

The end-user will have the possibility of repeating simulations changing some parameters in the scenario configuration

in automated way, and to receive tests evaluation report in automated way, indicating if the test is passed or not

through the comparison of the system performance w.r.t. assigned KPIs (for example taking into account the VB GNSS-

based positioning accuracy requirements for the different ERTMS scenarios, as reported in ReD-1).



Date: 24/12/2019 Page: 19/43

Figure 4-1: GATE4Rail Functional architecture

5 Simulation and Verification Infrastructure goals The GATE4Rail main goal is to provide a lab test architecture capable of simulating railway scenarios for GNSS-based

ERTMS VB, offering a geo-distributed up-to-date simulation and verification environment able to connect GNSS and

ETCS laboratories and facilities for testing the performance of the whole system.

GATE4Rail aims at simulating end to end rail scenarios including GNSS. It is based on a complete simulation chain,

from train, infrastructure and EVC simulation functions to VB trigger through GNSS simulation and VB positioning

simulation, and closing the loop back to the EVC.

GATE4Rail platform also provides the capability to account for rare GNSS events (considering global and local faults),

as well as various configurations encountered in the railway operational environment.

Moreover, GATE4Rail will foresee automation of simulations, from the scenario definition to the results analysis and

report generation. GATE4Rail is unique in this sense since it aims at performing a zero on site testing (fulfilling S2R TD

2.6 –Zero On-Site Testing) including both the whole ETCS and the GNSS with global and local hazards, able to evaluate

the entire system performance with automatic test repetition and analysis of their results, increasing the efficiency of

test resources management, and reducing the need of real lab equipment due to acquisition and maintenance. The

methods and tools for test environment and needed upgrades implementation will be defined taking into account a

set of common requirements for a future notified body approval.

5.1 Target user needs This section is focused on the definition of possible target user needs of the GATE4Rail platform.



Date: 24/12/2019 Page: 20/43

5.1.1 System design: operational needs

5.1.1.1 Initial constraints As a background of the user needs definition, it is to be kept in mind that the simulation platform is to be put in the

overall context of the Shift2Rail masterplan.

GATE4Rail intends to support the TD 2.6 of the Innovation Programme 2 which aims at developing new laboratory

test framework.

The following strategic high-level requirements have to guide the definition of the GATE4Rail architecture:

Zero on-site testing objective: which implies that the simulation tools and procedures have to support full

laboratory end-to-end test processes;

Sub-components from different suppliers: which implies a clear definition (standardization) of the functions

and interfaces of the GATE4Rail platform;

Remote connection of different components: which reinforces the importance of the virtual lab approach;

Costs reduction and efficiency increase for testing technologies and their evolutions: a dedicated process

that can be upgraded to stay up-to-date increases the efficiency of test resources management and reduces

the need of real lab equipment due to acquisition, maintenance etc;

Contribution of the necessary safety integrity level: A laboratory test allows simulating rare GNSS (global and

local) events as well as various configurations encountered in the railway operational environment and thus

characterising the safety level of a solution with large data sets that could not be obtained by

experimentation.

5.1.1.2 Operational Users As explained in [ReD-1] the very starting point of any properly engineered system is the understanding of the users’

expectations and of the operations to be performed by the system.

The basis to designing a system correctly is to have a clear list of the users of the system and their operational needs

i.e. what the systems is supposed to support them with. The support provided by the system may be for existing

procedures or new procedures. The list of use cases will define the scope of tasks and activities to be covered by the

system.

This identification task has been performed in the WP2 [ReD-1] and below are the main users and their corresponding

needs described as use cases:

“The different type of users that will use the testbed to perform simulations are, first of all, the following:

IMs (infrastructure managers): a business entity whose objective is the construction of railway lines and the

management of their operation;

Railway undertakings (RU): Railway undertakings is an entity that operates a railway and/or trains; this entity

can be private or public.

By implementing the principles of modularity in the project of the testbed, in a future perspective also the following

may be viewed as potential users:

Manufacturers: entity responsible for creating, designing and manufacturing specific components for the

railway sector.

Notified Bodies: the Notified Bodies are impartial bodies with the competence and responsibility necessary to

carry out the certification of compliance in accordance with established norms.”



Date: 24/12/2019 Page: 21/43

5.1.1.3 Operational use cases

Each user has different needs that constitute the key of the architecture definition. The main needs of the users have

been identified in [ReD-1]. Below is the list of the identified potential use cases for GATE4Rail simulation and

verification infrastructure:

(1) Support for the new line design engineering: The platform would be useful to validate the preliminary

engineering design and evaluate the correctness of the ERTMS trackside and database data (including also

GNSS) and the engineering principles used. The potential users for this type of tests are the IMs or the ERTMS

suppliers.

(2) Validation of the line engineering (Use Case #2 / User: IM, see [ReD-1])

The main goal of this use case is to prove that ERTMS/ETCS functionalities have been implemented correctly

and according to the ERTMS specifications and the national engineering rules, making sure that the line is

interoperable. The tests results will be part of the technical file that is assessed by a NoBo in order to issue

the EC certificate as required in the CCS TSI.

This kind of test case is normally executed on site (it can be performed with different trains) and in the ERTMS

labs.

(3) Tests for the Certification of different components: Another activity that would be done in the testbed

would be the certification of the following elements:

Track database: IMs or trackside suppliers carry out this campaign.

GNSS-based on-board equipment: user; OBU equipment manufacturer.

VBR: user, manufacturer.

Receiver for Rail: user: manufacturer.

(4) Support for route compatibility test (Use Case #4 / User: XX. See [ReD-1] )

The aim of this use case is to put in service a specific train in a specific line fulfilling the railway specifications.

This test campaign consists on a list of test cases that have to be executed with the same train that will get

the authorisation for placing in service and will be running along that specific line. These tests are mostly

executed on site.

(5) Support to the characterisation of a railway line (from the GNSS point of view): for example for global

effects (ephemeris, satellite clock faults, ionospheric divergence), local effects (as multipath and

interferences), or optimum position of VB GNSS-based. Users: IMs, consultants, railway undertakings or

manufacturers. They can evaluate through GATE4Rail simulation and verification infrastructure performance

of GNSS (focusing in particular on GPS and Galileo) in some operational scenarios (especially where the use of

GNSS is challenging) in nominal but also fault conditions (reproducing same rare conditions) with the aim to

design on board LDS innovative solutions based on multi-sensor GNSS-based platform.

In the framework of the GATE4Rail project, the definition of railway and GNSS test cases [ReD-2] and the PoC will be

based on operational use case (5).

6 System Requirements This section is devoted to show the high level test-bed system requirements. According to 5.1.1.3, the following

general user requirements are derived for GATE4Rail simulation and verification infrastructure and its future

evolutions, as reported in Table 4. The fourth column of Table 4 reports if the requirement is applicable to PoC

foreseen in the GATE4Rail project.



Date: 24/12/2019 Page: 22/43

Table 4: GATE4Rail user requirements

Requirement ID

Title Description Proof of Concept Compliance

GR-UR-001 Main needs The simulation platform shall implement the defined use cases

Yes

(only operational use case (5))

GR-UR-002 Equipment under test

The simulation and verification infrastructure shall allow to user to connect the considered equipment

under test to perform tests

No

GR-UR-003 Test Set-up The simulation and verification infrastructure shall allow to user to define the test set-up for test

execution

Yes

GR-UR-004 Test Reporting The simulation and verification infrastructure shall allow to user to obtain a test report in automated way

once the test is completed

Yes

GR-UR-005 Learning The simulation and verification infrastructure shall allow users to evaluate the impact on system

considering new functionalities

No

Table 5 shows the GATE4Rail simulation and verification infrastructure high level system requirements.

Table 5: GATE4Rail system requirements

Requirement ID


GR-SR-001 Geo-distributed Architecture

The simulation and verification infrastructure shall connect GNSS and ETCS laboratories and facilities for performance

evaluation of the end-to-end system

Yes

GR-SR-002 Full Access The simulation and verification infrastructure shall allow for full access to the test environment everywhere and every

time

No

GR-SR-003 Platform Evolution The simulation and verification infrastructure shall allow to test a future GNSS based signalling system taking advantage of existing infrastructures, but also being flexible enough to

allow for stepwise integration approaches

Yes

GR-SR-004 H/W and S/W Upgrades

Easy Integration

The simulation and verification infrastructure shall allow an easy integration if new H/W and S/W upgrades in the labs or in general new functionalities for the product under test are

required

No



Date: 24/12/2019 Page: 23/43

Requirement ID


GR-SR-005

Real and simulation components

The simulation and verification infrastructure shall support the use of both real system components and simulation

elements for an end-to-end simulation chain providing unified and standardized interfaces allowing to several involved

parties to contribute to the same testing layout

No

GR-SR-006 Controlled Configuration

The simulation and verification infrastructure shall support easily created and controlled configurations

Yes

GR-SR-007 Scenarios Flexibility The simulation and verification infrastructure shall support different configurations for a railway operation environment (i.e. run with different real track data or with simulated track data) and configure different GNSS conditions (considering

global and local failures)

Yes

GR-SR-008 Maintainability The simulation and verification infrastructure shall be maintainable and able to include new features (as S/W

release notes)

Yes

GR-SR-009 Automated Test Results Evaluation

The simulation and verification infrastructure shall implement an automated analysis of test results

Yes

GR-SR-010 Automated Test Report

The simulation platform shall provide an automated generation of test reports

Yes

GR-SR-011 Automatic test repetition

The test bed shall be able to provide automatic test repetition No

GR-SR-012 Automated Test update

The simulation platform shall provide an automated test update

No



Date: 24/12/2019 Page: 24/43

6.1 Functional GATE4Rail simulation and verification infrastructure Requirements This section describes the functional system requirements of the final GATE4Rail platform. Some of them are

applicable to the demonstrator foreseen in the project framework. The mapping of system requirements (at final step)

to proof of concept (at GATE4Rail project step) is shown in fourth column of Table 6.

Table 6: GATE4Rail functional requirements at system level

Requirement ID


GR-SFR-001 Multi-constellation

The simulation and verification infrastructure shall be able manage signals from both GPS and GALILEO

constellations at least

Yes

GR-SFR-002 Multi Frequency

The simulation and verification infrastructure shall be able manage L1/

E1, L5/E5a GNSS signals at least

Yes

GR-SFR-003 ERTMS Scenario generation

The simulation and verification infrastructure shall support the

generation of different ERTMS scenarios: Full Supervision, Start of Mission, Staff

Responsible

Yes

GR-SFR-004 Configurability The simulation and verification infrastructure shall allow to configure the

main GNSS parameters for scenario generation

Yes

GR-SFR-005 Rail Traffic generation The simulation and verification infrastructure shall be able to generate

different train movement profiles

Yes

GR-SFR-006 Global Hazard modelling

The simulation and verification infrastructure shall be able to inject

global hazard on GNSS signals and raw measurements (e.g. ephemeris fault, satellite clock fault, multiple failures,

etc.)

Partially

GR-SFR-007 Local Hazard modelling The simulation and verification infrastructure shall be able to inject local

hazard on GNSS signals and raw measurements (e.g. multipath, EMI,

jamming and spoofing)

Partially

GR-SFR-008 Historical fault data The simulation and verification infrastructure shall be able to import specific historical fault GNSS patterns

coming from other research institutions

No



Date: 24/12/2019 Page: 25/43

Requirement ID


GR-SFR-009 Additional Sensors data generation

The simulation and verification infrastructure shall support the

generation of additional sensors data synchronous and coherent with the

simulation

Partially (only IMU)

GR-SFR-010 Used Signals The simulation and verification infrastructure shall be able to feed the On Board Unit with signals recorded in rail measurement campaigns as well as

with synthetic signals.

Partially

GR-SFR-011 Area map The simulation and verification infrastructure shall be able to import a

3D layout of the environment taking into account the height of the obstacles (e.g. tunnels, bridges, presence of buildings,

railway station, etc.)

Partially

GR-SFR-012 Results evaluation The simulation and verification infrastructure shall include analytics tool box for the evaluation of the results (as

PVT estimate, PL calculation, VB detection)

Yes

GR-SFR-013 Runtime Monitoring In the case of error during the simulation, The simulation and

verification infrastructure shall provide message/alert to user

Yes

GR-SFR-014

Graphical User Interface

The test-bed shall have a graphical user interface for user to select: 1) GNSS scenario (date, time,

constellations, PVT algorithms, etc.);

2) track scenario to be used (track layout, type and number of

balises); 3) the type of faults (local and

global phenomena); 4) the type of KPIs to be computed

and automatically reported (like VB positioning accuracy)

Yes

GR-SFR-015 Test Result Graphical Indication

The test-bed shall be able to provide graphical indication if the test is passed

or not

Yes



Date: 24/12/2019 Page: 26/43

6.2 Operational GATE4Rail simulation and verification infrastructure Requirements This section will describe the operational test bed requirements and which are the target values to be reached for

them. The following requirements have been identified:

Table 7: GATE4Rail operational requirements at system level

Requirement ID Title Description Proof of Concept Compliance

GR-SOR-001 Test-bed availability The test-bed availability is continuous and a message shall be sent to user

when the test-bed is not available for simulations

No

GR-SOR-002 Maximum time acceptable for the user to generate

report

Maximum time acceptable for the user to generate report when the

simulation is successfully completed

No

GR-SOR-003

Test-bed operation modalities

The test-bed shall be able to operate both on a part of the complete

ERTMS/GNSS chain (for example verifying the system performance in

particular scenario operative conditions) and on complete chain

(train ride), considering the different ERTMS and GNSS scenarios occurring

in the train ride)

Yes

GR-SOR-004 Number of simultaneous users

The test-bed shall be able to operate with number of simultaneous users

higher than 2

No

GR-SOR-005 Sensitivity analysis The test-bed shall be able to perform a sensitivity analysis on the

considered scenario (varying the main GNSS parameters included in the

input configuration file according to selected values)

Yes

GR-SOR-006 Number of repetitions of the same test to

performed

The test-bed shall be able to perform a number of the same test repetitions

higher or equal than 2

Yes

7 GATE4Rail simulation and verification infrastructure demonstrator module

decomposition The general architecture defined for GATE4Rail test-bed is defined in Figure 7-1 able to simulate the performance of

GNSS in the rail context in a virtualized and geo-distributed environment by using the same constituents defined in

the section 3.



Date: 24/12/2019 Page: 27/43

Related to the interfaces between constituents, GATE4Rail has followed an approach based on the current

standardized ERTMS/ETCS functionalities to be able to run scenarios with real/simulated ERTMS/ETCS on-board and

trackside equipment.

The GATE4Rail architecture final solution will be assessed in [ReD-8]. The candidate solution currently seems to be

based on Option 2 and Option 3, as reported in Section 3 where a new communication channel for the Augmentation

information transmission to VBR is considered w.r.t. the standardized ERTMS/ETCS on-board and trackside

functionalities.

The Augmentation information is received directly by the VBR from trackside. The GATE4Rail logic scheme is shown

in Figure 7-2. It will consist of five main modules geo-distributed inside the different ERTMS/ETCS and GNSS

laboratories of the Consortium partners fulfilling the GATE4Rail general architecture.

Figure 7-1: GATE4Rail general architecture

The five main modules in a geo-distributed configuration are:

1. Module #1: Emulated Moving Train (CEDEX);

2. Module #2: Mission Control System and Train Dynamics (CEDEX);

3. Module #3: GNSS Signal Generation (M3SB/GUIDE);

4. Module #4: GNSS Augmentation and On Board Unit (RDL);

5. Module#5: Virtual Balise Trigger (RDL).

ERTMS/ETCS OBGNSS


TrainVBR ERTMS/ETCS OB

GNSS SIS

EGNOS SISGNSS

receiver



RBC

IMU Sensors


EGNOS

Local AIMN

Module#3

Module#4#5

Module#1#2

Module#1#2

GSM-R modem

EVC

RBC




Information




Date: 24/12/2019 Page: 28/43

Figure 7-2 shows the GATE4Rail architecture logic scheme with the 5 modules by following the same module

distribution of the Figure 7-1: GATE4Rail general architecture:

Figure 7-2: Overall GATE4Rail Logic Scheme

OBU GNSS observationgenerator

PVT

Module #1

Emulated moving train

Mission Control System

Train Dynamics

Global Track Info

Local Hazard generator

Global Hazard generator

AIMN GNSS observationgenerator

Ground Truth info - GNSS

AIMN Obs & Nav data

Environmentalinfo

Local Track info

Global Hazard

DB

Local Hazard

DB

OBU Obs & Nav data

AIMN Info

GNSS signalplayback

OBU I/Q samples

AIMN I/Q samples

GNSS signalplayback(s)

GNSS Receiver(s)

GNSS Receiver

AIMN GNSS Processing

OBU GNSS Processing

IMU sensoremulator

Virtual baliselocations

Balisedetected trig.

Virtual balisetrigger

PVT, PL

Module #2

Module #3Module #4

Module #5

Ground Truth info - IMU

AIMN Obs & Nav data

AIMN Obs & Nav data

AIMN RF signal(s)

OBU RF signal

COTS device(s) COTS device(s)

COTS device COTS device

IMU data

Syncronization signal

PVT, PL Data

GNSSVBR

ERTMS/ETCS OBERTMS/ETCS Trackside

Train



Date: 24/12/2019 Page: 29/43

7.1 Module #1: Emulated Moving Train It is a Railway Traffic Generator represented in Figure 7-2 through the grey block and is implemented through the

CEDEX ETCS/ERTMS laboratory that generates the railway traffic. Moreover, this block interacts with the Module#5

(Balise detected trigger (described in detail below)) that states if the train is passed over a VB located in the route set.

Additionally, the module #1 drives the train movement according to the test scenario specification Train Simulator is

the module that performs the calculations of the train movements in the Scenario. The information of this block is

used as in input in the Module#2 to define the train dynamics for the Module#3.

This Module might include industrial ETCS components, as the ETCS on-board equipment or the Radio Block Centre.

The interaction with this kind of components is complex and restricted to fulfil the ETCS European specifications.

The separation of the VBR (functionally included in Module #4 and #5) from its natural host, the ETCS on-board

equipment, even at geographical level, is an important constraint of the project, driving the demonstration

architecture to a very particular design, only usable for the proof of concept demonstration.

7.2 Module #2: Mission Control System & Train Dynamics The module (in orange shaded in Figure 7-2) processes the information received from the traffic generator (position

and speed profile of the specific train, etc.) and translates them into a set of information usable by GNSS infrastructure.

In particular, the Mission Control System takes inputs from the Global Track info (a sort of GIS of the section with

track map, obstacles, etc., potentially external and made available by a specific provider in the future) and from the

traffic generator and defines the route of the train. Particularly, the main outputs are:

1. Global Track Info: a. GNSS coordinates and mileages of the line; b. Location of the balises in the line; c. Environmental information; d. Local track info (information about the portion of track nearby the train)

2. Circulation 3D-Speed profile: it defines the train movement profile for the circulation in a route set:

a. Location of the train at the first epoch; b. Movement profile of the train location during the performance of the Scenario; c. Simulation time window (temporal extension of the simulation);

3. Route Ground Truth: table of coordinates run by the train on the route is set. Once the track is modelled,

ground truth can be sampled at different rate (1 meter, 5 meter, etc.)

4. Route Balise location: the table records the location of each balise on the route set.

The Train Dynamics block takes the inputs of the previous blocks and generates the movement trajectory of the train.

Particularly, the output consists of Ground truth info that is a list of train positions and the time. The schematic

overview of the main inputs/outputs of the Mission Control System & Train Dynamics block is depicted in Section 8.1.

7.3 Module #3: GNSS Signals Generation The module (shaded node in blue) is responsible for the generation of synthetic GNSS signals and observables both in

nominal and faulty conditions (injecting global hazards considering historical rare faults recorded on GPS satellites

ephemeris and clocks; synthetic faults on GALILEO) and local hazards on GNSS signals (multipath, signal blockage,

unintentional and intentional interferences and spoofing).



Date: 24/12/2019 Page: 30/43

A direct connection with external repositories (since some research institutions have historical GNSS fault databases)

including both global and local GNSS rare faults can be foreseen in future evolutions of virtualized simulation and

verification infrastructure. Concerning local hazards that affects the railway environment, multipath and obstructions,

the scope is to better represent their effects on the following parameters: satellites signals availability due to

obstructions; C/N0 attenuation due to the surrounding environment; errors on ranging and position domain due to

multipath or NLOS. This will improve the representativeness of the GNSS in the railway scenarios of the interest

(regional, urban and suburban and freight lines).

In the GATE4Rail project framework, the impact of GNSS faults, local and global hazards, will be studied in position

domain whenever this is possible. Working in position (and eventually speed) domain enables to directly modify the

ground truth before adopting it in the simulations. This approach can be used to quickly test tracks environment

(entirely or a portion) for establishing their capacity in adopting VBs, and in case to find-out best locations to install

them. Working directly in position domain requires less computations effort for Module 3 making simulations easier

to perform.

Particularly, the blue module takes as input the ground truth, environmental information and the augmentation

network (as EGNOS or local AIMN (considering 2-Tier approach [ReD-9] or one of them in modular way)). The outputs

of this module are raw data (pseudoranges, carrier phase, Doppler shift, C/N0).

This block allows a direct injection of hazards in I/Q (In-phase /Quadrature) samples or in the RF (Radio-Frequency)

domain. In that case, this block will include a GNSS receiver (used for benchmark too). Otherwise, you can synthetize

through this block the global and local hazards by injecting them directly into the raw data domain without the need

of RF signals generation.

An optional output containing the I/Q samples can be foreseen. The I/Q samples can then be upconverted and

transmitted as RF signals through a COTS GNSS signal playback (purple shaded). The RF signal can be then used to

feed a COTS GNSS receiver (purple shaded) to provide the raw data. The COTS devices provisioning will be out of the

scope of the GATE4Rail project and will represent a future extension.

7.4 Module #4: GNSS Augmentation and On Board Unit Module This module represents the GNSS-based train positioning unit. It includes a GNSS-based OBU and a conventional

augmentation network (EGNOS or local AIMN). A two-tier AIMN architecture (EGNOS plus DGPS) is also supported. In

this way, one can evaluate and test the performance of the whole system in terms of VB accuracy, integrity and

availability (according to the philosophy of modular-based design) then comparing different alternatives for both

augmentation network and OBU. Through OBU, different ad hoc techniques for multipath detection and exclusion

and RAIM can be tested. This module processes the input data and provides PVT and PLs.

7.5 Module #5: Virtual Balise Trigger module This mustard-colored block detects the passage over a VB and notifies this event. Particularly its output is the passage

trigger with the balise reference ID. The inputs are the VB positions and the PVT estimation.

Figure 7-3: Overall GATE4Rail Logic Scheme by ERTMS/ETCS and GNSS laboratories of the Consortium partners [RD-3] shows

the GATE4Rail geo-distributed architecture logic scheme configuration between the laboratories of the Consortium

partners [RD-3].



Date: 24/12/2019 Page: 31/43

Figure 7-3: Overall GATE4Rail Logic Scheme by ERTMS/ETCS and GNSS laboratories of the Consortium partners [RD-3]

CEDEX

RadioLabs

OBU GNSS observationgenerator

Module #1Emulated moving train

Mission Control System

Train Dynamics

Global Track Info

Local Hazard generator

Global Hazard generator

AIMN GNSS observationgenerator

Ground Truth info - GNSS

AIMN Obs & Nav data

Environmentalinfo

Local Track info

Global Hazard

DB

Local Hazard

DB

OBU Obs & Nav data

AIMN Info

GNSS signalplayback

OBU I/Q samples

AIMN I/Q samples

GNSS signalplayback(s)

GNSS Receiver(s)

GNSS Receiver

AIMN GNSS Processing

OBU GNSS Processing

IMU sensoremulator

Virtual baliselocations

Balisedetected trig.

Virtual balisetrigger

PVT, PL

Module #2

Module #3 Module #4

Module #5

Ground Truth info - IMU

AIMN Obs & Nav data

AIMN Obs & Nav data

AIMN RF signal(s)

OBU RF signal

COTS device(s) COTS device(s)

COTS device COTS device

IMU data

Syncronization signal

PVT, PL Data

M3S



Date: 24/12/2019 Page: 32/43

8 Functional Decomposition In this section, the functional decomposition of each module is reported.

8.1 Module #1 The module #1 functional decomposition is shown in Table 8.

Table 8: Module #1 Function decomposition

Code Name Description Input Output

1.1 Train and Track simulator

1.1.1 Track simulation GUI

This function is responsible for performing the circulation defined in the test scenario:

Route combination o Signal

aspects o Point status

Selection of VB/Eurobalises telegrams of the route.

Additionally, while running a specific scenario, this function is responsible of:

Updating track occupation status

Evaluation of the route status according to the information received.

Computation of signalman actions during the performance of the Scenario.

EVC configuration (parametrization), if required.

Radio configuration, if required.

Internal: 1.1.3

Internal: 1.1.3 1.1.4 1.2.1 1.4.1

External: Signal man operator

External: Not foreseen

1.1.2 Train simulation GUI

This function is responsible for:

Train dynamics according to train and track parameters

Internal: 1.1.3

Internal: 1.1.3 1.3.1 1.4.1

External: Train Driver




Date: 24/12/2019 Page: 33/43

Calculation and management of train movements.

Management of EVC I/O signals.

Management of operational procedures by the driver.

1.1.3 Scenario Manager This function is responsible for coordination of the Track Simulation and the Train Simulation tools, mainly translating the 2-D information on the Track to the 1-D of the Train and vice versa. It also provides the link to the external modules.

Internal: 1.1.1 1.1.2

Internal: 1.1.1 1.1.2 1.2.1 1.3.1 1.4.1

External: VB/Eurobalises DB information Module#5

External: Module#2

1.1.4 Telegram Trackside Simulator

This function is responsible for the simulation of the ERTMS VB/Eurobalises transmission telegrams. This function should be included within the Track Simulation Function, but due to its relevance for the project, it is decided to deal with it independently.

Internal: 1.1.1

Internal: 1.3.1 1.4.1



1.2 ERTMS Trackside equipment

1.2.1 Radio Trackside Only in Level 2/3, this function is responsible for the interchange of radio message between the EVC and the trackside equipment. This equipment can be:

Real (RBC)

Simulated (Radio Module Simulator)

Internal: 1.1.1 1.3.1

Internal: 1.3.1 1.4.1

External: Signalman operator


1.3 ERTMS On-board equipment

1.3.1 EVC This function is responsible for a computer-based system that supervises the movement of the train to

Internal: 1.1.2 1.1.4 1.2.1

Internal: 1.3.2 1.2.1



Date: 24/12/2019 Page: 34/43

which it belongs, on basis of information exchanged with the trackside sub-system, the train driver and the train simulator. This equipment can be:

Real (ERTMS/ETCS on-board equipment)

Simulated (EuroCab Simulator)

External: Train Driver


1.3.2 EVC Juridical Recording Unit

This function is responsible for recording train events complying with the ERTMS/ETCS standard.

Internal: 1.3.1

Internal: 1.5.1



1.4 Laboratory Scenario records

1.4.1 Scenario Recorder Unit

This function is responsible for recording all the data generated or transmitted (e.g. radio message) by blocks:

Track simulation GUI

Train simulation GUI

Scenario Manager

Telegram Trackside Simulator

Radio Trackside

Internal: 1.1.1, 1.1.2, 1.1.3, 1.1.4, 1.2.1

Internal: 1.5.1



1.5 Analysis of the Scenario

1.5.1 Scenario Analyser This function is responsible for analysing the record generated during the performance of the Scenario according to the Test Case Instantiation (TCI) observables defined.

Internal: 1.3.2 1.4.1

Internal: Not foreseen


External: Report



Date: 24/12/2019 Page: 35/43

8.2 Module #2 The module #2 functional decomposition is shown in Table 9.



2.1 GNSS Track Information generation

2.1.1 Line Track Information generation.

This function is responsible for generating information from the Global Track Information DB in line with the railway data format.


Internal: 2.1.2

External: Global Track Info DB


2.1.2 Route Track Information selection.

This function is responsible for selecting Line Track Information (track sections) for the route set.

Internal: 2.1.1

Internal: 2.2.1, 2.3.1, 2.4.1

External: Module#1


2.2 Circulation 3D-Speed profile

2.2.1 Train speed profile conversion to Circulation 3D-Speed profile.

This function is responsible to convert 1D Train Speed profile into Geographic Coordinate System for the Route Track Information.

Internal: 2.1.2


External: Module#1

External: Module#3

2.3 Route Ground Truth

2.3.1 Generation of Route Ground Truth.

This function is responsible to model 1D route into Geographic Coordinate System samples (for a predefined rate) for the Route Track Information.

Internal: 2.1.2



External: Module#4

2.4 Route Balise location

2.4.1 Generation of Route Balise location.

This function is responsible to define the location of the Balises in the Route Track Information.

Internal: 2.1.2



External: Module#5



Date: 24/12/2019 Page: 36/43

8.3 Module #3 The third module can be decomposed in four architectural blocks and two databases.

The two databases contain respectively local and global hazard record/information and description. These data will

be used to generate these hazard events so that the OBU and AIMN can be modelled in case of both ‘real’ faulty

events (i.e., observed and measured events) and simulated ones.

The four sub-modules are: the global and local hazard generators, and the AIMN signal generator and OBU signal

generator. The sub-modules are described from a functional stand point in Table 10.



3.1 Global and local hazards generators

3.1.1 Global hazard import

This function is responsible for importing information related to global GNSS hazard database (real and simulated fault events)


Internal: 3.1.5

External: Global hazard DB

External:

3.1.2 Local hazard import

This function is responsible for importing information related to local GNSS hazard database (real and simulated fault events)


Internal: 3.1.6

External: Local hazard DB


3.1.3 Ground truth GNSS reading

This function is responsible for reading the GNSS ground truth data


Internal: 3.1.6, 3.3.1

External: Module #2


3.1.4 Environment data reading

This function is responsible for reading the environmental data surrounding the GNSS ground truth data already mentioned in 3.1.3


Internal: 3.1.6

External: Module #2


3.1.5 Global hazard generation

This function is responsible for generating global hazard from the corresponding DB

Internal: 3.1.1

Internal: 3.2.2, 3.3.1





Date: 24/12/2019 Page: 37/43


3.1.6 Local hazard generation

This function is responsible for generating local hazard from the corresponding DB according to the environmental data

Internal: 3.1.2, 3.1.3, 3.1.4 (Note: 3.1.3 is needed since local hazard is due to both the environment and the train position relative to this environment.)

Internal: 3.3.1



3.2 AIMN GNSS signal generator

3.2.1 Network information import

This function is responsible for importing necessary information (with the augmentation network topology and characteristics: number of receivers, receiver characteristics, kind of augmentation network) r elated to the augmentation network set up


Internal: 3.2.2

External: Characteristics of the network


3.2.2 AIMN GNSS signals generation

This function is responsible for generating GNSS observations (pseudoranges, carrier phase, Doppler shifts and C/N0) and signals IQs applicable to the network (AIMN)

Internal: 3.2.1, 3.1.5

Internal:


External: Module #4

3.3 OBU GNSS signal generator

3.3.1 OBU GNSS signals generation

This function is responsible for generating GNSS observations and signals IQs applicable to the on-board unit

Internal: 3.1.3, 3.1.5, 3.1.6

Internal:


External: Module #4



Date: 24/12/2019 Page: 38/43

8.4 Module #4 The fourth module can be decomposed in three architectural blocks: AIMN GNSS processing, OBU GNSS processing

and the IMU sensor emulator. The first two blocks are responsible for the processing chain downstream the sensors.

Therefore, their input is represented by the raw data (pseudoranges, carrier phase, Doppler, C/N0), the ephemeris

and the IMU observables (accelerations and angular speed). The third block emulates the output of inertial sensors,

generating the observables needed to feed the OBU GNSS Processing block. The three blocks implement the function

reported in Table 11.



4.1 AIMN GNSS Processing

4.1.1 Observation data import

This function is responsible for importing raw data captured by the GNSS receiver.


Internal: 4.1.4, 4.1.5, 4.1.6

External: Module #3


4.1.2 Navigation data import

This function is responsible for importing ephemeris data


Internal: 4.1.4, 4.1.5, 4.1.6

External: Module #3


4.1.3 EGNOS messages import

This function is responsible for importing EGNOS data


Internal: 4.1.5, 4.1.6

External: Module #3


4.1.4 Reference Station integrity monitoring

This function is responsible for assessing the healthiness of the reference stations

Internal: 4.1.1, 4.1.2

Internal: 4.1.5, 4.1.6



4.1.5

Satellite integrity monitoring

This function is responsible for assessing the healthiness of the satellites

Internal: 4.1.1, 4.1.2, 4.1.3, 4.1.4

Internal: 4.1.6, 4.1.8



4.1.6 Augmentation data Generation

This function is responsible for generating the augmentation data (either differential correction for DGNSS architecture or raw data for relative positioning schemes)

Internal: 4.1.1, 4.1.2, 4.1.3, 4.1.4, 4.1.5

Internal: 4.1.7



4.1.7 Augmentation Data Gateway

This function is responsible for Augmentation data delivery to the OBU

Internal: 4.1.6



External: OBU GNSS Processing (4.2.3)

4.1.8 Integrity info Gateway

This function is responsible for integrity information delivery to the OBU

Internal: 4.1.5






Date: 24/12/2019 Page: 39/43

4.2 OBU GNSS Processing

4.2.1 Observation data import

This function is responsible for importing raw data captured by the GNSS receiver.


Internal: 4.2.7, 4.2.8

External: Module #3


4.2.2 Navigation data import

This function is responsible for importing ephemeris data


Internal: 4.2.7, 4.2.8

External: Module #3


4.2.3 Augmentation data import

This function is responsible for importing Augmentation data received by the AIMN GNSS processing block


Internal: 4.2.7, 4.2.8

External: AIMN GNSS Processing (4.1.7)


4.2.4 Integrity info import

This function is responsible for importing integrity information received by the AIMN GNSS processing block


Internal: 4.2.7, 4.2.8

External: AIMN GNSS Processing (4.1.8)


4.2.5 IMU data import This function is responsible for importing IMU data received by the IMU observations generator


Internal: 4.2.7 (in case of multi-sensor ARAIM), 4.2.8

External: IMU observations generator (4.3.4)


4.2.6

Local Track info import

This function is responsible for importing the information about the track database


Internal: 4.2.7 (in case of track-constrained ARAIM), 4.2.8, 4.2.9

External: Module #2


4.2.7

ARAIM This function is responsible for assessing the healthiness of the used satellites for PVT computation

Internal: 4.2.1, 4.2.2, 4.2.3, 4.2.4, 4.2.5 (in case of ARAIM), 4.2.6 (in case of track-constrained ARAIM)

Internal: 4.2.8, 4.2.9



4.2.8 PVT estimation This function is responsible for the PVT estimation

Internal: 4.2.1, 4.2.2, 4.2.3, 4.2.4, 4.2.5, 4.2.6, 4.2.7

Internal: 4.2.9, 4.2.10



4.2.9 PL evaluation This function is responsible for the Protection Level evaluation

Internal: 4.2.7, 4.2.8

Internal: 4.2.10





Date: 24/12/2019 Page: 40/43

4.2.10 PVT & PL Gateway This function is responsible for delivery the PVT solution with the associated Protection Level

Internal: 4.2.8, 4.2.9



External: Module #5

4.3 IMU sensor emulator

4.3.1 Ground Truth info import

This function is responsible for importing the data contained in the Ground Truth concerning the Inertial Sensor


Internal: 4.3.2, 4.3.3

External: Module #2


4.3.2 Emulate 3-axial accelerometer

This function is responsible for emulating a 3-axis accelerometer providing the accelerations along the track, vertical and cross-over

Internal: 4.3.1

Internal: 4.3.4



4.3.2 Emulate 3-axial Gyro

This function is responsible for emulating a 3-axis gyroscope providing the attitude changing: pitch rate, roll rate and yaw rate

Internal: 4.3.1

Internal: 4.3.4



4.3.4 IMU observables gateway

This function is responsible for the delivery to the OBU of the IMU observables

Internal: 4.3.2, 4.3.3






Date: 24/12/2019 Page: 41/43

8.5 Module #5 The module #5 is responsible for triggering the event related to the virtual balise detection. This module implements

the following functions, as reported in Table 12:



5.1 Virtual balise trigger

5.1.1 PVT & PL data import

This function is responsible for importing the PVT estimation result and the associated PL


Internal: 5.1.3

External: Module #4


5.1.2 Virtual balise locations import

This function is responsible for importing the locations of the virtual balise


Internal: 5.1.3

External: Module #2


5.1.3 Virtual Balise Detection

This function is responsible for detecting the passage over the balise

Internal: 5.1.1, 5.1.2

Internal: 5.1.4



5.1.4 Balise detected notifier

This function is responsible for notifying the balise detected event

Internal: 5.1.4



External: Modulo #1



Date: 24/12/2019 Page: 42/43

Conclusions The document shows the GATE4Rail simulation and verification infrastructure high level architecture taking into

account the work already carried out in other ESA/GSA H2020 research projects focused on the use of GNSS for rail.

Different options of GATE4Rail simulation and verification infrastructure architecture are shown, taking into account

the minimization of impact of GNSS introduction into ERTMS trackside and On Board functionalities.

Moreover, the document shows the future evolution of GATE4Rail platform high level architecture oriented to

services. User, general, functional and operational test-bed requirements are defined. Finally, the document reports

the module decomposition of the GATE4Rail demonstrator with its functional analysis.

The detailed design of simulation and verification infrastructure will be carried out in [ReD-8] through a deep SWOT

analysis of different selected options, and with a particular emphasis on the project demonstrator.



Date: 24/12/2019 Page: 43/43

END OF THE DOCUMENT