DEVELOPMENT AND EARLY RESULTS OF A GALILEO UERE/UERRE MONITORING FACILITY

Transcription

1 DEVELOPMENT AND EARLY RESULTS OF A GALILEO UERE/UERRE MONITORING FACILITY Wolfgang Werner, IFEN GmbH Udo Rossbach, IFEN GmbH Massimo Eleuteri, Thales-Alenia Space Italy Daniele Cretoni, Thales-Alenia Space Italy BIOGRAPHY Wolfgang Werner received a diploma in Computer Science from the University of Technology in Munich (Germany) in 1994 and a Ph. D. from the University FAF Munich in Since 1999 he is Technical Director of IFEN GmbH. He led the algorithm development for the EGNOS Check Set and also worked on integrity algorithms in the framework of several Galileo projects. Based on this experience he tracks and supports all activities in the field of integrity. Udo Rossbach holds a a degree in aeronautical engineering from the Technical University Aachen (Germany) and a Ph.D. in surveying engineering from the University of Federal Armed Forces Munich, Germany. Since 1999 he is working as a systems engineer with IFEN GmbH, where he is involved in the development of algorithms and software for GPS, GLONASS, EGNOS and Galileo applications. ABSTRACT Since satellite navigation systems exist, there is the question with regard to their performances in terms of accuracy, availability, continuity and within the last years also in terms of integrity. Considering the accuracy error budget many models have been developed by scientists, institutions or companies over the last thirty years. These models try to characterize the error on the satellite signals in a statistical way to be able to take them into account in an optimal tuning of parameters for position, velocity and time solutions. Due to the GPS pioneering role in satellite navigation systems, the models have been used and validated for GPS in most of the cases. The future European satellite navigation system Galileo is now on the horizon. Hence, performance verification based on real Galileo signal measurements now becomes more and more important for Galileo. Within the ESA GSTB-V1 project Galileo end-to-end performances have been investigated for the first time with real Galileo algorithms, but based on GPS signals. Within GSTB-V2 the signals of the first Galileo test satellites have been analyzed. With Galileo aiming at very high performance standards, it becomes important that the actually reached performance is verified and checked independently. One of the performance parameters of a satellite navigation system is accuracy. Although one of the most important aspects, the User Equivalent Range Errors (UERE) and User Equivalent Range Rate Errors (UERRE) from the user point of view so far have not been assessed yet. Therefore, a UERE/UERRE Monitoring Facility (UMF) is being developed. The objective of the UMF is the determination of the UERE/UERRE budget on Galileo signals as well as the characterization and verification of Galileo receivers. The UMF is able to separate the major UERE/UERRE error components and compute relevant statistics on them. For this purpose the UMF consists of a control computer and several environmental sensors, like a meteorological sensor, a Integrated Water Vapor (IWV) radiometer and a GPS reference receiver. Furthermore, it makes use of a high-quality rubidium frequency standard, a spectrum analyzer and, of course of the Galileo receivers. In addition to the environmental sensors reference data, such as precise orbit and clock data, are needed that come from external sources. The error components that can be determined are satellite orbit and clock error, tropospheric and ionospheric residual errors, multipath, interference effects and measurement noise. All these error components can be computed per frequency E1, E5, E6 and per service Open Service (OS), for dual or single frequency users, as well as for the Safety-of-Life service (SoL). An Early Version (EV) of the UMF that is capable of analyzing data of GIOVE-B signals has already been developed and first results are available. This paper describes the context, purpose, functionality, architecture and algorithms of the UMF INTRODUCTION Galileo will be the future European satellite navigation system. The system is being developed by the European Space Agency as a system prime and an industrial consortium. Compared to the American Global Positioning System (GPS), Galileo will be different in its constellation, services and functionality and signal structure. The signal structure of Galileo has undergone a long way of development and finally has been agreed at

