Outlier Rejection, Fault Detection and Robust Fusion

4.2.16 Outlier Rejection, Fault Detection and Robust Fusion

Innovation gating, discussed in the previous section, answers an immediate question:

\[ \boxed{ \text{Should this particular measurement be used in the estimator update?} } \]

But spacecraft navigation must answer a broader and more difficult set of questions:

\[ \boxed{ \text{Is the sensor actually becoming faulty?} } \]

\[ \boxed{ \text{Is the abnormal measurement only a temporary outlier?} } \]

\[ \boxed{ \text{Should the sensor be isolated from the estimator?} } \]

\[ \boxed{ \text{Can navigation continue safely using the remaining sensors?} } \]

\[ \boxed{ \text{Should the mission enter a degraded navigation mode?} } \]

These questions form the basis of outlier rejection, fault detection, fault isolation, recovery, and robust sensor fusion.

A practical spacecraft estimator cannot be designed under the assumption that every sensor always behaves exactly according to its nominal Gaussian noise model.

Real sensors may experience:

• isolated spikes,
• temporary bad measurements,
• persistent bias,
• slowly drifting bias,
• excessive noise,
• frozen measurements,
• intermittent dropouts,
• timestamp corruption,
• communication faults,
• incorrect covariance reporting,
• saturation,
• false target detections,
• incorrect feature associations,
• environmental interference,
• complete sensor failure.

Therefore, robust navigation requires several layers of protection.

A useful high-level architecture is

\[ \boxed{ \text{Sensor Measurement} } \]

\[ \downarrow \]

\[ \boxed{ \text{Basic Validation} } \]

\[ \downarrow \]

\[ \boxed{ \text{Innovation / Outlier Test} } \]

\[ \downarrow \]

\[ \boxed{ \text{Fault Detection} } \]

\[ \downarrow \]

\[ \boxed{ \text{Fault Isolation} } \]

\[ \downarrow \]

\[ \boxed{ \text{Sensor Reweighting / Exclusion} } \]

\[ \downarrow \]

\[ \boxed{ \text{Degraded or Reconfigured Navigation}. } \]

The important principle is:

\[ \boxed{ \text{Robust Sensor Fusion Does Not Merely Estimate the State; It Also Evaluates Whether Its Information Sources Can Still Be Trusted.} } \]

4.2.16.1 Outlier, Fault and Failure Are Not the Same

These terms should be distinguished carefully.

An outlier is an individual measurement that is inconsistent with the expected measurement distribution.

A fault is an abnormal condition in a sensor, interface, model, or processing chain.

A failure is a condition where the subsystem can no longer perform its required function.

Thus:

\[ \boxed{ \text{Outlier} \neq \text{Fault} \neq \text{Failure}. } \]

For example, one camera feature may be mismatched while the camera itself remains fully healthy.

Similarly, one GNSS measurement may contain multipath without implying receiver failure.

4.2.16.2 Why This Distinction Matters

If every outlier is treated as a sensor failure, healthy sensors may be unnecessarily disabled.

If every abnormal measurement is treated as harmless noise, a genuine fault may remain undetected.

Therefore the estimator must distinguish between:

\[ \boxed{ \text{Temporary Measurement Problem} } \]

and

\[ \boxed{ \text{Persistent Sensor Problem}. } \]

This usually requires considering behavior over time rather than one measurement alone.

4.2.16.3 Categories of Measurement Abnormalities

A useful classification is:

Isolated Outlier

One unusual sample appears but subsequent measurements return to normal.

Persistent Bias

Measurements remain shifted by approximately a constant amount.

Drift

Measurement error gradually increases with time.

Excessive Noise

The mean may remain correct, but measurement variance increases significantly.

Frozen Measurement

The sensor repeatedly outputs an old or constant value.

Dropout

Measurements stop arriving.

Intermittent Fault

The sensor alternates between valid and invalid behavior.

Complete Failure

The sensor provides no useful navigation information.

These cases require different detection and recovery strategies.

4.2.16.4 Isolated Outliers

Suppose the nominal measurement is

\[ z_k = h(x_k)+v_k. \]

An outlier may be represented as

\[ \boxed{ z_k = h(x_k) + v_k + o_k } \]

where

\[ o_k \]

is a large abnormal error.

For most samples:

\[ o_k=0. \]

For occasional outliers:

\[ |o_k| \gg \sigma_v. \]

Innovation gating is usually very effective against this type of error.

4.2.16.5 Why One Outlier Can Be Dangerous

In a Kalman-type estimator:

\[ \boxed{ \hat x^+ = \hat x^- + Kr. } \]

If the innovation

\[ r \]

is extremely large, then the correction

\[ Kr \]

can also become large.

Therefore one bad measurement can abruptly pull the estimated state away from the true trajectory.

This is especially dangerous during close-proximity RPO, where navigation errors can propagate directly into guidance and control commands.

4.2.16.6 Persistent Bias

A biased sensor may be represented as

\[ \boxed{ z_k = h(x_k) + b + v_k. } \]

If

\[ b \]

is small, individual measurements may still pass the innovation gate.

But the innovation mean becomes approximately

\[ \boxed{ E[r_k] \approx b. } \]

Therefore persistent innovation bias is often more informative than a single gate failure.

4.2.16.7 Bias Detection

A moving-average innovation can be defined as

\[ \boxed{ \bar r_k = \frac{1}{N} \sum_{i=k-N+1}^{k} r_i. } \]

For an unbiased measurement process:

\[ \bar r_k \approx0. \]

A persistent nonzero value can indicate:

• sensor bias,
• calibration error,
• timing bias,
• frame misalignment,
• modelling bias.

4.2.16.8 Drift Fault

A drift fault develops gradually.

For example:

\[ \boxed{ b_{k+1} = b_k + d\Delta t } \]

where

\[ d \]

is the drift rate.

Because each individual change may be small, instantaneous innovation gating may not detect the fault early.

Trend-based monitoring becomes necessary.

4.2.16.9 Why Slowly Developing Faults Are Difficult

A slowly drifting sensor may remain inside the statistical gate for a long period.

Thus:

\[ \boxed{ \text{Measurement Passes Gate} } \]

does not necessarily imply

\[ \boxed{ \text{Sensor Is Healthy}. } \]

Long-term residual statistics are needed.

4.2.16.10 Excessive Noise Fault

Suppose the expected measurement covariance is

\[ R. \]

A degraded sensor may instead have

\[ \boxed{ R_{\text{actual}} > R_{\text{nominal}}. } \]

The mean measurement may still be correct, but innovations become more variable.

Symptoms include:

• frequent gate failures,
• larger innovation variance,
• unstable measurement corrections.

4.2.16.11 Detecting Excessive Noise

Compare empirical innovation covariance:

\[ \boxed{ \hat S = \frac{1}{N-1} \sum_{k=1}^{N} (r_k-\bar r)(r_k-\bar r)^T } \]

with the predicted covariance:

\[ \boxed{ S_k = HP^-H^T+R. } \]

If the empirical covariance becomes consistently larger than predicted, the sensor noise model may no longer be valid.

4.2.16.12 Frozen Sensor Fault

A frozen sensor may output

