Date: 04/08/2020 Page: 3/60

Executive summary

GATE4Rail consists of the design and development of a geo-distributed simulation and verification platform connecting Global Navigation Satellite System (GNSS) centres of excellence and ERTMS (European Railway Traffic Management System)/ETCS (European Train Control System) laboratories in Europe to evaluate GNSS performances in the railway environment with agreed methodologies and tools. The expected target of the test-bed platform includes infrastructure managers, railway undertakings, manufacturers of the railway industry and Notified Bodies. The aim is to reduce the need of tests on field, considering very rare fault events too.

In the frame of GATE4Rail project, Work Package (WP) 3 deals with the definition of a comprehensive methodology and the associated tools able to characterise the GNSS performance into the railways application scenarios defined in WP2 in the framework of a Virtual Balise detection in ETCS/ERTMS context.

The present document (deliverable D3.1) is the first report delivered by GATE4Rail WP3. It is specifically dedicated to the definition of a standardised database in order to characterize GNSS in different rail scenarios and the description of Consortium tools included in the GATE4Rail test-bed able to generate local and global hazards and evaluate their impact on GNSS performance.

The project takes advantage from the well-consolidated experience derived from past and ongoing projects on GNSS application in the rail domain (GSA H2020 ERSAT GGC, S2R VITE, GSA H2020 STARS and GSA H2020 RHINOS).

WP2 defined the primary GNSS-ETCS operational scenarios including Hazardous and System Fault situations, the use cases in the railway environment (D2.1 document [ReD-1]) as well as the test cases for the performance evaluation (D2.2 document [ReD-2]). Test cases were defined for ERTMS/ETCS, covering Virtual Balises cases of study in the ERTMS field, and for GNSS, covering GNSS phenomenon cases in the railway field. In addition, the main railway environments that affect and/or impact the GNSS overall performance within a typical operational scenario were identified.

D4.1 document ([ReD-3]) of WP4 defined the functional and operational requirements with the detailed design of the geo-distributed simulation and verification infrastructure. In particular, five main modules geodistributed inside the different ERTMS/ETCS and GNSS laboratories of the Consortium partners were identified for the GATE4Rail test-bed:

 Module #1: Emulated Moving Train. It is a Railway Traffic Generator.  Module #2: Mission Control System and Train Dynamics. It processes the information received from the traffic generator and translates them into a set of information usable by GNSS infrastructure.  Module #3: GNSS Signal Generation. It is responsible for generating GNSS raw data both in nominal and fault conditions taking into account different environments crossed by train in the considered railway track.  Module #4: GNSS Augmentation and On Board Unit. It represents the GNSS-based train positioning unit.  Module#5: Virtual Balise Trigger. It is responsible for detecting the passage over a Virtual Balises and for the notification of this event.

The analysis here reported has been defined taking into account:

-which are the main GNSS parameters needed to characterize GNSS performance in different rail segments (high speed, regional, freight lines);

Date: 04/08/2020 Page: 4/60 -the impact of crossed rail environment on GNSS performance through the application of the Consortium tools in some specific test scenarios extracted from D2.2.

The main results of WP3 are the definition of the structure of a standardised database that is detailed in section 3 of the present document and the definition of the main capabilities of the tools for GNSS characterization in different rail operational scenarios and GNSS environments, illustrated in section 4. The tools responsible for the GNSS characterization in the railways environment are the ones included in the Module #3 of the GATE4Rail test-bed that is in charge of the generation of the simulated GNSS signals (both in nominal and fault conditions).

The contents of this deliverable will be considered as input for the D4.2 and D4.3 documents where the detailed design of the GATE4Rail test-bed and its testing and verification will be respectively shown.

Date: 04/08/2020 Page: 5/60 GATE4Rail aims at implementing a geo-distributed automated simulation and verification architecture connecting GNSS and ETCS laboratories and facilities capable of simulating railway scenarios for GNSS-based ERTMS applications by integrating different simulation blocks and by defining their interfaces in order to cover the global simulation chain.

Index of Figures

Index of tables

In the frame of GATE4Rail project, WP3 focuses on the identification of the parameters and the main tools required to support the characterization of the GNSS performance into the railways application scenarios.

According to this approach, this document defines a standardised database and identify the tools of the Consortium included in the GATE4Rail simulation and verification infrastructure able to characterize the GNSS in the rail domain considering different environments crossed by train along railway track ride.

The contents of this deliverable will be considered as input for the D4.2 and D4.3 documents where the detailed design of the GATE4Rail test-bed and its testing and verification (considering the use of the tools for the generation of global and local faults injected on GNSS raw data and for the analysis of their impact on GNSS performance in rail domain) will be respectively shown.

Reference Documents

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

Description of Changes from the Previous Revision

Revision 00 -N/A.

Introduction

In the frame of GATE4Rail project, WP3 deals with the definition of a methodology for the evaluation of global and local GNSS faults effects and the associated tools able to characterize the GNSS performance in the railway application scenarios defined in WP2 to cover the main events that can occur during an operational scenario.

The present document is specifically dedicated to the definition of a standardised database containing the main GNSS parameters needed to characterize GNSS performance in different railways scenarios and the description of Consortium tools, mainly included in the Module 3 of the GATE4Rail test-bed, able to generate local and global hazards and evaluate their impact on GNSS performance.

Chapter 3 of this deliverable takes advantage from the results derived from other projects on GNSS application in the rail domain such as GSA H2020 ERSAT GGC, S2R VITE, GSA H2020 STARS and GSA H2020 RHINOS (in which databases have been built with threats detection) to define a standardised database identifying the parameters to be tested to consider the effects of global and local GNSS faults and the raw data to be used to process the PVT solution. Outcomes of D3.2 document [ReD-5], in which error models are defined for fail-safe positioning components focusing in particular on GNSS local hazards, are also considered.

Chapter 4 is devoted to the description of the methodology and the associated Consortium tools able to characterise the GNSS performances in the railway domain. A detailed description on how they are configured and applied to simulate and characterize the GNSS behaviour in nominal condition and in presence of global and local hazards in a selection of scenarios of interest is also reported.

Finally, Chapter 5 draws conclusions about the work performed and its outcome.

3 Standardised Database for GNSS characterization in the railway

State of the art of past and on-going projects

This section provides a summary of the state of the art of past and on-going projects, such as GSA H2020 RHINOS, GSA H2020 STARS, GSA H2020 ERSAT GGC and S2R VITE, in which databases have been built in terms of parameters to be tested in order to consider the effects of the railway environment (local and/or global) on the receiver processing and the raw data to be used to process the PVT solution.

RHINOS

Assumptions

In RHINOS (Railway High Integrity Navigation Overlay System) project a description of the construction and functioning of a Geographical Information System (GIS) database model of the railway environment was provided. The assumption was that landscape features in the immediate vicinity of railway can cause deleterious effects on positioning derived from GNSS signals. Narrow canyons, buildings, tunnels and natural features (e.g. trees and other vegetation) are typical features to be considered within the railway environment. A GIS is a system designed to capture, store, manipulate, analyse, manage, and present all types of spatial or geographical data.

Date: 04/08/2020 Page: 13/60

Selection of measurements relevant for the database definition

The GIS database contains primarily open source data relating to the railway environment. In the RHINOS project two different sources of information were considered:

 Digital Surface Models (DSMs) derived from LiDAR. They are a potentially source of information to determine the effects of features both man-made (e.g. buildings, cuttings, bridges and tunnels) and natural (e.g. vegetation and hills). They derive from point cloud data often acquired by aerial surveys. Each point represents an x/y/z measurement with z value derived by the time taken for a sensor to emit a pulse of light at a target and the sensor receive back the reflected pulse.  Polar Distortion Photography Database based on Google Street View. Google Street View is a network of adjacent 360 o high-resolution panorama images divided into quadratic tiles. The images are viewed using Google Maps in a web browser or may be accessed via the Google Maps static application programming interface. The database uses the lat/long coordinates to place the unique 'pano' ID at the scene's location along the railway track.

