SIST EN 16803-4:2025

SLOVENSKI STANDARD
01-januar-2025
Vesolje - Uporaba sistemov globalne satelitske navigacije (GNSS) za ugotavljanje
položaja pri inteligentnih transportnih sistemih (ITS) v cestnem prometu - 4. del:
Opredelitve in postopki sistemskega inženiringa za načrtovanje in potrjevanje
preskusnih scenarijev
Space - Use of GNSS-based positioning for road Intelligent Transport Systems (ITS) -
Part 4 : Definitions and system engineering procedures for the design and validation of
test scenarios
Raumfahrt - Anwendung von GNSS-basierter Ortung für Intelligente Transportsysteme
(ITS) im Straßenverkehr - Teil 4: Definitionen und systemtechnische Verfahren für den
Entwurf und die Validierung von Testszenarien
Espace - Utilisation du positionnement GNSS pour les systèmes de transport routier
intelligents (ITS) - Partie 4: Définitions et procédures d'ingénierie système pour la
conception et la validation de scénarios d'essai
Ta slovenski standard je istoveten z: EN 16803-4:2024
ICS:
03.220.20 Cestni transport Road transport
33.060.30 Radiorelejni in fiksni satelitski Radio relay and fixed satellite
komunikacijski sistemi communications systems
35.240.60 Uporabniške rešitve IT v IT applications in transport
prometu
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

EUROPEAN STANDARD EN 16803-4

NORME EUROPÉENNE
EUROPÄISCHE NORM
November 2024
ICS 33.060.30; 35.240.60
English version
Space - Use of GNSS-based positioning for road Intelligent
Transport Systems (ITS) - Part 4 : Definitions and system
engineering procedures for the design and validation of
test scenarios
Espace - Utilisation du positionnement GNSS pour les Raumfahrt - Anwendung von GNSS-basierter Ortung
systèmes de transport routier intelligents (ITS) - Partie für Intelligente Transportsysteme (ITS) im
4: Définitions et procédures d'ingénierie système pour Straßenverkehr - Teil 4: Definitionen und
la conception et la validation de scénarios d'essai systemtechnische Verfahren für den Entwurf und die
Validierung von Testszenarien
This European Standard was approved by CEN on 13 October 2024.

CEN and CENELEC members are bound to comply with the CEN/CENELEC Internal Regulations which stipulate the conditions for
giving this European Standard the status of a national standard without any alteration. Up-to-date lists and bibliographical
references concerning such national standards may be obtained on application to the CEN-CENELEC Management Centre or to
any CEN and CENELEC member.
This European Standard exists in three official versions (English, French, German). A version in any other language made by
translation under the responsibility of a CEN and CENELEC member into its own language and notified to the CEN-CENELEC
Management Centre has the same status as the official versions.

CEN and CENELEC members are the national standards bodies and national electrotechnical committees of Austria, Belgium,
Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy,
Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Republic of North Macedonia, Romania, Serbia,
Slovakia, Slovenia, Spain, Sweden, Switzerland, Türkiye and United Kingdom.