\[ \boxed{ z_k=z_{k-1} } \]

for many consecutive samples.

This is dangerous because the value may still look numerically reasonable.

If vehicle motion is small, the frozen measurement may even pass innovation gates initially.

4.2.16.13 Frozen-Data Detection

A simple test monitors

\[ \boxed{ \Delta z_k = z_k-z_{k-1}. } \]

If

\[ \Delta z_k=0 \]

for an unexpectedly long duration while the predicted state is changing, the sensor may be stuck.

A stronger test compares the measurement derivative with predicted dynamics.

4.2.16.14 Measurement Dropout

A dropout means no valid measurement is received.

This is different from an outlier.

For dropout:

\[ \boxed{ \text{No Measurement Update}. } \]

The estimator should continue propagation using:

\[ \boxed{ \text{Dynamics} + \text{Remaining Sensors}. } \]

4.2.16.15 What Happens During Dropout

Without measurement correction:

\[ \boxed{ P_{k+1}^- = F_kP_k^+F_k^T+Q_k. } \]

Covariance therefore generally grows.

This correctly reflects increasing uncertainty.

A healthy estimator should not artificially keep covariance small during prolonged measurement absence.

4.2.16.16 Intermittent Dropout

Some sensors may alternate between:

\[ \boxed{ \text{Available} } \]

and

\[ \boxed{ \text{Unavailable}. } \]

This can happen because of:

• camera occlusion,
• GNSS blockage,
• star-tracker blinding,
• LiDAR geometry,
• communication interruption.

The estimator should therefore support event-driven availability rather than assuming periodic measurements always arrive.

4.2.16.17 Bad Data

Bad data is a broad term that can include:

• corrupted packet values,
• incorrect timestamps,
• invalid units,
• wrong frame transformations,
• impossible measurements,
• incorrect sensor health flags.

Not all bad data originate from the sensor hardware itself.

The complete measurement chain must therefore be monitored.

4.2.16.18 Fault Detection

Fault detection asks:

\[ \boxed{ \text{Has Something Abnormal Occurred?} } \]

Detection does not yet determine which component is responsible.

Possible detection quantities include:

• innovation magnitude,
• NIS,
• innovation mean,
• innovation variance,
• innovation autocorrelation,
• sensor quality flags,
• packet errors,
• timeout conditions.

4.2.16.19 Fault Isolation

Fault isolation asks:

\[ \boxed{ \text{Which Sensor or Subsystem Is Responsible?} } \]

This is usually more difficult than fault detection.

For example, high camera innovation could result from:

• bad camera measurement,
• incorrect attitude prediction,
• timing error,
• frame transformation error,
• target maneuver.

Isolation requires additional evidence.

4.2.16.20 Detection vs Isolation

The sequence is:

\[ \boxed{ \text{Detect Abnormal Behavior} } \]

\[ \downarrow \]

\[ \boxed{ \text{Determine Its Source} } \]

\[ \downarrow \]

\[ \boxed{ \text{Take Corrective Action}. } \]

Thus:

\[ \boxed{ \text{Fault Detection} \neq \text{Fault Isolation}. } \]

4.2.16.21 FDI

FDI means:

\[ \boxed{ \text{Fault Detection and Isolation}. } \]

A navigation FDI system may monitor:

\[ \boxed{ r_i, \quad NIS_i, \quad \text{health}_i, \quad \text{availability}_i. } \]

The objective is to identify abnormal sensor behavior before it corrupts the state estimate.

4.2.16.22 FDIR

FDIR extends FDI to include recovery:

\[ \boxed{ \text{Fault Detection, Isolation and Recovery}. } \]

The complete sequence is:

\[ \boxed{ \text{Detect} \rightarrow \text{Isolate} \rightarrow \text{Recover / Reconfigure}. } \]

Recovery may mean:

• excluding one sensor,
• switching to redundancy,
• changing estimator mode,
• increasing covariance,
• holding the spacecraft,
• entering safe navigation mode.

4.2.16.23 Role of the Navigation Filter in FDIR

The estimator normally should not make every mission-level FDIR decision itself.

Instead it provides diagnostic information such as:

\[ \boxed{ \text{Sensor Validity} } \]

\[ \boxed{ \text{Innovation Statistics} } \]

\[ \boxed{ \text{Covariance} } \]

\[ \boxed{ \text{Navigation Health}. } \]

Higher-level flight software can then determine the required mission response.

4.2.16.24 Innovation-Based Fault Detection

A simple fault detector uses:

\[ \boxed{ NIS_k = r_k^TS_k^{-1}r_k. } \]

If:

\[ NIS_k>\gamma, \]

the measurement is suspicious.

However, one threshold crossing is weak evidence.

Repeated crossings provide stronger evidence.

4.2.16.25 Consecutive Failure Logic

Define:

\[ \boxed{ N_{\text{fail}} } \]

as the number of consecutive failed gates.

A sensor may transition to suspect when:

\[ \boxed{ N_{\text{fail}} \ge N_1. } \]

It may transition to faulted when:

\[ \boxed{ N_{\text{fail}} \ge N_2. } \]

where

\[ N_2>N_1. \]

4.2.16.26 Why Consecutive Logic Helps

Gaussian noise occasionally creates legitimate large residuals.

Therefore a single failure should rarely trigger permanent isolation.

Consecutive logic distinguishes:

\[ \boxed{ \text{Random Statistical Event} } \]

from

\[ \boxed{ \text{Persistent Abnormal Behavior}. } \]

4.2.16.27 Moving-Window Fault Logic

Instead of requiring consecutive failures, count failures in a window.

For example:

\[ \boxed{ N_{\text{reject}} = \sum_{i=k-W+1}^{k} I_i } \]

where

\[ I_i= \begin{cases} 1,&\text{measurement rejected}\\ 0,&\text{measurement accepted}. \end{cases} \]

A sensor becomes suspect if too many failures occur within the window.

4.2.16.28 Rejection Ratio

Define:

\[ \boxed{ f_{\text{reject}} = \frac{ N_{\text{rejected}} }{ N_{\text{total}} }. } \]

A rising rejection ratio may indicate:

• sensor degradation,
• worsening environment,
• covariance mismatch,
• model mismatch.

It provides a useful long-term health metric.

4.2.16.29 CUSUM Fault Detection

Small persistent faults may not cross instantaneous gates.

A Cumulative Sum (CUSUM) detector can accumulate evidence.

Conceptually:

\[ \boxed{ g_k = \max \left( 0, g_{k-1} + s_k-\nu \right) } \]

where

\[ s_k \]

is a fault-sensitive statistic.

If:

\[ g_k>h, \]

a fault is declared.

4.2.16.30 Why CUSUM Helps

Suppose innovation has a small positive bias.

Each sample may remain inside the NIS gate.

But repeated small deviations accumulate.

CUSUM therefore detects:

\[ \boxed{ \text{Small Persistent Faults} } \]

that instantaneous gates may miss.

4.2.16.31 Generalized Likelihood Ratio

Another approach compares:

\[ \boxed{ H_0: \text{Sensor Healthy} } \]

against

\[ \boxed{ H_1: \text{Sensor Faulted}. } \]

