Diversity Architecture for Robust GNSS/INS Navigation in Launcher Applications ^†

Abstract

The ESA DIVERGENCE (Diversity Architecture for Robust GNSS Receivers in Launcher Applications) project is focused on the design of a GNSS/INS hybrid navigation system and an appropriate FDIR/FDE algorithm for GNC applications in launchers and re-entry vehicles. The main goal is to demonstrate architecture robustness with respect to possible threats and weaknesses introduced by GNSS and INS technology. A baseline navigation system architecture has been developed through a sensor fusion algorithm, which combines IMU, GNSS/DGNSS, a radar altimeter, and a star sensor to cover the accuracy requirements for all the flight phases. The navigation system has been designed to be easily adaptable to multiple applications, such as expendable launch vehicles, micro-launchers, reusable first stage boosters and unmanned re-entry vehicles. The most critical threats/failures were considered for the development of the FDIR/FDE algorithm, comprising GNSS signal outages, spoofing, satellite/receiver clock bias/drift discontinuities, IMU failures, saturation, vibration rectification, coning and sculling, and INS software numerical failures. A preliminary description of the implemented robust FDIR/FDE techniques is reported, and an analysis is conducted to compare the performance before and after FDIR/FDE algorithm implementation in a representative launcher scenario.

1. Introduction

With respect to the navigation function, launch vehicles have traditionally relied solely on high-grade INS (Inertial Navigation Systems) but in the last two decades, there has been an increasing interest in the use of hybrid navigation, fusing GNSS together with INS to achieve GNC (Guidance Navigation and Control) and safeguard function in launcher applications. GNSS is used in applications that require higher accuracy in the long-term than the is achieved by traditional INS-only systems (e.g., reusable stages and re-entry vehicles) and relax the requirements on the INS system, thus lowering system costs (which is especially relevant for micro-launchers). This interest yielded new GNSS/INS navigation systems, some operational like the one on Falcon 9, and some still under development, like the NAVIGA system for the Vega-C launcher. In the case of reusable stages and re-entry vehicles, higher navigation accuracy is required for the last phases associated with the landing. To meet such accuracies, complementary sensors are commonly used; specifically, radar altimeters are typically used for altitude estimation relative to the landing pad.

Despite this, considering the safety-critical applications for launcher and re-entry system environments, such a navigation system must also demonstrate robustness with respect to the possible threats and weaknesses introduced by the GNSS and INS technology. For this reason, the focus of this research is to develop a robust design for a GNSS/INS navigation system while considering recovery mechanisms to reduce the risk (up to acceptable levels) in the case of possible failure or threats which may cause the loss or degradation of the navigation function.

2. Launcher Scenarios

2.1. Use Cases Under Investigation

Five use cases (UCs) based on expendable launch vehicles, reusable launch vehicles and re-entry vehicles has been selected in the project (Figure 1) and the following six mission scenarios (SCs) have been identified to test the robustness of the navigation system architecture:

Figure 1. Launcher use cases under investigation.

• [SC-001] Vega launch to LEO SSO.
• [SC-002] Vega launch to MEO.
• [SC-003] Ariane-5 launch to GTO.
• [SC-004] Falcon-9 first stage re-entry and landing.
• [SC-005] Shefex-2 microgravity mission.
• [SC-006] Space Rider re-entry.

2.2. IMU/GNSS Failure and Threats

It is worth noting that a launcher environment is characterized by high levels of accelerations and vibrations. The design parameters, including accounting for shocks and random vibrations, as reported in the launcher user manual [1], represent the design drivers for payloads and are usually defined with a 99% confidence level. Extreme shock and vibration values that exceed the expected values defined by the launch authority may occur for a short time period during the launch ascent and descent phases, especially during transonic flight and stage separations. Although these events are considered low probability events, they can have a huge impact on the navigation output in terms of attitude and velocity error cumulation. Considering the extensive work reported in [2] regarding the classifications of failure mode for the navigation sensors, the following threats and failures were selected for this study as part of the DIVERGENCE project: (1) IMU saturation; (2) IMU rectification coning and sculling; (3) INS software failures; (4) ionospheric scintillation; (5) multipath; (6) RF interference; (7) spoofing; (8) satellite/receiver clock bias and drift discontinuity; and (9) IMU/receiver hardware failures.

3. Baseline Launcher Navigation Architecture