Finally, two algorithms used to derive the elevation angles and obscuration using the GIS database model of the railway environment were presented in the RHINOS project: DSM Modelling and Polar Coordinate Image Processing.

STARS

3.1.2.1 Assumptions STARS (Satellite Technology for Advanced Railway Signalling) project objective was the characterization of the railway environment from a GNSS point of view. It identified the possible techniques and methods to characterize the local phenomena that cause GNSS performance degradation and PVT errors. The analysed local phenomena were the multipath, RFI (Radio Frequency Interference), and GNSS signal visibility and attenuation. A selection of the parameters and measurement considering aspects related to frequencies, constellations, elevation masks, sampling frequency, output format, synchronization, and auxiliary data to characterize the local phenomena was performed.

For the measurement equipment selection, receiver's data storage formats and post-processing tools to carry out the lab tests were analysed.

Selection of measurements relevant for the database definition

The list of all the measurements collected in the STARS project was selected according to the information needed to assess the sources of influence on GNSS navigation solution. In particular, the measurements were classified into four categories:

1. measurements related to the GNSS and SBAS (Satellite-based Augmentation Systems) signals processing. 2. Measurements related to GNSS and SBAS RF (Radio Frequency) samples. 3. Measurements related to the railway environment. 4. Measurements related to the train.

Database structure

Google cloud was used as the data storage server for the STARS database. The data stored during the project were organized based on different sources of origin of the measurements and on three different locations where data were acquired. The following structure for directory model of STARS database was used:  separate directory was created for each partner responsible for the measurement  separate subdirectory was created for each day of measurement campaign Date: 04/08/2020 Page: 14/60  separate sub-subdirectory was created for each device  separate file was created for data from each data source (measuring device with given configuration, virtual sensor, GT data, data of Reference position of GNSS antenna, etc.)  separate metafile with measurement description was created for each measurement  Separate file (or continuous sequence of files) with signature of data file.

The GNSS measured data were converted and stored in RINEX files since it is a universal format independent of receiver used to collect the measurements. For the GT position data, the selected format was the text file format with each row containing a time-stamped GT position. The data resulting from processing of measured data were stored in a text file. In addition, the binary raw data files from GNSS receivers, comprising additional parameters and useful information for the analysis, were also included in the database.

Accessibility

Access rights to the database are restricted as defined in STARS Grant Agreement.

ERSAT GGC

Assumptions

The standard process defined in ERSAT GGC (ERTMS on SATELLITE Galileo Game Changer) project identified the information to be acquired by the selected measurement system and the simulation methods for characterizing GNSS signals along a railway track to enable the classification of the track areas as suitable or not suitable for Virtual Balises (VB) placement. The track area classification process addressed only the local hazard causes and in particular the limited sky visibility, multipath, NLOS (Non Line-Of-Sight), in-band, nearband and out-of-band interference. The criteria used for the classification of the track areas, the classification procedure and the information to be stored in a repository system were identified during the project.

Selection of measurements relevant for the database definition

To characterize the GNSS SIS (Signal In Space) with respect to the local hazard causes addressed in the ERSAT GGC project the following information was acquired and measured:

 receiver observations in a proprietary format that can be converted into RINEX-format messages.

The measurement receiver data included at least the following measurements: carrier-to-noise ratio, pseudorange and carrier phase measurements using GPS C/A code signal at L1 frequency and as raw measurement without any iono or tropo model corrections.  Observations as above defined but obtained by other GNSS constellations (e.g. GALILEO E1 and E5, GPS L5, GLONASS L1)  Power spectral density measurements  AGC (Automatic Gain Control) measurements  Video record of the surroundings (optional)  GNSS samples collected at non-zero IF frequency by RPS equipment (optional)  GNSS augmentation data  Constellation almanac data and navigation messages (ephemeris data).  Receiver settings  Track data

Database definition

A common structured data repository linked to a specific 'Campaign' was used in ERSAT GGC database. Together with the raw measurement acquired during such a campaign, it also contained information about Date: 04/08/2020 Page: 16/60

Taking into account the above assumptions and the state-of-the-art of past and on-going projects in which databases have been built with threats detection, for the definition of the GNSS standardized database to be used to characterize the GNSS reception in the railway environment, three main categories of measurements have been selected and described in the following subsections: raw measurements, railway environmental information and the parameters associated with the error models.

Raw measurements

This category of data comprises all the necessary measurements that are used by the PVT unit for PVT estimation. The following parameters have been identified to be included in the GNSS database: All these measurements shall be available for multiple frequencies and multiple GNSS constellations and in particular for:


 Constellations: GPS + GALILEO (mandatory), GLONASS  Frequencies: GPS L1 C/A (mandatory), GPS L5 (mandatory), GALILEO L1 and L5 (mandatory), GPS L2P(Y), GPS L2C, GLONASS L1

Concerning raw data format, all GNSS measurements should be made available in the de-facto standard RINEX 3.x. which is a widely recognized standard for storing of raw data. In addition to RINEX format, receiver's binary formats files can also be considered since they contain more information than RINEX ones (e.g. RF interference or multipath that is not supported in RINEX files).

Railway Environmental information

This category of data comprises the information about the presence of obstacles and sources of shading or blockage on the railway line. The following parameters have been identified to be included in the standardised GNSS database:  Sky visibility due to trackside obstacles in terms of elevation masking angle and number of GNSS satellites in view w.r.t. time  Local obstacle information (such as presence of buildings, foliage, bridges, tunnels) on the railway line  Environmental type information (such as open-sky, urban, peri-urban, forest) for a railway line

Error models parameters

This category of data comprises the parameters that describe the error models defined and used in GATE4Rail project. In particular, the following subsection summarizes the main features and the necessary input data and parameters defined for the GATE4Rail error model simulators. A detailed description of these tools is provided in section 4.1.

Date: 04/08/2020

Page: 17/60

UGE Positioning Error Simulator for local defined areas

The local error generator aims at providing latitude and longitude errors to be applied to the track reference depending on the type of environment crossed by the train.

The tool itself requires few parameters:

 reference trajectory  for each point of the trajectory: label of environment type However, the tool also embeds error models (one for each type of environment) that are provided with the error routine and that have been a priori computed based on the exploitation of existing databases.

Here below is presented: 1/ the existing data that have been used, 2/ the parameters used to compute error models, and 3/ the parameters of the error models provided.

Inputs extracted from databases for the error generator

The simulator of local defined area errors uses pre-existing databases. The data used are:

-the RINEX file acquired by the receiver on board -the reference trajectory (from STARS database, the *.RPO file)

Existing databases are not labelled depending on the environment crossed by the train (urban, forest etc.…). Some records can cross several types of environments (such as mountainous and cities along Swiss lines, some others are more homogeneous such as forest along Czech lines, or rural environment along Spanish lines). Moreover, the availability of video images that could be used in an automatic process to detect masking environment is very low: some fish-eye images have been acquired by AZD in STARS without automatic processing, and some by UGE along Spanish line, with processing but mainly in rural area.

As a first step, the environment has been classified for a couple of lines with a manual process based on the information available on Google Earth. As a first estimation, error models will be provided as Gaussian distributions. Thus, for each environment, they can be represented by a mean µ and a variance σ 2 .

Based on STARS data, the distributions summarized in Table 4 have been proposed, that will require to be refined in the future with more extensive availability of data.

GUIDE Local Obstacles Errors Tool

Developed tools generates errors, in position domain, for the interaction of GNSS signals with some defined obstacles present on the railway lines. The analysis of GNSS receiver behaviour in presence of well-defined obstacles has shown that the errors behaviour is quite similar on different obstacles. In the case of tunnel PVT errors have not been estimated starting from 𝑡 + 2 seconds and they have been re-estimated starting from 𝑡 -1 second.

StellaNGC GNSS error model parameters

