GNSS Failure Analysis and Impact on Users

Transcription

1 GNSS Failure Analysis and Impact on Users Norbert SUARD CNES 18/11/2014

2 OUTLINE Introduction Failure categories and events Observations Clock events Wrong data in navigation messages Non compliance to GPS ICD Conclusion 2

3 INTRODUCTION Motivations Definition of GPS complements (mid 90 s) Expected failure rate on one side Unscheduled events (Unusable Until Further Notice) on another side Feared event characterisation Impact on users (foreseen, observed) Open questions» are failure rate and unscheduled events in line?» are unscheduled events via NANU complete» are GPS complement efficient on such events?» Is the feared event list complete? Litterature (reports ) and permanent observations (IGS stations, ESTB, EGNOS, NTMF) to answer Presentation mainly based on GPS/SBAS experience. 3

4 FAILURE CATEGORIES Fault characterisation From the space segment (satellites) single (narrow) fault» Unlikely case to get 2 faulty SV at same epoch From the Input Data for the message generation» EOPP - Earth Orientation Parameter Prediction (ODTS)» Solar Flux observations (Ionosphere Model Correction parameter)» UTC(USNO) offset data (UTC-GPST prediction) All satellites affected before upload => single or multiple (wide) fault depending on the upload scheme From the control segment single or multiple faults depending on the failure mode and on the upload scheme SPS PS 2008 Fig. B.1-1 4

5 Fault characterisation (con t) FAILURE CATEGORIES Different Upload schemes One SV at a time with immediate effect» Current GPS (could change in the future) Several SV at a common time with immediate effect» GALILEO design Upload with a common time of application» GLONASS possibility (01 Apr 2014 observation) From the User segment Not under the Constellation Service Provider responsibility but need to be considered» Sources of error /faults Signal distorsions caused by ionospheric and/or tropospheric scintillation Receiver ionospheric/tropospheric compensation errors Receiver noise Receiver hardware/software faults ICD implementation Multipath and receiver multipath mitigation Antenna effects Interference and receiver interference mitigation User error SPS PS 2008 Fig. B.1-1 5

6 FAILURE CATEGORIES Fault characterisation (con t) Fault causing a clear signal stop Continuity/service availability concern Accuracy degradation possible (geometry / DOP issues) with remaining SV Fault causing a degraded signal Integrity concern Accuracy position degradation from small (<1m) to large (>10 km) with an information designating the satellite as non HEALTHY» Caution: for GPS, non HEALTHY and UNHEALTHY are not synomymous» Interface Control Document to list all the possiblities GPS SPS PS UNHEALTHY designation (4 conditions with one refering to the 9 alarms conditions 2.3.4) GPS SPS PS MARGINAL designation (3 conditions) to be considered in function of the application» Implementation under Receiver manufacturer responsibility with no information designating the satellite as non HEALTHY» CSP means and maximum time to react. 6

7 OBSERVATIONS Clock events 20km The largest that has been observed 01 Jan 2004, PRN23:» 18:30 beginning of the clock failure» 21:18 satellite set UNHEALTHY» NANU» Satellite excluded by WAAS and ESTB» More info: SVN-23/PRN-23 Integrity Failure of 01 Jan 2004, Capt Heather Eastlack 2 nd Space Operations Squadron, Effect of a GPS Anomaly on Different GNSS Receivers, A.L.Vogel, C. Macabiau, N. Suard, ION GNSS 2005 Toulouse Rx: Latitude, Longitude, Altitude and Horizontal errors from 18h00 to 22h00 UTC1 10km 20km 20km 7

8 OBSERVATIONS Clock events 02 June 2006, PRN30» 20:00 beginning of the clock failure» 21:14 satellite set UNHEALTHY» NANU» Satellite excluded by EGNOS From 20h to 20h14:» Common degradation (same shape) in GPS mode Around 20h26:» At BRGS, the exclusion of PRN30 has created a DOP problem with the 4 remaining locked SV (explaining the 20 km of error in position). For local EGNOS users, this creates a discontinuity event. This DOP problem was repeated each day until the PRN30 came back in service From 21h to 22h:» SV30 is reacquired by some receivers (GRAS, BRGS, EGNOS RIMS) : not in line with the NANU information possible operator error in GPS MCS. BRGS (scale 1 st curve: -2*10 4 ; 2*10 4 m) GRAS (scale 1 st curve: ; 2*10 3 m) CNES-CMT (scale 1 st curve: -40; 20m) TORN (scale 1 st curve: -20; 10m) Figure 1: Impacts of GPS30 failure on user position in GPS mode (lat, long, H, V) Shapes of degradations is different at each location (caution: scale factor are not the same). Degradation for GPS users: - 35 m range at TORN (Madrid/Torrejon, Spain) - 50 m range at CNES - 2 km range at GRAS (Grasse, South of France) - 20 km range at BRGS (Bergen, Norway) No degradation in the accuracy for EGNOS one CNES-CMT is more noisy due to the non smoothing option. 8