CEN-CENELEC Management Centre:
Rue de la Science 23, B-1040 Brussels
© 2024 CEN/CENELEC All rights of exploitation in any form and by any means Ref. No. EN 16803-4:2024 E
reserved worldwide for CEN national Members and for
CENELEC Members.
Contents Page
European foreword . 4
Introduction . 5
1 Scope . 7
2 Normative references . 8
3 Terms, definitions and acronyms . 8
3.1 Terms and definitions . 8
3.2 Acronyms . 10
4 Technical documentation for designing scenario . 11
4.1 Technical documentation for “R&R” . 11
4.1.1 General. 11
4.1.2 Expression of needs . 12
4.1.3 Test specifications . 12
4.1.4 Test plan . 13
4.1.5 Field test condition and validation . 29
4.2 List of documents to produce for simulation scenario . 30
4.2.1 General. 30
4.2.2 Types of scenarios to produce (on “R&R” base or manual for simulators) . 30
4.2.3 Technical documentation . 32
5 Requirements for collecting data . 35
5.1 Identification of the technical documentation . 35
5.1.1 General. 35
5.1.2 Test plan . 35
5.1.3 Technical documentation on instruments . 35
5.1.4 Field test validation . 35
5.2 Requirements for human resources . 35
5.3 Requirements for tests platform . 36
5.3.1 Representativeness of the platform . 36
5.3.2 Installation requirements . 37
5.4 Requirements for RTMeS . 38
5.4.1 General. 38
5.4.2 Type of data . 39
5.4.3 Inertial navigation system requirements . 40
5.5 Requirement for GNSS signals digitization . 48
5.5.1 General. 48
5.5.2 IQ data format . 48
5.5.3 Signals digitizer properties . 49
5.5.4 Signals digitizer installation and RF components . 51
5.5.5 Choice of the antenna . 52
5.6 Requirements for GNSS constellations simulator . 52
5.7 Requirements for benchmark GNSS receiver . 53
5.8 Requirement for GBPT embedded . 54
5.9 Requirements for other sensors. 55
5.9.1 General. 55
5.9.2 Initial sensors . 55
5.9.3 Optical sensors . 56
5.9.4 GNSS augmentation/correction data . 57
5.10 Requirements for control video . 57
6 Requirements for data validation . 58
6.1 Validation of the field test . 58
6.2 Validation of data for reference trajectory . 59
6.2.1 General . 59
6.2.2 Validation of GNSS data . 60
6.2.3 Validation of inertial measurements and hybridized trajectory . 61
6.2.4 Estimation of the uncertainties . 63
6.3 Validation of digitized GNSS signals . 64
6.3.1 General . 64
6.3.2 Analysis of RF signals power . 64
6.3.3 Analysis of effects on benchmark GNSS receiver . 68
6.4 Validation of sensors inertial measurements . 73
6.5 Validation of corrections data (NRTK, PPP…) . 77
6.5.1 General . 77
6.5.2 Example of validation of NRTK correction . 78
6.6 Characterization of the scenario . 80
6.6.1 General . 80
6.6.2 Dynamics analysis . 80
6.6.3 GNSS measurements analysis . 81
Annex A (informative) Impact of multi-constellation on RTK results . 85
Annex B (normative) PPK data validation . 89
Annex C (normative) Inertial measurements and hybridized trajectory validation . 93
Annex D (informative) How lever arms error could affect final reference trajectory . 98
Annex E (normative) Impact of C/N0 difference on measurements availability . 102
Annex F (normative) Scenario characterization example . 104
Bibliography . 113

European foreword
This document (EN 16803-4:2024) has been prepared by Technical Committee CEN/TC 5 “Space”, the
secretariat of which is held by DIN.
This European Standard shall be given the status of a national standard, either by publication of an
identical text or by endorsement, at the latest by May 2025, and conflicting national standards shall be
withdrawn at the latest by May 2025.
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CEN shall not be held responsible for identifying any or all such patent rights.
EN 16803, Space — Use of GNSS-based positioning for road Intelligent Transport Systems (ITS), consists
of the following parts:
— Part 1: Definitions and system engineering procedures for the establishment and assessment of
performances;
— Part 2: Assessment of basic performances of GNSS-based positioning terminals;
— Part 3: Assessment of security performances of GNSS-based positioning terminals;
— Part 4: Definitions and system engineering procedures for the design and validation of test
scenarios.
This document has been prepared under a mandate given to CEN by the European Commission and the
European Free Trade Association.
Any feedback and questions on this document should be directed to the users’ national standards body.
A complete listing of these bodies can be found on the CEN website.
According to the CEN-CENELEC Internal Regulations, the national standards organisations of the
following countries are bound to implement this European Standard: Austria, Belgium, Bulgaria,
Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland,
Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Republic of
North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Türkiye and the
United Kingdom.
Introduction
The EN 16803 series of CEN-CENELEC standards deals with the use of GNSS technology in the
intelligent transport domain and addresses more particularly the issue of performance assessment.
As recalled in the following Figure 1, the generic functional architecture of a road ITS system based on
GNSS, two main sub-systems can be considered: the positioning system [GNSS-based positioning
terminal (GBPT) + external terrestrial sources of data] and the road ITS application processing the
position quantities output by the terminal to deliver the final service to the user.
The EN 16803 series tends to give keys in order to assess the whole positioning-based road ITS system.

