Integrity in Multimodal Transport Applicationsguide-gnss.net/contenuguide/uploads/2015/07/... · Integrity in Multimodal Transport Applications Standards are on the Way . ... automated
Post on 06-Oct-2020
0 Views
Preview:
Transcript
Integrity in Multimodal Transport Applications
Standards are on the Way
An Appealing and catalyst Market…
08/07/2015 Ref.: 2
LBS & Multimodal : A Huge Market…
Source: GSA, GNSS Market report, Issue 4 Source: GSA, Bergh Insight
Also a driving market for other
applications
Drive the chipset manufacturer, And tomorrow Mass market chipsets may be the source for other applications
Appealing market, but still issues to solve…
08/07/2015 Ref.: 3
Dense Urban Environments
Indoor
Light coverage • Needs a high sensitivity receivers, since the signal is attenuated
• Causes a lot of troubles:
•Blocking situations : Not enough satellites received
•Multipath causing accuracy problems and also integrity problem when needed
•Attenuation problems
•Attenuated signals
•Interfered signals
• Blocking, sensitivity and multipath issues
Integration…
• To address these applications, needs to integrate a positioning system into a device….
•Hiden antenna, and poor antenna gain
•Interferences, ….
Larg
e v
arie
ty o
f e
nvi
ron
me
nts
Same performances, Integrated in a device
Smal
l D
evic
e
Not Only an issue of propagation…
08/07/2015 Ref.: 4
Interferences : A major threat for critical applications
Spoofing : Situation is even worse…
Integrity is a must… for applications development
08/07/2015 Ref.: 5
Integrity, Relaibility The key assets for Road applications booming
Smart Integrity
Signal distorsion detection
(Correlation, CCC)
Multi Sensors Fusion
PVT techniques(RAIM-Like)
AGNSS Server (SLP/GMLC)
Road
LBS Tomorrow
Billing in LBS…
Location based charging
A large variety of applications
08/07/2015 Ref.: 6
Various applications….And various needs…
Emergency Services Car Accident Reconstruction
Fleet & goods Management
ADAS C-ITS
RUC PAYD
Not a single “Position” Integrity need…
The QoS is considered through an overall
approach…
08/07/2015 Ref.: 7
From the receiver to the application
…Supported by needed Test bed to assess new concepts validity
It needs second standardization process…
08/07/2015 Ref.: 8
GNSS chipset
Positioning Terminal
Localization System
The Solution can not rest only a mere GNSS receiver, but shall be
integrated in a whole localization system
Application
Why do we need Standards?
08/07/2015 Ref.: 9
Chipsets market is driven by
LBS,
Very efficient and integrated
chipset,
but closed…
Large Variety of applications,
Requiring to get access to low
layer interface
AB
I Res
earc
h 2
01
0
A Gap in very strong
standardisation area
From LBS to Aviation
A huge markets that could benefits from accessing low layers interfaces to build ad hoc
solutions, with specific needs…
A new standards
Group created
ETSI, TC-
SES/SCN (Sat. Navigation and
Communication)
• Objective:
• Standardise a location system (Features, interfaces and performances),
including hybrid positioning devices
• Place GNSS at the centre of the system
• Define needs and technologies for multi modal applications
• Standards developed under TC-SES/SCN can be seen as a basis for other groups
TC-SESGNSS Technology Standards
TC-SESGNSS MOPS
A new GNSS-oriented standardisation group created at ETSI and in CEN TC5 WG1
With consistence towards other
standardisation bodies
The overall methodology
08/07/2015 Ref.: 11
Identification of features to be standardized
Standardization of the
architecture of a reference
location system
Standardization of the minimum
performances and associated Tests
procedures
Standardization of the logical
interfaces between sensors
•Reinforced standards location performances
• Availability (Indoor)
• Accuracy
•Integrity
• Even in bad reception conditions
•Spoofing detection
• Detect spoofing on open signals
•Interference and Jamming robustness
•Architecture definition
• - Define the reference architecture to provide/implement the identified features
• Multi-sensor architecture
• GNSS
• Inertial sensors
• Networks elements
• …
•Define the minimum required performances for each of the identified architecture
• Define a set of conditions
• Define the associated performances
•Define the test procedures for the whole location system
• For each feature, based on the defined architecture
•Define the interfaces between sensors
• Allows to build system based on open building blocks
•Define/propose protocol specification on AM interface
Publication of
TR 101 593 (10/2012)
Addressed by Mutlipart
TS 103 246
Example of compatible implementation : A wide
range of technologies Type of application End user Location system Application module Value added service
Road charging State / Minitries of
transports
fleet of On-Board Units, equipped with positioning module, distributed over
the target road users.
Billing server collecting OBU positions and
building billing information
Possibility to apply road charges with no infrastructure.
Car navigation Driver Positioning (using GNSS,
inertial and odometer measurements)
Navigation application, providing guidance
visualization to driver Road navigation
Precision farming Farmers Distributed RTK solution,
with reference station and positioning modules, PPP
Harvest scheduling application, providence
guidance signal to automated farming
vehicles
Autonomous and efficient harvesting
Ride sharing Carsharing aficionados
Fleet of On-Board Units, equipped with positioning module, distributed over
participating cars.
Car sharing application collecting OBU positions and building appropriate
scheduling
Possibility to achieve simple and efficient car
sharing
Transaction synchronization
Trading company
GNSS sensors restituting GNSS time for single time
reference
Stock exchange trading application, using
provided GNSS time as time reference.
Global synchronization of assets worldwide.
House arrest monitoring Penitentiary authorities
Monitoring wristlet, reporting position when
prisoner steps out of constrained area
Central server collecting alarms reported by
wristlets
House arrest remote monitoring means
Integrity
High Accuracy
(PPP)
Indoor
Timing
Need from ETSI TC-SES group
• Positioning in Terrestrial applications – Need for improved performance
– Growing use of complex systems, multi-sensors
– GNSS Hybridization needed
• Standardization work aimed by TSG
– Define a location system standard, complying with a wide range of technical domains, in particular those not benefiting from an extensive standard
– Create location system minimum performance standard, architecture dictionary and test standards, available to market actors and other std bodie
• Already achieved – Definition of GNSS-based Location System architecture
Standardisation Overall approach
08/07/2015 Ref.: 14
• Work flow formalized through 5 Work Items
Standardization of GNSS-Based Location Systems (GBLS) • DTS/SES-00368 : Location system Functional Requirements TS 103 246 part 1
• DTS/SES-00331 : Reference architecture TS 103 246 part 2
• DTS/SES-00332 : Minimum performance requirements TS 103 246 part 3
• DTS/SES-00348 : Data exchange protocols TS 103 246 part 4
• DTS/SES-00349 : Test specifications TS 103 246 part 5
Part 1 Functional
Requirements
Part 2 Reference
Architecture
Part 3 Performance
Requirements
Part 4 Data exchange
Protocols
Part 5 Performance Test
Specification
To be approved before end 2015
Overall architecture (Level 2 architecture - 103 246 )
08/07/2015 Ref.: 15
GBLS Reference Architecture
• From functional requirements
• Defines GBLS logical architecture composed of:
– Positioning module:
• Sensor management
• Localization module
• I/F to Application
– Central Facility (optional):
• Central management
• I/F to Application
TS Part 2 available at: http://www.etsi.org/deliver/etsi_ts/103200_103299/10324602/01.01.01_60/ts_10324602v010101p.pdf
Overall architecture (Level 3 Architecture – TS 103 246 )
08/07/2015 Ref.: 16
A multi sensors architecture, and complex hybridization layers
Data Exchange Protocol (TS 103 248)
GBLS Data Exchange Protocol
Identification and definition of
needed information to be
exchanged to enable location
related-data computation
For both internal interfaces
(“core” interface), and external
interface (towards external
application module)
Propose a non-mandatory
protocol description at logical
level (OSI “application” layer, #7)
External
Interface
Internal
Interface
Performance Requirements - TS 103 246
08/07/2015 Ref.: 18
Environments & Use cases
Set of reference performances
Horizontal Accuracy
Vertical Accuracy
Availability of required accuracy
Precise GNSS time restitution
Time-to-first-fix
Position Authentication
Interference Localization
Robustness to Interference
GNSS denied survival
GNSS Sensitivity
Position Integrity Protection Level
Position Integrity Time-to-Alert (TTA)
Environment type
Open area
Rural area
Suburban
Urban
Asymmetric area
Industrial area
Static
Dynamic
Considering also Failures, & external threats
Multipath conditions
• Extension of 3GPP specifications (TS 34.172) • With various levels of MP
Environments definition : Overall approach
08/07/2015 Ref.: 19
Initial relative Delay [m]
Carrier Doppler frequency of tap [Hz]
Code Doppler frequency of tap [Hz]
Relative mean Power [dB]
0 Fd Fd / N 0
X Fd - 0.1 (Fd-0.1) /N Y
NOTE: Discrete Doppler frequency is used for each tap.
Masking conditions
Define sky conditions All along a trajectory
Interference conditions
Define interferences level, And types of interferences
Spoofing Conditions
Only threats already described in literacy…
Masking Conditions
08/07/2015 Ref.: 20
Open Skyplot
Ligth Masking
Dense Masking
Urban Canyon
Asymetric Visibility
Blocking
Covered Area, GNSS+Telco Cut-off zone Perfo req. applicable
Multipath conditions
08/07/2015 Ref.: 21
• Simple model, identical to 3GPP one
– To tests GNSS behavior with respect to specific threats
– With various delays depending on the constellation, signals
Initial relative Delay [m]
Carrier Doppler frequency of tap
[Hz]
Code Doppler frequency of tap
[Hz]
Relative mean Power [dB]
0 Fd Fd / N 0
X Fd - 0.1 (Fd-0.1) /N Y
NOTE: Discrete Doppler frequency is used for each tap.
Multipath level Low Med High
System Signals X [m] Y [dB] Y [dB] Y [dB]
Galileo
E1 125 [tbd] -4.5 [tbd]
E5a 15 [tbd] -6 [tbd]
E5b 15 [tbd] -6 [tbd]
GPS/Modernized GPS
L1 C/A 150 [tbd] -6 [tbd]
L1C 125 [tbd] -4.5 [tbd]
L2C 150 [tbd] -6 [tbd]
L5 15 [tbd] -6 [tbd]
GLONASS G1 275 [tbd] -12.5 [tbd]
G2 275 [tbd] -12.5 [tbd]
Interference conditions
08/07/2015 Ref.: 22
EMI level NI
Low -200 dBW/Hz
Medium -195 dBW/Hz
High -185 dBW/Hz
Several types of Interferences
Pulsed Interference Continuous Interference
Wide Band Narrow band Chirp White Noise CW
Several levels
Use cases depending on environment type
08/07/2015 Ref.: 23
Operational environment
type
Masking conditions Multipath Level
Interference level
Magnetic conditions
Telco beacons distribution
Polar plot Zone Atten
Open Area Open sky
x1 0 dB
Null Null Nominal Rural
distribution x2 [tbd]
(total)
Rural Area Light masking
x1 0 dB
Low Low Nominal Rural
distribution x2 Total
x3 10 dB
Suburban Area Dense
masking
x1 0 dB
Medium Low Nominal Suburban
distribution x2 Total
x3 Total
Urban Area Urban Canyon x1 0 dB
High Medium Degraded Urban
distribution x2 Total
Asymmetric
Area
Asymmetric
visibility
x1 15 dB
High Medium Degraded Urban
distribution x2 Total
x3 Total
Industrial Area Dense
masking
x1 0 dB
High High Degraded Suburban
distribution x2 Total
x3 Total
Spoofing Conditions
08/07/2015 Ref.: 24
Only literacy-based spoofing risk taken into account
1. Direct spoofed GNSS signal introduction 2. Shadowed spoofed GNSS signal
introduction
1. Erroneous PSR measurement; 2. Erroneous time estimates; 3. Erroneous estimates of the position (for
both static of moving scenario).
Several types of attacks
Spoofing Testing
08/07/2015 Ref.: 25
Moving terminal
Several use cases…
Scenario identifier
Attack class
Number of spoofed
PRNs
TSP range (dBW)
Misleading information
category
Error model Model value
range
M-1 Shadow All(1) [-144.5 -140.5] Estimated Time Ramp [2-20] ns/s(2)
M-2 Shadow 4 [-148.5 -144.5] PSR measurement Ramp [3.5-6.5] m/s
M-3 Shadow 4 [-148.5 -144.5] Estimated Position Ramp [1-7.5] m/s(2)
M-4 Direct 4 to 12(3) [-142.5 -137.7] Estimated Time step
function [5-60] s
M-5 Direct 4 to 12(3) [-142.5 -137.7] Estimated Position step
function [0.1-10] km
Conclusion
• A new positioning standardization initiative has been pushed forward based on
– The EC M/496 mandate
– An industrial momentum
• It covers
– multimodal applications
– Multi-sensors devices with a GNSS core (GNSS based positioning terminals)
• It targets to
– Define the interfaces between sensors to ease proprietary positioning engine development
– Define new type of performances for such devices (Integrity, spoofing detection, etc…)
– Define minimum performances for each type of applications, depending on various classes of sensors
– Define a tests suite for GNSS based positioning terminals
• The work done aims at being coordinated with other groups (3GPP, OMA, CEN/CENELEC, etc…)
Rel-1 will be frozen in Q4 2015 Everybody is invited to contribute at ETSI
Backup
08/07/2015
A critical Application : Ecotaxe
08/07/2015 Ref.: 28
• An already operational solution
– GNSS RUC Solution of TAS applied to the
French Ecotaxe project
– Mastering the performance of the
complete collect chain
– Supported by a strong standardization
activity
A critical Application : Ecotaxe, based on full
hybridized solution
08/07/2015 Ref.: 29
• TAS already develops GNSS-based hybrid location systems demonstrating that GNSS can meet the expectations, provided a specific technological know-how.
High availability
Integrity or Confidence level even in dense urban environments
Built-in Spoofing detection
Interference mitigation and localisation
Solution based on deep hybridisation scheme,
Provides Integrity indicators
Technological trend: illustration (Cont’d)
15/03/2012
Confidence level supplied with hybridization and appropriate algorithms.
Spoofing detection, see ION 2011, Authentication of GNSS Position: An Assessment of Spoofing Detection Methods, Y. Bardout, TAS-F
top related