2 international level. Details of the signal structure can e.g. be found in [1], [2]. Currently the development of the In-Orbit-Validation (IOV) phase comprising the first four satellites is ongoing. The first two test satellites called GIOVE-A and GIOVE- B have already been launched and their signals are available for early validation purposes. An important point of the system is, of course, its performance. This performance depends on many different parameters of the system and needs to be assessed from an independent point of view. Typically the four radio navigation parameters are of importance: accuracy, availability, continuity of service and integrity, and there are stringent requirements for these performance parameters imposed on the system design. To verify the Galileo system's performances a set of independent tools is currently being developed, which are not linked to the core system. These tools are dedicated to the different performance parameters. One of these is the UERE/UERRE Monitoring Facility (UMF). The objective of the UMF is the determination of the UERE/UERRE budget on Galileo signals as well as the characterization and verification of Galileo receivers. The main purpose of the UMF is to allow analysis of the Galileo user's User Equivalent Range Error (UERE) budget. Furthermore User Equivalent Range Rate Errors (UERRE) will be computed for assessment. The UMF consists of a series of environmental sensors and of Galileo receivers. This will allow gaining insight on the one hand into the signal-in-space characteristics, but also in the environmental characteristics and in the quality of the test receivers. The UMF is being developed by IFEN under contract from Thales Alenia Space Italy (TAS-I) in the framework of the System Support activities of the ESA Galileo project. The project has been started in the beginning of 2008 and is scheduled to run until the end of While the final version of the IOV UMF is foreseen to evaluate the signal-in-space of the four IOV satellites, an early version (EV) has already been developed to analyze the GIOVE-B signals. data and some standard products will also be displayed during data collection. The second need for UERE performance analysis is to derive a precise truth reference to allow obtaining absolute UERE values per satellite, signal and/or service. For this purpose the UMF must make use of several hardware items that measure the environment and the satellite signals. In addition reference data from the International GNSS Service (IGS) and an external (independent) ODTS estimation for GIOVE are used. When precise orbits and clock data are available from these sources, a proper synchronization of the data with the measured data needs to be performed and the absolute impact of broadcast orbit and clock errors on the UERE can be computed. For the purpose of further analyzing the UERE performances, output of statistical products and the capability for batch processing are required. There is a long list of UMF products that support the performance verification activities. Among them are the following: Satellite orbit error Satellite clock error Tropospheric residual error Ionospheric residual error Measurement noise Multipath bias Total UERE / UERRE All these error components will be computed per frequency: E1, E5, E6 and per service: Open Service (OS), for dual or single frequency users, as well as for the Safety-of-Life service (SoL). ARCHITECTURE The UMF will consist of three main components, the UMF Primary Node (UPN), and two UERE Data Collection Facilities (UDCF). One of those data collection facilities will be a fixed (UDCF-F) and one will be a mobile (UDCF-M) unit. FUNCTIONALITY The needed functionalities of the UMF can be identified when its use cases are assessed. Four main use cases have been identified: Antenna LAN Archive Server External Hard disk Antenna 1. Data collection and real-time analysis 2. Post-processing analysis 3. Statistical analysis 4. Batch processing. Ref. Time System Receiver System Reference Receiver System Environment Monitoring System Control PC Fixed UDCF Control PC (+Monitor, Keyboard) Mass Storage UMF Primary Node Control PC Mass Storage Ref. Time System Receiver System Ref. Receiver System(RTK Rover) Environment Monitoring System RTK Reference Station Mobile UDCF The first basic need is data collection (and real-time analysis). For this purpose, the UMF needs to acquire the signals to be analyzed via a test receiver on the one hand and to monitor the environment (highly-accurate meteorological data, spectrum analyzer data, etc.) on the other hand. For purpose of ionospheric determination, an SBAS-capable reference receiver is used. The collected Figure 1: UMF architecture overview UMF System Boundary This will allow investigating the UERE budgets for both static as well as kinematic users. It is foreseen that the UDCF-F is co-located to the UPN, while the UDCF-M will be used for remote kinematic data collection and real-time analysis. Data retrieval from the

3 mobile unit is foreseen to take place via external hard disks once the UDCF-M has returned to the site of the UPN. All data are archived on an external archive server, which is not part of the UMF. This server will provide the functionality of managing all data coming from the different elements and providing data for specific test cases and post-processing tasks. The following figure 3 shows the UMF Early Version, which is very similar to the UDCF-F. known as accurately as possible, because absolute values of error components need to be derived. Figure 3: Thies meteo sensor (top) and Radiometrics IWV Radiometer Figure 2: UMF EV rack H/W The UMF EV hardware consists of a control PC with mass storage unit, an uninterruptible power supply (UPS), a stable frequency reference (Symmetricom 8040C rubidium atomic clock), a GPS reference receiver (NovAtel ProPak 3), a spectrum analyzer (Agilent N9010A EXA), an integrated water vapor (IWV) radiometer (Radiometrics) and a meteorological sensor (Thies Datalogger MeteoLOG TDL14). For the UMF EV, a Septentrio GeNeRx receiver has been used for tracking signals from GIOVE-B. The meteorological sensor, radiometer and the test user receiver are depicted in figures 4 and 5 below. As for the performance analysis and UERE budget determination, all environmental conditions need to be Figure 4: Septentrio GeNeRx receiver A meteorological sensor on the ground measuring temperature, humidity and pressure is not sufficient for determining the full tropospheric delay on the signals. With such a sensor, the dry part of the tropospheric effect may be obtained well enough, but the wet part would still be too uncertain. For this reason, the UMF also makes use of an IWV radiometer, measuring the wet (and total) tropospheric delay up to a certain atmospheric height (see e.g. [3], [4] or [5]).