The baseline launcher navigation system relies on a GNSS/INS sensor fusion engine (Figure 2). The IMU is considered the primary navigation sensor, which provides high-rate information on angular/velocity increments to the kinematic propagator. The OBS (observables) data message using PR (pseudo-range) or PRR (pseudo-range rate) measurements are primarily used by the GNSS/INS architecture for the TC (tightly coupled) integration. Alternatively, the PVT data message (position, velocity, time) can also be used for the LC (loosely coupled) integration as a backup solution. The use of a multiple-constellation (GPS, Galileo) and multiple-frequency (L1/E1, L5/E5a) GNSS receiver was assumed in accordance with the characteristics of Qascom’s QN400 Space SDR receiver.

Figure 2. Baseline launcher navigation engine.

Although the system is primarily designed to use the GNSS OBS data message to perform TC integration, other aiding sensors are supported by the sensor fusion engine to extend the capabilities of the navigation system to re-entry space vehicles and other types of local navigation applications (e.g.: drones, aircraft):

• Attitude: This information can be provided by a star sensor in quaternion form to initialize/correct the navigation system during the orbital phase before re-entry.
• Altitude: This information can be provided by a radar altimeter to enhance the altitude accuracy for re-entry vehicle applications (e.g., Falcon-9) or a barometric altimeter to bound the vertical channel error for drone/aircraft applications.
• Heading: This information can be provided by a magnetometer in combination with a WMM (world magnetic model) to reduce the heading error when a low-grade IMU sensor is used in drone/aircraft applications.

4. Robust Launcher Navigation Architecture

Starting from the baseline launcher navigation architecture, three different techniques have been selected to improve the system robustness. The three techniques work at different levels of the new launcher GNSS/INS engine, as reported in Figure 3.

Figure 3. Robust launcher navigation engine.

• IMU FDIR: Assuming a hot redundancy configuration of three IMUs, this technique implements a voting logic to identify the failed IMU and allow the switch to a backup unit in case of failure identification in the primary unit. The algorithm is inspired by the work reported in [3].
• GNSS/INS FDIR: This technique uses a combination of GNSS observables and INS kinematic states to identify out-of-specification drift for the INS and/or receiver clock offset/drift discontinuities. Moreover, the algorithm can identify abrupt changes in single PR/PRR observables caused by satellite failure. The algorithm is inspired by the work reported in [4].
• GNSS/INS FDE: This technique uses a combination of GNSS observables and INS kinematic state to identify slow drift in PR/PRR observables. It is useful to exclude spoofed satellites or observables affected by slow drift change over time. The algorithm is inspired by the work reported in [5,6].

4.1. IMU FDIR

The IMU FDIR capability is provided when three IMUs are simultaneously valid in the launcher navigation system. Each IMU is assumed to be a three-axis IMU, and the main scope of the algorithm is to detect and isolate the failed IMU boxes. An alternative approach to IMU FDI could involve the skewing of the IMU boxes to identify failures within individual axes, rather than classifying the entire unit as malfunctioning. However, this method faces challenges due to the typical usage of navigation-grade IMUs in space launch vehicles. These IMUs operate internally at significantly higher rates than the provided output rate. Consequently, the output is subjected to down-sampling and compensation for coning and sculling effects. This compensation process results in a scenario where measurements in each axis are influenced by measurements in the other two axes, inevitably leading to the spread of a failure from one axis to the others. Three IMU boxes are then assumed to be onboard the vehicle, whilst the core of the fault detection and identification is an algorithm which compares a discriminator between the IMU measurement modules with the estimated noise in the discriminator. The estimated noise is mainly a function of the sensor error model and the sensor error specifications. For the theoretical details regarding the FDI algorithm implementation, the reader can refer to the work reported in [3].

4.2. GNSS/INS FDIR/FDE

The GNSS/INS FDIR/FDE is performed using the combination between the INS kinematic state and the GNSS observables. Its main objective is to provide the filtered observables to the GNSS/INS Kalman filter. The FDIR/FDE architecture is based on a cascade between different FDIR and FDE processing blocks, as reported in Figure 4. One FDIR and FDE algorithm is utilized for each type of observable provided by the GNSS receiver: PR and PRR. For each type of observable, the FDIR runs first and the FDE is performed second. The sequence between FDIR and FDE is an important design choice and allows the FDIR algorithm to first detect the following: (1) large single GNSS channel blunders; (2) large GNSS channel common mode bias discontinuities; or (3) large INS kinematic state divergences with respect to the GNSS solution. Regarding points 2 and 3, it is important to underline that the FDIR is performed before the FDE algorithm because in the event of a receiver oscillator clock bias/drift discontinuity or a divergence in the INS kinematic, the FDIR algorithm is the first to identify these type of threats, allowing it to adapt the error covariance matrix (from P to P′ to P″) related to the bias/drift or INS kinematic state failure.