9 Clock events OBSERVATIONS 31 July 2006, PRN03» 21:15 possible beginning of the clock failure» No NANU» Failure confirmed in GPS Ephemeris Error Screening and Results for , L. Keng and al., ION ITM 2010» Satellite corrected and then excluded by EGNOS (23:04 to 23:22). 9 BRGS (scale 4 th curve: -50; 50m) Same shapes of degradations at each location (caution: scale factor are not the same), except at GRAS (Grasse, France) & FU1N (Fucino, Italy) where a second spike in vertical domain occurred. Degradation in the 50 m range for GPS users except at CNES (10m see above), no degradation for EGNOS one CNES-CMT is more noisy due to the non smoothing option. Was there an amplified effect when smoothing on?. CNES-CMT (scale 4 th curve: -10; 10m) GRAS (scale 4 th curve: -40; 20m) FU1N (scale 4 th curve: -50; 50m) Figure 1: Impacts of GPS30 failure on user position in GPS mode (lat, long, H, V) GO2N (scale 4 th curve: -40; 20m)

10 OBSERVATIONS Clock events 08 March 2004, PRN11» 13:23 beginning of the failure» No NANU» Failure confirmed in FAA quarterly report» All observables at different locations impacted in a same manner => Clock anomaly 900s L1o2 where L1o2(t) = L1o1(t) - L1o1(t-1), L1o1(t) = L1(t) - L1(t-1) C1o2 where C1o2(t) = C1o1(t) - C1o1(t-1), C1o1(t) = C1(t) - C1(t-1) Code Noise masked real start/stop times of the event It consisted in a series of "stair step" variations in the observed (apparent) Doppler frequency of the satellite signal. Each "stair step" lasted 1.4 to 1.6 seconds, with a relatively constant observed Doppler during that interval. The stair steps followed an approximation to a sine wave or triangle wave with a period of about 6 seconds. The amplitude of this wave increased and then decreased until it was invisible. 10

11 OBSERVATIONS Clock events 08 March 2004, PRN11» Degradation in ESTB (EGNOS testbed) positioning more important than in GPS one» Dynamic of the event (<2s) too high to provide adequate correction by ESTB (>4s) ESTB and GPS positioning errors (Latitude top, longitude, Height, Horizontal bottom) measured at Toulouse A good correlation between the shape of Fast Correction and envelop of L1/C1 observation,. 11

12 Wrong data in message : TGD Jan 2004, PRN22 OBSERVATIONS» Wrong TGD in its navigation message during several days after its commissioning on the 10 Jan ns instead of ns» More than one additional meter on the daily mean vertical error in GPS only mode Difficulties to discriminate it from ionosphere daily impact Clealy visible during night when PRN22 visible over Toulouse and ionosphere residual error less important Example: comparison 10/01/2004 to 15/01/2004» No impact in ESTB positioning Delta TGD (broadcast internal determination) is part of the range corrections ESTB and GPS positioning errors (Latitude top, longitude, Height, Horizontal bottom) measured at Toulouse 12

13 meter OBSERVATIONS Wrong data in message : Wrong IONO 10 parameters 28 May 2002 to 02 Jun 2002, all PRN» errors in ionosphere delay correction database coefficients (USAF report)» Daily statistics at Toulouse +6m in GPS vertical daily mean ~2m in GPS horizontal daily mean» Additional ranging error (USAF report) +/- 16m» No degradation observed in ESTB positioning Of course (independent ionosphere corrections) Average : Comparison ESTB & GPS Lat_Mean_Peg Lon_Mean_Peg Ver_Mean_Peg Hor_Mean_Peg Lat_Mean_GPS Lon_Mean_GPS Ver_Mean_GPS Hor_Mean_GPS Day ESTB and GPS positioning errors measured at Toulouse daily mean over May