4 ALGORITHMS The UMF data processing is performed in the core software component, the UERE Performance Analysis and Assessment Tool (UPAAT). The data processing performed in the UPAAT is split in two chains. On one hand there is a user-like processing, resulting in a PVT solution. On the other hand there is the determination of the UERE/UERRE and its components. This includes an assessment of the quality of the PVT solution. All the processing is done for GPS and Galileo. Both single-frequency users (GPS L1, L2, Galileo E1, E5a, E5b, E6) and service users (GPS L1/L2, Galileo OS, SoL) are covered. Where it is possible, processing results from one user type are shared with the users in order to avoid duplicate computations. For simplicity, the descriptions in the following refer to UERE only. But all of the processing is also performed for the UERRE and its components. The computation of the PVT solution corresponds largely to what a normal GPS or Galileo user would do. It consists of a pre-processing with cycle slip detection and carrier phase smoothing. Ionospheric and tropospheric delays are corrected for [7], [8]. With the corrected ranges the current receiver position is computed, using a leastsquares algorithm. Depending on the user type (single- /multi-frequency), appropriate algorithms are used (e.g. standard vs. modified Hatch filter, broadcast ionospheric model vs. dual-frequency correction). Besides the PVT solution itself, all of the intermediate results (e.g. the atmospheric delays) are also regarded as results here and used in further processing. Figure 5: UPAAT real-time processing steps Accepted Observations Figure 6: UPAAT post-processing steps The UERE determination is subdivided into four processing steps. Only two of them are performed in realtime: The assessment of the PVT solution and the computation of those UERE components that can be performed in real-time. The other two steps are only available in post-processing, because they make use of external reference data that is not available in real-time. These two steps are the assessment of the broadcast navigation data and the determination of the remaining UERE components up to the total UERE. The following figures show these processing blocks. The computation of real-time UERE components comprises those values that can be derived from the pseudorange, carrier phase, Doppler and SNR measurements directly, without the knowledge of external reference data. Figure 7: Computation of UERE real-time components The first step is an extensive data pre-processing. This includes cycle-slip detection and correction, carrier phase smoothing, a correction of ranges and phases for antenna and cable effects, a tropospheric correction using the actually observed IWV radiometer data as well as meteorological data, a multi-frequency ionospheric correction and a range correction for the satellite clock. Furthermore, ionospheric delays are computed from the corresponding data in the received SBAS messages [6]. These delays (ionospheric and tropospheric) are also used as truth references and are later compared to the delays computed by the user. Where appropriate (e.g. smoothing or ionospheric delay), all these processing steps make use of all available frequencies. For the satellite clock correction, the broadcast navigation message is used. When the UPAAT is running in post-processing, the known external reference is used. The second processing step is a computation of measurement differences, such as code-minus-carrier or pilot-minus-data. Second and third order time differences are also included, based on which the measurement noise is determined. The mean time to loss-of-lock is computed as an important data quality indicator. As a next step, the code-minus-carrier differences are statistically evaluated to obtain an analysis of the multipath effects on the observations.