Figure 4. FDIR/FDE algorithm processing diagram.

The covariance adaptation is the main recovery action performed by the FDIR algorithm, and without this mechanism, a receiver oscillator clock bias/drift discontinuity or a kinematic state divergency at a given time may cause the FDE algorithm to identify all the following observations as invalid, excluding them from their integration in the Kalman filter update phase. FDIR and FDE algorithms are designed to use both PR and PRR measured observations ($\tilde{\mathit{\rho }},\widetilde{\dot{\mathit{\rho }}}$) and predicted observations ($\widehat{\mathit{\rho }},\widehat{\dot{\mathit{\rho }}}$) to provide a VF (validity flag) vector for each FDIR/FDE processing block as an output. The VF and the full update matrices ($\mathsf{\Delta }\mathit{z},\mathit{H},\mathit{R}$) are then collected via common exclusion logic to provide the filtered update matrices ($\mathsf{\Delta }{\mathit{z}}_F,{\mathit{H}}_F,{\mathit{R}}_F$) to the GNSS/INS Kalman filter and perform the measurement update phase.

5. Simulation Environment

A simulation environment for the launcher navigation system was designed (Figure 5) with the main goal to test the GNSS/INS and FDIR/FDE algorithm prototyped in MATLAB (v.23.2) language, allowing the user to perform Monte Carlo simulations and rapidly change the INS/KF configuration based on the space vehicle type (INS_cfg.xlsx) and the sensor error specifications (KF_cfg.xlsx).

Figure 5. MATLAB GNSS/INS simulator.

Spirent SimGEN/SimSENSOR engines were used to provide the kinematic truth reference, the satellite data (in terms of range and range rates), and the sensors data without errors (IMU, altimeter). A performance error model was implemented for the sensors and the GNSS receiver, enabling the failures and threats to be introduced through a user-defined time-schedule data file (SIM_cfg.xlsx) and an error budget file (EB_cfg.xlsx). The simulator is also capable of using real GNSS receiver data provided by Qascom’s QN400 Space Software Defined Receiver to verify the tracking loop performance of the real receiver in the most representative RF scenario for the future project needs. Moreover, the use of a real GNSS receiver combined with an RF interference generator (such as Qascom QA707) will allow in the future the implementation of scenarios with spoofing and jamming interference performed at the RF level.

6. Simulation Scenario

The scenario [SC-001] for the Vega launch into LEO orbit (Figure 6) was selected to present the results for the robust GNSS/INS architecture. For each threat/failure, a specific ID was defined, and a single simulation was performed to compare the performance of the navigation system with/without the FDIR/FDE algorithm for robust navigation. The threat and failure IDs are defined in Table 1 and the main flight events, which correspond to the time of failure, are reported in Table 2. A navigation grade IMU was selected for the Vega scenario applications, and the main error parameters are reported in Table 3 and are in accordance with the data reported in [7]. A static period of 5 min was considered at the start of the scenario to allow for the INS system leveling and alignment through ZUPT and to emulate the required period to perform the acquisition and tracking of enough satellites for the GNSS receiver.

Figure 6. Vega LEO simulation scenario.

Table 1. Threat and failure IDs for the simulation.

ID	Threat and Failure	Description
01	SV clock bias and drift discontinuity	(a) Single SV step error of 300 m (b) Single SV drift error of 0.5 m/s
13	Spoofing	(a) Spoofing of 4 SV with drift error of 0.2 m/s (b) Spoofing of 4 SV with step error of 50 m
19	Receiver clock bias and drift discontinuity	Receiver clock step error of 1000 Km
22	Receiver HW failure	Zero-hold measures for 50 s
25	IMU saturation	Accelerometer x–y–z-axes saturation for 0.01 s
27	IMU coning and sculling	30 Hz coning motion with 1 mrad amplitude on gyro X–Y-axes and 30 Hz sculling motion of 1 mm amplitude on accelerometer X-axis
28	IMU HW failure	Zero-hold measures for 15 s
29	INS numerical failure	Introduction of negative value (−10) in the covariance matrix diagonal for tilt x state
30	Vibration G-rms	Vibration of 6 G-rms
31	GNSS signal outage	Signal outage of 15 s