The main models provided by StellaNGC are:

 Atmospheric models. They provide the possibility to select (and even to tune) models of the atmospheric impact (both the ionosphere and troposphere impacts) on GNSS signal propagation.  Interferences. They allow the definition of interference signal scenarios to be added on top of the GNSS signals. This cover the selection of the type of interference signal to be used, the start and stop time, and the signal power pattern. It is to be noted that several types of signals can be used during the same scenario. The list of signals available is provided in D3.2 [ReD-5].  Multipath: although not used in the context of GATE4Rail (as this part will be addressed by UGE and GUIDE local effect models), StellaNGC also provides users the possibility to define how multipath will impact GNSS signals (from statistical approach to ray tracing based on the 3D modelling of the receiver environment

As detailed in section 4.1.1, StellaNGC is a very flexible and customisable GNSS simulation platform. Yet, it can also be complex to properly define all parameters relevant to a specific scenario (as some parameters can required a significant GNSS expertise). In the context of GATE4Rail, the aim is to keep the use of the simulation platform as easy and straightforward as possible. To do this, it is planned to reduce as much as possible the number of parameters that users have to define for enabling to perform all scenarios defined in WP2 (all other parameters being determined automatically to ensure realistic GNSS simulations). Hereafter are presented the list of parameters that has to be provided in order to define the simulation (see also D4.2 for further details about the Module #3 interfaces).

Date/time

At first, it has to be defined the date (day, month & year) and time (hour & minute) of the scenario simulation. More specifically, users will be requested to provide the date and time of the scenario start. These parameters will be used to determine the position of satellites in the sky for the entire simulation.

Trajectory

The trajectory to be used can be defined in different way for StellaNGC (see 4.1.1 for more details). Yet, in the context of GATE4Rail, the input trajectory has to reflect a realistic speed profile of a train on a realistic line. This input is generated and provided by Module #2 (as part of the 'Dynamic Ground Truth' data). In addition to the two previous local errors, the impact of local environment on the satellite visibility will also be accounted thanks to Module #2 that will provide, all along the line, the masking angle information. In this context, what will be requested during the definition of the simulation is whether the satellite visibility is to be accounted for the simulation scenario.

3.

Interferences (local hazard)

The list of interferences signals available for GATE4Rail is provided in section 4.1.1. In this context, what will be requested during the definition of the simulation is to define the interference scenario to be used (if any). The interference scenario shall contain:

 the type of interference signal to be generated;  the start and stop time of generation for each type of interference signal;  the power profile over time for each type of interference signal.

Global errors

A number of global errors will also be made available to end-users for the setup of their scenarios. Amongst the list of possibilities available in Stella NGC, the three following types of errors have been selected as the most relevant for the GATE4Rail demonstrator:

 Errors in the navigation messages (ephemeris) broadcasted by satellites  Errors in the navigation messages (clock) broadcasted by satellites  Abnormal ionospheric conditions.

Stella NGC provides the possibility to introduce errors in the navigation messages broadcasted by the satellites. Among the different subparts of the navigation messages that can be changed, it is possible to modify the satellite ephemeris information. This will introduce a discrepancy between the actual position of the satellite and the position used by the receiver to compute the pseudo-range and the consequently the PVT.

Yet, the modification of ephemeris parameters (described as a set of Keppler parameters) can be complex and probably not necessary in the context of the project. As a consequence, ephemeris modifications will be pre-defined per satellites. End-users will only be requested to define:

Date: 04/08/2020 Page: 21/60  Whether or not ephemeris errors have to be introduced  The number of satellites for which ephemeris errors will be introduced  The start and stop time of erroneous ephemeris broadcast for each satellite.

Similarly, to ephemeris errors, clock errors can also be introduced in the broadcasted navigation message of satellites. With the same objective of keeping the GATE4Rail platform easy to use (also for non GNSS expert), clock will also be predefined so that end-users only have to define:

 Whether or not clock errors have to be introduced.  The number of satellites for which clock errors will be introduced.  The start and stop time of erroneous clock information broadcast for each satellite.

Ionospheric impact on GNSS signals has been modelled. In Stella NGC, both the Klobuchar and the Nequick models can be used. In addition, it is also possible for the user to provide IONEX or self-defined input files for accounting for the ionospheric effect.

This latter option is useful to defined abnormal ionospheric conditions that can hardly be modelled by the usual Klobuchar or Nequick approaches.

Again, the definition of the ionospheric description parameters that would abnormal but still realistic is not obvious. Hence, the proposed solution for GATE4Rail demonstrator is to predefine the ionospheric conditions and to give end-user the possibility to define:

 Whether or not ionospheric abnormal conditions have to be introduced  The start and stop time of this ionospheric event.  The date and time (and duration) of the scenario.  The GNSS constellations and frequencies to be simulated (e.g., GPS and GALILEO on the upper frequency L1/E1).  The mobile motion along time.  The environmental conditions, such as the atmospheric conditions (both ionospheric and tropospheric), the local environment conditions (e.g., multi-path, masking, RF interferences, …).  Signal errors and/or anomalies (e.g., navigation message errors, satellite clock errors, …).

Databases used by Consortium tools

It is key to note that StellaNGC can be used both using a classical GUI (Graphic User Interface) based approach, but also (and this is what will do for GATE4Rail) using a dedicated API (Application Protocol Interface).

Features

As shown hereunder, StellaNGC is based on a layer architecture. Thanks to that implementation approach, the GNSS simulator provides to the user and external systems simulation data at different level (RF, IQ, GNSS Raw data, trajectory). In this section main features of the simulator are described. Then, as it can be constraining to operate in the lab, user can control the system remotely. This Remote Control can be done via the remote desktop protocol available on any windows machine.

Additionally, it is possible to integrate StellaNGC within a larger test bed. In this case, an API (Application Protocol Interface) is available. Thus, StellaNGC can be controlled and monitored through TCP/IP commands.

Finally, the simulator can be interfaced with a hardware trigger which will allow to launch GNSS simulation synchronously with external systems.

L1-C/A L1P Y-codeless L1-C L2-P Y-codeless L2-C L5 GLONASS G1-C/A G2-C/A Galileo E1-BC E6 E5a E5b QZSS L1-C/A L2-C L5 Beidou B1 B2

SBAS L1 EGNOS / WAAS / MSAS

Scenario management strategy

There is to note the high degree of configurability of the simulator. The user can modify more than 1000 parameters to customize a simulation. To quickly manage user defined scenarios, StellaNGC has the following simulation scenario management strategy:

 Pre-defined scenario: StellaNGC is deployed with pre-defined scenario library. This allows the user to easily perform a simulation.  Loading scenario: the user has the ability to load supplied default scenario and/or load its own previously saved scenario.  Saving scenario: the user has the ability to save its scenario. It allows not having to reconfigure each parameter of each layer.

Trajectory Layer

The trajectory layer defines the motion and the attitude of the simulated mobile.

Date: 04/08/2020 Page: 25/60 The trajectory can be configured as follows:

 Open loop: in this case, the trajectory is defined in configuration mode (before the beginning of the simulation). The trajectory can be defined in several way and for several type of vehicle (terrestrial, special, ….). In the context of GATE4RAIL, the most appropriate trajectory description mode is to import files.

.3.1 GNSS Model

To be able to compute the GNSS model, the layer has to be configured. The GNSS model can be divided in several sub-models as shown hereunder: In the GNSS Infrastructure model, user has access to the following configuration:

 GNSS ground segment configuration: user can control what is going to be broadcasted as a navigation message by the simulated SV. User can auto-populate messages from an ephemeris file (such as RINEX).

Hardware Layers

The hardware layers comprise the modulation and physical layer. In a general way, these layers will be automatically operated by StellaNGC.

Simulated Satellite: By default, StellaNGC will be configured to generate 8 satellites per constellation

In order to allow synchronization:

 Internal 10MHz clock  External 10MHz clock input  1 PPS signal generation.

Vulnerabilities Options

The following sub-sections presents an overview of the vulnerabilities simulation of StellaNGC: Multipath and interferences.

Multipath

In GNSS, Multipath is the main sources of error as this effect changes in a random way, without correlation with space and time. The parameters which characterize a multipath are identified hereunder:

 The main parameter is the delay of the NLOS (Non-Line Of Sight) with the LOS (Line Of Sight) signal. This is equivalent to specify a Delta-Pseudorange.  Delta Doppler  Delta phase In StellaNGC, 3 types of multipath (namely 'User defined Model', 'Statistics Model', and '3D Scene Model'the latter is based on the integration of a 3D propagation, reflection and diffraction software named SE-NAV from OKTAL-SE and StellaNGC) models are proposed. For each of them, the GNSS Model will produce the GNSS Multipath Raw data identified in previous section.

Yet, as mentioned above, in GATE4Rail context, the impact of the local environment will be accounted thanks to 'local error models' (see section 4.1.2 and 4.1.3). As a consequence, multipath models of StellaNGC will not be used.

RFI interference

Interference can be classified in two parts: unintentional and intentional interference.

Unintentional Interference

Unintentional interference can directly be generated on the GNSS lower band (e.g. DME-TACAN at 962-1213MHz impacting L5/E5 GNSS band). They can be generated outside the GNSS band but with a high power which lead the harmonics on the GNSS band to be at a higher level that GNSS signals (e.g. the 14th harmonics of a VOR beacon at a 10km distance is still 40 dB above GNSS signals).

A short list of unintentional RF interference able to be generated by StellaNGC is given hereafter.  Center frequency: center frequency among all RFI will be generated. The reachable RFI generation frequencies are then combined with target bandwidth  Power level: maximum average power of all RFI combined. Once these parameters are defined, relative RFI power is linked to the hardware target dynamic Once target is configured, user can generate RFI and control for each of the RFI the following generic parameters:

 ON/OFF: enable/disable the RFI generation on-the-fly.

 Frequency shift: add on-the-fly a Frequency shift on the RFI.  Power level attenuation: control on-the-fly the power level of the RFI.

In addition, each of the RFI type has its own applicable parameters (e.g. for DME-TACAN pulse pair period).

Date: 04/08/2020 Page: 32/60

Hardware compatibility

The software is compatible with the following RF targets:

 VST second generation (NI-5840 in the second generation of Vector Signal Transceiver) o 500MHz instantaneous bandwidth on L Band: One RF stage is needed for multi-frequency management. o Calibrated target: the 5840 is factory-calibrated and can be yearly calibrated to ensure high end RF performance (e.g. IQ imbalance & frequency response); o List of calibration item can be found here http://zone.ni.com/reference/en-XX/help/374564L-01/calexec/procedure_5840/  VST first generation (NI-5644R and NI-5646R)  USRP-RIO (NI-2950R 120MHz)

UGE tool -error modelling in typical environments

As described with more details in D3.2 [ReD-5], the main source of errors is related to the environment surrounding the receiver and the impact that this last has on the signal reception. With the tool introduced here, GNSS performances are associated to typical environment in which it is supposed to perform. We can distinguish typical environment as open-sky, urban, peri-urban causing different errors on GNSS measurements.

The developed tool requires inputs that are:

-for each point of the trajectory, a description of the local environment (cf. classes proposed below), -a set of positioning error distributions (one per class).

The generation of these inputs requires on one hand, the labelling of every new trajectory with the environment labels.

On the other hand, for distribution availability, the following process has been performed:

-pre-labelling of samples with the surrounding environment of the track. As a first step, it requires manual identification of the track environment which can be done with google map. The complete route is divided into different regions representing the major proportion around the track. That can include open-sky, foliage and buildings in a first stage and more later. -Considering each of these areas, position estimates collected in previous projects are used with their associated ground truth in order to draw error distribution for each class of environment. These distributions are inputs for the tool as some are illustrated on The role of the tool is then, based on these inputs, to generate for any new trajectory, random errors along latitude and longitude axes in order to estimate a trajectory taken into account the corrupted reception of the signals. Error distributions have been chosen with a Gaussian shape for the first feasibility demonstration. This distribution shape reduces the probability of generating large errors contained in the distribution queues. These specific effects could be investigated with other models for queues or with complementary tools such as the one from GUIDE.

Guide tool -Local error modelling

Local errors have a non-negligible impact on PVT solutions estimated by the receiver. Their modelling can be quite difficult if the proper methodology, and a good dataset, is not used. As it is possible to observe in Figure 4.17 and Figure 4.18, the use of a unique PVT track does not permit to have a fair estimation of the GNSS errors caused by a bridge crossing. The analysis of multiple tracks, obtained under same GNSS conditions, enables a better comprehension of PVT errors and a better modelling.

The analysis of multiple PVT errors shows that these last ones are composed by two main components:

 Accuracy  Precision

Point Instant Time

This study aims to provide a simulation for "virtual receivers" in a certain position and instant. The parameters that can be customized by the user are described below.

Study Creation. GNSS Config

Constellation Constellation Type (GPS, Galileo, Both)

Almanac

With 4 options: -Current: using the most actual almanac.

-Online: connecting to the official webpage of the Navigation System. -Load: to load existing files in the system. -Closest: downloads the previous almanac related to the date of the analysis or uses the most closest from the files stored in NAVtools' default folder. This option is also available in the next step.

NAGUs/NANU

This field allows the user to load the folder in which status files are located, selecting the folder in which they are located (for this reason, the application does not shows the files included in that folder).

Acceptable Compliance

Defining the percentage of an acceptable compliance in a specified and an a subinterval

(

Point Temporal

This case covers an analysis for a certain position and embedded in a time frame selected by the user. This analysis is focused on performing a temporal analysis located on a predefined railway which has to be imported using the Railway Management Window. The parameters that can be customized are described in the following table: This analysis also covers the complete customization of the time schedule and the instants to be taken in consideration can be configured by the user. For more information, please check the previous section related to the Point-Temporal study.

Date: 04/08/2020 Page: 41/60

Run Track

This last case covers the analysis of a certain railway in which a specified passing instant has been defined for all its positions. The following explains how the GNSS4RAIL tool works and which are the parameters to select when launching a simulation for track characterization.

Railway

To choose between the imported railways, filtered by the ones that have associated time instants per position. After selecting this feature, the railway will be represented in NAVtools' GIS.

Select closest almanac

Selects the option "Closest" in the constellations selected in previous steps.

Date: 04/08/2020 Page: 45/60

Tools use cases

In this section the methodology and the application of the tools in a selection of scenarios of interest are presented. In particular, the description of how the tools defined in section 4.1 are configured and used to simulate and characterize the GNSS behavior in nominal condition and in presence of system vulnerabilities, limitations, global and local hazards is provided.

The primary GNSS-ETCS operational scenarios including Hazardous and System Fault situations have been defined in the context of WP2. In particular, in D2.2 document [ReD-2] three main railway environments that affect and/or impact the GNSS overall performance within a typical operational scenario have been identified: a) Open Sky Railway Operational Environment b) Restricted Railway Operational Environment c) Urban Railway Operational Environment