The likelihood ratio is

\[ \boxed{ \Lambda = \frac{ p(z|H_1) }{ p(z|H_0) }. } \]

If

\[ \Lambda \]

becomes sufficiently large, the fault hypothesis is favored.

4.2.16.32 Sensor Health State Machine

A practical sensor-health machine may use:

\[ \boxed{ \text{Healthy} } \]

\[ \downarrow \]

\[ \boxed{ \text{Suspect} } \]

\[ \downarrow \]

\[ \boxed{ \text{Faulted} } \]

\[ \downarrow \]

\[ \boxed{ \text{Recovering} } \]

\[ \downarrow \]

\[ \boxed{ \text{Healthy}. } \]

This is much more robust than one Boolean health flag.

4.2.16.33 Healthy State

In the healthy state:

• measurements pass validation,
• NIS statistics are nominal,
• packet integrity is good,
• timing is valid,
• sensor quality flags are acceptable.

The measurements are fused normally.

4.2.16.34 Suspect State

A sensor may become suspect after:

• repeated gate failures,
• abnormal covariance,
• intermittent packet errors,
• unusual innovation trends.

In this state, the estimator may:

• reduce measurement weight,
• increase monitoring,
• require additional confirmation.

4.2.16.35 Faulted State

When sufficient evidence indicates failure:

\[ \boxed{ \text{Sensor Contribution} \rightarrow 0. } \]

The sensor is excluded from state correction.

It may still be monitored diagnostically.

4.2.16.36 Recovering State

A faulted sensor should not necessarily be trusted immediately after valid data reappears.

The system may require:

\[ \boxed{ N_{\text{good}} \ge N_{\text{recover}}. } \]

Only then is it reintroduced.

4.2.16.37 Why Recovery Hysteresis Is Important

Without hysteresis, a marginal sensor may rapidly switch:

\[ \boxed{ \text{Healthy} \leftrightarrow \text{Faulted}. } \]

This can destabilize estimator behavior.

Different fault and recovery criteria reduce such oscillations.

4.2.16.38 Sensor Exclusion

Sensor exclusion means removing one sensor's measurement update from the estimator.

If sensor i is excluded:

\[ \boxed{ K_i r_i \rightarrow 0. } \]

The filter continues using the remaining measurements.

4.2.16.39 Exclusion Must Preserve Covariance Consistency

When a sensor is excluded, no information from that measurement is gained.

Therefore:

\[ \boxed{ P^+ = P^- } \]

for that skipped update.

The covariance should not be artificially reduced.

4.2.16.40 Sensor Isolation vs Measurement Rejection

Measurement rejection is temporary:

\[ \boxed{ \text{Reject One Measurement}. } \]

Sensor isolation is persistent:

\[ \boxed{ \text{Exclude Future Measurements Until Recovery}. } \]

This distinction is fundamental.

4.2.16.41 Robust Fusion

Robust fusion attempts to reduce the effect of abnormal measurements without requiring perfect binary classification.

Instead of:

\[ w \in \{0,1\}, \]

a robust estimator may use:

\[ \boxed{ 0\le w\le1. } \]

Thus a suspicious measurement can influence the estimator less strongly.

4.2.16.42 Hard Rejection

Hard rejection means:

\[ \boxed{ w=0. } \]

A valid measurement receives:

\[ \boxed{ w=1. } \]

This approach is simple and easy to interpret.

4.2.16.43 Soft Reweighting

For a moderately abnormal residual:

\[ \boxed{ 0

The measurement is retained but its influence is reduced.

This may improve continuity when sensor errors are occasionally heavy-tailed rather than completely invalid.

4.2.16.44 Robust M-Estimators

An M-estimator minimizes:

\[ \boxed{ J = \sum_i \rho(e_i) } \]

where

\[ e_i \]

is a normalized residual and

\[ \rho \]

is a robust loss function.

Unlike ordinary least squares, large residuals are given reduced influence.

4.2.16.45 Ordinary Least Squares

Standard Gaussian estimation corresponds approximately to:

\[ \boxed{ \rho(e) = \frac12e^2. } \]

The penalty grows quadratically.

Thus extremely large residuals can dominate the optimization.

4.2.16.46 Huber Loss

Huber loss is:

\[ \boxed{ \rho(e) = \begin{cases} \frac12e^2, & |e|\le c \\ c|e|-\frac12c^2, & |e|>c. \end{cases} } \]

Small residuals behave like Gaussian least squares.

Large residuals grow only linearly.

4.2.16.47 Huber Weight

The corresponding approximate weight is:

\[ \boxed{ w(e) = \begin{cases} 1, & |e|\le c \\ \dfrac{c}{|e|}, & |e|>c. \end{cases} } \]

Therefore:

\[ \boxed{ \text{Large Residual} \rightarrow \text{Reduced Influence}. } \]

4.2.16.48 Tukey Biweight

A stronger robust method is the Tukey biweight.

For sufficiently large residuals:

\[ \boxed{ w(e)\rightarrow0. } \]

Therefore extreme measurements are effectively ignored.

This can work well when genuine gross outliers are expected.

4.2.16.49 Cauchy-Type Robust Loss

Another heavy-tailed loss is:

\[ \boxed{ \rho(e) = \frac{c^2}{2} \ln \left( 1+\frac{e^2}{c^2} \right). } \]

It grows more slowly than quadratic loss for large residuals.

4.2.16.50 Choosing a Robust Loss

The choice depends on expected data characteristics.

Huber:

• keeps moderate residuals,
• easy to tune.

Tukey:

• strongly suppresses extreme outliers.

Cauchy:

• useful for heavy-tailed error distributions.

No robust loss is universally best.

4.2.16.51 Robust Weighting Through R

A robust weight can be implemented by modifying effective covariance:

\[ \boxed{ R_{\text{eff}} = \frac{R}{w}. } \]

If

\[ w<1, \]

then:

\[ R_{\text{eff}}>R. \]

The Kalman gain decreases, reducing measurement influence.

4.2.16.52 Interpretation of Robust Covariance Scaling

For:

\[ w=1, \]

use nominal covariance.

For:

\[ w\ll1, \]

treat the sensor as highly uncertain.

For:

\[ w\rightarrow0, \]

the measurement is effectively ignored.

This provides a smooth transition between normal fusion and rejection.

4.2.16.53 Robust Fusion Is Not a Substitute for FDIR

A severely failed sensor should not simply remain in the estimator with tiny weight forever.

Persistent abnormal behavior should trigger:

\[ \boxed{ \text{Fault Detection} \rightarrow \text{Isolation}. } \]

Robust weighting is most useful for transient contamination and moderate outliers.

4.2.16.54 Heavy-Tailed Measurement Models

Gaussian measurement models assume:

\[ v \sim \mathcal N(0,R). \]

But real data may exhibit heavy tails.

A heavy-tailed likelihood assigns more probability to large errors than a Gaussian distribution.

This reduces overreaction to occasional large residuals.

4.2.16.55 Gaussian Mixture Model

A robust measurement model may be:

\[ \boxed{ p(z|x) = (1-\epsilon) \mathcal N( h(x),R ) + \epsilon \mathcal N( h(x),R_{\text{out}} ). } \]

where:

\[ R_{\text{out}} \gg R. \]

The second component represents outliers.

4.2.16.56 Interpretation of Mixture Models

The estimator acknowledges that a measurement could originate from either:

\[ \boxed{ \text{Nominal Sensor Distribution} } \]

or

\[ \boxed{ \text{Outlier Distribution}. } \]

This is statistically richer than a strict Gaussian assumption.

4.2.16.57 Student-t Measurement Model

Another robust choice is a Student-t likelihood.

Compared with Gaussian noise, it has heavier tails.

Therefore large residuals are less surprising and exert less excessive influence.

This can be useful for optical and LiDAR data with occasional contamination.

4.2.16.58 Robust Sensor Fusion and Particle Filters

Particle Filters naturally support non-Gaussian likelihoods.

Each particle receives weight:

\[ \boxed{ w_i \propto p(z|x_i). } \]

Using robust likelihoods prevents one bad measurement from collapsing the particle distribution incorrectly.

4.2.16.59 Particle Weight Collapse

If a corrupted measurement gives almost zero likelihood to nearly all particles:

\[ \boxed{ N_{\text{eff}} = \frac{ 1 }{ \sum_i w_i^2 } } \]

may become very small.

External validation or robust likelihoods can reduce this risk.

4.2.16.60 Redundancy

Fault-tolerant navigation relies heavily on sensor redundancy.

Redundancy can be:

• identical sensors,
• different sensors measuring the same quantity,
• different sensors indirectly observing the same state.

For example:

\[ \boxed{ \text{Camera Range} } \]

and

\[ \boxed{ \text{LiDAR Range} } \]

may provide cross-checking.

4.2.16.61 Hardware Redundancy

Hardware redundancy means multiple physical units.

For example:

\[ \boxed{ \text{IMU A} + \text{IMU B}. } \]

If one fails, the other can continue navigation.

4.2.16.62 Analytical Redundancy

Analytical redundancy uses models or other sensors rather than duplicate hardware.

For example:

\[ \boxed{ \text{Predicted Angular Rate} } \]

can be compared with:

\[ \boxed{ \text{Gyroscope Measurement}. } \]

The difference provides a residual for fault detection.

4.2.16.63 Cross-Sensor Residual

For two sensors measuring the same quantity:

\[ z_A, z_B, \]

define:

\[ \boxed{ r_{AB} = z_A-z_B. } \]

If independent:

\[ \boxed{ S_{AB} = R_A+R_B. } \]

Then:

\[ \boxed{ d_{AB}^2 = r_{AB}^T S_{AB}^{-1} r_{AB}. } \]

This can detect disagreement.

4.2.16.64 Three-Sensor Isolation

With sensors:

\[ A, B,C, \]

suppose:

\[ A\approx B \]

but:

\[ C \]

disagrees strongly with both.

Then C becomes the most likely faulty branch.

This is a common redundancy principle.

4.2.16.65 Limitation of Majority Voting

Suppose:

\[ A \]

is highly accurate while:

\[ B,C \]

are both poor.

Simple voting could incorrectly reject A.

Therefore:

\[ \boxed{ \text{Covariance-Weighted Consistency} } \]

is preferable to raw voting.

4.2.16.66 Common-Mode Faults

Redundant sensors may share common dependencies.

Examples include:

• common time reference,
• common attitude transformation,
• common power supply,
• common thermal environment,
• common calibration database.

Therefore multiple sensors can agree and still be wrong.

4.2.16.67 Example of Common-Mode Failure

Suppose camera and LiDAR both transform measurements using the same incorrect attitude matrix.

Both may agree with each other.

Yet both may produce incorrect inertial relative position.

Thus:

\[ \boxed{ \text{Sensor Agreement} \neq \text{Guaranteed Correctness}. } \]

4.2.16.68 Federated Fault Isolation

In a federated filter, each sensor or sensor group may have a local estimator.

For branch i:

\[ \boxed{ \hat x_i, \quad P_i, \quad NIS_i. } \]

The master estimator can monitor local-filter health.

4.2.16.69 Benefit of Local Filters

If one local branch becomes faulty, it can be isolated without contaminating all other branches immediately.

This is one reason federated architectures are attractive for fault-tolerant spacecraft navigation.

4.2.16.70 Local Filter Exclusion

If branch j becomes unhealthy:

\[ \boxed{ I_j \rightarrow 0 } \]

where

\[ I_j \]

represents its information contribution.

The master filter then fuses only healthy branches.

4.2.16.71 Degraded Navigation Mode

A degraded mode occurs when the full nominal sensor set is unavailable, but navigation can still continue with reduced performance.

For example:

\[ \boxed{ \text{GNSS + Camera + LiDAR + IMU} } \]

may degrade to:

\[ \boxed{ \text{Camera + IMU}. } \]

The estimator must reflect the increased uncertainty.

4.2.16.72 Degraded Does Not Mean Failed

A degraded mode means:

\[ \boxed{ \text{Reduced Navigation Capability} } \]

not necessarily:

\[ \boxed{ \text{Navigation Failure}. } \]

The key question is whether the remaining performance still satisfies mission requirements.

4.2.16.73 Covariance in Degraded Mode

When sensors are removed, state observability may weaken.

Therefore:

\[ \boxed{ P } \]

typically grows.

Guidance and mission logic should respond to actual covariance, not simply sensor count.

4.2.16.74 Example: GNSS Loss

Suppose GNSS becomes unavailable.

Navigation may continue using:

\[ \boxed{ \text{IMU} + \text{Camera}. } \]

But absolute position observability may degrade.

The covariance should reflect this.

4.2.16.75 Example: Camera Loss

During close-proximity RPO, loss of camera may leave:

\[ \boxed{ \text{LiDAR} + \text{IMU}. } \]

Relative range may remain strong, but some angular or feature-based information may weaken depending on the LiDAR measurement type.

4.2.16.76 Example: LiDAR Loss

If LiDAR fails during close-proximity RPO, camera pose estimation may continue.

However, range precision or robustness may degrade.

Guidance may therefore reduce approach rate or move to a hold point.

4.2.16.77 Example: IMU Fault

An IMU fault is especially important because inertial propagation often runs at the highest rate.

Possible responses include:

• switch to redundant IMU,
• use gyro-only or accelerometer-only fallback,
• reduce maneuvering,
• enter safe mode.

4.2.16.78 Navigation Mode State Machine

A navigation system may define:

\[ \boxed{ \text{NOMINAL} } \]

\[ \boxed{ \text{DEGRADED\_1} } \]

\[ \boxed{ \text{DEGRADED\_2} } \]

\[ \boxed{ \text{NAV\_UNAVAILABLE}. } \]

Transitions depend on sensor health and estimator uncertainty.

4.2.16.79 Navigation Availability

Navigation availability asks:

\[ \boxed{ \text{Can the navigation system provide a usable state estimate right now?} } \]

It depends on:

• active sensors,
• covariance,
• observability,
• state age,
• estimator health.

4.2.16.80 Navigation Integrity

Integrity asks:

\[ \boxed{ \text{Can the system trust that dangerous navigation errors are unlikely to remain undetected?} } \]

Fault detection and robust fusion contribute directly to integrity.

4.2.16.81 Continuity

Continuity refers to maintaining valid navigation without unexpected interruption during a required operation.

Frequent false sensor isolation can damage continuity.

Therefore fault detection must balance protection with availability.

4.2.16.82 Integrity–Availability Trade-Off

A very aggressive fault detector may reject sensors quickly.

This protects integrity but can reduce availability.

A permissive detector may preserve availability but risk accepting faulty data.

Thus:

\[ \boxed{ \text{Integrity} \leftrightarrow \text{Availability}. } \]

This is an important design trade.

4.2.16.83 False Alarm

A false alarm occurs when a healthy sensor is declared faulty.

Define:

\[ \boxed{ P_{FA} = P( \text{Declare Fault} | \text{Sensor Healthy} ). } \]

High false-alarm rates unnecessarily reduce navigation availability.

4.2.16.84 Missed Detection

A missed detection occurs when a faulty sensor remains undetected.

Define:

\[ \boxed{ P_{MD} = P( \text{No Fault Declared} | \text{Sensor Faulty} ). } \]

This can threaten navigation integrity.

4.2.16.85 Detection Probability

Define:

\[ \boxed{ P_D = 1-P_{MD}. } \]

A good fault detector aims for:

\[ \boxed{ P_D \rightarrow1 } \]

while keeping:

\[ \boxed{ P_{FA} } \]

acceptably low.

4.2.16.86 Detection Delay

Fault detection also has a time dimension.

Define:

\[ \boxed{ T_D = t_{\text{detected}} - t_{\text{fault onset}}. } \]

A detector may have high detection probability but still be too slow for close-proximity spacecraft operations.

4.2.16.87 Why Detection Delay Matters in RPO

During final approach, spacecraft state can change significantly over short times.

A sensor fault that remains undetected for several seconds may cause:

• incorrect position estimate,
• wrong relative velocity,
• unsafe thrust command.

Therefore detection speed becomes part of navigation safety.

4.2.16.88 Fault Isolation Delay

Isolation may take longer than detection.

The system might first know:

\[ \boxed{ \text{Something Is Wrong} } \]

before determining:

\[ \boxed{ \text{Which Sensor Is Wrong}. } \]

During this interval, conservative guidance behavior may be appropriate.

4.2.16.89 RPO Far-Range Fault Response

At far range, navigation usually has larger margins.

A temporary sensor issue may lead to:

\[ \boxed{ \text{Continue with Reduced Sensor Set}. } \]

Rapid abort may not be necessary.

4.2.16.90 RPO Mid-Range Fault Response

At mid range, the system may:

• reduce approach rate,
• hold position,
• switch sensor source,
• wait for reacquisition.

The exact response depends on remaining observability.

4.2.16.91 RPO Close-Range Fault Response

Near the target, fault tolerance becomes much more critical.

A critical navigation sensor fault may cause:

\[ \boxed{ \text{Hold} } \]

or

\[ \boxed{ \text{Retreat} } \]

before uncertainty exceeds the safe corridor.

4.2.16.92 Precision Relative-Navigation Fault Logic

During precision RPO, navigation decisions should not depend only on estimated relative state.

The estimator should also confirm that the solution remains trustworthy through:

\\[ \boxed{ \text{Navigation Health} } \\]

and

\\[ \boxed{ \text{Sensor Health}. } \\]

4.2.16.93 Precision-Navigation Condition with Health

A conceptual precision-navigation condition can combine state quality and estimator health:

\\[ \boxed{ \text{PrecisionNavReady} = C_r \land C_v \land C_\theta \land C_\omega \land C_P \land C_H } \\]

where:

• C_r: relative-position condition,
• C_v: relative-velocity condition,
• C_\theta: relative-attitude condition,
• C_\omega: relative angular-rate condition,
• C_P: covariance condition,
• C_H: navigation-health condition.

4.2.16.94 Fault During Precision-Navigation Dwell

Some mission transitions require navigation conditions to remain valid continuously for a dwell time

\\[ T_d. \\]

If a critical sensor becomes faulted during this interval, the dwell should not continue blindly.

Possible responses include:

• pause the dwell,
• reset the dwell,
• hold the current relative-navigation phase,
• transition to a degraded navigation mode.

4.2.16.95 Sensor Reconfiguration

After isolating a faulty sensor, the estimator may need to change:

• measurement model,
• state dimension,
• covariance structure,
• update frequency,
• process-noise tuning.

This is called estimator reconfiguration.

4.2.16.96 State-Dimension Reconfiguration

Suppose a bias state is only associated with a sensor that has been permanently disabled.

The filter may either:

• retain the state,
• freeze it,
• remove it.

Changing state dimension dynamically is possible but increases implementation complexity.

4.2.16.97 Covariance Inflation After Reconfiguration

After losing an important sensor, the estimator may need to increase uncertainty.

Conceptually:

\[ \boxed{ P \leftarrow P+\Delta P. } \]

This should be based on physical reasoning and verification rather than arbitrary inflation.

4.2.16.98 Reinitialization

A severe estimator fault may require reinitialization.

For example:

\[ \boxed{ \hat x \rightarrow \hat x_0 } \]

\[ \boxed{ P \rightarrow P_0. } \]

Reinitialization should generally be a last resort because it discards accumulated navigation information.

4.2.16.99 Sensor Reintroduction

If a sensor recovers, it should usually undergo:

• packet validation,
• timing validation,
• physical validation,
• innovation monitoring,
• confirmation period.

Only then should normal fusion resume.

4.2.16.100 Reintroduction Gate

A returning sensor may require:

\[ \boxed{ N_{\text{good}} \ge N_{\text{required}}. } \]

The measurements may first be monitored without affecting the state.

4.2.16.101 Monitor-Only Mode

In monitor-only mode:

\[ \boxed{ \text{Compute Residuals} } \]

but:

\[ \boxed{ \text{Do Not Update State}. } \]

This allows health to be evaluated before restoring trust.

4.2.16.102 Why Monitor-Only Mode Is Useful

Suppose a camera resumes after temporary blinding.

Immediately trusting the first measurement may be risky.

Monitoring several measurements first confirms:

• target association,
• timing,
• consistency,
• covariance.

4.2.16.103 Fault-Tolerant Fusion Architecture

A robust architecture may be:

\[ \boxed{ \text{Sensor Inputs} } \]

\[ \downarrow \]

\[ \boxed{ \text{Sensor-Specific Validation} } \]

\[ \downarrow \]

\[ \boxed{ \text{Innovation Generation} } \]

\[ \downarrow \]

\[ \boxed{ \text{Outlier Rejection} } \]

\[ \downarrow \]

\[ \boxed{ \text{Health Monitoring} } \]

\[ \downarrow \]

\[ \boxed{ \text{Fault Isolation} } \]

\[ \downarrow \]

\[ \boxed{ \text{Robust Weight / Sensor Exclusion} } \]

\[ \downarrow \]

\[ \boxed{ \text{Fused Navigation State}. } \]

4.2.16.104 Sensor Health Vector

The estimator can maintain:

\[ \boxed{ h = \begin{bmatrix} h_{\text{GNSS}}\\ h_{\text{camera}}\\ h_{\text{LiDAR}}\\ h_{\text{star tracker}}\\ h_{\text{IMU}} \end{bmatrix}. } \]

Each element may contain more than a Boolean value.

4.2.16.105 Rich Sensor Health State

For each sensor, health information may include:

\[ \boxed{ \{ \text{available}, \text{valid}, \text{suspect}, \text{faulted}, \text{recovering} \}. } \]

Additional metrics may include:

• rejection ratio,
• last valid timestamp,
• NIS,
• internal quality.

4.2.16.106 Navigation Health Output

The estimator can produce a global health flag:

\[ \boxed{ H_{\text{nav}}. } \]

Possible states:

\[ \boxed{ \text{NOMINAL} } \]

\[ \boxed{ \text{DEGRADED} } \]

\[ \boxed{ \text{UNSAFE} } \]

\[ \boxed{ \text{INVALID}. } \]

4.2.16.107 Navigation Health Should Depend on Covariance

Sensor count alone is insufficient.

Two healthy sensors may still provide poor observability.

Therefore:

\[ \boxed{ H_{\text{nav}} = f( \text{sensor health}, P, \text{observability}, \text{state age} ). } \]

4.2.16.108 Sensor Exclusion and Observability

Removing a sensor can make some states weakly observable or completely unobservable.

Therefore every sensor-failure mode should be analyzed in terms of remaining observability.

This connects directly to the next section:

\[ \boxed{ 4.2.17\ \text{Observability in Sensor Fusion}. } \]

4.2.16.109 Fault Detection Using Redundant State Estimates

Another approach is to run separate estimators:

\[ \boxed{ \hat x^{(1)}, \hat x^{(2)}, \hat x^{(3)}. } \]

Each excludes or uses different sensors.

Comparing their outputs can help isolate faults.

4.2.16.110 Solution Separation

Suppose:

\[ \hat x_{\text{all}} \]

uses all sensors and:

\[ \hat x_{(-i)} \]

excludes sensor i.

Then define:

\[ \boxed{ \Delta x_i = \hat x_{\text{all}} - \hat x_{(-i)}. } \]

Large separation may indicate that sensor i strongly influences the full solution.

4.2.16.111 Why Solution Separation Helps

Innovation monitoring checks one measurement against one prediction.

Solution separation examines how the complete navigation solution changes when a sensor is removed.

This can provide stronger integrity monitoring.

4.2.16.112 Residual Bank

A residual bank may contain several diagnostic residuals:

\[ \boxed{ r_1, r_2, \dots, r_M. } \]

Each residual is designed to respond differently to different faults.

The pattern of residual activation helps isolate the faulty sensor.

4.2.16.113 Structured Residuals

Suppose:

\[ r_1 \]

is sensitive to GNSS faults but insensitive to camera faults.

Suppose:

\[ r_2 \]

is sensitive to camera faults.

Then the combination of residuals gives a fault signature.

4.2.16.114 Fault Signature Matrix

A conceptual matrix may be:

\[ \boxed{ F = \begin{bmatrix} 1&0&0\\ 1&1&0\\ 0&1&1 \end{bmatrix}. } \]

Each column represents a possible fault.

Each row represents a residual.

The observed residual pattern can help identify the fault source.

4.2.16.115 False Camera Detection

During vision-based RPO, a false target or feature association may produce a large pose error.

Detection layers may include:

• geometric validation,
• RANSAC,
• reprojection error,
• pose-solver confidence,
• innovation gate,
• cross-check with LiDAR.

This is an example of layered fault protection.

4.2.16.116 False LiDAR Pose

LiDAR registration may converge to an incorrect local solution.

Internal metrics such as:

• ICP residual,
• inlier fraction,
• convergence score

should be combined with navigation innovation.

A numerically converged ICP solution is not automatically correct.

4.2.16.117 GNSS Faults

GNSS-related anomalies may include:

• multipath,
• low satellite count,
• poor geometry,
• cycle slip,
• incorrect fix status,
• receiver reset.

Therefore GNSS fault logic should combine receiver status with estimator residuals.

4.2.16.118 Star-Tracker Faults

Star trackers may experience:

• blinding,
• false star identification,
• lost-in-space failure,
• Earth limb contamination.

Internal status flags are especially valuable because estimator residuals alone may not identify the cause.

4.2.16.119 Magnetometer Faults

Magnetometer anomalies may result from:

• onboard current,
• magnetic torquers,
• nearby mechanisms,
• calibration errors.

A useful test compares measured field magnitude with expected geomagnetic magnitude.

4.2.16.120 IMU Faults

IMU fault modes include:

• gyro bias jump,
• accelerometer bias jump,
• excessive noise,
• saturation,
• frozen axis,
• scale-factor error.

Because the IMU drives propagation, these faults can affect the state continuously rather than only at update times.

4.2.16.121 Axis-Level IMU Fault Isolation

A three-axis gyro may have only one faulty axis.

Therefore health monitoring can operate at the component level:

\[ \boxed{ h_{\omega_x}, h_{\omega_y}, h_{\omega_z}. } \]

This can allow partial sensor use if architecture permits.

4.2.16.122 Fault Detection in Propagation Sensors

Measurement sensors produce residuals naturally.

Propagation sensors such as IMUs require indirect residuals.

Examples:

• gyro vs star tracker,
• accelerometer vs GNSS-derived acceleration,
• IMU propagation vs camera pose.

This is analytical redundancy.

4.2.16.123 Fault Detection After Thruster Firing

During a burn, sensor residuals may grow because of:

• vibration,
• timing error,
• incorrect thrust model.

Before isolating sensors, the system should determine whether the anomaly is correlated with actuator events.

4.2.16.124 Actuator Faults Can Look Like Sensor Faults

Suppose commanded thrust is:

\[ F_c \]

but actual thrust is:

\[ F_a \neq F_c. \]

The estimator prediction becomes incorrect.

Multiple sensors may then generate large innovations.

Thus:

\[ \boxed{ \text{Large Sensor Residual} \neq \text{Necessarily Sensor Fault}. } \]

4.2.16.125 Common-Model Check

If many independent sensors simultaneously disagree with prediction, investigate:

• dynamics model,
• actuator model,
• time synchronization,
• common frame transformation.

This is usually more plausible than simultaneous independent sensor failures.

4.2.16.126 Fault-Tolerant RPO Navigation

A robust RPO estimator should support failure of at least some sensing channels while preserving enough information to:

• hold safely,
• retreat,
• abort,
• continue degraded approach if permitted.

This requires sensor redundancy and observability analysis.

4.2.16.127 Mission-Phase Sensor Priority

Different sensors may be critical in different phases.

Far range:

\[ \boxed{ \text{GNSS / Relative GNSS} } \]

may dominate.

Mid range:

\[ \boxed{ \text{GNSS + Camera} } \]

may dominate.

Close range:

\[ \boxed{ \text{Camera + LiDAR + IMU} } \]

may dominate.

Fault handling should therefore be mission-phase aware.

4.2.16.128 Critical vs Non-Critical Sensor Fault

A fault is mission critical if loss of that sensor causes navigation requirements to be violated.

Thus:

\[ \boxed{ \text{Sensor Criticality} = f( \text{Mission Phase}, \text{Redundancy}, \text{Required Accuracy} ). } \]

The same sensor can be noncritical in one phase and critical in another.

4.2.16.129 Fault Response Matrix

A practical system can define a table:

Exact actions depend on mission design.

4.2.16.130 Robust Navigation Does Not Mean Ignoring Bad Sensors

The objective is not to make the estimator tolerate arbitrarily bad data.

The objective is:

\[ \boxed{ \text{Detect} + \text{Limit Influence} + \text{Isolate} + \text{Continue Safely if Possible}. } \]

4.2.16.131 Fault Injection Testing

Estimator robustness should be verified through intentional fault injection.

Examples include:

• measurement spikes,
• step bias,
• ramp drift,
• increased noise,
• frozen values,
• packet loss,
• stale timestamps,
• covariance errors.

4.2.16.132 Step-Bias Injection

Inject:

\[ \boxed{ z_{\text{fault}} = z_{\text{nominal}} + b } \]

at time:

\[ t_f. \]

Measure:

• innovation response,
• detection delay,
• isolation time,
• navigation error.

4.2.16.133 Drift Injection

Use:

\[ \boxed{ b(t) = d(t-t_f) } \]

for:

\[ t\ge t_f. \]

This tests sensitivity to slowly developing faults.

4.2.16.134 Noise Increase Injection

At fault time:

\[ \boxed{ R_{\text{true}} : R_0 \rightarrow \lambda R_0. } \]

with:

\[ \lambda>1. \]

Evaluate whether the monitoring logic identifies the increasing residual variance.

4.2.16.135 Frozen Measurement Injection

After:

\[ t_f, \]

set:

\[ \boxed{ z_k=z(t_f). } \]

Verify whether frozen-data detection triggers before state error becomes excessive.

4.2.16.136 Dropout Injection

Remove measurements for duration:

\[ T_{\text{drop}}. \]

Evaluate:

• covariance growth,
• degraded-mode behavior,
• reacquisition.

4.2.16.137 Intermittent Fault Injection

Introduce faults randomly:

\[ \boxed{ I_k \sim \text{Bernoulli}(p_f). } \]

Then:

\[ z_k = z_k^{nominal} + I_ko_k. \]

This tests robust behavior under intermittent corruption.

4.2.16.138 False Covariance Injection

Keep measurement values correct but provide:

\[ \boxed{ R_{\text{reported}} \neq R_{\text{true}}. } \]

This tests whether consistency monitoring identifies covariance misreporting.

4.2.16.139 Timing Fault Injection

Add:

\[ \boxed{ \Delta t_{\text{fault}}. } \]

Even with perfect sensor values, wrong timing can generate abnormal innovations.

This verifies that timing faults are not incorrectly classified as sensor hardware faults.

4.2.16.140 Frame Fault Injection

Introduce frame rotation:

\[ \boxed{ C_{\text{wrong}} = \Delta C C_{\text{true}}. } \]

Observe systematic residual signatures.

This tests fault isolation between sensor and frame-processing logic.

4.2.16.141 Monte Carlo Fault Analysis

Monte Carlo campaigns should randomize:

• fault onset,
• fault magnitude,
• fault duration,
• affected sensor,
• environmental condition,
• initial state.

Performance should be evaluated statistically.

4.2.16.142 Monte Carlo Fault Metrics

Useful metrics include:

\[ \boxed{ P_D } \]

\[ \boxed{ P_{FA} } \]

\[ \boxed{ T_D } \]

\[ \boxed{ P_{\text{isolation correct}} } \]

\[ \boxed{ \text{Navigation RMSE} } \]

\[ \boxed{ \text{Mission Success Rate}. } \]

4.2.16.143 Fault Containment Metric

Measure maximum navigation error after fault onset:

\[ \boxed{ e_{\max} = \max_{t\ge t_f} \| x(t)-\hat x(t) \|. } \]

This measures how well robust fusion limits the impact of the fault.

4.2.16.144 Detection Before Hazard

A useful requirement is:

\[ \boxed{ T_D < T_{\text{hazard}}. } \]

The fault must be detected before navigation error reaches a hazardous level.

4.2.16.145 Recovery Time

Define:

\[ \boxed{ T_R = t_{\text{recovered}} - t_{\text{fault cleared}}. } \]

This measures how quickly the system safely returns to nominal operation.

4.2.16.146 HIL Fault Testing

Hardware-in-the-loop testing should inject faults at the sensor interface whenever possible.

Examples:

• freeze data stream,
• corrupt selected packets,
• introduce delays,
• alter measurement values,
• change covariance fields.

This validates the actual onboard implementation.

4.2.16.147 Fault Logging

For every detected fault, log:

\[ \boxed{ t_{\text{fault}} } \]

\[ \boxed{ \text{sensorID} } \]

\[ \boxed{ \text{faultType} } \]

\[ \boxed{ NIS } \]

\[ \boxed{ \text{health transition} } \]

\[ \boxed{ \text{recovery action}. } \]

This supports post-flight diagnosis.

4.2.16.148 Fault Reason Codes

Examples:

• OUTLIER
• BIAS_SUSPECTED
• DRIFT_SUSPECTED
• FROZEN_DATA
• EXCESS_NOISE
• DROPOUT
• TIME_INVALID
• FRAME_INVALID
• COVARIANCE_INVALID

Specific reason codes improve traceability.

4.2.16.149 Fault Dashboard

A diagnostic display may show:

This gives immediate visibility into navigation health.

4.2.16.150 Robust Fusion in Simulink

A practical Simulink chain may be:

\[ \boxed{ \text{Sensor Measurement} } \]

\[ \downarrow \]

\[ \boxed{ \text{Validation} } \]

\[ \downarrow \]

\[ \boxed{ \text{Innovation / NIS} } \]

\[ \downarrow \]

\[ \boxed{ \text{Fault Monitor} } \]

\[ \downarrow \]

\[ \boxed{ \text{Weight / Enable Signal} } \]

\[ \downarrow \]

\[ \boxed{ \text{Measurement Update}. } \]

4.2.16.151 Enabled Measurement Update

A hard-rejection implementation can use:

\[ \boxed{ \text{measurementEnable} \in \{0,1\}. } \]

If:

\[ \text{measurementEnable}=0, \]

the update block is bypassed.

4.2.16.152 Weighted Measurement Update

A robust implementation may use:

\[ \boxed{ w\in[0,1]. } \]

Then either:

\[ R_{\text{eff}} = \frac{R}{w} \]

or another robust weighting formulation is used.

4.2.16.153 Sensor-Fault State Machine in Simulink

A Stateflow chart may implement:

\[ \boxed{ \text{Healthy} \rightarrow \text{Suspect} \rightarrow \text{Faulted} \rightarrow \text{Recovering}. } \]

Transitions can use:

• NIS thresholds,
• consecutive failure counts,
• timeout conditions,
• recovery counters.

4.2.16.154 MATLAB Fault-Monitor Function

A conceptual function may be:

\[ \boxed{ [ \text{health}, w, \text{reason} ] = \text{updateSensorHealth} ( NIS, \gamma, q, t ). } \]

This keeps fault-monitoring logic modular.

4.2.16.155 Interface Between Estimator and FDIR

The estimator may output:

\[ \boxed{ \{ \hat x, P, H_{\text{nav}}, h_i, NIS_i, \text{age}_i \}. } \]

FDIR then decides mission-level actions.

4.2.16.156 Do Not Mix Navigation and Mission Decisions Unnecessarily

The estimator should identify:

\[ \boxed{ \text{Navigation Health}. } \]

Guidance and FDIR should decide:

\[ \boxed{ \text{Hold / Retreat / Abort}. } \]

This separation improves software architecture and verification.

4.2.16.157 Fault-Tolerant Design Philosophy

A useful philosophy is:

\[ \boxed{ \text{Detect Early} } \]

\[ \downarrow \]

\[ \boxed{ \text{Limit Fault Influence} } \]

\[ \downarrow \]

\[ \boxed{ \text{Isolate Correctly} } \]

\[ \downarrow \]

\[ \boxed{ \text{Preserve Navigation if Possible} } \]

\[ \downarrow \]

\[ \boxed{ \text{Enter Safe Mode if Necessary}. } \]

4.2.16.158 Common Implementation Mistakes

Typical mistakes include:

• declaring sensor failure after one rejected sample,
• confusing dropout with rejection,
• reducing covariance after rejected data,
• ignoring fault persistence,
• ignoring common-mode failures,
• using majority voting without covariance,
• keeping a permanently failed sensor weakly weighted forever,
• re-enabling a sensor immediately after one valid sample,
• failing to grow covariance in degraded mode,
• assuming redundancy guarantees observability,
• interpreting all high NIS as sensor faults,
• not checking timing and frame errors first,
• allowing navigation health to depend only on sensor count,
• failing to log rejected measurements.

4.2.16.159 Robust Fusion and Safety

Robust fusion creates a protective barrier:

\[ \boxed{ \text{Sensor Fault} } \]

\[ \not\Rightarrow \]

\[ \boxed{ \text{Immediate Navigation Failure}. } \]

Instead:

\[ \boxed{ \text{Sensor Fault} \rightarrow \text{Detection} \rightarrow \text{Isolation} \rightarrow \text{Reconfiguration}. } \]

That is the essential purpose of fault-tolerant sensor fusion.

4.2.16.160 Key Equations at a Glance

Faulted Measurement

\[ \boxed{ z = h(x) + v + f } \]

where f represents fault contribution.

Innovation

\[ \boxed{ r = z-\hat z. } \]

NIS

\[ \boxed{ NIS = r^TS^{-1}r. } \]

Persistent Innovation Mean

\[ \boxed{ \bar r = \frac1N \sum_k r_k. } \]

Rejection Ratio

\[ \boxed{ f_{\text{reject}} = \frac{ N_{\text{rejected}} }{ N_{\text{total}} }. } \]

Robust Weight

\[ \boxed{ 0\le w\le1. } \]

Effective Covariance

\[ \boxed{ R_{\text{eff}} = \frac{R}{w}. } \]

CUSUM

\[ \boxed{ g_k = \max \left( 0, g_{k-1}+s_k-\nu \right). } \]

Detection Delay

\[ \boxed{ T_D = t_{\text{detected}} - t_{\text{fault onset}}. } \]

Effective Particle Number

\[ \boxed{ N_{\text{eff}} = \frac{1}{ \sum_i w_i^2 }. } \]

4.2.16.161 Key Takeaways

The main ideas of robust sensor fusion are:

• An outlier is not automatically a sensor fault.
• A sensor fault is not automatically complete navigation failure.
• Isolated outliers are usually handled by innovation gating.
• Persistent faults require health monitoring over time.
• Bias faults often appear as nonzero innovation mean.
• Drift faults require trend monitoring.
• Excessive noise appears as increased innovation variance.
• Frozen sensors require temporal checks, not only NIS.
• Dropout and rejection are different conditions.
• Fault detection determines whether abnormal behavior exists.
• Fault isolation determines where it originates.
• FDIR adds recovery and system reconfiguration.
• One rejected measurement should rarely disable a sensor permanently.
• Consecutive failure logic reduces false isolation.
• Moving-window statistics help detect intermittent problems.
• CUSUM helps detect small persistent faults.
• Robust weighting can reduce measurement influence without full rejection.
• Huber and other M-estimators provide continuous outlier suppression.
• Heavy-tailed likelihoods improve robustness when Gaussian assumptions are poor.
• Robust weighting does not replace fault isolation.
• Redundant sensors enable cross-checking.
• Covariance should be considered when comparing sensors.
• Common-mode faults remain possible even with redundancy.
• Federated filters can simplify sensor-fault isolation.
• Sensor exclusion must preserve covariance consistency.
• Degraded navigation can remain usable even when one sensor fails.
• Remaining observability must be checked after sensor loss.
• Navigation health should depend on covariance and observability, not sensor count alone.
• Precision relative-navigation logic should include navigation-health conditions.
• A critical sensor failure during close-proximity RPO may require hold, retreat, or abort.
• Sensor reintroduction should normally use a confirmation period.
• Monitor-only mode is useful during recovery.
• Fault-injection testing is essential.
• Monte Carlo analysis should evaluate detection probability and false-alarm probability.
• Detection delay is important for safety.
• HIL testing should verify the implemented FDIR logic.
• Estimator outputs should include sensor and navigation health.
• Mission-level recovery decisions should remain coordinated with guidance and FDIR.

The most important distinction is:

\[ \boxed{ \text{Rejecting One Measurement Is Not the Same as Declaring a Sensor Fault}. } \]

The most important robust-fusion objective is:

\[ \boxed{ \text{Prevent Abnormal Measurements from Causing Large Navigation Errors While Preserving as Much Useful Information as Possible}. } \]

And the most important fault-tolerant navigation principle is:

\[ \boxed{ \text{A Sensor Fault Should Degrade Navigation Gracefully Rather Than Cause Immediate Estimator Failure}. } \]

Next: 4.2.17 Observability in Sensor Fusion

Once a faulty sensor is removed, the next critical question becomes:

\[ \boxed{ \text{Can the Remaining Sensors Still Determine All Required Spacecraft States?} } \]

For example, removing GNSS may leave the spacecraft with camera and IMU measurements, but whether the complete position, velocity, attitude, and bias states remain recoverable depends on the measurement geometry and spacecraft motion.

This leads directly to 4.2.17 Observability in Sensor Fusion, where the key topics should include:

• observable and unobservable states,
• observability matrices,
• rank conditions,
• nonlinear observability,
• local observability,
• sensor geometry,
• range-only observability,
• bearing-only observability,
• attitude observability,
• bias observability,
• clock-bias observability,
• lever-arm and calibration-state observability,
• maneuver-dependent observability,
• persistent excitation,
• sensor dropout and loss of observability,
• observability during RPO phases,
• observability after sensor failures,
• and the connection between observability, covariance growth, and degraded navigation.