EN 16803-1:2020

SLOVENSKI STANDARD
01-november-2020
Nadomešča:
SIST EN 16803-1:2016
Vesolje - Uporaba sistemov globalne satelitske navigacije (GNSS) za ugotavljanje
položaja pri inteligentnih transportnih sistemih (ITS) v cestnem prometu - 1. del:
Definicije in sistemsko-tehnični postopki za določanje in ocenjevanje zmogljivosti
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
Raumfahrt - Anwendung von GNSS-basierter Ortung für Intelligente Transportsysteme
im Straßenverkehr - Teil 1: Definitionen und Systemtechnikverfahren für die Festlegung
und Überprüfung von Leistungsdaten
Espace - Utilisation de la localisation basée sur les GNSS pour les systèmes de
transport routiers intelligents - Partie 1 : Définitions et procédure d’ingénierie système
pour l’établissement et la vérification des performances
Ta slovenski standard je istoveten z: EN 16803-1:2020
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-1
NORME EUROPÉENNE
EUROPÄISCHE NORM
September 2020
ICS 33.060.30; 35.240.60
Supersedes EN 16803-1:2016
English version
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
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
1 : Définitions et procédures d'ingénierie système pour Straßenverkehr - Teil 1: Definitionen und
l'établissement et l'évaluation des performances Systemtechnikverfahren für die Festlegung und
Überprüfung von Leistungsdaten
This European Standard was approved by CEN on 12 July 2020.

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, Turkey and United Kingdom.

CEN-CENELEC Management Centre:
Rue de la Science 23, B-1040 Brussels
© 2020 CEN/CENELEC All rights of exploitation in any form and by any means Ref. No. EN 16803-1:2020 E
reserved worldwide for CEN national Members and for
CENELEC Members.
Contents Page
European foreword . 3
Introduction . 4
1 Scope . 8
2 Normative references . 8
3 Terms and definitions . 8
3.1 General terms . 8
3.2 Specific terms . 10
3.3 Abbreviations . 15
4 Description of the generic architecture of a Road ITS System based on GNSS . 16
4.1 Generic architecture . 16
4.2 Components . 16
5 Definition of performance metrics for positioning terminals . 18
5.1 General . 18
5.2 Outputs of the Positioning terminal . 18
5.3 Inputs to the performance characterization process . 20
5.4 Performance features . 20
5.5 Performance metrics . 21
5.6 Introduction to Performance Requirements . 34
6 Operational scenarios . 37
6.1 Definition . 37
6.2 GNSS environments classification and characterization . 39
7 Sensitivity Analysis. 42
7.1 General . 42
7.2 Presentation of the method . 42
8 PVT error models . 48
8.1 General . 48
8.2 Different types of error models . 49
8.3 Conformity assessment of the PVT error models . 49
Annex A (informative) Positioning performances metrics rationale. 51
A.1 General . 51
A.2 Performance metrics . 51
Bibliography . 57

European foreword
This document (EN 16803-1:2020) has been prepared by Technical Committee CEN-CENELEC/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 March 2021, and conflicting national standards shall be
withdrawn at the latest by March 2021.
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.
This document supersedes EN 16803-1:2016.
This document has been prepared under a mandate given to CEN by the European Commission and the
European Free Trade Association.
This revision of EN 16803-1 includes updates that are necessary to understand correctly the two next
EN – Part 2 and Part 3. Some concepts and metrics not identified at the very beginning of EN 16803-1
definitively required to be aligned with last works of CEN/TC 5/WG 1 standardization group. Global
architecture has not been modified, i.e. the table of content is unchanged. Among updates, the
Introduction describes the LBS and ITS market for which these EN series are targeted. The GNSS Based
Positioning Terminal (GBPT) is introduced later in the document, so that the “positioning system”
concept can be developed and be included in the new set of ITS applications such as autonomous driving.
The clause “Terms and Definitions” includes some new inputs now, like “Record&Replay”, or “Reference
Material”. About metrics, a new one has been introduced: the continuity metric that is slightly different
from the availability metric and could help to define how a service should be continuous. Definition of
Time To First First (TTFF) is also proposed in this revision. It should help to share a common vision of
what should be a hot/warn/cold start by using commonly accepted definitions. The concept of
performances classes has also been refined with the new subclause “Introduction to Performance
Requirements”. Finally, the sensitivity analysis concept has been enlarged or adapted to cover the
integrity assessment.
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.
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, Turkey and the United
Kingdom.
Introduction
The civil applications of geopositioning are undergoing exponential development. The latest market
analysis for the GNSS systems shows two major fields of application that, all together, practically share
the whole of the market:
— intelligent Transport Systems (ITS), mainly in the Road ITS domain;
— location Based Services (LBS), accessible on smartphones and tablets.