14 OBSERVATIONS Wrong data in message : Wrong Solar flux predictions 07 Mar 2011 to 13 mar 2011, all PRN» Errors in the solar flux predictions causing an inadequate ionosphere correction parameter choice by MCS operations Up to + 20 m in Daily Vertical Error Confirmed with GPS NAVCEN» No impact for SBAS users 6m 14

15 OBSERVATIONS Wrong data in message : bad ephemeris (maneuver and SV not set to UNHEALTHY) 10 Apr 2007, PRN18 NANU : SV Scheduled to be in maintenance from 13:30 to 01:30 (11Apr) 15:53: beginning of the maintenance, SV HEALTH flag still HEALTHY (MCS ops error) error depending on the location PRN18 Range Error and SPS 3D error at 3 sites (FAA PAN report #58) 15

16 OBSERVATIONS Wrong data in message : bad ephemeris (error in EOPP) 50 m 17 Jun 2012, PRN19 GPS position error depending on location» Vertical Position Error (VPE) 16m at Tromso (Norway) 35m at Brussels (Belgium) 48-50m at Toulouse, Dionysus (Greece) 280m at Bangalore (India) Around 0m if in replay mode the ephemeris set broadcasted from 00:10:36 to 00:36:36 is suppressed PRN19 excluded by SBAS explicitely (alarm) or implicitely (set not used - IODE not referenced) Max Range Error (FAA PAN report #78) VPE - Toulouse 300 m VPE - Bangalore 16

17 OBSERVATIONS Wrong data in message : bad ephemeris (error in EOPP suspected) 01 Apr 2014, GLONASS constellation 21:00: All GLONASS SV measured by the GLONASS IAC Monitoring Facility as failed (URE>75m) or broadcasting an illegal ephemeris several 10 km of error in the position 50 km HPE - Toulouse 17

18 OBSERVATIONS Wrong data in message : IODE/IODC wrong repetition ICD compliance 5 Jan 2006, PRN1» Reuse of IODE/IODC values in violation with GPS ICD repetition rules ICD: IODE non repeated during 6h, IODC not repeated during 7 days» IODE is the key information for correction at least from SBAS, GBAS, PPP» SBAS: IOD (slow corrections) must match to IODE: check, validity duration management; Rx storage Accuracy degradation (+171% H, +19% V Toulouse receiver) Integrity degradation (+44% H, +6% V Toulouse receiver) More information on that event: GPS Issue of Data, Ephemeris (IODE) Issues, N. Suard and al,, ENC-GNSS 2008 No NANU Other occurrences Same type GPS Ephemeris Error Screening and Results for , L. Keng and al,, ION ITM 2011 Unhealthy/Uncommissionned SV Numerous cases but not considered as an anomaly New type: 21 Mar 2014, PRN25» Change in ephemeris data without any change for IODE/IODC» Specific IIF» No NANU 18

19 OBSERVATIONS Non Standard Code mode ICD compliance 30 Jun 2009, PRN30 Short Non Standard Code mode» Not really described in the ICD, only possible existence is mentionned typically 6 to 24 s duration, no NANU» Transition to NSC is a condition to consider the satellite as untrackable, but how a Rx has to react when the Standard Code is relocked? Other sources of short interruptions (scintillation, masking/occultation ) Observations» Some NSC are <4s» Confirmed by GPS NAVCEN Minimum duration is in fact 1.5s Integrity impact possible for SBAS users if no alarm sequence broadcasted» In case of single Not Monitored arriving after the end of the NSC mode Evolution done in WAAS and EGNOS» Alarm sequence (repeated DU or NM) when Standard Code lost for one SV for all RIMS 19

20 CONCLUSION Various cases of observed faults have been presented Under the CSP responsibility» Different origins (clock, input data, model, operation, ICD compliance)» Single or multiple SV cases Different orders of magnitude in the observed accuracy error Don t forget the ones due to a Rx fault (ICD implementation) see back up slide Unscheduled NANU (Unusable Until Further Notice) Not really representative of the real rate of failure occurrences» Just a minimum rate» More usefull for continuity/availability concern This presentation is just an excerpt of various observed cases Interest to have a permanent monitoring system» To ensure validity of assumptions/feared events on which applications are based GPS works well but it works better with a complement for a high integrity performance objective Expected to be still the case with new GPS III or any other constellation 20

21 CONCLUSION Thank you for your attention 21

22 BACK UP SLIDE GPS usability conditions Rx must implement the following conditions (SPS PS extract) 22