Taking into account the above outcomes of WP2, a selection of scenarios of interest in which the tools can be applied to characterise the GNSS performance in the railway operational environment has been carried. All the involved tools are applied in each scenario of interest based on the type of error that has to be simulated. In the context of WP3 only the tools related to the GNSS characterization in the railway environment are involved so mainly Module #3 tools and the GNSS4Rail tool from Module #2. The entire chain of the GATE4Rail platform, comprising all the modules and the related tools, will be taken into account in the context of WP4. -Mask: provides the 360 points of mask separated by commas (1º of resolution) for each point of the line. The information of the mask can be also represented graphically over the track to allow a quick and general overview of "red" zones or obscuration zones. The tool has been tested on a test scenario on a railway line in Spain. The line presents two overpasses on the entire route. Results on both bridges, estimated for 10 iterations, show that the tool is able to read on the environmental info file the presence of obstacle and to fairly reproduce GNSS error impact due to the presence of these lasts.

M3SB tool application

In the following sections are provided for each test scenario described in The mathematical expression of the upward chirp signal whose frequency is increasing as time passes along the pulse is given as:

Where:

 f0 is the starting frequency, which value is comprised in L-band  T is the pulse width, this will be a user-defined parameter  K is the chirp rate, its value is related to the frequency bandwidth and to the pulse width through the formula: 𝐾=𝑓1-𝑓0𝜏 f1 is the final frequency reached in one pulse  n is an integer, which defines the number of pulses.