Figure 1 — Cumulative Revenue 2015-2025 by segment (Source: GNSS Market Report, Issue 5,
copyright © European GNSS Agency, 2017)
When a Road ITS system needs GNSS positioning, which is the case for most of them, there is the question
of the choice of the type of terminal or of its minimum performances that are necessary to satisfy the
system's final requirements at user level. To meet these requirements, the system includes a processing
module called Road ITS application which uses the outputs (PVT = Position-Velocity-Time) of a
positioning system to provide the service with a given End-to-end performance. Consequently, this latter
depends on the quality of the positioning outputs, which are highly variable with respect to the
operational conditions of the system, but also on the performance of the Road ITS application itself.
Figure 2 represents the breakdown of a Road ITS system into its two main components.
Figure 2 — The two main components of a Road ITS system
The main Road ITS systems concerned by this issue are:
— autonomous driving;
— GNSS-based Road User Charging systems (road, parking zone, urban…);
— localized emergency calls (eCall);
— electronic tachograph;
— taximeter;
— regulated freight transport systems (hazardous substances, livestock, etc.);
— “Pay-as-you-drive” insurance;
— road management systems, traffic information systems;
— advanced Driver Assistance Systems (ADAS);
— etc.
Some Road ITS systems are considered as “safety critical”, because their failure may cause human death
or injury and others are “liability critical”, because they include financial or regulatory aspects. In some
cases, their development is subject to an official certification/homologation process.
Particularly for those systems, there exists a strong need to be able to prove they do meet their End-to-
end performance requirements related to positioning, but presently there is no standard that supports
such certification process.
The performance management approach proposed in this document is based on a classical system
engineering approach and is a support for engineers facing the problem of handling the performances of
a Positioning-based road ITS system all along the system development.
This overall performance management approach can be summarized as follow:
Figure 3 — Logic of the overall performance management approach
The starting point of any performance management of a Positioning-based road ITS system should be the
definition and clear statement of the E2E performances which are targeted by the system to design and/or
test, as expressed by the customer.
In the context of this document, the system breakdown into components is the one that has been
introduced above:
— Positioning System;
— The Road ITS application.
The interface between these two components is assumed to be the PVT information, together with some
auxiliary information, for instance Integrity information if the Positioning System is designed to support
this kind of feature.
Performance requirements are generally stated as requirements on the outputs of a given system
component, assuming that the other components feeding it with input information do respect their own
performance requirements.
Hence, the performance allocation of the E2E performances between the system components should
follow the general scheme below.
Figure 4 — Generic performance allocation process
The performance requirements of the Road ITS application are actually the same ones as the system E2E
performance requirements but expressed under the condition that the Positioning System respects certain
performances requirements.
NOTE Depending on the application, performance requirements may need to be put only on the position output
or only on the velocity output by the Positioning System.
Due to the specificities of GNSS performances, which are due to be defined statistically and which are
highly dependent on the operational conditions, margins should be planned in the performance
allocations, in order to allow the system to meet its performance requirements, even when, in certain
conditions, one of its component does not strictly meet its own requirements. This is the objective of what
is called “Sensitivity Analysis”.
1 Scope
EN 16803-1 addresses the final stage of the performance management approach, i.e. the assessment of
the whole Road ITS system performance equipped with a given Positioning System, using the Sensitivity
analysis method.
EN 16803-1 addresses the identification and the definition the positioning performance features and
metrics required for Positioning System assessment.
This document gives definitions of the various items to be considered when specifying an Operational
scenario and provides a method to compare finely two environments with respect to their effects on GNSS
positioning performance.
This document gives definition of the most important terms used all along the document and describes
the architecture of a Road ITS system based on GNSS as it is intended in this standard.
This document does not address:
— the performance metrics to be used to define the Road ITS system performance requirements, highly
depending on the use case and the will of the owner of the system;
— the performance requirements of the various kinds of Road ITS systems;
— the tests that are necessary to assess Positioning System performances (Record and Replay tests for
this purpose will be addressed by EN 16803-2 and EN 16803-3.
2 Normative references
There are no normative references in this document.
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
• ISO Online browsing platform: available at http://www.iso.org/obp
• IEC Electropedia: available at http://www.electropedia.org/
3.1 General terms
3.1.1
digital map
digital description of the road network and of a certain number of attributes assigned to the elements of
this network
Note 1 to entry: Takes the form of a geo-referenced database at the data processing level.
3.1.2
epoch
time at which a GNSS measurement is made
3.1.3
GNSS
Global Navigation Satellite Systems
general acronym designating satellite positioning systems
3.1.4
GPS
Global Positioning System
GPS-Navstar American satellite positioning system
3.1.5
ITS
Intelligent Transport Systems
systems applying information, communication and positioning technologies to the transport domain
3.1.6
navigation
action of leading a vehicle or pedestrian to a given destination, by calculating the optimal trajectory and
giving guidance with reference to this trajectory and its real time position
3.1.7
navigation message
data transmitted by the GNSS satellites and necessary for the position computation
3.1.8
performance
global characterization of the quality of the service provided by a system
Note 1 to entry: The performance is generally composed of several given performance features of given outputs
of the system and measured by using given metrics.
3.1.9
performance class
domain delimited by 2 boundaries for a given performance metric
3.1.10
performance feature
given characteristic used to qualify and quantify the service provided by a system
EXAMPLE Accuracy for a Positioning system.
3.1.11
performance metric
precise definition of the means of measuring a given performance feature of a given output of a system
EXAMPLE An Accuracy metric can be the median value of an error sample acquired during a given test
following a given protocol.
3.1.12
positioning
action of determining the position of a mobile object or a person
3.1.13
pseudo-range
measurement, by the GNSS receiver, of the distance between a satellite antenna and the receiver antenna,
biased by the error due to the difference between the satellite clock and the receiver clock
Note 1 to entry: Belongs to the category of Raw measurements.
3.1.14
RM
reference material
material, sufficiently homogeneous and stable with reference to specified properties, which has been
established to be fit for its intended use in measurement or in examination of nominal properties
[SOURCE: International vocabulary of metrology – Basic and general concepts and associated terms
(IVM)]
EXAMPLE
• Reference trajectory (or Ground Truth);
• Data set consisting of the selected test scenario.
3.1.15
SBAS
Satellite Based Augmentation System
regional augmentation system of complete satellite systems
EXAMPLE GPS WAAS, EGNOS, QZSS MSAS and GLONASS SDCM are examples for regional augmentation
systems.
3.1.16
trajectory
series of time-stamped positions (and possibly speeds) of a mobile object
3.1.17
Timestamp Resolution
size of the smallest time lapse which would result in different consecutive timestamps
Note 1 to entry: It can be understood as the value of the least significant bit within the word used to encode the
timestamp.
3.2 Specific terms
3.2.1
application quantity
quantity produced by the Road ITS application, from which an End-to-end performance can be calculated
Note 1 to entry: This quantity is normally deducted from a set of positions (and/or speeds) produced by the
Positioning system.
EXAMPLE The time of presence of a vehicle inside a given zone is an Application quantity for a Geofencing
application.
3.2.2
assisted GNSS
technique consisting in assisting the positioning calculation performed by the GNSS terminal by
providing it, via a telecommunication system, with partial or full navigation data as borne by the GNSS
signal transmitted by the satellites
Note 1 to entry: This technique reduces the Time To First Fix, and lowers the acquisition sensitivity threshold.
3.2.3
benchmark GNSS receiver
off-the-shelf, low-cost and high sensitivity GNSS receiver capable of providing pseudo-range
measurements
Note 1 to entry: This kind of receiver is proposed in this document as a benchmark sensor of the environmental
constraints that affect the GNSS signals propagation for fine comparison of environments between themselves.
3.2.4
E2E performance - end-to-end performance
performance of the service provided by a Road ITS system
Note 1 to entry: E2E performance is measured by applying a performance metric to an Application quantity.
EXAMPLE For a Taximeter, the accuracy of the travelled distance is an E2E performance.
3.2.5
geofencing
function consisting in determining the presence of certain persons or of certain moving objects within a
certain geographical zone
Note 1 to entry: This zone can be defined in several ways.
3.2.6
geo-object
geographic entity, having the form of a virtual polygon, framing a point of interest or delimiting a zone of
interest
3.2.7
integrity
general performance feature referring to the trust a user can have in the delivered value of a given
Position or Velocity component
Note 1 to entry: This feature is expressed by 2 quantities: the Protection level and the associated Integrity risk.
Note 2 to entry: In this document, the definition of integrity is inspired by, but significantly simpler than, the
definition of the same concept for the civil aviation community.
Note 3 to entry: For other domains than GNSS positioning, Integrity may have other definitions.
3.2.8
integrity risk
IR
probability that, for Positioning terminals providing a Protection level as integrity-related quantity, the
actual error on a given output component exceeds its associated Protection level
3.2.9
misleading information rate
MIR
observed rate, for Positioning terminals providing a Protection level as integrity-related quantity, at which
the actual error on a given output component exceeds its associated Protection level
Note 1 to entry: The MIR differs from the IR in that the MIR is a purely empirical quantity (e.g. based on
observations obtained through field testis) whereas the IR determination comprises also a complete and rational
analysis of the system design, its potential weaknesses, threats, etc. (RAMS analysis). The MIR is an empirical first
approximation of the IR, and usually an optimistic one.
3.2.10
map-matching
processing operation consisting in determining the position of the mobile on a map representing the road
network
Note 1 to entry: Requires a digital map.
3.2.11
operational scenario
description of the conditions in which the GNSS-based road ITS system is operating and particularly
affecting the GNSS-based positioning terminal
3.2.12
position
location of the positioning terminal or, more specifically, of some reference point attached to it, such as
the antenna phase centre
3.2.13
positioning system
set of hardware and software components, which can be in different locations, but interconnected, which
contribute to estimating the position, velocity and associated timestamp of a mobile object
3.2.14
positioning terminal
equipment (unit) carried by a vehicle or a person delivering a position solution to a Road ITS application
Note 1 to entry: The Positioning terminal is the component of the Positioning system which is directly interfaced
with the position data user (in this document the Road ITS application).
Note 2 to entry: The Positioning terminal uses a GNSS receiver which may be hybridized or assisted.
3.2.15
positioning module
software component of the Positioning terminal processing the PVT from the data of different sensors
3.2.16
positioning-based road ITS system
system consisting of one or several Positioning terminals and of a Road ITS application providing a
Positioning-based Road ITS service
3.2.17
positioning-based road ITS service
main function(s) of a Positioning-based Road ITS system, making use of the Application quantities
EXAMPLE Computation and secure storage of charge events for a road charging system.
3.2.18
protection level
estimation of an upper bound for the error made on a Position or Velocity component (e.g. the plane
position) associated with a given probability called Integrity risk
Note 1 to entry: Like the actual error, this quantity can be characterized by its distribution function.
3.2.19
PVT error model
parametric mathematical model representing the errors affecting a PVT component, composed with noise
and biases observed on this component, output by a Positioning terminal operating in a certain
environment
Note 1 to entry: The PVT error model is used to draw pseudo-random trajectories representative of real
trajectories.
3.2.20
Position, Velocity and Time
PVT
data related with the position, the velocity and the time which is available at the output of a GNSS receiver
or of a Positioning terminal in general
3.2.21
Record and Replay
R&R
test techniques consisting to digitize GNSS signals and sensor measurements in the real world campaigns
so that they can be repeated later on suitable laboratory test benches
3.2.22
raw measurements
quantities available in a GNSS receiver after the signal processing stage from which the PVT will be
calculated
Note 1 to entry: The Pseudo-ranges for each tracked satellite are essential components of the Raw measurements.
3.2.23
reference trajectory
series of time-stamped positions of a reference point on a mobile object (test vehicle), produced by a
Reference trajectory measurement system
Note 1 to entry: This reference trajectory may be called “Ground truth” in some other documents.
3.2.24
RTMeS
reference trajectory measurement system
measurement means capable of accuracy performances better of at least one order of magnitude than
those of the required performance of the Positioning terminal being tested
3.2.25
road ITS application
processing part downstream of the Positioning terminal(s) which computes the Application quantities and
provides the Road ITS service
3.2.26
operational scenario
description of the conditions in which the GNSS-based road ITS system is operating and particularly
affecting the GBPT. An operational scenario is composed of:
— the set-up conditions of the terminal, and particularly of the antenna of the GNSS receiver;
— the trajectory of the mobile vehicle (more precisely of the antenna);
— the environmental conditions
3.2.27
test scenario
composed of GNSS SIS data and potential sensor data resulting from field tests, complemented by RTMeS
data, and 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.
3.2.28
sensitivity analysis
method to assess the performance of a Road ITS application or of a whole Road ITS system, consisting in
injecting a high number of simulated degraded PVT data obtained by adding to a reference trajectory PVT
error models representing the real errors observed during dedicated field tests
3.2.29
speed
norm of the velocity vector
Note 1 to entry: The speed describes how fast the user moves relatively to the ground irrespectively of its
direction.
3.2.30
velocity
velocity of the positioning terminal relative to the ground expressed as a three-component vector
3.3 Abbreviations
Acronym Description
ADAS Advanced Driver Assistance System
CDF Cumulative Distribution Function
EFC Electronic Fee Collection
E2E End-To-End
EGNOS European Geostationary Navigation Overlay Service
GBPT GNSS-based positioning terminal
GNSS Global Navigation Satellite System
HPL Horizontal Protection Level
IMU Inertial Measurement Unit
IR Integrity Risk
ITS Intelligent Transportation System
LBS Location Based Services
MIR Misleading Information ITS Rate
NLOS Non Line Of Sight
PDF Probability Density Function
PVT Position Velocity Time
R&R Record and Replay
RM Reference material
RTMeS Reference Trajectory Measurement System
SBAS Satellite based Augmentation system
TIR Target Integrity Risk
TTFF Time To First Fix
4 Description of the generic architecture of a Road ITS System based on GNSS
4.1 Generic architecture
A Positioning-based road ITS system based on GNSS consists of a Positioning system and of a Road ITS
application, using positioning data to provide a Service for the user (navigation aid, tracking, events or
presence detection, etc.). Figure 5 presents the architecture of such a system.

Figure 5 — Generic architecture of a Road ITS system
4.2 Components
4.2.1 Positioning components and outputs
The Positioning terminal is the on-board part of the Positioning system, i.e. the part attached to the mobile
object (vehicle), which position is expected by the application. In this respect, the terminal is the
component of the Positioning system which is directly interfaced with the Position quantities user (in our
case the Road ITS application). More precisely, since this document is addressing the uses cases where a
GNSS receiver is used, the terminal is called GNSS-based positioning terminal, or GBPT.
The terminal itself consists of a series of on-board sensors and a positioning software component
(Positioning module) supplying the Road ITS application with Position quantities. The Positioning module
inside the terminal, or the GNSS sensor itself, can use external GNSS data provided through a data
transmission channel, for instance assistance data, differential GNSS data or SBAS data. The position
computation can also be partially or totally performed by a module external to the vehicle. In both of
these cases, the Positioning system is only partially on-board the vehicle, but the GBPT is always on-board
and remains the component providing the final position output to the application.
In the frame of this document, the GBPT shall use at least a GNSS receiver which can be hybridized or
assisted.
In the frame of this document, the Position quantities output by the GBPT shall comprise at least one of
the two following quantities:
— the position of the phase centre of the GNSS receiver antenna or of any other reference point of the
vehicle, expressed in a standard geodetic reference system;
— the velocity of this point;
each of them being associated with a timestamp indicating the time to which the output corresponds.
Depending on the application, the position can be either the 3 components of the 3D position (i.e. a
vector), or a subset of them, for example the 2D horizontal position (projection of the 3D position on the
horizontal plane or on a plane tangent to the ellipsoid used by the geodetic reference frame) or the
vertical position.
The same way, the velocity can be limited to the horizontal 2D velocity or even to the module of it, i.e. the
horizontal speed, or to any single component of the 3D velocity vector.
In the case when the Positioning terminal is delivering Integrity information on any position or velocity
component of the PVT, this information shall comprise at least:
— a Protection level (PL) on the concerned PVT component, according to the definition given in this
document, that is to say a value that statistically bounds the error of the position or velocity
component provided by the positioning terminal with a very high probability,
— computed for a given Integrity risk, which is the complementary probability of the latter, that is to
say the probability that the actual error on the component actually exceeds the associated Protection
level.
4.2.2 Road ITS application and outputs
The Road ITS application is a software module which is broken down for the purpose of this document
into two sub-modules:
1) The Technical sub-module which transforms the Position quantities into Application quantities
derived directly from the PVT and other data depending on the application and which are the key
quantities necessary to deliver the final service to the user.
EXAMPLE 1 Position on a road segment (map-matched position), charging point detection, zone entry/exit
detection, distance covered are examples of Application quantities.
2) The Business sub-module which is dedicated to the provision of the final service and highly dependent
on the business model chosen by the operator of the system.
EXAMPLE 2 Computation of the bill to be sent to the user for a road user charging system is an example of
processing done by this sub-module. Since this processing can be extremely variable, this sub-module is out of
the scope of this document and will be considered in this document only the cases when the End-to-end
performances of the system providing the service are established on the Application quantities.
5 Definition of performance metrics for positioning terminals
5.1 General
This section provides the definition of the positioning metrics. The metrics defined herein shall be used
for the characterization of the PVT performances as the basis for establishing requirements, and for
evaluation and validation purposes. The logic for performance metrics definition comprises:
— A detailed definition of position terminal outputs to which the different metrics will be defined
(see 5.2).
— An identification of characteristics of those outputs that are relevant for the identification of
performance features (see 5.3)
— An identification of the performance features to be described (see 5.4)
— A definition of metrics (see 5.5).
5.2 Outputs of the Positioning terminal
The outputs expected from the Positioning terminal, also called Position quantities, were specified in 4.1
to be those related to position, velocity and time (PVT). The following list aims at identifying all the
parameters that can be of interest to the vast majority of Road ITS applications that take advantage of PVT
information:
— Position: is the location of the positioning terminal (or, more specifically, of some reference point
attached to it, such as the antenna phase centre) expressed in some specified reference frame (e.g.
WGS84) and system of coordinates (e.g. geodetic or Cartesian). The position output can include all
position components (e.g. longitude, latitude and height) or just a subset of them (e.g. longitude and
latitude) depending on the needs of the application.
— Velocity: is the velocity of the positioning terminal relative to the ground. In its more general form
it is a three-component vector which will most typically be expressed in a Cartesian coordinate
system whose frame is centred at the user position (e.g. the local horizontal reference frame, with
)
coordinates referring to North, East and Up directions ).
— Speed: is the Euclidean norm of the velocity vector, and hence describes how fast the user moves
(relative to the ground) irrespective of the direction. It is of relevance in many applications and hence
it shall be specifically addressed. When accompanied by heading, speed provides an equivalent
description of the velocity vector of a vehicle (provided that its motion is mainly horizontal, which is
typically the case with land vehicles, otherwise the pitch angle may be additionally provided).
Depending on the specific application, it can be convenient to present the motion information to the
user in the form of speed and heading (and pitch), but in general, the velocity vector (expressed in
some orthonormal reference frame such as the local East-North-Up reference) is the most