Table 2. Timeline scenario of threat and failure introduction.

Time (s)	Flight Event	Threat and Failure ID
		01	13	19	22	25	27	28	29	30	31
300	1st stage ignition
367	Max. dynamic pressure
390	1st stage separation		a
407	2nd stage ignition
480	2nd stage separation	a
517	3rd stage ignition
522	Fairing Jettison
629	3rd stage separation	b
649	4th stage ignition		b
1024	End of first boost

Table 3. IMU error budget parameters for gyroscope and accelerometer.

	Gyroscope Errors		Accelerometer Errors
Parameter	Unit	Value	Unit	Value
Full scale (FS)	°/s	1000	g	40
Quantization	°/h	1.68 × 10−3	µg	1.86 × 10−2
Noise, angle/velocity random walk	°/√h	0.01	µg/√Hz	20
Noise, flicker	°/h	0.02	µg	10
Bias, on/off repeatability	°/h	0.1	µg	200
Bias, rate/acceleration random walk	°√h	0.005	µg/√h	10
Bias, thermal residual, τ = 10 min	°/hr	0.01	µg	10
Bias, vibration sensitivity	°/h/g2	0.01	µg/g2	50
Scale factor, on/off repeatability	ppm	100	ppm	100
Scale factor, non-linearity	ppm@FS	50	ppm@FS	50
Scale factor, drift, τ = 1 month	ppm/√month	10	ppm/√month	50
Misalignment	mrad	0.1	mrad	0.1
Non-orthogonality	mrad	0.05	mrad	0.05
Bias, G-sensitivity	°/h/g	0.01	-	-
Scale factor, G-sensitivity	ppm/g	1	-	-

7. Simulation Results

Simulation results are reported for the [SC-001] in terms of normalized RMS error with respect to the accuracy requirements to better identify the most critical threat/failure IDs. The receiver clock discontinuity (ID 19), the IMU accelerometer saturation (ID 25), and the IMU HW failure (ID 28) have the most detrimental effects in terms of performance degradation, as reported in Figure 7.

Figure 7. Vega LEO—normalized RMS error for each threat ID.

The ability of the FDIR algorithm to exclude failures and recover the system in the most serious scenarios is depicted in the following figures with the associated KF-3σ standard deviation. When a receiver clock bias discontinuity is emulated (ID 19), the FDIR algorithm adapts the clock bias KF covariance to respond quickly to the common bias variation in all PR measurements, reducing the position error (see Figure 8).

Figure 8. Vega LEO—horizontal position error and clock bias with threat ID 19.

When an IMU accelerometer saturation is emulated (ID 25), the FDIR algorithm correctly identifies this failure as an INS kinematic divergency, and thus performs the covariance pumping in the proper KF velocity covariance elements to respond quickly to the discrepancy between the predicted GNSS only and the GNSS/INS solution (see Figure 9).

Figure 9. Vega LEO—horizontal position/velocity errors with threat ID 25.

When a failure is emulated in the primary IMU (ID 28), the IMU FDIR algorithm correctly identifies the failure and switches the navigation system to use the secondary IMU. The switch to the backup IMU is performed before the failure affects the navigation system kinematic performance, propagating the attitude kinematic states, which can lead to the total failure of the launcher mission (see Figure 10).

Figure 10. Vega LEO—horizontal position/velocity and attitude errors with threat ID 28.

8. Conclusions

In the present work, a new architecture for robust GNSS/INS navigation in launcher applications has been proposed. The new architecture uses a combination of different FDIR/FDE techniques at the GNSS and IMU level to overcome the possible failure and threats introduced in launcher scenarios. A simulation scenario based on MATLAB has been developed to allow for the user to rapidly change the navigator configuration or enable/disable the usage of additional sensors (e.g.: star sensor or radar-altimeter) to select the type of IMU and modify the GNSS receiver model parameters. A comparison between the navigation performance before and after the introduction of the robust navigation techniques has been reported, showing a drastic reduction in the errors, especially regarding receiver clock step failures, accelerometer saturation, and IMU failures, which have been identified as the most detrimental failures for a launcher navigation system.

At the time of writing, the GNSS/INS engine has also been prototyped in C++ and tested on a Zynq 7000-based target platform, considering all the possible sensor data latency that a real-time system must deal with. The future goal for the project is to perform a realistic emulation of the navigation system for launcher applications in terms of simulation environments, sensor performance, and computation capability, leading the way for a possible future integration into an on-board computer.