Date: 04/08/2020 Page: 56/60 This deliverable is the first report delivered by GATE4Rail WP3. The general objective of WP3 was to define a comprehensive methodology and the associated tools able to characterise the GNSS performance into the railways application scenarios defined in WP2 in the framework of a VB detection in ETCS/ERTMS context.

Taking advantage from the well-known experience derived from past and ongoing projects on GNSS application in the rail domain, a reference GNSS database that includes the parameters to be tested to consider the effect of local and global hazards and the raw data to be used to process the PVT solution has been defined.

The methodology and the tools of the Consortium included in the GATE4Rail simulation and verification infrastructure able to characterize the GNSS in the rail domain considering different environment crossed by train along railway track ride have been identified and described.

Finally, results about the application of the tools in a selection of scenarios of interest in nominal condition and in presence of system vulnerabilities, limitations, global and local hazards have been presented.

These findings should be used as input to the WP4 dedicated to the detailed design of the GATE4Rail simulation and verification platform.

3. 1

 1 .1.2 Selection of measurements relevant for the database definition ...................................... 3.1.2 STARS ....................................................................................................................................... 3.1.2.1 Assumptions ........................................................................................................................ 3.1.2.2 Selection of measurements relevant for the database definition ...................................... 3.1.2.3 Database structure .............................................................................................................. 3.1.2.4 Accessibility ......................................................................................................................... 3.1.3 ERSAT GGC ...............................................................................................................................

3. 2

 2 .1.3.1.2 Generation of the models In order to estimate the position, we have used RTKLib, an open source software to process GNSS observation (GPS and Galileo) recorded in the RINEX format. For the parameter setting, the positioning mode is set to 'Single' that implements least square solution for the position computation. All other parameter selected for the position estimation are shown in figure 3.1. Kalman Filter can be applied by changing the positioning mode to 'Kinematic' in RTKLib.

Figure 3 . 1

 31 Figure 3.1 Settings available with RTKLib

Figure 3 . 2 -

 32 Figure 3.2 -Examples of GNSS receiver PVT behaviour under bridgesFigure 3.2 shows that for all analysed bridges the behaviour of the PVT solutions is always similar. We note:  a dispersion of the trajectories starting in the first epoch under the bridge and continuing until the receiver is still under the obstacle.

Figure 4 .

 4 Figure 4.1 StellaNGC Layer Approach

Figure 4 .

 4 Figure 4.2 StellaNGC Main GUI

Figure 4 .

 4 Figure 4.3 Trajectory Configuration User Interface

  Three options are accessible: o NMEA (GGA) o KML o Formatted file (ECEF frame)  Close-loop: In this mode, the user defines the TCP/IP port from which StellaNGC receives the motion information. The provided data information can be basic or further detailed: o Position stimuli, including one or several parameters out of:  Used Reference for position (among ECEF, ECI, LLA_WGS84, LLA_MSL)  Used Reference for dynamics (among ECEF, ECI, NED, Front/Right/Below)  Position  Speed  Acceleration  Jerk o Attitude stimuli, including one or several parameters out of:  Attitude  Angular Velocity  Angular Acceleration  Angular Jerk  Multi-trajectory: the user can define two different and independent trajectories. The typical use case is the simulation of relative and differential correction (stations and rover). 4.1.1.1.3 Model Layer The model layer computes from the trajectory data the relevant mathematical models for GNSS and IMU sensor. Date: 04/08/2020 Page: 26/60 4.1.1.1

Figure 4 . 4

 44 Figure 4.4 GNSS Model Overview

Figure 4 .

 4 Figure 4.5 StellaNGC GNSS ground segment configuration

Figure 4 .

 4 Figure 4.6 StellaNGC GNSS Space Segment Configuration In the GNSS Signal Perturbations Models, user has access to the following configurations:  Atmospheric perturbations Models: o Ionosphere Perturbations  Klobuchar,  Nequick,  IONEX file,  user-defined file o Troposphere Perturbations (MOPS)  Multipath Model: for more information, please refer to section 4.1.1.1.5.1: o User defined multipath o Statistical multipath o 3D scene determinist multipath  Earth Obscuration Model: elevation mask (including dynamic elevation masks)

Figure 4 .

 4 Figure 4.7 StellaNGC GNSS Perturbation Model Configuration In the GNSS Local models, user has access to the following configuration:  Rx Antenna: gain and polarization, off-axis, antenna mispointing  Multi-antenna

Figure 4 .

 4 Figure 4.8 StellaNGC GNSS Local Model configuration 4.1.1.1.3.2 IMU Model In order to address hybridization challenges, StellaNGC implements an Inertial Measurement Unit (IMU) sensor simulation. The IMU sensor embeds 2 types of sub-sensor simulation: gyroscope and accelerometer. As shown hereunder, this model will then give at the output the linear acceleration and angular velocity.

Figure 4

 4 Figure 4.9 IMU Model Overview

Figure 4 .

 4 Figure 4.10 StellaNGC IMU Model Configuration 4.1.1.1.4 Hardware LayersThe hardware layers comprise the modulation and physical layer. In a general way, these layers will be automatically operated by StellaNGC.

  4.1.1.1.5.1.1 Stella NGC GNSS Model and multipath Among the different layers of StellaNGC the GNSS Model layer (see section 4.1.1.1.3) is responsible for generating the GNSS Raw data (Pseudorange, Doppler, Navigation message etc. for each service, satellite, Date: 04/08/2020 Page: 30/60 constellations, receiver antenna and trajectory). The computation is based on the configuration and control of the model and the input trajectory.

Figure 4 .

 4 Figure 4.11 Stella GNSS Model synoptic

Figure 4 .

 4 Figure 4.12 Software User Interface User can configure the hardware target with the following parameters:

Figure 4

 4

Figure 4 .Figure 4 .

 44 Figure 4.13 Error database creation process

Figure 4 .

 4 Figure 4.15 Simulated track generation

Figure 4 .

 4 Figure 4.16 shows some example of 3 simulated track errors on a reference track.

Figure 4 .

 4 Figure 4.16 Real track error vs simulated track error (over-bounding errors)

Figure 4 .

 4 Figure 4.17 Single PVT track (cyan/blue) after a bridge crossing

Figure 4 .

 4 Figure 4.18 Multiple PVT tracks (cyan/blue) after bridge crossing

Figure 4 .

 4 Figure 4.19 PVT errors accuracy and precision examplesThe estimation of the two components allows obtaining better trajectory reproductions in presence of obstacles.4.1.3.1 "Record & Replay" Modelling MethodologyIn order to have a fair modelling of PVT errors in presence of certain obstacles, GUIDE relies on the "Record & Replay" methodology. This allows obtaining multiple PVT solutions coming from the same GNSS receiver, or a batch of the same model, under identical GNSS conditions, identical carrier dynamic and environment characteristics.The methodology can be resumed in four main parts:

  4.1.4.2 Study Types/Positioning & TimingAfter defining the constellations to be used, next step is the selection of the name's and type's study. There are four types of studies based on time/space variables.

Figure 4 .

 4 Figure 4.22 Point Instant Time Study.

Figure 4 .

 4 Figure 4.23 Point Temporal Study.

Figure 4 .

 4 Figure 4.24 Track Temporal Study.

Figure 4 .

 4 Figure 4.25 Run Track Study

4.1. 4 . 3

 43 Terrain and environmentIn GNSS4RAIL Simulations window, you can check the compliance of terrain data with the configured study. This tool can also use a selection of obstacles clicking on Obstacle Selection button and selecting the obstacles created in the Obstacle Editor plugin and will offer the user the minimum requirement to perform and accurate analysis in terms of the resolution of the DTM/DSM that must be implemented.

Figure 4 .

 4 Figure 4.26 3D model management

Figure 4 .

 4 33 depicts the simulation framework and the interaction between the different tools for the scenarios simulations. Detailed information about the interfaces and input data required by each tool are provided in D4.2 [ReD-4]. Date: 04/08/2020 Page: 46/60