5 The tropospheric delays as computed by the user according to his model are compared to the reference delays obtained from the radiometer. This yields the contribution of the troposphere model to the UERE. Likewise, the user-computed ionospheric delays are compared to the truth references. Actual receiver clock offsets are computed as the mean over all measurement residuals at the receivers. Finally, a real-time estimation of the Total UERE is computed as the sum of the previously computed contributions. Figure 10: Computation of UERE post-processing components Figure 8: Characterization of PVT solution For the assessment of the PVT solution, the computed receiver positions, velocities and clock offsets are compared to the known values. This is done both for the PVT solutions computed by the UMF and the solutions computed and output by the receivers themselves. For the mobile DCF, the known position and velocity is taken from the DGPS reference system. The receiver clock offsets as estimated in the real-time part of the UERE computation are taken as the known reference values. Figure 9: Assessment of broadcast navigation data In the assessment of the broadcast navigation data, the contributions to the UERE budget of the satellite navigation message, i.e. due to imperfect orbit, clock or BGD information, are computed. The orbit contribution is the distance between the orbital positions derived from the broadcast navigation message and that derived from the truth reference, projected onto the line-of-sight to the receiver position. For service users, the contribution of the broadcast satellite clock to the UERE is the difference between the broadcast and the true clock information. For single-frequency users, the satellite BGD (broadcast as well as true) are applied first, before the difference is computed. The orbit and clock contributions are then added up to obtain the combined ODTS contribution to the UERE. Finally those UERE components are computed that require external knowledge (reference data) for their determination. This includes additional ionospheric/ tropospheric assessment (with e.g. TEC maps from IGS) and a more refined Total UERE as is possible in real-time. The Total UERE is computed as the difference between the observed range and the expected range, taking into account geometry, satellite and receiver clocks, atmospheric delays and the ODTS contribution. This is done for each of the Galileo services and each of the single frequencies. Furthermore, a refined multipath analysis is performed here, along with an analysis for effects of ionospheric scintillation [9], [10] or signal interference. CONCLUSIONS An independent UERE/UERRE Monitoring Facility (UMF) is being developed for evaluation of the Galileo system performance in terms of UERE/UERRE budget. For this purpose it consists of several hardware sensors and algorithms to derive the truth reference and compute the absolute budget components. The paper has described the functionality and architecture of the UMF as well as the algorithms used. ACKNOLEDGEMENTS The UMF is developed by IFEN GmbH under contract from Thales-Alenia Space Italy as part of the System Support activities of ESA s Galileo project. REFERENCES [1] G. W. Hein, J. Godet, J.L. Issler, J.-C. Martin, P. Erhard, R. Lucas-Rodriguez, A. R. Pratt: Status of GALILEO Frequency and Signal Design. Proceedings of ION GPS 2002, September 24-27, 2002, Portland, Oregon, USA. [2] J. A. Avila-Rodriguez, G. W. Hein, S. Wallner, J.L. Issler, L. Ries, L. Lestarquit, A. De Latour, J. Godet, F. Bastide, T. Pratt, J. Owen: The MBOC Modulation - A Final Touch for the Galileo Frequency and Signal Plan, Inside GNSS - Engineering Solutions for the Global Navigation Satellite System Community, pp , Vol.

6 2, No. 5, September/October 2007, Gibbons Media & Research LLC. [3] F. Solheim, J. Vivekanandan, R. Ware, C. Rocken: Propagation Delays Induced in GPS Signals by Dry Air, Water Vapor, Hydrometeors and other Atmospheric Particulates. Journal of Geophysical Research, Vol. 104, No.D8, pp , April, [4] F. Solheim, J.Godwin, R. Ware: Passive ground-based remote sensing of atmospheric temperature, water vapor, and cloud liquid water profiles by a frequency synthesized microwave radiometer. Meteorologische Zeitschrift, N.F. 7, pp , December [5] C. Alber, R. Ware, C. Rocken, F. Solheim: GPS Surveying with 1 mm Precision Using Corrections for Atmospheric Slant Path Delay. Geophysical Research Letters, 1999 [6] RTCA SC-159, Minimum Operational Performance Standards for Global Positioning System/Wide Area Augmentation System Airborne Equipment, RTCA/DO- 229 C / [7] ESA, Galileo Single Frequency Ionospheric Model for User Receivers, ESA-DEUI-NGTN/02650, 2.0 / [8] ESA, Galileo Reference Troposphere Model for the User Receiver, ESA-APPNGREF/00621-AM, 2.3 / [9] W. Fu, S. Han, C. Rizos, M. Knight, A. Finn, Real- Time Ionospheric Scintillation Monitoring, ION GPS ITM 1999, Nashville, September 14-17, 1999 [10] A. Dodson, T. Moore, M. H. O. Aquino, S. Waugh, Ionospheric Scintillation Monitoring in Northern Europe, ION GPS ITM 2001, Salt Lake City, September 11-14, 2001