gnss automated virtualized test environment for rail
TRANSCRIPT
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
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
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: 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
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: 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
Table 11: Module #4 Function decomposition ............................................................................................................... 38
Table 12: Module #5 Function decomposition ............................................................................................................... 41
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: 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).
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: 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
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: 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
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: 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).
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: 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
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: 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
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: 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.
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: 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
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: 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
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: 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.
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: 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.
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: 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
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: 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
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
GSM-R (Euroradio)
Option 2:3G/4G/5G
EVC
RBC
SIS Data Virtual Balise Reader ETCS OBU
Augmentation data received from EGNOS/Local AIMN.
Triggerof Virtual Balise
Information
Odometry information
ERTMS/ETCS OB
ERTMS/ETCS Trackside
TrainGNSS VBR ERTMS/ETCS OB
GNSS SIS
EGNOS SISGNSS
receiver
PVT EngineTrack Maps
3D -> 1DProtection Level
Triggerof Virtual Balise
Information
RBC
RBC
Atmosphere
SIS Data Virtual Balise Reader ETCS OBU
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
Aug. Info. from Trackside
Odometry information
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: 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).
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: 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.
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: 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.”
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: 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.
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: 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
Title Description Proof of Concept Compliance
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
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: 23/43
Requirement ID
Title Description Proof of Concept Compliance
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
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: 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
Title Description Proof of Concept Compliance
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
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: 25/43
Requirement ID
Title Description Proof of Concept Compliance
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
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: 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.
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: 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
ERTMS/ETCS Trackside
TrainVBR ERTMS/ETCS OB
GNSS SIS
EGNOS SISGNSS
receiver
PVT EngineTrack Maps
3D -> 1DProtection Level
RBC
IMU Sensors
Aug. Info. from Trackside
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.
Triggerof Virtual Balise
Information
Odometry information
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: 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
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: 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).
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: 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].
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: 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
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: 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
External: Not foreseen
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: 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
External: Not foreseen
External: Not foreseen
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
External: Not foreseen
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
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: 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
External: Not foreseen
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
External: Not foreseen
External: Not foreseen
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
External: Not foreseen
External: Not foreseen
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: Not foreseen
External: Report
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: 35/43
8.2 Module #2 The module #2 functional decomposition is shown in Table 9.
Table 9: Module #2 Function decomposition
Code Name Description Input Output
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: Not foreseen
Internal: 2.1.2
External: Global Track Info DB
External: Not foreseen
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
External: Not foreseen
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
Internal: Not foreseen
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
Internal: Not foreseen
External: Not foreseen
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
Internal: Not foreseen
External: Not foreseen
External: Module#5
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: 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.
Table 10: Module #3 Function decomposition
Code Name Description Input Output
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: Not foreseen
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: Not foreseen
Internal: 3.1.6
External: Local hazard DB
External: Not foreseen
3.1.3 Ground truth GNSS reading
This function is responsible for reading the GNSS ground truth data
Internal: Not foreseen
Internal: 3.1.6, 3.3.1
External: Module #2
External: Not foreseen
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: Not foreseen
Internal: 3.1.6
External: Module #2
External: Not foreseen
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
External: Not foreseen
External: Not foreseen
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: 37/43
Code Name Description Input Output
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
External: Not foreseen
External: Not foreseen
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: Not foreseen
Internal: 3.2.2
External: Characteristics of the network
External: Not foreseen
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: Not foreseen
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: Not foreseen
External: Module #4
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: 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.
Table 11: Module #4 Function decomposition
Code Name Description Input Output
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: Not foreseen
Internal: 4.1.4, 4.1.5, 4.1.6
External: Module #3
External: Not foreseen
4.1.2 Navigation data import
This function is responsible for importing ephemeris data
Internal: Not foreseen
Internal: 4.1.4, 4.1.5, 4.1.6
External: Module #3
External: Not foreseen
4.1.3 EGNOS messages import
This function is responsible for importing EGNOS data
Internal: Not foreseen
Internal: 4.1.5, 4.1.6
External: Module #3
External: Not foreseen
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
External: Not foreseen
External: Not foreseen
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
External: Not foreseen
External: Not foreseen
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
External: Not foreseen
External: Not foreseen
4.1.7 Augmentation Data Gateway
This function is responsible for Augmentation data delivery to the OBU
Internal: 4.1.6
Internal: Not foreseen
External: Not foreseen
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
Internal: Not foreseen
External: Not foreseen
External: OBU GNSS Processing (4.2.4)
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: 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: Not foreseen
Internal: 4.2.7, 4.2.8
External: Module #3
External: Not foreseen
4.2.2 Navigation data import
This function is responsible for importing ephemeris data
Internal: Not foreseen
Internal: 4.2.7, 4.2.8
External: Module #3
External: Not foreseen
4.2.3 Augmentation data import
This function is responsible for importing Augmentation data received by the AIMN GNSS processing block
Internal: Not foreseen
Internal: 4.2.7, 4.2.8
External: AIMN GNSS Processing (4.1.7)
External: Not foreseen
4.2.4 Integrity info import
This function is responsible for importing integrity information received by the AIMN GNSS processing block
Internal: Not foreseen
Internal: 4.2.7, 4.2.8
External: AIMN GNSS Processing (4.1.8)
External: Not foreseen
4.2.5 IMU data import This function is responsible for importing IMU data received by the IMU observations generator
Internal: Not foreseen
Internal: 4.2.7 (in case of multi-sensor ARAIM), 4.2.8
External: IMU observations generator (4.3.4)
External: Not foreseen
4.2.6
Local Track info import
This function is responsible for importing the information about the track database
Internal: Not foreseen
Internal: 4.2.7 (in case of track-constrained ARAIM), 4.2.8, 4.2.9
External: Module #2
External: Not foreseen
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
External: Not foreseen
External: Not foreseen
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
External: Not foreseen
External: Not foreseen
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
External: Not foreseen
External: Not foreseen
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: 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
Internal: Not foreseen
External: Not foreseen
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: Not foreseen
Internal: 4.3.2, 4.3.3
External: Module #2
External: Not foreseen
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
External: Not foreseen
External: Not foreseen
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
External: Not foreseen
External: Not foreseen
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
Internal: Not foreseen
External: Not foreseen
External: OBU GNSS Processing (4.2.5)
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: 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:
Table 12: Module #5 Function decomposition
Code Name Description Input Output
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: Not foreseen
Internal: 5.1.3
External: Module #4
External: Not foreseen
5.1.2 Virtual balise locations import
This function is responsible for importing the locations of the virtual balise
Internal: Not foreseen
Internal: 5.1.3
External: Module #2
External: Not foreseen
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
External: Not foreseen
External: Not foreseen
5.1.4 Balise detected notifier
This function is responsible for notifying the balise detected event
Internal: 5.1.4
Internal: Not foreseen
External: Not foreseen
External: Modulo #1
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: 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.
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: 43/43
END OF THE DOCUMENT