Figure 4 .

 4 Figure 4.35 Code of mask file

Figure 4 .

 4 36 shows an example of La Alhondiguilla station in the Spanish line.

Figure 4 .

 4 Figure 4.36 Graphical mask over the track

Figure 4 .

 4 Figure 4.37 Graphical mask close to a mountain

Figure 4 .

 4 Figure 4.38 Environment identification on the test scenario a. open-sky, b. forest/foliage.

Figure 4 .

 4 Figure 4.39 Tool results for the open-sky region present on the line

Figure 4 .

 4 Figure 4.40 Tool results for the Tree/Foliage region present on the line

Figure 4 .

 4 Figure 4.41 -Overpasses identification on test scenarioThe tool has been executed ten times on the same scenario to analyse the ability to reproduce aleatory behaviour of GNSS receivers in this passing under obstacles. Next figure provides obtained results.

Figure 4 .

 4 Figure 4.42 -Tool results for the 1 st overpass present on the line

Figure 4 .

 4 Figure 4.43 -Tool results for the 2 nd overpass present on the line

4. 2

 2 .4.1.1 Reference scenario The reference scenario is the simulation of reference trajectory without adding any errors. Hereunder are the configuration parameters used for Stella-HIL. 1. Constellation -L1(E1), SBAS 2. RINEX File for GPS (Galileo) 3. RINEX File for SBAS 4. GPS Time -time according to RINEX 5. Trajectory Model -Trajectory XYZ File Date: 04/08/2020 Page: 54/604.2.4.1.2 Jamming LFM (Linear Frequency Modulation) and WGN (White Gaussian Noise) jamming signals are chosen as they have significant impact on GNSS receiver. Also, these kinds of jammers are widely available in the market (an example of typical jammer is depicted in Figure4.44 ). Also, there are radars using chirp (LFM) pulses which can occupy the entire L band.

Figure 4 .

 4 Figure 4.44 Typical in-car chirp jammers Personal Privacy Devices4.2.4.1.2.1 LFM -Linear frequency modulationThe first test is the adding of chirp jamming signal using Stella-ITF on top of GNSS signal simulated by Stella-HIL. The common waveform is the LFM pulse, also known as the chirp pulse. The chirp waveform, which is shown in Figure4.45, is repeated every 𝑇 intervals. 𝑇 is called the pulse repetition interval or pulse repetition period; its inverse gives the pulse repetition frequency.

Figure 4 .Date

 4 Figure 4.47 ITF power profile The following interference parameters have been used:  Frequency: L1/E1  FM sweep time: 0,000156s  Frequency Shift (BW) -40MHz

Figure 4 .

 4 Figure 4.48 Eccentricity Semi-major axis information in RINEX file 4.2.4.1.4 SIS failure -Clock fault The clock scenario is used to define one or more clock variation events relating to one or more satellites. This permits to finely control the satellite clock behaviour. The scenario is composed of the following information:  Clock Bias (s) --50 * 10  Clock Drift (s/s) -0  Clock Drift Rate (s/s²) -04.2.4.2 Test Scenario Description for Restricted EnvironmentThe reference scenario is the simulation of reference trajectory which already includes errors corresponding to restricted environments like:  Tunnels and Cuttings  Other Infrastructures (Industrial Areas, Airports etc.)  Woods/Forests  Mountains and Canyons

  Contents Executive summary............................................................................................................................................ Contents ............................................................................................................................................................ 1 Scope ......................................................................................................................................................... 1.1 Purpose and Applicability .................................................................................................................. 1.2 Reference Documents ....................................................................................................................... 1.3 Related Documents ........................................................................................................................... 1.4 Terms, Acronyms and Abbreviations ............................................................................................... 1.5 Disclaimer excluding JU responsibility ............................................................................................. 1.6 Description of Changes from the Previous Revision ....................................................................... 2 Introduction .............................................................................................................................................