Figure 1 — Generic functional architecture of a road ITS system based on GNSS
[SOURCE: EN 16803-1:2020: Space — Use of GNSS-based positioning for road Intelligent Transport
Systems (ITS) — Part 1: Assessment of security performances of GNSS-based positioning terminals]
The scope of relevance of the different parts of the EN 16803 series is reminded hereafter:
— EN 16803-1:2020 proposes a method called “sensitivity analysis” to assess the adequacy of the
GBPT’s performances to the end-to-end performance of the road ITS system. In addition, this first
EN defines the generic architecture, the generic terms and the basic performance metrics for the
positioning quantities. EN 16803-1:2020 can be of interest for many different stakeholders but is
targeting mainly the ITS application developers;
— EN 16803-2:2020 proposes a test methodology based on the replay in the lab of real data sets
recorded during field tests, assuming no security attack during the test;
— EN 16803-3, proposes a complement to this Record and Replay (R&R) test methodology to assess
the performance degradation when the GNSS signal-in-space (SIS) is affected by intentional or
unintentional radio-frequency (RF) perturbations. Next sections below stress the importance of
this assessment in the context of the security threats.
These two ENs (part 2 and part 3) are mainly targeting the generalist RF test laboratory that will be in
charge of assessing the performances of GBPTs for different applications using replay techniques.
This document, EN 16803-4, describes the methodology needed for the record of the real data sets and
is targeting mainly the GNSS-specialized test laboratories that will be in charge of elaborating the test
scenarios.
Important note on EN ISO/IEC 17025 standard:
The EN 16803 series has the scope to define the methodology for the assessment of performances of
GBPT for road intelligent transport. As a reminder: a complete certification process shall follow the
EN ISO/IEC 17065. And the current norm doesn’t address that.
Intrinsically, this statement means that any laboratory working either for the creation of the scenario or
for the evaluation of the GBPT, using the created scenario, should be accredited EN ISO/IEC 17025
norm with the suitable scopes. Even if EN ISO/IEC 17025 can be mentioned in this document, authors
remind here that EN 16803 series (especially this current part 4) can be used outside of the scope of
EN ISO/IEC 17025, i.e. outside of the scope of accredited laboratories. Nevertheless, users of the
EN 16803 series have still to keep in mind that producing accredited test results will always have
higher liability and quality.
As a summary of that note:
1. EN 16803 series can be used for performing accredited tests; and this is even encouraged.
EN ISO/IEC 17025 is the right standard to respect in that context;
2. EN 16803 series can also be used for performing internal or private tests, outside of any
accreditation or certification schemes;
3. a complete certification process shall follow the EN ISO/IEC 17065 standard. And this is not the
topic of the EN 16803 series.
1 Scope
This document is mainly addressed to GNSS-specialized laboratories, in charge of creating reference
test scenarios that will be replayed by other users such as generalist RF lab. It is a fundamental key-
point to be able to deliver homogenous test scenarios. Indeed, in the context of GNSS receiver
certification, the process itself is independent from the laboratory which designed and made the
scenario. In other words, the conformity level of any GNSS-based positioning terminal (GBPT) is the
same whatever the specific scenario used. Using a specific urban scenario from a GNSS-specialized
laboratory A leads to the same conclusion as using another specific urban scenario from a GNSS-
specialized laboratory B. This is really the aim of this document: giving requirements and guidelines to
all GNSS-specialized laboratories in order to make inter-operable test scenarios.
It will thus provide requirements and guidelines on the following topics:
— what technical documentations are required to design test scenarios (Clause 4) through:
o technical documentation for “R&R”,
o list of documents to produce for simulation scenario;
— how to collect data in order to build test scenarios (Clause 5) through:
o identification of the technical documentation,
o requirements for human resources,
o requirements for tests platform,
o requirement for RTMeS,
o requirement for GNSS signals digitization,
o requirements for GNSS constellations simulator,
o requirements for benchmark GNSS receiver,
o requirement for GBPT embedded,
o requirements for other sensors;
— how to validate data – after a data collection– in order to be sure of it (Clause 6) through:
o validation of the field test,
o validation of data for reference trajectory,
o validation of digitized GNSS signals,
o validation of SENSORS inertial measurements,
o validation of corrections data (NRTK, PPP…),
o characterization of the scenario.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
EN 16803-1:2020, Space - Use of GNSS-based positioning for road Intelligent Transport Systems (ITS) -
Part 1: Definitions and system engineering procedures for the establishment and assessment of
performances
EN 16803-2:2020, Space - Use of GNSS-based positioning for road Intelligent Transport Systems (ITS) -
Part 2: Assessment of basic performances of GNSS-based positioning terminals
3 Terms, definitions and acronyms
3.1 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https://www.iso.org/obp/
— IEC Electropedia: available at https://www.electropedia.org/
3.1.1
GNSS-based positioning terminal
GBPT
component that basically outputs PVT
Note 1 to entry: the term “component” can be understood as “system”.
[SOURCE: EN 16803-2:2020, 3.1.1 modified – Note 1 to entry has been added]
3.1.2
hybridized GNSS-based positioning terminal
H-GBPT
GBPT using at least another additional sensor (different from a GNSS receiver) to compute position
EXAMPLE H-GBPT can be a GNSS-inertial sensor-fused-system.
3.1.3
device under test
DUT
device that is assessed
Note 1 to entry: in the context of EN 16803-2:2020 and EN 16803-4, DUT refers to GBPT.
3.1.4
test scenario
non-empty combination of UTS that allows to assess a GBPT in the desired environments and
complemented by a metadata description file
Note 1 to entry: data inside a test scenario are raw data, either RF signals from GNSS satellites, or raw data from
other embedded sensors.
Note 2 to entry: a test scenario is the whole package that a GNSS-specialized test laboratory delivers to a
Generalist RF test laboratory in charge of performance assessment tests according to the EN 16803 series.
Note 3 to entry: considering the 6 different environments as specified in EN 16803-1:2020, there is a combination
of 2^6-1 = 63 possible test scenarios; from let‘s say ―rural only‖ test scenario up to ―all environment‖ test
scenario that covers the 6 different environments. See subclause 4.2.2 of EN 16803-2:2020 for more details.
[SOURCE: EN 16803-2:2020, 3.1.3, modified]
3.1.5
unitary test scenario
UTS
elementary brick composed of GNSS SIS data and potential sensor data resulting from field tests
Note 1 to entry: see subclause 4.2.2 of EN 16803-2:2020 for more details.
[SOURCE: EN 16803-2:2020, 3.1.4, modified]
3.1.6
uniform environment data set
UEDS
output of the DUT collected after a replay in laboratory, sorted by environment; being a concatenation
of the output of the DUT for all UTS restricted to a unique environment
Note 1 to entry: see subclause 6.5 of EN 16803-2:2020 for more details.
Note 2 to entry: considering the 6 different environments as specified in EN 16803-1:2020, there is the same
number of UEDS; i.e. 6.
Note 3 to entry: data composing a uniform environment data set are PVT data, as they are output by a GBPT.
Note 4 to entry: uniform environment data sets are the data sets to which the metrics shall be applied to assess
the performances of the device under test.
[SOURCE: EN 16803-2:2020, 3.1.5, modified]
3.1.7
GNSS-specialized laboratory
laboratory in charge of producing test scenarios for generalist RF test laboratories
3.1.8
generalist RF test laboratory
laboratory in charge of assessing the performances of GBPTs using recorded test scenarios
3.1.9
real time kinematic
RTK
differential GNSS technique enabling high precision positioning thanks to the use of corrections send by
a close base station (GNSS receiver)
Note 1 to entry: close being with around 20 km around the rover.
3.1.10
networked real time kinematic
NRTK
differential GNSS technique enabling high precision positioning thanks to the use of corrections
provided by a service relying on online servers (NTRIP service)
3.1.11
precise point positioning
PPP
global GNSS technique enabling high precision positioning thanks to the use of corrections of satellites
positions and clock
3.2 Acronyms
Acronym Description
CDF Cumulative distribution function
DUT Device under test
GBPT GNSS-based positioning terminal
GNSS Global navigation satellite system
HGBPT or H-GBPT Hybridized GNSS-based positioning terminal
IGN National Geographical Institute [Institut Géographique National]
IMU Inertial measurements unit
INS Inertial navigation system
KPI Key points of interest
ODO Odometer unit
NRTK Networked real time kinematic
PPK Post-processing kinematic
PPP Precise point positioning
PVT Position velocity and time
R&R Record and replay
RMS Root Mean Square
RF Radio frequency
RINEX Receiver independent exchange format
RTK Real time kinematic
RTMeS Reference trajectory measurements system
Rx Receiver
VSWR Voltage standing wave ratio
4 Technical documentation for designing scenario
4.1 Technical documentation for “R&R”
4.1.1 General
To perform field tests, either for data collection or live test of a DUT, is quite a complex operation
requiring high levels of skills, professional instruments and validated software and methodologies:
1. human resources: realization of field tests on GBPT, or data collection for scenario creations, shall
be planned, supervised and analysed by people having a verified knowledge about the satellite
navigation (geolocation techniques) and GNSS metrology;
2. hardware: evaluation of DUT performances, directly or through R&R technique, requires having a
very precise reference trajectory for the comparison. Considering all possible classes of GBPT the
reference trajectory shall derive from high-level instrumentation (GNSS Rx INS ODO) providing the
best possible accuracy;
3. software: the hardware part alone, however, it is not sufficient for the derivation of the most
accurate reference trajectory (example of a backward algorithm). In the same way, the used
software shall be validated to be sure that all data can be processed correctly, i.e. without errors
(PPK, Hybridization).
Considering the complexity and requirements associated with the field test executions, a detailed test
plan shall be drafted providing all information stated in the previous 3 bullets.
Besides, other information shall be provided for the scenario to meet the requirements of the
EN 16803-1:2020 and the EN 16803-2:2020:
— description of trajectory;
— expected test environments and/or characterized obstacles;
— types of data to be collected;
— classes of GBPT to test;
— performances that is possible to test.
The overall information will, at the end of the document, enables the validation of such developed
scenario.
To comply with previous requirements, four main documents shall be provided:
1. test plan: a detailed description of the test to perform; the used instruments, the platform, the
human resources, the foreseen route with the expected environments;
2. field test validation: this document shall make a critical review of the actual conditions met during
the field test. Instruments, platform, people executing the test and other conditions shall be
coherent with the ones foreseen in the test plan.
3. measurement uncertainty estimations of reference trajectory: being the “term of comparison”
for the estimation of all performances of DUTs and considering the accuracy that these last can
reach under certain conditions (RTK + IMU) the reference trajectory shall be the most accurate
possible. The document shall prove the way the trajectory has been estimated and to justify the
derived uncertainties;
4. collected data validation: in case of a reference scenario, the collected data shall be used for the
certification of GBPTs. The validation of the collected data sets, in terms of representativeness, shall
be proved through a series of analyses allowing a competent and entitled third part to validate
them.
Details about these two last documents will be analysed Clause 6 as part of the requirements for the
validation of collected data.
Two other kinds of document should be added to the technical one. They are not considered as
mandatory for the design of any operational scenario, incidentally, they can provide relevant
information to any GNSS-specialized laboratory if well drafted.
The first document represents the expressions of needs. It should be drafted by any GBPT users or
integrators providing a series of information not known to GNSS-specialized laboratories, enabling
better identification of al technical needs.
The second one is a technical specification of the needs expressed by GBPT users or integrators. It
should be drafted by GNSS-specialized laboratories, and it can be seen as a link between the test plan
and the expression of needs.
4.1.2 Expression of needs
The present document is not considered mandatory for the designing of an operational scenario.
It should be drafted by all stakeholders like GBPT integrators or final users to fairly specify their needs
in terms of:
— identification of the application;
EXAMPLE GBPT used for autonomous vehicle driving.
— typical expected environment (as classified in EN 16803-1:2020) and typical expected
constraints (for example on peripheral road tunnels and/or bridges are expected to be met);
— typical dynamics of the platform;
— expected performances: according to the application selected, needs in term of accuracy
(positions, velocities, angles), continuity availability and integrity (positions, velocities, angles)
should be different;
— estimated budget for the GBPT: the estimated budget should include the eventual prix of an
antenna and/or a correction service.
This first document, if properly drafted, will enable GNSS laboratories to properly perform the most
adapted operational scenarios for all needs expressed by one or more GBPT users/integrators.
4.1.3 Test specifications
This second document is the direct conversion of the expressions of needs in technical specifications.
As for the first one, it is not considered as mandatory for the design of an operational scenario.
It should be drafted by GNSS laboratories in charge of operational scenarios realization.
The document, referring to a defined expression of needs, should identify:
— GBPT/antenna categories: according to the needs expressed by the final user/integrators the
laboratory should identify the most appropriate GBPT that could be tested for a defined application,
or a group of them having similar environments, dynamics and GBPT classes;
— platform: as for the GBPT, the most suitable platform to use for the tests should be identified;
— test cases: according to the expected typical environment and obstacles the most appropriates test
cases should be identified by the laboratory designing the scenario;
— uncertainties on reference trajectory: according to the GBPT classes that could be tested, a
proper identification of needs, in term of used instrument and required uncertainties, should be
done for the reference trajectory.
4.1.4 Test plan
4.1.4.1 General
Two previous documents, expression of needs and test specifications, are not considered as mandatory.
They only have the aim to create a sort of link between GBPT users/integrators not having a technical
background for the designing operational scenarios and GNSS laboratories having limited knowledge
about the applications and the expected performances of GBPT.
The test plan is the most critical document to develop an operational scenario (cf. EN 16803-1:2020,
5.1) or a DUT live test in the frame of the EN 16803 norm. It shall provide a series of information
intended to identify the following elements.
— TEST CONTEXT
Any test campaign shall be planned in a clear context. It can be a test campaign aiming to test a
receiver during its development phase, or for its final characterization. In the same way, a test
campaign can be performed in the frame of EN 16803 to collect data for the development of an
operational scenario. In all cases, the test context shall be identified since from this first
information shall determine the requirements related to RTMeS system (reference
instrumentation), identification of the course, environments and human resources.
— TEST METHODOLOGY
In case of certification of a GBPT in the frame of the EN 16803 series, the test plan shall refer to the
test methodology expressed in EN 16803-2:2020. In this document, the methodology to conduct
tests in a laboratory using operational scenarios is properly described. In case of tests not fully
complying with EN 16803-2:2020, the methodology shall be explained.
— GBPT IDENTIFICATION
Even if not considered in EN 16803, GBPT should be embedded in the test vehicle during the data
collect test campaign. In other cases, there could be the need to perform a field test for direct
evaluation of a GBPT. In this case, a complete description of the GBPT shall be provided. Are
considered essential information; GBPT S/N (and other information enabling a unique
identification), P/N (identification of the hardware design), firmware version, set-up (for example
for GNSS mask angle and C/N0 mask, dynamic filter, used constellations and signals, use of
correction service). If included as part of the GBPT antenna properties shall be listed as well.
The laboratory executing the test should use more than one GBPT (in parallel). In this case, the
identification of all of them shall be done as for the single GBPT case.
— TEST DEFINITION
Test definition section shall list all details enabling to any user to determine the course (specified in
EN 16803-1:2020) to be followed with sufficient details in other that any people can reproduce it:
o suitable vehicle;
o expected dynamics;
o environments (rural, peri-urban, …);
o specific obstacles (bridges, foliage,…);
o forecast or expected weather.
The interesting obstacles present on the route shall be listed as well.
The overall information shall lead to the identification of the “kind of trips” as in EN 16803-2:2020,
4.2.2.1.3 and typical environments as in EN 16803-1:2020, 6.2.2 in order identify all cases that is
possible to test with the current scenario.
— TEST DATA MANAGEMENT
A system for the data management during the test (GBPT test or data collect), shall be identified in
the test plan. Such system aims to prove that the naming rule adopted enables the correct
identification of the collected data avoiding any possible ambiguity in the naming process leading to
the exchange of data among instruments.
— HUMAN RESOURCES
The test plan shall identify all persons taking part in the test. They shall be listed jointly with a
short description of their knowledge in the GNSS/geolocation domain. the appointed persons have
to respect the requirements listed in EN 16803-4 dedicated to the data collection.
— INSTRUMENTATION
The instrumentation used during the field test shall be listed and details about their configuration
shall be provided. Under these section three sub-categories shall be present at a minimum:
o RTMeS instruments: all instruments concurring to the estimation of the reference trajectory
shall be listed. Details about the processing of the data shall be provided;
o data collection instruments: all instruments embedded for data collection, for the
establishment of an operational scenario, shall be listed. Details about set-up and installation
shall be provided;
o benchmark instruments: all instruments used as a benchmark (control) for the validation of
collected data shall be listed. Their installation details, as well as their set-up shall be listed
since can be required to re-use it in laboratory.
— PLATFORM AND INSTALLATION
The used platform (also sometime mentioned as carrier) and installations details shall be described
in this section. Particular attention shall be given to the installation and orientation of all sensors
collecting inertial data since their knowledge is a fundamental parameter for the use in
replay/post-processing.
— IDENTIFIED GBPT CLASSES AND METRICS
This part shall list the classes of GBPTs that can be tested using the scenario under design
(standalone, high-precision, hybridized). The identification of the GBPT class will directly impact, in
the data validation process, the expected uncertainties of the reference trajectory and the quality of
the data collected. The most is expected to be accurate the GBPT PVT, the most the reference
trajectory and collected data shall be accurate.
This section shall also identify the metrics that can be tested on GBPT using the scenario under
design.
— SUCCESS CRITERIA
This section of the scenario shall define which are the success criteria to adopt for the different
steps of the operational scenario creation. In details three main phases can be identified:
1. success criteria for the data collect campaign;
2. success criteria for the reference trajectory estimation;
3. success criteria for the data validation.
The first point will be analysed directly in this deliverable as part of the document to provide for
the scenario designing. The second and the third part will be analysed in Clause 6 as part of the
requirements for collected data validation.
— TEST REPORT
The last part of the test plan shall specify how the test report will be created (analysis done, metrics
analysed, environments-subdivision). In the frame of EN 16803-2:2020, a detailed section is
dedicated in Clause 8.
4.1.4.2 Test context
This part of the test plan acts as an introduction to the operational scenario that is supposed to be
designed. Information included in this part should be used, then, to write a sort of scenario flyer
permitting to any RF lab carrying out replay sessions to fairly select the proper scenario according to
the tests to perform and to the GBPT to test.
In the case of design of a test campaign aiming to collect data for the creation of a reference scenario, in
the frame of EN 16803 norm, the section shall report:
“The present test plan aims to identify the overall condition for the data collection aiming to create an
operational scenario to be used in the frame of the EN 16803 norms.”
A series of extra information should be given for the sake of clarity. For example, “the present scenario
is composed of single-frequency GNSS data (L1); IMU data from a different type of sensors, DMI data
from reference odometer. Addressed GBPTs include all single frequency GBPT, using or not inertial
measurements. Accuracy, integrity and availability metrics can be estimated on this scenario.”
The last information that should be provided concern the environments expected to be met during the
field test and the typical journey addressed as in EN 16803-2:2020. For example, “the reference
scenario is collected in flat rural environment reproducing the typical journey Sunday in the
countryside”.
4.1.4.3 Test methodology
Any test plan is drafted according to a test methodology. In the case of live tests, the methodology
consists in installing the GBPT on the foreseen carrier and log all outputs of interest. At the same
moment, data enabling the estimation of the most accurate reference trajectory are collected. Once in
laboratory, errors affecting the positions, velocities and other KPI, are analysed by comparison with the
reference one.
In case of creation of an operational scenario in the frame of EN 16803 norm, the test methodology is
defined in the EN 16803-2:2020. The laboratory shall refer to this document to announce the used test
methodology.
Details about the methodology should be added in case of need. For example, if a GBPT has been
embedded during the data collection test campaign, and its performances will be analysed for
comparison with replays.
4.1.4.4 GBPT identification
To comply with all EN 16803 series, the embedded DUT, here identified as GBPT, shall be accurately
listed and their properties identified.
Software used shall be listed as well, by the way, if their role is just dedicated to the set-up and/or data
log, and they are directly provided by the instrument manufacturer, a simple identification of the
software name and version is enough. In case of software executing any treatment o
...