1) Another common local Cartesian reference frame is given by the vehicle’s body axes: the longitudinal axis (which is usually
taken to point forwards), the transversal axis (pointing leftwards) and the normal axis (orthogonal to the first two and pointing
upwards when the vehicle is horizontal and right side up). So far as no significant side slipping or bouncing takes place, the
projection of a vector (such as the velocity vector or the position error vector) on the longitudinal axis can be assimilated to the
so-called along track component of the vector (such as the “along track velocity” or the “along track position error”). Likewise,
the projection of a vector on the transversal axis can be assimilated to the so-called cross-track component of the vector (such
as the “cross-track velocity” or the “cross-track position error”). The transformation between the body frame and the local
horizontal frame is given by the Euler angles: heading, pitch and roll.

informative. When only the horizontal components of the velocity vector are used to compute the
speed, the resulting value shall be referred to as the horizontal speed.
— Heading: is the angle between the vehicle’s longitudinal axis forward direction and the North
direction measured clockwise along the horizontal plane (e.g. for vehicles looking northwards,
eastwards, southwards and westwards the corresponding headings would be 0, 90, 180, and 270
degrees respectively). Note that in order to compute the heading it is necessary to first project the
longitudinal axis into the horizontal plane when it is inclined whatever the reason (e.g. when the
vehicle is climbing up a slope). The heading angle may be used along with the speed as an alternative
description in polar coordinate of the vehicle’s horizontal velocity vector. Polar coordinates of a 2D
vector are given by the vector’s Euclidean norm plus the angle (heading in this case) of the vector
relative to some predefined direction (the North direction in this case), and special care shall be taken
when comparing vectors in polar coordinates, since such comparisons may lead to wrong
conclusions (e.g. note that the difference of the norm is not the norm of the difference).
— Pitch: is the angle between the vehicle’s longitudinal axis forward direction and the horizontal plane,
positive in the upwards direction. This angle is not relevant in most road applications, but may be
)
needed if a complete description of the velocity vector in spherical coordinates or of the vehicle’s
attitude is required.
— Roll: is the banking angle of the vehicle, defined as the (signed) angle of the shortest rotation around
the longitudinal axis required to take the vehicle’s transversal axis to the horizontal position so that
the vehicle remains right side up. Note that, for a complete description of this concept, an additional
convention is required for the sign of the roll angle, which is not addressed here. Note also that the
roll angle is ill-defined when the vehicle’s longitudinal axis is pointing vertically, which is a most
unlikely situation. This angle is not relevant in most road applications but may be needed if a
complete description of the vehicle’s attitude is required for some reason.
— Protection levels: a Protection level (PL) is a value that, with a very high probability, bounds the
error of some position or velocity component (or of any other output of interest for which error
bounding makes sense, such as heading or some other attitude angle). Therefore, the complementary
probability, known as the Integrity Risk, that the error in an output component exceeds its associated
protection level shall be very small. Actually, it shall be so small as to not exceed a threshold known
)
as the Target Integrity Risk, which is application-specific A Protection level is a real-time and
dynamic quantity which may vary from one output epoch to the next.
— Timestamp: is a tag that indicates the time to which all other items in this list correspond, and is
usually referred to some well-known time standard, such as UTC or GPS time.

2) Spherical coordinates of a 3D vector are given by the vector’s Euclidean norm plus two angles (heading and pitch in this
case): one between the vector and a predefined direction (the upwards direction in this case) and another one between the
vector’s projection into the plane orthogonal to the predefined direction (the horizontal plane in this case) and another
predefined direction within that plane (the North direction in this case). Similar considerations apply as for polar coordinates
regarding vector comparisons in spherical coordinates.

3) The Target Integrity Risk may be extremely small (e.g. in the order of 1E-7) for some applications, which poses serious
challenges to the validation of the Integrity Risk against its requirements. In most cases, a satisfactory validation will not be
achieved only through testing, but some kind of RAMS assessment will be required, including FTA, FMECA, threat assessment,
etc. This norm does not cover the procedures to carry out such RAMS engineering, but only the metrics used to evaluate
performances from a purely experimental perspective.

-------------
...