3 Standardised Database for GNSS characterization in the railway ........................................................... 3.1 State of the art of past and on-going projects ................................................................................ 3.1.1 RHINOS .................................................................................................................................... 3.1.1.1 Assumptions ........................................................................................................................

  Figure 4.17 Single PVT track (cyan/blue) after a bridge crossing ....................................................................Figure 4.18 Multiple PVT tracks (cyan/blue) after bridge crossing .................................................................Figure 4.19 PVT errors accuracy and precision examples ............................................................................... Figure 4.20 Study case ..................................................................................................................................... Figure 4.21. GNSS Configuration. ....................................................................................................................Figure 4.22 Point Instant Time Study. .............................................................................................................Figure 4.23 Point Temporal Study. ..................................................................................................................Figure 4.24 Track Temporal Study. ..................................................................................................................Figure 4.25 Run Track Study ............................................................................................................................Figure 4.26 3D model management ................................................................................................................Figure 4.27 Results of the tool GNSS4RAIL ......................................................................................................Figure 4.28 GIS representation in Point Instant Studies. ................................................................................Figure 4.29 Point/Track Temporal Study Results. ...........................................................................................Figure 4.30 Point/Track Temporal Study Result Stage. ...................................................................................Figure 4.31 Point/Track Temporal Study Results -GIS View .......................................................................... ........................Figure 4.36 Graphical mask over the track ......................................................................................................Figure 4.37 Graphical mask close to a mountain ............................................................................................Figure 4.38 Environment identification on the test scenario a. open-sky, b. forest/foliage. .........................Figure 4.39 Tool results for the open-sky region present on the line .............................................................Figure 4.40 Tool results for the Tree/Foliage region present on the line ....................................................... LFM) pulse radar with 𝐾 = 1012 ...............................................................................Figure 4.47 ITF power profile ..........................................................................................................................Figure 4.48 Eccentricity Semi-major axis information in RINEX file ................................................................Figure 4.49 Scenario illustration: reference scenario includes multipath .......................................................Figure 4.50 Scenario illustration -reference scenario includes EMI ...............................................................Figure 4.51 Scenario illustration: reference scenario includes foliage attenuation error .............................

	Figure 4.41 -Overpasses identification on test scenario ................................................................................
	Figure 4.42 -Tool results for the 1 st overpass present on the line .................................................................
	Figure 4.43 -Tool results for the 2 nd overpass present on the line ................................................................
	Figure 4.44 Typical in-car chirp jammers Personal Privacy Devices ................................................................
	Figure 4.45 Chirp (LFM) pulse radar 𝐾 = 1012 ..............................................................................................
	Figure 4.46 PSD chirp (

Figure 3.1 Settings available with RTKLib ........................................................................................................ Figure 3.2 -Examples of GNSS receiver PVT behaviour under bridges ..........................................................

Figure 4.1 StellaNGC Layer Approach ..............................................................................................................

Figure 4.2 StellaNGC Main GUI ........................................................................................................................

Figure 4.3 Trajectory Configuration User Interface .........................................................................................

Figure 4.4 GNSS Model Overview ....................................................................................................................

Figure 4.5 StellaNGC GNSS ground segment configuration ............................................................................

Figure 4.6 StellaNGC GNSS Space Segment Configuration ..............................................................................

Figure 4.7 StellaNGC GNSS Perturbation Model Configuration ......................................................................

Figure 4.8 StellaNGC GNSS Local Model configuration ...................................................................................

Figure 4.9 IMU Model Overview .....................................................................................................................

Figure 4.10 StellaNGC IMU Model Configuration ............................................................................................

Figure 4.11 Stella GNSS Model synoptic ..........................................................................................................

Figure 4.12 Software User Interface................................................................................................................

Figure 4.13 Error database creation process...................................................................................................

Figure 4.14 Histogram and error distribution .................................................................................................

Figure 4.15 Simulated track generation ..........................................................................................................

Figure 4.16 Real track error vs simulated track error (over-bounding errors) ................................................ Date: 04/08/2020 Page: 7/60 Figure 4.32 Run Track -KML Exporting. ..........................................................................................................

Figure 4.33 Tools application chain .................................................................................................................

Figure 4.34 Mask generation screen ...............................................................................................................

Figure 4.35 Code of mask file ..................................................................................................

  GNSS Parameters. ............................................................................................................................... Table 7 Point Instant Time Study Parameters. ................................................................................................ Table 8 Point Temporal Study Parameters. ..................................................................................................... Table 9 Track Temporal Study Parameters ..................................................................................................... Table 10 Run Track Study Parameters .............................................................................................................

	Table 1 Reference Documents ..........................................................................................................................
	Table 2 Related Documents .............................................................................................................................
	Table 3 Terms, Acronyms and Abbreviation ...................................................................................................
	Table 4 Errors distribution for each environment ...........................................................................................
	Table 5 GNSS signals available for GATE4Rail .................................................................................................
	Table 6 Date: 04/08/2020	Page: 8/60

Table 11

 11 Tools use cases .................................................................................................................................. Table 12 Type of local obstacles ...................................................................................................................... Table 13 GNSS4RAIL mask report in .csv .........................................................................................................

	Date: 04/08/2020

Table 3

 3 Terms, Acronyms and Abbreviation

  Time tag information (TOW and week or GPS Time or UTC time)  Code phase measurements or pseudo ranges in meters  Carrier phase measurements in cycles or accumulated Doppler in meters  Doppler frequency in Hz  Carrier-to-Noise ratio

 Loss of lock indicator  GPS/ Galileo/ GLONASS Navigation message or ephemeris data  Satellite elevation and azimuth or satellite position  Position and velocity in 3D ECEF Cartesian coordinate system  Position and velocity in geodetic coordinates  DOP values (VDOP, HDOP, PDOP, TDOP)  SBAS decoded data

Table 4

 4 Errors distribution for each environment

  2.1.3.3.3 GNSS ParametersAnother set of key parameters is the list of GNSS signals to be simulated. Stella NGC can generate most of From the GNSS simulation point of view, AIMN is nothing more than a GNSS simulation for which the trajectory consists in a static point (the antenna position of the ground station receiver). In this respect, what will be required in terms of AIMN configuration is: Local errors will provided by the local error tools (see sections 4.2.2 and 4.2.3). As mentioned, the effects of local errors are accounted for in the PVT domain. This implies that local errors will be modelled based on the addition of errors on the input trajectory (see D3.2 [ReD-5] for more details). In this context, what will be requested during the definition of the simulation is to choose whether or not they want to activate the local errors models that accounting for the local environment and that accounting for the local infrastructure. It is worth to remind that both models can be used separately or together.

	3.2.1.3.3.4 AIMN
	 the number of AIMN station to be considered;
	 the location of each AIMN station;
	 the GNSS parameters (i.e., the GNSS constellation and signals to be considered -see above) for each
	AIMN station.
	3.2.1.3.3.5 Local Errors
	3.2.1.3.3.6 Satellite visibility (local environment impact)
	Date: 04/08/2020	Page: 20/60

the existing GNSS signals (almost all frequencies of all GNSS constellations -see the list of signals available in Table

5

). It will be to the end-user to select which are the constellations (GPS, GALILEO, GLONASS and/or BEIDOU) of interest for its scenario and which signals have to be generated for each constellation (e.g.: L1 and L5 for GPS, E1 only for GALIELO, no signals for GLONASS nor for BEIDOU).

  has a set of data from a pre-campaign for ERSAT GGC project. These GNSS data were recorded in March 2019 in the Atlantic Axis (North West of Spain). Local errors are mostly due to tunnels and terrain obstruction of satellites (mountainous region). the tools for local error modelling. It is responsible for the generation of synthetic GNSS signals and observables both in nominal and faulty conditions injecting global (e.g. satellite clock or ephemeris error, ionospheric degradation) and local hazards (multipath, signal blockage, interferences) on GNSS signals. The GNSS4RAIL tool from Module #2 is responsible to provide geometry and availability of GNSS satellites (GPS, GALILEO or GPS+GALILEO) along the train trajectory considering the specific track environment and the labels for different types of local obstacles located in the path followed by the train.M3 Systems commercializes a complete GNSS suite, named StellaNGC®, dedicated to GNSS receivers test and validation. StellaNGC®is a GNSS Radio Frequency simulation platform enabling to feed by cable GNSS device under test. The key advantages of simulation testing against real live testing is that simulation provides a fully controlled environment (both in terms of satellite signals and the environmental conditions) and complete repeatability of the tests. It also enables testing non-nominal conditions or unlikely events and scenarios. The main scenario parameters that users can defined in StellaNGC® are:

	4.1.1 M3SB tool -StellaNGC®
	4 Simulation framework and tools application methodology
	4.1 Tools definition

GUIDE has used as database a series of field tests where GNSS signals have been digitized. Among them the most important field test concerns a test campaign done in April 2017 on the regional railway line between the villages of Rodez and Albi in the south of France. Other test campaign, done on normal roads and using a car, have been used to validate the developed tool. UGE has used several databases acquired during the STARS project (2016-2018) and in particular the data acquired in Switzerland. The complete route is 163 km long with nearly 3 hours of measurements. It has used odometry and Eurobalise system to estimate the ground truth [ReD-3]. The track incorporates several environments such as spares trees, forests, tunnels, trenches, bridges and buildings.

INECO

This section describes the GATE4Rail simulation tools, included in the GATE4Rail test-bed and already available in the GNSS labs, that are strictly related to the GNSS characterization in the railway domain: all tools available in the Module #3 and GNSS4RAIL tool from Module #2. Module #3 includes the StellaNGC Date: 04/08/2020 Page: 22/60 simulator and

  At the output of the trajectory layer (software) is available in real time the mobile motion (3D position, speed, acceleration, radial position, radial speed and radial acceleration)  At the output of the GNSS model layer (software) is available in real time every channel GNSS raw data  At the output of the IMU (Inertial Measurement Unit) model layer (software) is available in real time the IMU sensor raw data (gyroscope, accelerometer and magnetometer)  At the output of the GNSS modulation layer (hardware) is available in real time the I/Q (4bits wide) on the hardware target DIO (Digital Input/Output) The intermediate data of the software layer are broadcasted in multicast UDP via protobuf protocol.

	Constellation Frequency/Signal	Frequency/Signals
	GPS
	4.1.1.1.1.3 GNSS Constellation
	Hereunder are presented the simulated GNSS frequencies/signals:
	Date: 04/08/2020	Page: 24/60

4.1.1.1.1.2 Layer approach and intermediate data StellaNGC is based on a layer approach. At the output of each layer are available intermediate data: 

Table 5

 5 GNSS signals available for GATE4Rail

  Intentional interferencesIntentional RF interferences are generated by various devices in order to jam with the GNSS signal, this can be done for example to deny the GNSS service. The following of waveform can be used to simulate jamming attempt: Multi-tone  Spread-spectrum o Direct Sequence Spread Spectrum (DSSS) o Frequency Hopping Spread Spectrum (FHSS) o Time Hopping Spread Spectrum (THSS)  White Noise interference 4.1.1.1.5.2.3 Software Interface M3 Systems RF Interference generator is a standalone application. Example of the User interface is shown below.

	4.1.1.1.5.2.2
	 DME/TACAN: DME (Distance Measurement Equipment) and TACtical Air Navigation
	 VOR: VHF Omni Directional Radio Range (VOR)
	 ILS: Instrument Landing System (ILS)
	 Primary Radars: the most commonly used radar waveforms are:
	o Continuous wave (CW)
	o Frequency Modulated Continuous Wave (FMCW)
	o Short pulse
	o Chirp (Linear Frequency Modulated [LFM]) pulse
	 Secondary Radar
	 JTIDS/MIDS: The Joint Tactical Information Distribution System / Multifunctional Information
	Distribution System (JTIDS/MIDS)
	 Wind profiler
	 Amateur Radio
	Date: 04/08/2020	Page: 31/60

Table 6 GNSS

 6 Parameters.

  valid minutes per hour/hour per day). It is not available for Point Instant Analysis.

	Min. Satellites	Minimum number of satellites.
	Max. HDOP	Maximum HDOP allowed.

Date: 04/08/2020 Page: 39/60

Table 7

 7 Point Instant Time Study Parameters.

Table 8

 8 Point Temporal Study Parameters.

	Date: 04/08/2020

Table 9

 9 Track Temporal Study Parameters

Table 10 Run

 10 Track Study Parameters

  Table 11 summarizes the selected use cases in term of:  operational environments (to cover some of the GNSS signal cases of study considered in WP2)  local and global effects to be simulated (global error, multipath, interference…)  type of GNSS fault condition (i.e. local or global)  scenario description For each operational environment described in Table11, a reference scenario is defined and used to benchmark the other scenarios belonging to the same environment type. Each scenario addresses only one error type (i.e. local or global) so that it is possible to isolate its effect and made a comparison with the reference scenario.

The following local and global faults are simulated:

 local fault due to obstacles (e.g., scenarios 20, 24 or 30 as well);  Local faults not due to obstacles (e.g., scenarios 11 and 21 as well);  Global errors (e.g., scenarios 12, 13, 22 and 23 as well).

  Table 11 the parameters and configuration used by StellaNGC tool. 4.2.4.1 Test Scenario Description for Open Sky Environment With reference to Table 11, Stella-HIL simulation sequence of the tests for open sky environment is the following:

	 Reference scenario with no errors
	 Jamming
	 Multiple Ephemeris faults
	 Clock Error

Date: 04/08/2020

Page: 15/60 the tracks and train runs performed for analysis. In particular, the SFTP repository structure of ERSAT GGC project mainly contained three types of data:

 Raw measurements & standard format data/Input data as defined in section 3.1.3.2  Intermediate Data (i.e. the outputs of each detection methods)  Classification Data (i.e. the final output of the classification process)

The classification output data were generated in terms of:

 A database containing the coordinates of each point and its classification  KML (Keyhole Markup Language) file for each track component for that allows the visual representation of the classification results through 3rd party applications.

VITE

3.1.4.1 Assumptions VITE (VIrtualisation of the Testing Environment) research project aims at reducing signalling onsite tests to a minimum while ensuring that laboratory tests can serve as evidence for valid system behaviour and are accepted by all stakeholders involved in the placing in service process. To achieve the main goal of VITE project of shifting as many tests as possible to the laboratory, it is mandatory to enable the complete reproduction of the rail project information in the laboratory. To facilitate this achievement, it is desirable to agree on a common format for such data. On VITE Deliverable D3.3 Description of the project data format, some available formats are discussed and compared.

VITE project also considers the importance of scalability in signalling data formats and the capability of hosting a variety of information along the track and its surroundings, as can be GNSS data in GATE4Rail. This turns the VITE documentation into a relevant source to be taken into account.

Database definition

The main contribution from VITE might be the data hierarchy relying on the topology description of the track. The organization of data following that structure would ease the integration of the navigation data with the ETCS signalling information. See reference [ReD-6] for further details.

Standardised GNSS Database definition

In order to define a GNSS standardised database that can be used to characterize the GNSS reception in the railway environment it is necessary to identify the parameters and measurements to be tested in order to consider the effects of the railway environment (local and/or global) on the receiver processing and the raw data to be used to process the PVT solution.

GNSS technologies are influenced by global as well as local hazards. By definition, global hazards will be shared by a large panel of users and are today well defined by global systems. Local hazards are caused by the infrastructure or vegetation around the track that creates blockages or multipath but also by interferers (intentional as well as non-intentional) that can degrade accuracy, availability and integrity of the GNSS solution.

The railway environment includes rules and equipment that can introduce other vulnerabilities to the signal reception, like EM (Electro Magnetic) interferences from external sources and locomotive, multipath both from trackside objects and from objects near locomotive roof mounted antenna and obstacles as tunnels, canyons that can reduce/block satellites visibility.

Date: 04/08/2020 Page: 36/60 1. Field test for digitization of GNSS signals and determination of the "Ground truth". 2. Replay of the digitized GNSS signals on one, or more, GNSS receivers. 3. Analysis of PVT errors with respect to the "ground truth" to estimate the trueness and the precision of the GNSS receiver in presence of a defined obstacle. The error distribution as their time correlation must be identified as well. 4. Modelling of the PVT errors enabling the reproduction of multiple trajectories.

The errors can be directly injected on the ground truth. Previous errors state, before the obstacle crossing, must be considered as well to avoid anomalous jumps in the whole trajectory.

Modelling Examples

The following figure just shows the first attempt to model PVT errors component for a bridge crossing on peripheral road.

INECO tool -GNSS4RAIL

The main objective of GNSS4RAIL is the simulation-based calculation of satellite visibility and geometry parameters considering railways environment in terms of natural and artificial obstacles. Both constellations (Galileo and GPS) can be assessed so far for analysing geometry and number of visible satellites at each point and at any time of the track. Simulation tool is useful for past scenarios or for future predictions.

GNSS Configuration

The GNSS parameters can be customized in this stage choosing between GPS, Galileo or both constellations working jointly. For each constellation, the configuration parameters are described below:

Results

Depending on the type of study that has been launched, the application will show different views of the results, but always with the criteria shown below:

 Green: the sample meets the minimum criteria.  Red: the sample does not meet the minimum criteria.  Grey: There is no digital model available or the digital model available is not accurate enough. A table that represents the visibility or non-visibility of satellites from some points of the track can be obtained from the GNSS4RAIL simulation tool as a result of environmental obstacles.

The GIS interface will also be updated with the current analysis, offering the direct link between the station and the satellites and highlighting the best HDOP combination and the non-included obstacles due to terrain, obstacles and operational limitations. The railway that has been analysed is also represented in the GIS, showing all the positions that have been studied and coloured according to their final result. This interface also allows the user to export different reports based on the results by pushing the button:

 Report: a predefined report in CSV format including information about the position of the sample, the date of application, the calculated result (0 for valid, 1 for no valid and NA for a non-conformance with DTM/DSM availability or accuracy).  Railway: the positions (including all the samples defined in the study) in a CSV format.  KMZ: a compatible document with Google Earth that includes the railway profile and the samples with information about the result in their description. The following type of local obstacles labels are provided by the GNSS4Rail tool for the path followed by the train: The following sub-sections describe how each tool has been applied in the selected scenarios and the achieved results.

INECO tool application

GNSS4RAIL simulation tool is used to calculate which is the satellites' visibility and geometry for each point of the line taking in consideration a 3D model of the environment and to provide obstacles identification information.

Outputs of GNSS4RAIL feeds Module #3, providing data that UGE and GUIDE tools will use to generate the appropriate error models to be injected in the StellaNGC simulator as well.

Date: 04/08/2020 Page: 48/60 GNSS4RAIL generates a report with environment data to be considered for a Line-of-sight analysis of the GPS or/and Galileo satellites. Finally, this data is provided in a "static way", isolated of time, for a specific line or line section, by providing the "terrain mask" that is blocking the satellites. Figure 4.34 shows the tool screen to generate the mask. The tool is capable to generate the mask of a line (if line coordinates are known and the 3D environment model is accurate enough) and this simulation is valid while natural or artificial obstacles do not change.

A simulation for Spanish line has been launched using the file "AE-Circulation Antenna 3D-Speed profile-100-20200508-080000-nlos" provided by CEDEX tool of Module #2. With the aim of interfacing with the rest of the platform tools, the main output of GNSS4RAIL is provided in a .csv report, addressing the following data: The used signal power profile is hereunder described and depicted in

Test Scenario Description for Local and Urban area railway environment

The reference scenario is the same as the reference scenario for Restricted Railway Environment. The difference is that the parameters used for the local error models are adapted.

In this case Stella-HIL has the same configurations as in section 4.2.4.1.1 expect it should have separate XYZ files for each of these errors:

 Multipath -presence of obstacles (light, severe)  Presence of unintentional EMI  Foliage attenuation by presence of trees It is to be noted that these XYZ errors files will be different from those of section 4.2.4.2.