4.2.26 Redundancy and Multi-Sensor Fusion

Spacecraft navigation and attitude determination systems rarely depend on a single sensor when the estimated state is mission-critical. A single gyroscope, star tracker, GNSS receiver, camera, or ranging sensor may provide excellent measurements, but any individual sensor can experience noise, bias, temporary loss of visibility, saturation, environmental disturbance, communication failure, or complete hardware failure.

Redundancy introduces multiple sources of information so that the navigation system can continue operating when one source becomes degraded or unavailable. Multi-sensor fusion goes further: instead of merely keeping a backup sensor in reserve, measurements from several sensors can be combined to improve accuracy, availability, observability, integrity, and fault tolerance.

These ideas are related but are not identical:

\[ \boxed{\text{Redundancy} \neq \text{Sensor Fusion}} \]

Redundancy concerns the availability of alternative sources of information. Sensor fusion concerns how information from multiple sources is combined.

A spacecraft may therefore have redundant sensors without continuously fusing them, or it may fuse measurements from several complementary sensors that are not physically redundant.

For example, three gyroscopes may provide homogeneous redundancy because they measure essentially the same physical quantity. A gyroscope, star tracker, and Sun sensor provide heterogeneous redundancy because they use different physical principles but contribute information about spacecraft attitude.

A robust navigation architecture often uses both.

4.2.26.1 Why Redundancy Is Needed

Consider a navigation system relying on one sensor:

\[ z=h(x)+v \]

where

x is the spacecraft state,
z is the measurement,
h(x) is the measurement model,
v is measurement noise.

If that sensor becomes unavailable,

\[ z \rightarrow \text{unavailable}, \]

the estimator may lose direct information about one or more components of the state.

The estimator may continue propagating the state using a dynamics model,

\[ \hat{x}_{k+1}^{-}=f(\hat{x}_k^{+},u_k), \]

but without measurement updates, uncertainty generally increases:

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

Therefore, losing measurements does not necessarily mean that the estimated state immediately becomes invalid. Instead, the navigation solution normally becomes progressively less certain.

Redundant sensing allows another measurement source to maintain or restore observability.

The purpose of redundancy is consequently broader than simply surviving complete hardware failure. It can protect against:

temporary sensor outages,
degraded measurement quality,
obstruction or loss of line of sight,
saturation,
excessive noise,
bias growth,
communication loss,
invalid data,
environmental interference,
processing faults,
calibration errors,
and complete sensor failure.

The central objective is navigation continuity with known uncertainty.

4.2.26.2 Redundancy Versus Diversity

Not all redundancy provides the same level of protection.

Suppose two identical sensors are installed:

\[ S_1,\qquad S_2. \]

If S_1 fails independently, S_2 may continue operating.

However, if both sensors are vulnerable to the same environmental effect or software error, both may fail simultaneously.

This introduces an important distinction between redundancy and diversity.

Redundancy

Redundancy provides multiple channels capable of supplying similar information.

Examples include:

multiple gyroscopes,
multiple star trackers,
multiple GNSS receivers,
multiple cameras,
multiple Sun sensors.

Diversity

Diversity provides measurements using different sensing principles, geometries, hardware implementations, algorithms, or environmental dependencies.

For example,

\[ \text{Gyroscope}+\text{Star Tracker} \]

provides more diversity than

\[ \text{Gyroscope A}+\text{Gyroscope B}. \]

Diversity is particularly valuable against common-cause failures.

A strong spacecraft architecture therefore asks not only:

“How many sensors do we have?”

but also:

“How independent are the failure mechanisms of those sensors?”

4.2.26.3 Homogeneous Redundancy

Homogeneous redundancy uses multiple sensors of the same type to measure the same or closely related quantities.

Suppose three gyroscopes measure angular rate:

\[ \boldsymbol{\omega}_1,\qquad \boldsymbol{\omega}_2,\qquad \boldsymbol{\omega}_3. \]

Ideally,

\[ \boldsymbol{\omega}_1 \approx \boldsymbol{\omega}_2 \approx \boldsymbol{\omega}_3 \approx \boldsymbol{\omega}. \]

Differences among the measurements arise from sensor noise, bias, scale-factor errors, misalignment, temperature effects, and possible faults.

Homogeneous redundancy allows the system to perform cross-checking.

For example,

\[ r_{12} = \boldsymbol{\omega}_1-\boldsymbol{\omega}_2, \]

\[ r_{13} = \boldsymbol{\omega}_1-\boldsymbol{\omega}_3. \]

Large disagreement may indicate that at least one measurement channel is abnormal.

The same concept applies to redundant star trackers, GNSS receivers, accelerometers, cameras, or other navigation sensors.

4.2.26.4 Heterogeneous Redundancy

Two sensors do not have to measure exactly the same physical quantity to provide redundancy at the state-estimation level.

Consider attitude determination.

A gyroscope measures angular rate:

\[ \boldsymbol{\omega}_m = \boldsymbol{\omega} + \mathbf b_g + \mathbf n_g. \]

A star tracker provides an absolute attitude measurement:

\[ q_{ST} = q\otimes\delta q. \]

A Sun sensor may provide a measured direction:

\[ \mathbf s_b = C_{BI}\mathbf s_I+\mathbf v_s. \]

These sensors produce fundamentally different measurements, but all contain information relevant to attitude.

Therefore,

\[ \boxed{ \text{measurement redundancy} \neq \text{state-information redundancy} } \]

Heterogeneous sensing can be especially powerful because different sensors often fail or degrade under different conditions.

4.2.26.5 Active and Standby Redundancy

Redundant sensors do not necessarily have to operate simultaneously.

Two broad strategies are possible.

Active redundancy

Several sensors operate simultaneously:

\[ S_1,\ S_2,\ S_3 \rightarrow \text{Estimator}. \]

Their measurements may be compared and possibly fused continuously.

Advantages include immediate fault detection, cross-validation, and no acquisition delay when one sensor fails.

However, active redundancy can increase power consumption, processing load, thermal load, data traffic, and estimator complexity.

Standby redundancy

One sensor operates while another remains inactive or secondary:

\[ S_1 \rightarrow \text{active}, \qquad S_2 \rightarrow \text{standby}. \]

If the active sensor fails,

\[ S_1\rightarrow\text{failed} \quad\Rightarrow\quad S_2\rightarrow\text{active}. \]

This can reduce power or operational wear, but the replacement sensor may require initialization, acquisition, calibration, or convergence before it can provide usable measurements.

Thus standby redundancy introduces a transition problem, connecting this topic directly to sensor handover.

4.2.26.6 Dual Redundancy

The simplest redundant architecture uses two sensors:

\[ z_1,\qquad z_2. \]

Their disagreement can be monitored:

\[ d=z_1-z_2. \]

A simple consistency test may be

\[ |d|

If this condition is violated, the measurements disagree.

However, two sensors create an important ambiguity.

Suppose

\[ z_1\neq z_2. \]

Which one is faulty?

With only two measurements, disagreement alone generally cannot determine that.

Additional information is needed, such as:

a dynamics prediction,
another independent sensor,
historical sensor health,
innovation statistics,
physical constraints,
or fault-diagnostic logic.

Therefore,

\[ \boxed{\text{Detection does not necessarily imply isolation}} \]

Dual redundancy can detect disagreement more easily than it can identify the failed sensor.

4.2.26.7 Triple Redundancy

Three independent sensors provide additional fault-isolation capability.

Suppose

\[ z_1\approx z_2, \]

while

\[ z_3 \]

differs significantly.

Then the agreement between z_1 and z_2 provides evidence that z_3 may be faulty.

This is the basis of majority voting.

For scalar measurements,

\[ z_{\text{vote}} = \operatorname{median}(z_1,z_2,z_3). \]

The median is attractive because one extreme outlier does not dominate the result.

For example, if

\[ z_1=10.01,\qquad z_2=10.03,\qquad z_3=17.2, \]

then

\[ z_{\text{vote}}=10.03. \]

The obviously abnormal third measurement is rejected naturally.

Triple redundancy therefore provides much stronger fault isolation than simple dual redundancy, provided the failure assumptions underlying the voting logic are valid.

4.2.26.8 Majority Voting

Voting is one of the simplest forms of redundant sensor management.

For three binary health decisions,

\[ H_1,\ H_2,\ H_3\in\{0,1\}, \]

a majority decision may be based on

\[ H_{\text{vote}} = \operatorname{majority}(H_1,H_2,H_3). \]

For continuous measurements, voting can instead use:

median selection,
pairwise agreement,
threshold clustering,
nearest-neighbour agreement,
or consistency with a predicted state.

Voting is useful when sensors are expected to provide equivalent information.

However, it is not automatically optimal for noisy continuous navigation measurements.

Two mediocre measurements can outvote one highly accurate measurement.

Therefore, voting is primarily a fault-management mechanism, not necessarily the best statistical estimation mechanism.

4.2.26.9 Sensor Selection

Another strategy is to select one sensor from several available sensors.

Suppose sensors provide measurements

\[ z_1,z_2,\ldots,z_m. \]

A health and quality function can assign each sensor a score:

\[ Q_i=f(\text{health},\text{noise},\text{geometry},\text{innovation},\text{availability},\ldots). \]

The system may select

\[ i^*=\arg\max_i Q_i. \]

Then

\[ z=z_{i^*}. \]

This approach is different from fusion because only one measurement source may be used at a time.

Selection can simplify estimator interfaces but discards potentially useful information from other valid sensors.

4.2.26.10 Averaging Redundant Measurements

If several sensors measure the same scalar quantity and have similar independent noise characteristics, simple averaging may reduce random noise.

For N measurements,

\[ z_i=x+v_i, \]

the average is

\[ \bar z = \frac{1}{N} \sum_{i=1}^{N}z_i. \]

If the measurement noises are independent, zero mean, and have equal variance

\[ \operatorname{Var}(v_i)=\sigma^2, \]

then

\[ \operatorname{Var}(\bar z) = \frac{\sigma^2}{N}. \]

Thus random measurement noise can decrease as more independent sensors are averaged.

But this improvement depends strongly on independence.

If the sensors share common errors, averaging cannot eliminate those errors.

4.2.26.11 Why Simple Averaging Can Be Wrong

Consider

\[ z_1=x+b+v_1, \]

\[ z_2=x+b+v_2, \]

where b is a common bias.

The average becomes

\[ \bar z = x+b+\frac{v_1+v_2}{2}. \]

Random noise is reduced, but the common bias remains:

\[ \boxed{\bar z\neq x} \]

even with many sensors.

Therefore, adding more sensors does not automatically make the estimate accurate.

Redundancy is valuable only when the error structure is understood.

4.2.26.12 Weighted Measurement Fusion

When sensors have different measurement quality, equal averaging is generally inappropriate.

Suppose

\[ z_1=x+v_1, \qquad z_2=x+v_2, \]

with

\[ v_1\sim\mathcal N(0,R_1), \qquad v_2\sim\mathcal N(0,R_2). \]

For independent scalar measurements, an information-weighted estimate is

\[ \hat{x} = \frac{ R_1^{-1}z_1+R_2^{-1}z_2 }{ R_1^{-1}+R_2^{-1} }. \]

The fused variance is

\[ P = \left( R_1^{-1}+R_2^{-1} \right)^{-1}. \]

The measurement with lower variance contributes more information.

This leads to an important principle:

\[ \boxed{ \text{Fusion weight should reflect measurement uncertainty} } \]

rather than arbitrary preference.

4.2.26.13 Matrix Form of Weighted Fusion

For vector estimates,

\[ \hat{\mathbf x}_1,\qquad \hat{\mathbf x}_2, \]

with independent covariances

\[ P_1,\qquad P_2, \]

the information matrices are

\[ Y_1=P_1^{-1}, \qquad Y_2=P_2^{-1}. \]

The combined information is

\[ Y_f=Y_1+Y_2, \]

and therefore

\[ P_f= \left(P_1^{-1}+P_2^{-1}\right)^{-1}. \]

The fused state becomes

\[ \boxed{ \hat{\mathbf x}_f = P_f \left( P_1^{-1}\hat{\mathbf x}_1 + P_2^{-1}\hat{\mathbf x}_2 \right) } \]

when the two estimates are independent.

That final condition is critical.

4.2.26.14 Measurement-Level Fusion

When raw or processed sensor measurements are available to a common estimator, the measurements can be incorporated directly:

\[ z_1=h_1(x)+v_1, \]

\[ z_2=h_2(x)+v_2, \]

\[ \vdots \]

\[ z_m=h_m(x)+v_m. \]

The measurement vector may be stacked:

\[ \mathbf z = \begin{bmatrix} z_1\\ z_2\\ \vdots\\ z_m \end{bmatrix}. \]

The corresponding measurement model is

\[ \mathbf z = \mathbf h(x)+\mathbf v. \]

This architecture allows the estimator to work directly with the sensor models and their uncertainties.

It can preserve more information than combining already processed state estimates.

4.2.26.15 Sequential Multi-Sensor Updates

Measurements do not need to arrive simultaneously.

Suppose sensor A provides a measurement at time t_A, followed by sensor B at t_B.

The estimator may perform

\[ \hat{x}^{-} \xrightarrow{z_A} \hat{x}^{+A} \xrightarrow{z_B} \hat{x}^{+B}. \]

Each sensor contributes information when its measurement becomes available.

This is especially important in spacecraft systems because different sensors may have very different update rates.

An IMU may update rapidly, while an optical navigation system may update much more slowly.

Multi-sensor fusion therefore naturally operates as an asynchronous information-processing problem.

4.2.26.16 State-Level Fusion

Sometimes individual subsystems produce complete or partial state estimates rather than raw measurements.

For example,

\[ \hat{x}_A,P_A \]

may come from one navigation subsystem, while

\[ \hat{x}_B,P_B \]

comes from another.

A higher-level estimator can then combine these estimates.

This is known as state-level fusion or track-to-track fusion.

It is attractive for modular spacecraft architectures because each sensor subsystem can perform local processing.

However, state-level fusion introduces one of the most important problems in multi-sensor estimation:

\[ \boxed{\text{correlation}} \]

between the estimates.

4.2.26.17 Why Correlation Matters

Suppose two local estimators use the same inertial propagation data.

Then

\[ \hat{x}_A \]

and

\[ \hat{x}_B \]

are not statistically independent.

Their estimation errors may satisfy

\[ P_{AB} = E[ (\tilde{x}_A) (\tilde{x}_B)^T ] \neq 0. \]

If the fusion algorithm incorrectly assumes

\[ P_{AB}=0, \]

shared information may be counted more than once.

The resulting fused covariance can become too small.

This produces an overconfident estimator.

Therefore,

\[ \boxed{ \text{More fused estimates do not necessarily mean more independent information} } \]

4.2.26.18 Information Double Counting

Suppose two local filters both use the same GNSS measurement.

Later, their state estimates are fused as though they were independent.

The GNSS information has effectively entered the final solution twice.

The resulting covariance may suggest greater certainty than the measurements actually support.

This is called information double counting.

It is one of the major dangers of decentralized and federated multi-sensor architectures.

Avoiding it requires:

tracking cross-covariances,
controlling information flow,
using independent local information,
or employing conservative fusion techniques when correlation is unknown.

4.2.26.19 Covariance Intersection

When the cross-correlation between two estimates is unknown, Covariance Intersection (CI) provides a conservative fusion method.

For two estimates,

\[ (\hat{x}_1,P_1), \qquad (\hat{x}_2,P_2), \]

define

\[ P_{CI}^{-1} = \omega P_1^{-1} + (1-\omega)P_2^{-1}, \]

where

\[ 0\leq\omega\leq1. \]

The fused state is

\[ \hat{x}_{CI} = P_{CI} \left[ \omega P_1^{-1}\hat{x}_1 + (1-\omega)P_2^{-1}\hat{x}_2 \right]. \]

The parameter \omega can be selected according to an objective such as minimizing

\[ \operatorname{tr}(P_{CI}) \]

or

\[ \det(P_{CI}). \]

CI is intentionally conservative because it does not assume unknown correlations are zero.

4.2.26.20 Cross-Checking Redundant Sensors

Before measurements are fused, they should often be checked for consistency.

For sensors i and j,

\[ d_{ij}=z_i-z_j. \]

A normalized disagreement measure can be formed using their expected uncertainty:

\[ D_{ij} = d_{ij}^T S_{ij}^{-1} d_{ij}, \]

where S_{ij} represents the expected covariance of their difference.

Then a consistency condition may be written as

\[ D_{ij}<\gamma. \]

This is more meaningful than comparing measurements using a fixed raw difference because the acceptable disagreement should depend on expected measurement uncertainty.

4.2.26.21 Cross-Checking Against the Navigation Solution

A sensor can also be checked against the estimator prediction.

For sensor i,

\[ \nu_i = z_i-h_i(\hat{x}^{-}). \]

The innovation covariance is

\[ S_i = H_iP^{-}H_i^T+R_i. \]

The normalized innovation squared is

\[ \boxed{ \epsilon_i = \nu_i^T S_i^{-1} \nu_i } \]

A persistently excessive innovation may indicate:

incorrect sensor data,
bias,
timing error,
frame error,
poor calibration,
incorrect covariance,
incorrect dynamics,
or an actual sensor fault.

Therefore, innovation monitoring is useful both for estimation and for FDIR.

4.2.26.22 Fault Detection, Isolation, and Recovery

Redundant sensing is closely connected with FDIR:

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

Detection

Determine whether something abnormal has occurred.

Isolation

Determine which sensor, channel, or subsystem is responsible.

Recovery

Reconfigure the navigation system to maintain the required capability.

For example,

\[ \text{Sensor A nominal} \rightarrow \text{Sensor A suspicious} \rightarrow \text{Sensor A isolated} \rightarrow \text{Sensor B dominant}. \]

Fusion and FDIR should therefore not be designed independently.

4.2.26.23 Hard Faults and Soft Faults

A hard fault produces an obvious loss of functionality.

Examples include:

no output,
invalid status word,
communication loss,
impossible value,
hardware shutdown.

A soft fault is more difficult to detect because the sensor continues producing plausible-looking data.

Examples include:

slowly growing bias,
increased noise,
scale-factor drift,
thermal sensitivity,
intermittent errors,
calibration degradation.

Soft faults are particularly important for sensor fusion because an estimator may continue accepting the measurements.

If R remains artificially small while the sensor quality deteriorates, the faulty sensor can receive excessive weight.

4.2.26.24 Sensor Health States

A useful architecture does not need to classify every sensor simply as

\[ \{\text{healthy},\text{failed}\}. \]

A richer state set may be

\[ \mathcal H_i = \{ \text{unavailable}, \text{acquiring}, \text{valid}, \text{degraded}, \text{suspicious}, \text{failed} \}. \]

This allows the estimator to react gradually.

For example,

\[ \text{valid} \rightarrow \text{degraded} \]

may increase measurement covariance,

while

\[ \text{suspicious} \rightarrow \text{failed} \]

may lead to measurement rejection.

This is often more robust than immediate binary switching.

4.2.26.25 Graceful Degradation

A fault-tolerant spacecraft does not necessarily maintain identical navigation performance after every sensor failure.

Instead, it should degrade in a controlled and predictable manner.

Suppose the nominal system provides

\[ \sigma_r=0.05\ \text{m}. \]

After losing a high-quality ranging sensor, another sensor may still provide

\[ \sigma_r=0.5\ \text{m}. \]

The navigation solution is less accurate but may remain valid for a reduced set of mission operations.

Thus,

\[ \boxed{ \text{Graceful degradation} = \text{reduced capability without uncontrolled loss of navigation} } \]

The estimator must communicate this degradation through its covariance, health flags, and navigation-mode status.

4.2.26.26 Redundancy Management

A dedicated redundancy-management layer may supervise multiple sensors.

Conceptually,

\[ \text{Sensors} \rightarrow \text{Validation} \rightarrow \text{Cross-checking} \rightarrow \text{Health assessment} \rightarrow \text{Selection/Fusion} \rightarrow \text{Estimator}. \]

This layer may perform:

status checking,
timing validation,
range checking,
consistency checking,
innovation monitoring,
sensor voting,
covariance adjustment,
measurement rejection,
channel isolation,
sensor switching,
and recovery management.

The estimator should not blindly accept every measurement merely because it arrived.

4.2.26.27 Redundant Gyroscopes

Gyroscopes are a natural example of homogeneous redundancy.

Suppose

\[ \boldsymbol{\omega}_{m,i} = \boldsymbol{\omega} + \mathbf b_i + \mathbf n_i. \]

With several gyroscopes, the system can compare the measured rates.

However, simply averaging them,

\[ \bar{\boldsymbol{\omega}} = \frac{1}{N} \sum_i \boldsymbol{\omega}_{m,i}, \]

does not remove individual biases unless those biases have suitable statistical properties.

A more sophisticated estimator may include separate bias states:

\[ x= [ q,\, \boldsymbol{\omega},\, \mathbf b_1,\, \mathbf b_2,\, \mathbf b_3 ]^T. \]

This allows the navigation system to distinguish spacecraft motion from sensor-specific bias behaviour.

4.2.26.28 Skewed Redundant Gyroscope Configurations

Redundant inertial sensors do not always have to be aligned exactly with the spacecraft axes.

Suppose several single-axis gyroscopes have sensing directions

\[ \mathbf a_1,\mathbf a_2,\ldots,\mathbf a_m. \]

Their measurements can be written

\[ \mathbf z=A\boldsymbol{\omega}+\mathbf v, \]

where

\[ A= \begin{bmatrix} \mathbf a_1^T\\ \mathbf a_2^T\\ \vdots\\ \mathbf a_m^T \end{bmatrix}. \]

For m>3, the system is overdetermined.

This redundancy can be exploited for both angular-rate estimation and fault detection.

A weighted least-squares solution is

\[ \hat{\boldsymbol{\omega}} = (A^TR^{-1}A)^{-1} A^TR^{-1}\mathbf z. \]

The residual

\[ \mathbf r = \mathbf z-A\hat{\boldsymbol{\omega}} \]

can then provide information about inconsistent sensor channels.

4.2.26.29 Redundant Star Trackers

Multiple star trackers may be used because a single star tracker can temporarily lose valid attitude measurements because of:

Sun intrusion,
Earth or Moon interference,
field-of-view obstruction,
spacecraft structure,
poor star-field geometry,
acquisition failure,
or internal faults.

If two star trackers observe different regions of the sky, their environmental vulnerability can differ.

Their measurements may be independently checked against the propagated attitude estimate.

For star tracker i,

\[ q_{ST,i}. \]

An attitude residual can be obtained from

\[ \delta q_i = q_{ST,i} \otimes \hat q^{-1}. \]

The small-angle part of \delta q_i can then be used as an estimator innovation or consistency metric.

4.2.26.30 Redundant GNSS Receivers

Multiple GNSS receivers can provide redundancy at several levels.

The system may use:

separate receiver hardware,
separate antennas,
multiple frequencies,
multiple constellations,
or independent navigation solutions.

A receiver may provide a complete state estimate,

\[ \hat x_{GNSS}, \]

or individual observables such as pseudorange and Doppler.

Raw-observable fusion can preserve more information, while state-level fusion may provide greater subsystem modularity.

However, redundant GNSS receivers are not necessarily independent if they share:

the same antenna,
the same satellite geometry,
common ephemeris information,
common atmospheric or environmental effects,
or common software.

Again,

\[ \boxed{ \text{hardware redundancy does not guarantee information independence} } \]

4.2.26.31 Redundant Cameras

Optical navigation may employ multiple cameras to improve:

field of view,
geometric coverage,
robustness to occlusion,
target visibility,
depth information,
and fault tolerance.

If two cameras observe the same feature, their measurements may provide geometric redundancy.

For example,

\[ z_1=h_1(x)+v_1, \]

\[ z_2=h_2(x)+v_2. \]

Different camera viewpoints can improve observability because their measurement Jacobians

\[ H_1,\qquad H_2 \]

may constrain different state directions.

Thus redundancy can improve not only reliability but also estimation geometry.

4.2.26.32 Redundant Range Sensors

Several ranging systems may provide overlapping measurements:

\[ \rho_1,\qquad \rho_2,\qquad \rho_3. \]

A direct range cross-check is

\[ d_{ij} = \rho_i-\rho_j. \]

However, the expected disagreement should account for measurement uncertainty:

\[ \operatorname{Var}(d_{ij}) = \sigma_i^2+\sigma_j^2 \]

for independent errors.

Therefore a normalized test is more meaningful:

\[ \frac{ (\rho_i-\rho_j)^2 }{ \sigma_i^2+\sigma_j^2 } <\gamma. \]

This illustrates how statistical reasoning improves simple redundancy checks.

4.2.26.33 Complementary Sensors Versus Redundant Sensors

Complementary sensors provide different information.

For example,

\[ \text{IMU}+\text{GNSS} \]

is primarily complementary.

The IMU provides high-rate motion information, while GNSS provides absolute position and velocity information.

By contrast,

\[ \text{GNSS Receiver A} + \text{GNSS Receiver B} \]

may provide direct redundancy.

A spacecraft navigation architecture often combines both concepts:

\[ \boxed{ \text{complementary fusion} + \text{redundant sensing} } \]

This provides both improved estimation performance and improved fault tolerance.

4.2.26.34 Redundancy and Observability

Redundancy should not be judged only by the number of sensors.

What matters is the independent information those sensors contribute.

For a linearized measurement system,

\[ z=Hx+v, \]

the information contributed by a measurement is related to

\[ H^TR^{-1}H. \]

For multiple sensors,

\[ \mathcal I = \sum_i H_i^TR_i^{-1}H_i. \]

Two sensors with nearly identical geometry may contribute strongly redundant information in one direction while leaving another state direction weakly observed.

Therefore:

\[ \boxed{ \text{more sensors} \not\Rightarrow \text{better observability in every direction} } \]

Sensor geometry matters.

4.2.26.35 Redundancy and Measurement Geometry

Consider two line-of-sight sensors observing approximately the same direction.

Their measurements may strongly constrain transverse motion but provide weak information along the line of sight.

Adding another sensor with nearly identical geometry may reduce noise without significantly improving the weak direction.

A sensor with a different viewpoint may provide substantially more useful information.

Thus a redundancy design should examine:

measurement geometry,
sensitivity matrices,
observability,
covariance eigenvalues,
and condition numbers,

rather than counting sensors alone.

4.2.26.36 Information Gain

A useful way to think about adding a sensor is to ask how much new information it contributes.

Suppose the prior information matrix is

\[ Y^{-}=(P^{-})^{-1}. \]

A linear measurement contributes approximately

\[ \Delta Y = H^TR^{-1}H. \]

Then

\[ Y^{+} = Y^{-} + H^TR^{-1}H. \]

A highly accurate sensor with favourable geometry can produce substantial information gain.

A redundant sensor with nearly identical error and geometry may provide much less new information than expected if its errors are correlated with existing measurements.

4.2.26.37 Common-Mode Errors

Suppose redundant sensors have

\[ z_i=x+b_c+b_i+v_i, \]

where

b_c is a common-mode error,
b_i is a sensor-specific bias,
v_i is random noise.

Averaging several sensors can reduce v_i and possibly some independent b_i, but not b_c.

Examples of common-mode effects can include:

shared timing error,
common thermal environment,
common reference error,
shared calibration model,
shared software defect,
shared power supply disturbance,
common mounting deformation,
or common external interference.

Common-mode errors are therefore central to redundancy design.

4.2.26.38 Common-Cause Failure

A common-cause failure is a single underlying event capable of degrading multiple supposedly redundant channels.

For example, two sensors may be separate hardware units but share the same power rail.

Then

\[ \text{power failure} \Rightarrow S_1\text{ unavailable} + S_2\text{ unavailable}. \]

Similarly, two optical sensors may be vulnerable to the same illumination condition.

Therefore, physical duplication alone is insufficient.

Redundancy should be evaluated across:

hardware,
power,
communication,
software,
algorithms,
mounting,
environmental susceptibility,
and external references.

4.2.26.39 Physical Separation and Redundancy

Physical placement can affect redundancy.

Two sensors mounted close together may experience similar:

thermal conditions,
vibration,
radiation environment,
structural deformation,
field-of-view obstruction,
or contamination.

Separating sensors may improve independence but can introduce other problems such as different structural alignment errors or more complex calibration.

Therefore, sensor placement is part of the navigation architecture, not merely a mechanical-layout decision.

4.2.26.40 Time Correlation

Sensor noise is not always white and independent.

For example,

\[ E[v_kv_{k-j}^T]\neq0. \]

Bias instability, drift, filtering, and preprocessing can create temporal correlation.

If the estimator assumes white measurement noise while the actual sensor error is strongly correlated, repeated measurements may appear to provide more independent information than they really do.

This can lead to underestimated covariance.

Multi-sensor fusion therefore requires attention to both:

\[ \text{cross-sensor correlation} \]

and

\[ \text{temporal correlation}. \]

4.2.26.41 Sensor Preprocessing and Hidden Correlation

Modern sensors often provide internally filtered or processed outputs.

A measurement labelled “position,” “attitude,” or “angular rate” may already contain information from:

internal filtering,
calibration,
aiding sensors,
previous measurements,
or external references.

If the spacecraft estimator later combines that output with the same underlying information, double counting can occur.

Therefore, interface documentation should clearly identify:

what the sensor output represents,
how it was produced,
what aiding information was used,
what covariance accompanies it,
and whether successive outputs are correlated.

4.2.26.42 Sensor Fusion With Different Update Rates

Suppose an IMU operates at

\[ f_{IMU}=100\ \text{Hz}, \]

a GNSS receiver at

\[ f_{GNSS}=10\ \text{Hz}, \]

and an optical sensor at

\[ f_{opt}=2\ \text{Hz}. \]

A common estimator should not wait for all sensors to update simultaneously.

Instead,

\[ \text{propagate} \rightarrow \text{IMU update} \rightarrow \text{propagate} \rightarrow \text{GNSS update} \rightarrow\cdots \]

Measurements should generally be processed according to their actual timestamps.

This is one reason asynchronous filtering is so important in multi-sensor spacecraft navigation.

4.2.26.43 Timestamp Consistency

A measurement from a high-quality sensor can still degrade the navigation solution if its timestamp is incorrect.

Suppose

\[ z(t_k) \]

is processed as though it occurred at

\[ t_k+\Delta t. \]

For a changing state,

\[ x(t_k+\Delta t) \neq x(t_k). \]

The resulting innovation can appear as a sensor error even though the sensor itself is healthy.

Therefore, redundant sensor comparison requires consistent timing.

A pair of sensors should not be declared inconsistent merely because their measurements correspond to different physical times.

4.2.26.44 Frame Consistency

Measurements from multiple sensors must also be expressed in compatible frames.

Suppose sensor A provides

\[ \mathbf z_A \]

in frame A, while sensor B provides

\[ \mathbf z_B \]

in frame B.

Before direct comparison,

\[ \mathbf z_A \]

must be transformed appropriately:

\[ \mathbf z_B^{(A)} = C_{AB}\mathbf z_B. \]

A frame transformation error can appear exactly like sensor disagreement.

Therefore,

\[ \boxed{ \text{cross-checking requires common time, frame, units, and conventions} } \]

4.2.26.45 Calibration Consistency

Redundant sensors may have different:

biases,
scale factors,
mounting angles,
lever arms,
thermal coefficients,
intrinsic calibration parameters.

Suppose

\[ z_i = S_i x+b_i+v_i. \]

Direct comparison of z_1 and z_2 without accounting for S_i and b_i can produce false fault detections.

Therefore, redundancy management depends strongly on correct calibration.

4.2.26.46 Lever-Arm Effects

Sensors mounted at different spacecraft locations may not observe exactly the same motion.

For rotational motion, velocity at sensor location i may include

\[ \mathbf v_i = \mathbf v_{CG} + \boldsymbol{\omega} \times \mathbf r_i. \]

Acceleration includes additional rotational terms.

Therefore, two physically separated inertial sensors cannot always be compared by simply subtracting their outputs.

The expected rigid-body kinematic difference must first be modelled.

This is especially important for high-accuracy cross-checking.

4.2.26.47 Weighted Voting

Voting and covariance weighting can be combined.

Suppose each sensor has a reliability or quality weight

\[ w_i. \]

A weighted estimate may be

\[ \hat{x} = \frac{ \sum_iw_iz_i }{ \sum_iw_i }. \]

However, w_i should have a defensible interpretation.

Possible inputs include:

covariance,
innovation consistency,
sensor health,
geometry,
signal quality,
tracking confidence.

Arbitrary weights can hide modelling errors and make the system difficult to verify.

4.2.26.48 Robust Fusion

Classical least-squares and Kalman filtering can be sensitive to large outliers.

Robust fusion attempts to reduce the influence of measurements that are statistically inconsistent without necessarily rejecting them immediately.

Instead of minimizing

\[ \sum_i r_i^2, \]

a robust estimator may minimize

\[ \sum_i\rho(r_i), \]

where \rho(\cdot) grows more slowly for large residuals.

This allows strong outliers to receive less influence.

Robust methods can be useful when occasional abnormal measurements are expected but hard thresholding would be too aggressive.

4.2.26.49 Measurement Gating

A simpler approach is measurement gating.

For measurement i,

\[ \epsilon_i = \nu_i^TS_i^{-1}\nu_i. \]

Then

\[ \epsilon_i\leq\gamma \]

may lead to measurement acceptance, while

\[ \epsilon_i>\gamma \]

may lead to rejection or further validation.

The threshold should be selected according to the measurement dimension and desired false-alarm probability.

Gating prevents extreme measurements from immediately corrupting the state estimate.

4.2.26.50 One Bad Sensor Can Corrupt the Fused Solution

Fusion is not automatically fault tolerant.

Suppose three sensors are fused and one develops a large bias.

If the estimator still assigns that sensor a small covariance,

\[ R_{\text{faulty}}\ll R_{\text{actual}}, \]

the faulty measurement may receive excessive influence.

Therefore,

\[ \boxed{ \text{multi-sensor fusion without validation can be less robust than careful sensor selection} } \]

Sensor validation must precede or accompany fusion.

4.2.26.51 Covariance Inflation for Degraded Sensors

A degraded sensor does not always need to be completely rejected.

Suppose nominal measurement covariance is

\[ R_i. \]

If sensor quality decreases, the system may use

\[ R_i' = \alpha R_i, \qquad \alpha>1. \]

The sensor then contributes less information while remaining available.

This provides a smooth transition between

\[ \text{fully trusted} \]

and

\[ \text{fully rejected}. \]

This concept also provides a natural bridge to adaptive sensor fusion in Section 4.2.27.

4.2.26.52 Dynamic Sensor Weighting

Sensor quality can change with operating conditions.

Therefore,

\[ R_i=R_i(t,\text{geometry},\text{quality},\text{environment},\ldots). \]

For example, an optical sensor may become more accurate as target image quality improves.

A GNSS measurement may become less reliable under poor geometry.

Instead of fixed fusion weights, the estimator can adapt the measurement covariance according to quality indicators.

This allows sensor dominance to change continuously.

4.2.26.53 Sensor Confidence Is Not the Same as Covariance

A sensor may output a confidence score such as

\[ c_i\in[0,1]. \]

However,

\[ c_i \]

is not automatically a statistical covariance.

A confidence score may be algorithm-specific and may not correspond directly to

\[ E[v_iv_i^T]. \]

Therefore, if confidence is used to modify R_i, the relationship should be calibrated and validated.

For example,

\[ R_i=f(c_i) \]

must be supported by test data or a justified sensor model.

4.2.26.54 Fault Isolation Through Residual Patterns

A single residual may indicate inconsistency but not necessarily identify the faulty source.

With several redundant measurements, patterns of residuals can provide isolation.

Suppose

\[ r_{12}\approx0, \]

\[ r_{13}\gg0, \]

\[ r_{23}\gg0. \]

The pattern suggests sensor 3 disagrees with both sensors 1 and 2.

Residual-pattern reasoning can therefore provide stronger fault isolation than individual threshold tests.

4.2.26.55 Model-Based Fault Detection

Redundancy does not always require multiple physical sensors.

A dynamics model can provide an analytical redundancy source.

The model predicts

\[ \hat z=h(\hat x^{-}), \]

while the sensor provides

\[ z. \]

The residual is

\[ r=z-\hat z. \]

Thus,

\[ \text{physical measurement} \]

can be compared with

\[ \text{model-predicted measurement}. \]

This is called analytical redundancy.

It is extremely useful when adding additional hardware is expensive or impossible.

4.2.26.56 Physical Versus Analytical Redundancy

Physical redundancy

Multiple physical sensors provide alternative measurements.

\[ S_1,\ S_2,\ S_3. \]

Analytical redundancy

A measurement is checked against information generated from models and other sensors.

\[ z_i \quad\text{versus}\quad h_i(\hat x). \]

Practical spacecraft systems often combine both.

Physical redundancy improves hardware fault tolerance.

Analytical redundancy improves fault detection and consistency checking without requiring one-for-one hardware duplication.

4.2.26.57 Redundancy at Different Architecture Levels

Redundancy can exist at several levels:

Sensor-element redundancy

Multiple sensing elements.

Sensor-unit redundancy

Multiple complete sensor units.

Measurement redundancy

Different measurements constrain the same state.

Estimator redundancy

Multiple navigation filters operate in parallel.

Computational redundancy

Navigation algorithms run on redundant processors.

Functional redundancy

Different sensing principles provide equivalent mission capability.

Therefore, “redundant navigation” is broader than simply installing duplicate sensors.

4.2.26.58 Redundant Estimators

Instead of feeding every sensor into one estimator, several estimators may operate simultaneously.

For example,

\[ \mathcal F_A:\text{IMU + GNSS}, \]

\[ \mathcal F_B:\text{IMU + optical navigation}, \]

\[ \mathcal F_C:\text{IMU + ranging}. \]

Their outputs can be compared:

\[ \hat x_A,\quad \hat x_B,\quad \hat x_C. \]

This provides architectural redundancy.

However, because these filters may share IMU data or other information, their estimation errors can be correlated.

Thus redundant estimators create both robustness opportunities and correlation-management challenges.

4.2.26.59 Centralized Multi-Sensor Fusion

A centralized architecture may feed all measurements into one estimator:

\[ \{z_1,z_2,\ldots,z_m\} \rightarrow \mathcal F. \]

Advantages include:

direct access to measurement models,
centralized covariance management,
potentially efficient use of information,
easier treatment of cross-sensor coupling.

Disadvantages include:

greater estimator complexity,
increased interface complexity,
potentially larger computational load,
and a stronger dependence on the central estimator.

Redundancy at the sensor level does not remove a single point of failure at the estimator level.

4.2.26.60 Decentralized Multi-Sensor Fusion

In a decentralized architecture,

\[ S_1\rightarrow\mathcal F_1, \]

\[ S_2\rightarrow\mathcal F_2, \]

\[ S_3\rightarrow\mathcal F_3, \]

and their outputs may later be combined.

This improves modularity and fault containment.

However, it creates challenges involving:

cross-covariance,
common information,
timing,
track-to-track fusion,
and information double counting.

Therefore, decentralization improves some forms of robustness while complicating statistical consistency.

4.2.26.61 Federated Redundancy

A federated architecture uses several local filters and a master fusion stage.

Conceptually,

\[ \mathcal F_1,\mathcal F_2,\ldots,\mathcal F_n \rightarrow \mathcal F_M. \]

Each local filter may use a different sensor subset.

This architecture can provide:

modularity,
fault isolation,
parallel processing,
and graceful degradation.

But information-sharing rules must be carefully designed to prevent overconfidence.

4.2.26.62 Redundancy and Navigation Integrity

Accuracy asks:

How close is the estimate to the true state?

Integrity asks:

Can the system reliably determine whether the estimate is safe to use?

Redundant sensing contributes strongly to integrity because independent measurements can detect inconsistencies that one sensor alone cannot reveal.

A navigation solution may be highly accurate under nominal conditions but have poor integrity if failures cannot be detected.

Therefore,

\[ \boxed{ \text{Accuracy and integrity are different navigation properties} } \]

4.2.26.63 Redundancy and Availability

Navigation availability can be expressed conceptually as

\[ A_{nav} = P(\text{navigation solution satisfies required performance}). \]

Adding redundant sensors can improve availability because loss of one measurement source does not necessarily eliminate the navigation solution.

However, the improvement depends on:

sensor independence,
common-cause failures,
estimator architecture,
switching logic,
required accuracy,
and mission geometry.

Thus redundancy should be evaluated at the navigation-function level, not just the component level.

4.2.26.64 Redundancy and Reliability

Component reliability and navigation reliability are related but not identical.

Suppose two sensors each have reliability R_s.

If either can independently provide the required function and their failures are independent, a simplified parallel reliability expression is

\[ R_{\text{parallel}} = 1-(1-R_s)^2. \]

But real spacecraft sensing systems rarely satisfy perfect independence.

Common-cause failures, shared power, shared processing, environmental effects, and shared references modify this idealized result.

Reliability calculations therefore require realistic architecture assumptions.

4.2.26.65 Redundancy and Sensor Geometry in RPO

In rendezvous and proximity operations, several sensors may contribute relative navigation information, such as:

cameras,
LiDAR,
radar,
relative GNSS where applicable,
bearing measurements,
range measurements,
and inertial sensors.

The useful sensor combination generally changes with operating conditions.

At longer ranges, one sensing family may provide the strongest information.

At closer ranges, optical or active ranging systems may provide increasingly precise relative measurements.

The principle is general:

\[ \boxed{ \text{redundancy should support overlapping navigation capability across operating regimes} } \]

The architecture should not rely on one sensor becoming available at exactly the instant another becomes unusable.

4.2.26.66 Overlapping Sensor Coverage

Suppose sensor A is useful over

\[ r\in[r_{A,\min},r_{A,\max}], \]

and sensor B over

\[ r\in[r_{B,\min},r_{B,\max}]. \]

A robust architecture prefers an overlap interval:

\[ [r_{B,\min},r_{A,\max}] \neq\varnothing. \]

Within this overlap region, both sensors can be:

cross-checked,
calibrated,
compared statistically,
fused,
and assessed for readiness.

Overlap is therefore valuable for both handover and redundancy management.

4.2.26.67 Sensor Diversity in RPO

Different relative-navigation sensors may fail under different conditions.

For example, optical systems depend strongly on image quality and illumination, while active ranging sensors depend on their own signal-return characteristics and geometry.

Using physically different sensing principles can reduce vulnerability to one common environmental condition.

This is a key reason why heterogeneous sensor suites are attractive for safety-critical proximity operations.

The goal is not simply to maximize sensor count but to maximize independent useful information.

4.2.26.68 Fault-Tolerant Fusion During Proximity Operations

As operations become more sensitive to navigation error, sensor redundancy becomes increasingly important.

A general architecture may require:

\[ \text{primary measurement valid} \]

and simultaneously

\[ \text{independent consistency source available}. \]

If disagreement grows,

\[ \text{continue nominal operation} \]

may no longer be appropriate.

The system may instead:

hold,
reduce allowed control authority,
revert to a previous mode,
use a degraded navigation configuration,
or execute predefined fault-response logic.

The exact response depends on mission design, but the general principle is that navigation confidence must constrain operational authority.

4.2.26.69 Redundancy and Control

The controller receives an estimated state:

\[ u=g(\hat x). \]

Therefore, a navigation fault can propagate directly into control commands.

Redundant sensing protects not only the estimator but also downstream control.

A useful architecture may therefore expose:

\[ \hat x, \qquad P, \qquad H_{nav}, \qquad M_{nav}, \]

where

\hat x is the navigation state,
P is covariance,
H_{nav} is navigation health,
M_{nav} is navigation mode.

The controller can then modify its behaviour according to actual navigation capability.

4.2.26.70 Navigation Quality Should Limit Control Authority

Suppose position covariance increases substantially after a sensor failure.

The system should not necessarily continue executing the same precision manoeuvre simply because a numerical state estimate still exists.

Instead,

\[ P>P_{\max} \]

may cause

\[ \text{precision operation inhibited}. \]

This establishes an important GNC principle:

\[ \boxed{ \text{control authority should be compatible with navigation certainty} } \]

Redundancy therefore supports safe control through better awareness of state-estimation quality.

4.2.26.71 Fault-Tolerant Measurement Update

A robust estimator may process each candidate measurement through several stages:

\[ z_i \rightarrow \text{status check} \rightarrow \text{range check} \rightarrow \text{timing check} \rightarrow \text{innovation check} \rightarrow \text{fusion}. \]

Only measurements satisfying the required validity criteria are allowed to update the state.

This prevents a redundant architecture from becoming a mechanism for injecting more faulty data.

4.2.26.72 Sensor Exclusion

If sensor i becomes inconsistent,

\[ \epsilon_i>\gamma, \]

the system may temporarily exclude it:

\[ S_i\rightarrow\text{excluded}. \]

Exclusion should generally be accompanied by a health state and recovery logic.

Otherwise a single noisy sample could permanently remove a healthy sensor.

A more complete sequence may be

\[ \text{valid} \rightarrow \text{suspicious} \rightarrow \text{excluded} \rightarrow \text{revalidation} \rightarrow \text{valid}. \]

4.2.26.73 Sensor Reintegration

A previously excluded sensor should not necessarily be accepted immediately after producing one apparently valid measurement.

Reintegration may require:

\[ N_{\text{good}} \]

consecutive valid measurements,

bounded innovation,

acceptable covariance,

valid sensor status,

and possibly a dwell time.

For example,

\[ N_{\text{good}}\geq N_{\min}. \]

This prevents rapid oscillation between inclusion and exclusion.

4.2.26.74 Hysteresis in Redundancy Management

Suppose exclusion occurs when

\[ \epsilon>\gamma_{\text{out}}. \]

Re-entry may require

\[ \epsilon<\gamma_{\text{in}}, \]

with

\[ \gamma_{\text{in}}<\gamma_{\text{out}}. \]

This creates hysteresis.

It prevents a sensor whose residual lies near the threshold from repeatedly entering and leaving the fused solution.

The same concept used for navigation-mode handover is therefore also useful for sensor health management.

4.2.26.75 Dwell Time

A sensor may be required to remain healthy for a minimum interval

\[ T_{\text{healthy}} \geq T_{\text{dwell}} \]

before reintegration.

Similarly, a sensor may need to remain inconsistent for a specified duration before being declared failed.

Dwell time helps distinguish:

\[ \text{temporary measurement disturbance} \]

from

\[ \text{persistent sensor fault}. \]

4.2.26.76 Fault Confirmation

A robust fault decision may combine several pieces of evidence:

\[ F_i = f( \epsilon_i, d_{ij}, H_i, Q_i, T_i ). \]

Here,

\epsilon_i is innovation consistency,
d_{ij} is cross-sensor disagreement,
H_i is hardware status,
Q_i is quality information,
T_i is persistence time.

This is generally more reliable than declaring a fault from one threshold crossing.

4.2.26.77 Redundancy and False Alarms

Fault detection creates a trade-off.

A very sensitive threshold can detect small faults quickly but may reject healthy measurements.

A loose threshold reduces false alarms but may allow faulty data into the estimator.

Thus the designer balances:

\[ P_D = P(\text{detect fault}|\text{fault}), \]

and

\[ P_{FA} = P(\text{declare fault}|\text{healthy}). \]

Threshold selection should therefore be supported by statistical analysis and testing.

4.2.26.78 Missed Detection

A missed detection occurs when a faulty sensor is accepted as healthy.

This can be particularly dangerous for slowly developing biases because the measurement may remain statistically plausible for some time.

Therefore, fault monitoring should consider not only instantaneous residual magnitude but also:

residual mean,
residual trend,
accumulated statistics,
long-term consistency,
and disagreement with independent sensors.

4.2.26.79 Bias Faults

Suppose

\[ z=x+b+v. \]

If

\[ b \]

slowly increases, individual measurements may remain within the gating threshold.

A windowed residual mean can reveal this:

\[ \bar\nu = \frac{1}{N} \sum_{k=1}^{N}\nu_k. \]

For a correctly modelled unbiased sensor,

\[ E[\nu]\approx0. \]

A persistent non-zero residual mean can therefore indicate bias or model mismatch.

4.2.26.80 Noise Increase

A sensor may remain unbiased but become noisier:

\[ R_{\text{actual}}>R_{\text{model}}. \]

Then the innovation sequence may exhibit excessive variance.

A comparison between measured innovation statistics and predicted

\[ S=HP^-H^T+R \]

can reveal this mismatch.

The response may be to increase R rather than immediately reject the sensor.

This is another connection to adaptive fusion.

4.2.26.81 Stuck Sensor Fault

A sensor can sometimes continue outputting a constant or nearly constant value.

For example,

\[ z_k=z_{k-1}=z_{k-2}=\cdots \]

despite changing spacecraft dynamics.

Range checking alone may not detect this because the value can remain physically plausible.

A temporal plausibility check may examine

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

If expected dynamics imply significant change but

\[ \Delta z_k\approx0 \]

for too long, a stuck-sensor fault may be suspected.

4.2.26.82 Sensor Saturation

A sensor may reach a measurement limit:

\[ |z|\geq z_{\max}. \]

Saturated measurements should not be treated as ordinary Gaussian measurements.

A saturation flag may therefore cause:

rejection,
covariance inflation,
use of another sensor,
or transition to a degraded mode.

Redundant sensors with different dynamic ranges can provide useful diversity against saturation.

4.2.26.83 Redundant Sensor Resolution

Two sensors can be redundant but have very different resolutions.

For example, one may provide coarse but robust information, while another provides precise measurements over a narrower operating range.

Then the lower-resolution sensor may remain useful as:

a cross-check,
a fallback,
an acquisition aid,
or a degraded-mode sensor.

Redundancy therefore does not require equal performance.

4.2.26.84 Primary and Secondary Sensors

A common architecture assigns sensors roles such as

\[ \text{primary}, \qquad \text{secondary}, \qquad \text{monitor}. \]

The primary sensor contributes strongly to the navigation estimate.

The secondary sensor may provide additional information.

The monitor may primarily support consistency checking.

These roles can change dynamically with operating conditions.

A sensor can therefore be secondary in one mode and primary in another.

4.2.26.85 Sensor Priority

Priority may be defined according to:

accuracy,
reliability,
field of view,
power,
computational cost,
geometry,
environmental suitability,
update rate,
or mission phase.

However, fixed priority should not override clear evidence of degraded quality.

A nominally preferred sensor should not remain dominant merely because it is labelled “primary.”

4.2.26.86 Redundancy and Power Management

Operating every redundant sensor continuously may be unnecessary or expensive.

A spacecraft may use:

\[ \text{primary active} + \text{backup standby}. \]

Before a critical phase, additional sensors can be activated and validated.

This creates a sequence:

\[ \text{power on} \rightarrow \text{initialize} \rightarrow \text{acquire} \rightarrow \text{validate} \rightarrow \text{fuse}. \]

Thus redundancy management interacts with spacecraft power and mission sequencing.

4.2.26.87 Warm and Cold Redundancy

Hot redundancy

Backup hardware is powered and operating continuously.

Warm redundancy

Backup hardware is partially active and can become operational quickly.

Cold redundancy

Backup hardware remains powered off until required.

These choices involve trade-offs among:

power,
readiness time,
hardware lifetime,
thermal behaviour,
fault detection,
and switching complexity.

For navigation sensors, acquisition time can be particularly important when choosing between these strategies.

4.2.26.88 Redundancy and Communication Architecture

Redundant sensors may share the same communication bus.

If the bus fails,

\[ S_1,S_2,S_3 \]

may all become inaccessible even though the sensors themselves remain healthy.

Therefore, end-to-end redundancy should consider the entire measurement path:

\[ \text{sensor} \rightarrow \text{power} \rightarrow \text{interface} \rightarrow \text{communication} \rightarrow \text{processor} \rightarrow \text{estimator}. \]

A redundant sensor connected through a single non-redundant critical path may provide less fault tolerance than expected.

4.2.26.89 Redundancy and Software Diversity

Identical sensors processed by identical software may share common software faults.

In some highly critical systems, different implementations or algorithms may be considered to reduce common-mode software risk.

However, software diversity introduces its own verification and maintenance burden.

The important principle is to distinguish:

\[ \text{component duplication} \]

from

\[ \text{failure independence}. \]

4.2.26.90 Redundancy and Calibration Architecture

Multiple sensors may require individual calibration states.

For example,

\[ x= [ x_{nav}, b_1, b_2, b_3 ]^T. \]

The estimator may simultaneously estimate the navigation state and individual sensor biases.

This can improve fault discrimination because disagreement between sensors can be attributed partly to estimated calibration differences rather than immediately interpreted as failure.

However, these calibration states must themselves be observable.

4.2.26.91 Bias Observability

Suppose two sensors measure

\[ z_1=x+b_1, \]

\[ z_2=x+b_2. \]

Their difference is

\[ z_1-z_2=b_1-b_2. \]

This identifies the relative bias, but not necessarily the absolute biases individually.

An independent reference or additional dynamics information may be required.

Therefore, redundant sensors can reveal disagreement without always determining which sensor is absolutely correct.

This is a recurring theme in fault isolation.

4.2.26.92 Redundancy and Truth Ambiguity

If several sensors disagree, the navigation system does not automatically know the truth.

Suppose

\[ z_1\approx z_2 \]

and

\[ z_3 \]

differs.

Majority logic suggests sensor 3 is abnormal.

But if sensors 1 and 2 share a common-mode fault, sensor 3 may actually be correct.

Therefore, majority voting relies on assumptions about failure independence.

This is why sensor diversity is so valuable.

4.2.26.93 Independent Physical Principles

A strong cross-check often comes from a sensor based on a different physical principle.

For example, an inertial propagation solution and an external absolute reference have different error mechanisms.

Their agreement therefore provides more meaningful evidence than agreement between two channels sharing most of their error sources.

The most valuable redundant sensor is not always the most similar sensor.

4.2.26.94 Redundancy and Covariance Realism

Suppose two sensors are healthy but the estimator uses

\[ R_1

The fused covariance becomes too optimistic.

Redundancy cannot compensate for incorrect uncertainty modelling.

Indeed, adding more measurements with underestimated covariance can make inconsistency worse.

Therefore,

\[ \boxed{ \text{redundancy requires realistic covariance models} } \]

4.2.26.95 Redundancy and Consistency

A multi-sensor estimator is consistent when its stated uncertainty agrees statistically with its actual estimation errors.

When truth data are available, NEES can be used:

\[ \epsilon_x = \tilde x^TP^{-1}\tilde x. \]

For individual measurements, NIS can be used:

\[ \epsilon_z = \nu^TS^{-1}\nu. \]

These metrics help determine whether the fused estimator is becoming overconfident after combining redundant information.

4.2.26.96 Why More Sensors Can Produce Worse Consistency

Suppose each new sensor is treated as independent even though the sensors share correlated errors.

Then each update reduces covariance.

After many updates,

\[ P\rightarrow\text{very small}, \]

while the actual estimation error does not decrease proportionally.

The estimator becomes increasingly overconfident.

Therefore,

\[ \boxed{ \text{incorrectly fused redundancy can reduce statistical consistency} } \]

This is why correlation modelling is not an optional theoretical detail.

4.2.26.97 Correlated Measurement Noise

For two measurements,

\[ \mathbf z= \begin{bmatrix} z_1\\ z_2 \end{bmatrix}, \]

the measurement covariance may be

\[ R= \begin{bmatrix} R_1 & R_{12}\\ R_{21} & R_2 \end{bmatrix}. \]

If

\[ R_{12}\neq0, \]

the measurement noises are correlated.

Ignoring these off-diagonal terms changes the information content assigned to the measurements.

Thus the complete covariance structure can matter when redundant sensors share common error sources.

4.2.26.98 Decorrelating Measurements

When the correlation structure is known, measurement transformations can sometimes be used to produce an equivalent decorrelated representation.

Conceptually,

\[ \tilde z=Tz \]

with

\[ \tilde R = TRT^T. \]

A suitable transformation may simplify processing.

However, the transformation must preserve the measurement information and be applied consistently to the measurement model.

The broader point is that correlation should be modelled, not ignored.

4.2.26.99 Sensor Failure Probabilities Are Not Fusion Weights

A sensor reliability such as

\[ P(\text{sensor healthy})=0.999 \]

is not the same as its measurement covariance

\[ R. \]

Reliability describes the likelihood of functioning correctly.

Covariance describes uncertainty in measurements while operating under the assumed model.

Both matter, but they answer different questions.

A highly reliable sensor can be relatively noisy.

A very precise sensor can have poor availability.

4.2.26.100 Accuracy, Reliability, Availability, and Integrity

These properties should be distinguished.

Accuracy

How close is the estimate to truth?

Reliability

How likely is the sensor/system to continue functioning?

Availability

How often is the required navigation capability available?

Integrity

How reliably can unsafe or invalid navigation information be detected?

Redundant multi-sensor architectures are often designed to improve several of these simultaneously, but improving one does not guarantee improvement in all the others.

4.2.26.101 Sensor Fusion Under Partial Failure

A sensor does not always fail completely.

For example, a multi-axis sensor may lose one axis.

Suppose

\[ z= \begin{bmatrix} z_x\\ z_y\\ z_z \end{bmatrix}. \]

If z_z becomes invalid, the estimator may still use

\[ \tilde z= \begin{bmatrix} z_x\\ z_y \end{bmatrix}. \]

This is preferable to discarding the entire sensor if the remaining channels are valid and useful.

Therefore, redundancy management may operate at the measurement-component level, not only at the sensor-unit level.

4.2.26.102 Partial Observability After Failure

After removing one sensor or measurement component, the estimator should determine whether the remaining system still observes the required state.

A navigation solution may remain mathematically computable while some state direction becomes weakly constrained.

This can appear as covariance growth in particular directions.

Therefore, fault recovery should evaluate

\[ P \]

and observability, not merely whether the estimator continues running.

4.2.26.103 Covariance Eigenstructure

The covariance matrix contains directional information.

Let

\[ P=V\Lambda V^T. \]

The eigenvalues

\[ \lambda_1,\lambda_2,\ldots,\lambda_n \]

represent uncertainty along corresponding eigen-directions.

After sensor failure, one eigenvalue may increase substantially while others remain small.

Therefore, a scalar measure such as

\[ \operatorname{tr}(P) \]

may not reveal the full navigation weakness.

Directional uncertainty matters.

4.2.26.104 Redundancy and Mission Requirements

The required level of redundancy depends on what the navigation system must support.

A coarse attitude estimate for safe mode may tolerate fewer sensors than a precision pointing mode.

Similarly, a far-range relative-navigation mode may tolerate larger uncertainty than a terminal proximity operation.

Therefore, redundancy should be linked to mission-mode requirements.

For mode m,

\[ P\preceq P_{\max,m} \]

may represent one part of the navigation requirement.

4.2.26.105 Minimum Sensor Set

For each navigation mode, the designer can define a minimum sensor set:

\[ \mathcal S_{\min,m}. \]

For example, one mode may require only inertial propagation plus a coarse reference, while another may require an additional absolute or relative measurement source.

The active sensor set is

\[ \mathcal S_{\text{active}}. \]

Mode readiness requires more than

\[ \mathcal S_{\min,m} \subseteq \mathcal S_{\text{active}}. \]

The sensors must also satisfy health, quality, geometry, and covariance requirements.

4.2.26.106 N-Modular Redundancy

A general redundant architecture may contain N equivalent channels.

For voting systems, a common requirement is that at least

\[ M \]

of the N channels agree.

This is called an

\[ M\text{-out-of-}N \]

architecture.

Triple modular redundancy is a familiar case:

\[ 2\text{-out-of-}3. \]

Increasing N can improve fault tolerance under certain assumptions but also increases:

hardware,
mass,
power,
interfaces,
processing,
and common-mode complexity.

4.2.26.107 Sensor Voting Is Not Always State Fusion

This distinction is important.

Suppose three sensors provide

\[ z_1,z_2,z_3. \]

Voting may select

\[ z_2. \]

The estimator then receives only z_2.

That is sensor selection using redundancy.

Alternatively, all healthy measurements may be statistically combined:

\[ z_1,z_2,z_3 \rightarrow \hat x. \]

That is multi-sensor fusion.

The two approaches solve related but different problems.

4.2.26.108 Voting Before Fusion

A practical architecture can combine them.

First,

\[ \{z_1,z_2,z_3\} \rightarrow \text{consistency/voting logic}. \]

Then the healthy set

\[ \mathcal S_H \]

is passed to the estimator:

\[ \mathcal S_H \rightarrow \text{fusion}. \]

Thus voting or fault isolation determines which measurements are trusted, while the estimator determines how the trusted information is combined.

4.2.26.109 Fusion-Based Fault Detection

The estimator itself can provide information for redundancy management.

For every sensor,

\[ \nu_i=z_i-h_i(\hat x^-) \]

can be monitored.

Therefore the information flow is bidirectional:

\[ \text{Sensor Manager} \rightarrow \text{Estimator} \]

and

\[ \text{Estimator Innovations} \rightarrow \text{Sensor Manager}. \]

This creates a tightly integrated navigation-and-FDIR architecture.

4.2.26.110 Circular Fault Logic

Care is required when using the fused estimate to judge the sensors that created that estimate.

Suppose one faulty sensor strongly corrupts

\[ \hat x. \]

Other healthy sensors may then appear inconsistent with the corrupted estimate.

This can produce incorrect isolation.

One mitigation is to use:

leave-one-out residuals,
parallel hypotheses,
independent monitors,
or robust estimation.

Fault-detection architecture must therefore consider dependency between the monitor and the data being monitored.

4.2.26.111 Leave-One-Out Consistency Testing

With several sensors, one approach is to construct an estimate without sensor i:

\[ \hat x_{-i}. \]

Then test sensor i against that independent prediction:

\[ \nu_i = z_i-h_i(\hat x_{-i}). \]

This reduces the possibility that the sensor being tested has already pulled the state toward its own faulty measurement.

The method can improve fault isolation, although it increases computational cost.

4.2.26.112 Multiple-Model Fault Isolation

Another strategy is to maintain several hypotheses:

\[ H_0:\text{all sensors healthy}, \]

\[ H_1:\text{sensor 1 faulty}, \]

\[ H_2:\text{sensor 2 faulty}, \]

and so on.

Each hypothesis can generate a likelihood:

\[ p(z|H_i). \]

The system can compare these likelihoods to determine which fault hypothesis best explains the measurements.

This provides a probabilistic approach to redundancy management.

4.2.26.113 Fault Isolation and Multiple Hypotheses

For N sensors, the number of possible fault combinations can grow rapidly.

If every sensor can be either healthy or failed, the theoretical number of combinations is

\[ 2^N. \]

Testing every combination becomes impractical for large N.

Therefore, real systems often restrict the hypothesis set using assumptions such as:

only one simultaneous fault,
predefined credible failure modes,
hierarchical fault isolation,
or subsystem-level monitoring.

4.2.26.114 Sensor Diversity and Fault Hypotheses

Diverse sensors can simplify fault isolation because their failure signatures may differ.

For example, if two sensors based on one physical principle disagree with a third independent sensing principle, the interpretation depends on their known failure modes and environmental conditions.

Thus fault isolation should use not only numerical disagreement but also sensor physics.

4.2.26.115 Redundancy During Sensor Acquisition

A newly activated sensor should not immediately be considered fully redundant.

It may pass through:

\[ \text{OFF} \rightarrow \text{BOOT} \rightarrow \text{ACQUIRE} \rightarrow \text{VALIDATE} \rightarrow \text{AVAILABLE}. \]

During acquisition, another sensor may remain responsible for navigation continuity.

This connects redundancy management with the handover logic developed previously.

4.2.26.116 Redundancy During Handover

During sensor handover, both the outgoing and incoming sensors may be simultaneously valid.

This overlap interval provides a valuable redundancy window.

The system can evaluate

\[ d=z_A-z_B \]

or their normalized innovations before the new sensor becomes dominant.

Thus redundancy is not only a permanent architecture property; it can also be temporarily increased during critical transitions.

4.2.26.117 Redundancy After Handover

After handover, the previous sensor may:

remain active as a monitor,
remain fused with lower weight,
enter standby,
or be powered down.

Keeping it temporarily active can provide additional confidence that the new navigation mode is stable.

However, continuing unnecessary sensors may increase power and processing demands.

4.2.26.118 Redundancy and Sensor Handover Failure

If the incoming sensor fails validation, the navigation system should not discard the previous valid source merely because a nominal transition point has been reached.

A robust transition is therefore

\[ \text{prepare} \rightarrow \text{validate} \rightarrow \text{commit}. \]

If validation fails,

\[ \text{rollback} \rightarrow \text{previous valid configuration}. \]

Redundancy provides the alternative information path that makes this rollback possible.

4.2.26.119 Redundancy and Degraded Mode

Suppose one of several critical sensors fails.

The system may transition from

\[ M_{\text{nominal}} \]

to

\[ M_{\text{degraded}}. \]

In degraded mode:

fewer measurements may be available,
covariance may increase,
update rates may decrease,
some state components may become weakly observable,
and operational permissions may be reduced.

The degraded mode should be deliberately designed and tested.

4.2.26.120 Navigation Reconfiguration

Sensor failure can change the estimator structure itself.

For example,

\[ x= [ r,v,q,b_g,b_a ]^T \]

may contain calibration states associated with sensors that are no longer active.

The filter may:

retain those states,
freeze them,
remove them,
or switch to another estimator configuration.

Reconfiguration must preserve covariance consistency.

4.2.26.121 State Removal

If a sensor-specific state is removed, simply deleting its covariance row and column without considering correlations may be inappropriate.

Suppose

\[ P= \begin{bmatrix} P_{xx}&P_{xb}\\ P_{bx}&P_{bb} \end{bmatrix}. \]

The state b may be correlated with navigation state x.

Estimator reconfiguration should therefore be designed carefully rather than treated as a bookkeeping operation.

4.2.26.122 State Addition

Similarly, activating a new sensor may require introducing a calibration state such as bias b_{new}.

Its initial covariance must represent uncertainty:

\[ P_{b,new}. \]

If initialized too confidently,

\[ P_{b,new}\rightarrow0, \]

the filter may resist correcting an incorrect initial calibration.

If initialized too loosely, convergence may be slow.

Sensor redundancy therefore interacts with estimator-state initialization.

4.2.26.123 Redundancy and Bias Estimation

When multiple sensors measure similar quantities, their disagreement can help estimate relative biases.

Suppose

\[ z_1=x+b_1+v_1, \]

\[ z_2=x+b_2+v_2. \]

Then

\[ z_1-z_2 = b_1-b_2+v_1-v_2. \]

This provides information about

\[ b_1-b_2. \]

Thus redundancy can improve calibration as well as fault tolerance.

4.2.26.124 Redundancy and Scale-Factor Estimation

Suppose

\[ z_i=(1+s_i)x+v_i. \]

With suitable excitation and independent reference information, redundant sensors can help estimate scale-factor differences.

However, without sufficient state excitation, scale factors may be weakly observable.

This illustrates a general principle:

\[ \boxed{ \text{redundancy provides information only when the system is sufficiently observable} } \]

4.2.26.125 Redundancy and Misalignment Estimation

A sensor mounting error may be represented by a small rotation

\[ C_{\text{true}} \approx (I-[\delta\theta\times])C_{\text{nominal}}. \]

Measurements from other sensors can help estimate

\[ \delta\theta. \]

Therefore, multi-sensor fusion can support in-flight alignment calibration.

But misalignment should not be confused with a sensor fault unless the architecture explicitly distinguishes these effects.

4.2.26.126 Sensor Diversity and Calibration

Different sensor types can constrain different calibration parameters.

For example, an inertial sensor may have bias drift, while an optical reference can periodically correct accumulated attitude error.

Thus heterogeneous fusion can make sensor error states observable that would otherwise drift.

This is one of the major benefits of complementary multi-sensor navigation.

4.2.26.127 Redundancy and Navigation Initialization

At startup, several sensors may contribute to initialization.

One sensor may provide coarse orientation.

Another may provide an absolute reference.

An inertial unit may then begin high-rate propagation.

Redundancy allows initialization results to be cross-checked before the navigation solution is declared valid.

Thus redundancy is important not only during steady-state operation but also during startup.

4.2.26.128 Redundancy and Reinitialization

After a severe estimator fault, the system may need to reinitialize navigation.

A redundant independent sensor or estimator can provide a reference state:

\[ \hat x_{\text{backup}} \rightarrow \hat x_{\text{reinitialized}}. \]

However, the uncertainty of the backup solution must be transferred correctly.

Reinitialization should not create artificially small covariance.

4.2.26.129 Redundancy and Safe Mode

A spacecraft safe mode may use a simpler, highly robust sensor set than precision navigation modes.

For example, a coarse attitude reference may be sufficient to maintain basic spacecraft safety even if precision sensors are unavailable.

This is a form of functional redundancy.

The backup does not reproduce full nominal performance; it preserves the minimum required function.

4.2.26.130 Redundancy and Mission Continuation

After sensor failure, the key question is not merely

“Can navigation continue?”

but

“Which operations can safely continue with the remaining navigation capability?”

Therefore, the system should map sensor configuration to allowed mission capability.

Conceptually,

\[ \mathcal S_{\text{active}} \rightarrow (P,H_{nav}) \rightarrow \mathcal O_{\text{allowed}}. \]

This prevents a degraded navigation solution from being used for an operation requiring nominal precision.

4.2.26.131 Redundancy and Measurement Availability

Let

\[ a_i(t)\in\{0,1\} \]

represent measurement availability.

Then the active measurement set is

\[ \mathcal Z(t) = \{z_i:a_i(t)=1\}. \]

The estimator should be capable of operating with changing

\[ \mathcal Z(t). \]

This is fundamental to robust multi-sensor navigation.

The filter should not assume a permanently fixed measurement set.

4.2.26.132 Redundancy and Dynamic Measurement Dimension

Because sensors can enter and leave the active set, measurement dimension may change.

At one update,

\[ z_k\in\mathbb R^{m_1}, \]

while later,

\[ z_{k+1}\in\mathbb R^{m_2}. \]

A flexible estimator architecture builds the measurement vector, Jacobian, and covariance from the currently valid measurements.

This is often preferable to filling unavailable channels with artificial values.

4.2.26.133 Missing Measurements

An unavailable sensor should generally not be represented as

\[ z=0 \]

unless zero is physically the correct measurement.

Instead, the measurement should simply be absent from the update.

Otherwise the estimator may interpret sensor absence as real information.

This simple implementation detail is important in multi-sensor systems.

4.2.26.134 Redundancy and Data Validity Flags

Each measurement should ideally carry metadata such as:

\[ \{ t_i,\, z_i,\, R_i,\, H_i,\, Q_i,\, F_i \}, \]

where

t_i = timestamp,
z_i = measurement,
R_i = covariance,
H_i = health,
Q_i = quality,
F_i = frame or configuration metadata.

Multi-sensor fusion requires more than numerical measurements alone.

4.2.26.135 Sensor Interface Contracts

A sensor-estimator interface should define:

units,
frames,
timestamps,
latency,
covariance meaning,
validity flags,
quality metrics,
saturation behaviour,
failure codes,
reset behaviour,
and update-rate expectations.

Without clear interface contracts, redundancy management becomes fragile.

A statistically sophisticated filter cannot compensate for ambiguous sensor metadata.

4.2.26.136 Redundancy and Latency

Suppose two sensors measure the same state but have different delays:

\[ \tau_1,\qquad\tau_2. \]

Direct comparison of their latest received values may be misleading because the values correspond to different physical times.

Measurements should be aligned to a common epoch or processed according to their true timestamps.

Latency is therefore part of sensor-fusion modelling.

4.2.26.137 Out-of-Sequence Measurements

A delayed measurement may arrive after newer measurements have already been processed.

Such a measurement is called an out-of-sequence measurement.

Simply applying it to the current state can be inconsistent.

Possible approaches include:

state-history buffering,
delayed-state updates,
repropagation,
or rejecting measurements whose latency exceeds allowable bounds.

Multi-sensor architectures with distributed processing must explicitly address this issue.

4.2.26.138 Redundancy and Data Dropouts

Intermittent communication can produce measurement dropouts.

Suppose sensor i normally updates every

\[ \Delta t_i. \]

If

\[ t-t_{i,\text{last}} > T_{\text{timeout}}, \]

the sensor may be marked unavailable.

A timeout should account for expected update rate and communication jitter.

Otherwise a slow but healthy sensor could be incorrectly declared failed.

4.2.26.139 Redundancy and Update-Rate Monitoring

A health monitor can compare observed and expected measurement rates.

For sensor i,

\[ f_{i,\text{obs}} \]

should remain near

\[ f_{i,\text{nom}}. \]

A decreasing update rate may indicate:

communication congestion,
processing overload,
sensor tracking difficulty,
or partial failure.

Thus timing behaviour itself can be a health indicator.

4.2.26.140 Redundancy and Sensor Reset

Some faults can be recovered by resetting the sensor.

A possible sequence is

\[ \text{fault detected} \rightarrow \text{sensor isolated} \rightarrow \text{reset} \rightarrow \text{reacquire} \rightarrow \text{validate} \rightarrow \text{reintegrate}. \]

During this process, redundant sensors maintain navigation continuity.

Without redundancy, resetting a critical sensor may temporarily remove navigation capability.

4.2.26.141 Redundancy and Estimator Reset

A sensor fault and an estimator fault are different.

If one sensor is faulty,

\[ \text{remove sensor} \]

may be sufficient.

Resetting the entire estimator could discard valid accumulated information.

Therefore, fault isolation should distinguish:

\[ \text{sensor fault}, \qquad \text{interface fault}, \qquad \text{estimator fault}. \]

4.2.26.142 Redundant Navigation Chains

For very high fault tolerance, a system may use separate navigation chains:

\[ \text{Sensor Set A} \rightarrow \text{Processor A} \rightarrow \text{Estimator A}, \]

\[ \text{Sensor Set B} \rightarrow \text{Processor B} \rightarrow \text{Estimator B}. \]

This reduces shared single points of failure.

However, truly independent chains require careful treatment of shared resources such as:

clocks,
power,
communication,
software,
and external references.

4.2.26.143 Cross-Channel Monitoring

Two navigation chains can compare their estimated states:

\[ \Delta x = \hat x_A-\hat x_B. \]

A normalized test can use

\[ S_{\Delta} = P_A+P_B-P_{AB}-P_{BA}. \]

If the chains are genuinely independent,

\[ P_{AB}=0, \]

and

\[ S_{\Delta}=P_A+P_B. \]

Again, the correlation assumption determines the validity of the comparison.

4.2.26.144 Three Navigation Chains

Three independent navigation solutions provide a form of state-level majority logic.

If

\[ \hat x_1\approx\hat x_2 \]

but

\[ \hat x_3 \]

differs strongly, the third chain may be considered suspicious.

However, state vectors are multidimensional and have covariances, so simple scalar voting is usually inadequate.

Statistical consistency measures are more appropriate.

4.2.26.145 Redundancy and Processor Failure

Sensor redundancy cannot maintain navigation if all sensor measurements depend on one failed processor.

Therefore, fault-tolerant navigation architecture may also consider computational redundancy.

This may include:

redundant processors,
partitioned software,
watchdogs,
failover logic,
and state synchronization.

The complete navigation chain must be considered.

4.2.26.146 Redundancy and Clock Failure

Multiple sensors may share one timing source.

A clock error can create apparently consistent but systematically wrong timestamps across several sensors.

This is a common-mode failure that sensor voting may not detect.

Independent timing references or clock monitoring can therefore be important in high-integrity navigation systems.

4.2.26.147 Redundancy and Reference Data

Several sensors may depend on common reference data.

Examples include:

ephemerides,
star catalogues,
calibration tables,
landmark databases,
target models.

A corrupted common database can affect multiple sensors simultaneously.

Therefore, redundancy analysis should include data dependencies, not just hardware.

4.2.26.148 Redundancy and Environmental Diversity

Different sensors may be affected differently by:

illumination,
radiation,
thermal environment,
electromagnetic interference,
vibration,
obscuration,
target surface properties.

A diverse sensor suite can therefore provide robustness across changing environments.

This is especially useful when no single sensor performs optimally throughout the complete mission envelope.

4.2.26.149 Redundancy and Geometry Diversity

Two sensors of the same type can still provide useful diversity if they have different geometry.

For example, cameras with different fields of view or mounting orientations may not lose target visibility simultaneously.

Similarly, multiple antennas at different locations can provide different visibility conditions.

Therefore, diversity can be achieved through both sensing physics and geometric configuration.

4.2.26.150 Redundancy and Frequency Diversity

Some sensors can operate using multiple frequencies or channels.

Different frequencies may have different noise, interference, or propagation characteristics.

Combining them can improve robustness and provide additional fault-detection capability.

However, measurements sharing common hardware or processing remain partly correlated.

4.2.26.151 Redundancy and Multi-Constellation Navigation

Using measurements from multiple external constellations can increase:

measurement availability,
geometric diversity,
and robustness to individual source loss.

But common receiver hardware or common environmental effects can still create shared vulnerabilities.

Therefore, source diversity and receiver redundancy are separate design dimensions.

4.2.26.152 Redundancy and Sensor Quality Metrics

Many sensors provide quality indicators.

Examples include:

tracking confidence,
number of tracked features,
signal strength,
dilution-of-precision measures,
image residuals,
ranging return quality,
star-tracker solution quality.

These metrics can support sensor management.

However, the estimator must determine how they relate to actual measurement uncertainty.

A quality metric should not automatically be treated as a statistically calibrated covariance.

4.2.26.153 Quality-Based Sensor Selection

Suppose each sensor produces quality q_i.

A simple architecture may choose

\[ i^* = \arg\max_i q_i. \]

But this may be inadequate if quality metrics from different sensor types have different meanings.

A better decision may combine:

\[ q_i,\quad R_i,\quad H_i,\quad \text{geometry},\quad \text{innovation}. \]

Sensor selection is therefore naturally a multi-criteria problem.

4.2.26.154 Covariance-Based Sensor Selection

A sensor may be preferred if it is expected to reduce state uncertainty most strongly.

For candidate sensor i, predict

\[ P_i^{+}. \]

Then compare quantities such as

\[ \operatorname{tr}(P_i^{+}), \]

\[ \det(P_i^{+}), \]

or uncertainty in mission-critical state directions.

This turns sensor selection into an information-management problem.

4.2.26.155 Information-Aware Sensor Scheduling

When power or processing resources are limited, not every sensor needs to operate continuously.

A sensor scheduler may activate the sensor expected to provide the greatest useful information.

Conceptually,

\[ i^* = \arg\max_i \frac{\text{expected information gain}} {\text{resource cost}}. \]

Resource cost might include:

power,
processor time,
communication bandwidth,
or thermal impact.

This connects sensor fusion with spacecraft autonomy.

4.2.26.156 Redundancy and Resource Constraints

More redundancy generally increases:

\[ \text{mass}, \quad \text{power}, \quad \text{cost}, \quad \text{processing}, \quad \text{interfaces}. \]

Therefore, the objective is not maximum redundancy.

The objective is sufficient redundancy to satisfy:

reliability,
availability,
integrity,
performance,
and fault-tolerance requirements

within spacecraft resource constraints.

4.2.26.157 Redundancy Allocation

Redundancy should be allocated according to failure consequence.

A sensor whose loss causes immediate loss of mission-critical navigation may justify stronger redundancy than a sensor whose function can be replaced by another subsystem.

Therefore, redundancy analysis should begin with functional failure consequences, not simply component count.

4.2.26.158 Functional Redundancy

Suppose Sensor A directly measures quantity y.

If Sensor A fails, Sensors B and C together may still allow y to be estimated.

Then B and C provide functional redundancy even though neither duplicates Sensor A.

For example,

\[ y = g(z_B,z_C,\text{dynamics}). \]

This is an important systems-engineering perspective on multi-sensor navigation.

4.2.26.159 Redundancy and Estimation Performance

Adding an independent valid measurement should generally reduce uncertainty in the directions it observes.

For a Kalman update,

\[ P^{+} = P^{-} - P^{-}H^T (HP^{-}H^T+R)^{-1} HP^{-}. \]

The reduction depends on:

prior covariance,
measurement geometry,
measurement noise,
and correlation.

Thus the benefit of an additional sensor can be quantified through covariance reduction.

4.2.26.160 Diminishing Information Returns

The first high-quality sensor measuring a poorly observed state may provide substantial improvement.

A second nearly identical sensor may provide less incremental benefit.

A third may provide still less.

Therefore, the relationship between sensor count and navigation performance often exhibits diminishing returns.

This is another reason why sensor diversity can be more valuable than simple duplication.

4.2.26.161 Redundancy and Nonlinear Measurements

Many spacecraft sensors have nonlinear measurement models:

\[ z=h(x)+v. \]

Examples include:

camera projection,
range,
bearing,
attitude measurements,
feature observations.

Therefore, disagreement between redundant sensors should often be evaluated in measurement space using their respective nonlinear models rather than by directly subtracting unlike outputs.

4.2.26.162 Innovation-Space Cross-Checking

For heterogeneous sensors, direct comparison may be impossible.

Instead, compare normalized innovations:

\[ \nu_i = z_i-h_i(\hat x^-). \]

Each sensor is then judged against the same predicted spacecraft state.

This provides a common statistical framework even when the sensors measure different physical quantities.

4.2.26.163 Residual Whitening

For innovation

\[ \nu_i \]

with covariance

\[ S_i, \]

a whitened residual can be formed:

\[ r_i = S_i^{-1/2}\nu_i. \]

Ideally,

\[ r_i \]

has approximately unit covariance when the measurement model is correct.

Whitened residuals allow measurements with different units and noise scales to be compared more meaningfully.

4.2.26.164 Redundancy and Statistical Independence Testing

If two sensor residual sequences are expected to be independent, persistent correlation may reveal a shared error source.

For residuals r_i and r_j,

\[ C_{ij} = E[r_ir_j^T]. \]

If

\[ C_{ij}\neq0 \]

unexpectedly, possible causes include:

shared environmental disturbance,
common timing error,
common model error,
or shared preprocessing.

Thus flight or test data can reveal hidden dependencies between redundant sensors.

4.2.26.165 Redundancy and Sensor Fault Trees

A fault tree can identify events leading to loss of navigation capability.

For example,

\[ \text{Loss of relative navigation} \]

may occur if

\[ (\text{Sensor A fails}) \land (\text{Sensor B unavailable}). \]

The fault tree can expose hidden common dependencies such as shared power or communication.

This provides a systems-engineering complement to estimator-level analysis.

4.2.26.166 Redundancy and Failure Mode Analysis

For each sensor, the designer should consider credible failure modes such as:

no output,
biased output,
excessive noise,
stuck output,
delayed output,
intermittent output,
corrupted metadata,
wrong frame,
wrong timestamp,
saturation.

Each failure mode can produce a different signature.

Therefore, a single generic “sensor failure” model is often insufficient for verification.

4.2.26.167 Fault Injection Testing

Redundancy management should be tested by deliberately injecting faults.

Examples include:

\[ z_{\text{fault}} = z+b, \]

\[ z_{\text{fault}} = z+n_{\text{large}}, \]

\[ z_{\text{fault}} = z(t-\tau), \]

or

\[ z_{\text{fault}} = \text{constant}. \]

The objective is to verify detection, isolation, reconfiguration, covariance response, and recovery.

4.2.26.168 Sensor Dropout Testing

A simple but important test is:

\[ z_i\rightarrow\text{unavailable}. \]

Verify that:

the estimator continues operating,
no zero measurement is accidentally injected,
covariance increases appropriately,
health flags change correctly,
remaining sensors are used,
and mission-mode logic responds appropriately.

4.2.26.169 Bias Ramp Testing

A slowly developing fault can be simulated as

\[ b(t)=kt. \]

Then

\[ z_{\text{fault}}=z+b(t). \]

This is more difficult to detect than an abrupt fault.

Testing bias ramps helps evaluate long-term innovation monitoring and soft-fault detection.

4.2.26.170 Noise Degradation Testing

Measurement noise can be increased:

\[ R_{\text{actual}} = \alpha R_{\text{nom}}, \qquad \alpha>1. \]

The test should determine whether the system:

detects reduced quality,
adapts covariance if designed to do so,
reduces sensor influence,
and remains statistically consistent.

4.2.26.171 Correlated-Fault Testing

Multiple sensors can be given a common error:

\[ z_i = h_i(x) + b_c + v_i. \]

This tests whether apparently redundant sensors are vulnerable to common-mode failure.

Such tests are important because independent single-sensor fault injection alone can overestimate system robustness.

4.2.26.172 Timing-Fault Testing

Inject timestamp error:

\[ t_{\text{reported}} = t_{\text{true}}+\Delta t. \]

Then verify whether:

innovation statistics reveal inconsistency,
timing monitors detect the problem,
delayed measurements are handled correctly,
and healthy sensors are not incorrectly isolated.

4.2.26.173 Frame-Fault Testing

Apply an incorrect sensor alignment:

\[ C_{\text{fault}} = \delta C C_{\text{true}}. \]

This can mimic a sensor bias or state-estimation error.

Frame-fault testing is valuable because interface and alignment errors can survive basic sensor health checks.

4.2.26.174 Multi-Fault Testing

Single-fault tolerance does not imply multiple-fault tolerance.

A system designed for

\[ N-1 \]

fault tolerance may not remain valid after two simultaneous failures.

Therefore, verification should clearly state the assumed fault model.

Do not claim general fault tolerance without specifying how many and which types of faults are covered.

4.2.26.175 Monte Carlo Redundancy Testing

Monte Carlo analysis can vary:

sensor noise,
biases,
dropout times,
failure times,
geometry,
timing,
initial covariance,
environmental conditions.

For run j,

\[ \theta^{(j)} \sim p(\theta). \]

Metrics can then be evaluated statistically over many runs.

This is useful for assessing robustness beyond a small set of deterministic cases.

4.2.26.176 Redundancy Verification Metrics

Useful metrics include:

Navigation availability

\[ A_{nav}. \]

Fault detection probability

\[ P_D. \]

False-alarm probability

\[ P_{FA}. \]

Detection time

\[ T_D. \]

Isolation time

\[ T_I. \]

Recovery time

\[ T_R. \]

Navigation error

\[ \|\tilde x\|. \]

Covariance consistency

using NIS and NEES.

A robust design should be evaluated across all these dimensions.

4.2.26.177 Detection Time

Suppose a fault occurs at

\[ t_f. \]

The system detects it at

\[ t_d. \]

Then

\[ T_D=t_d-t_f. \]

Detection time matters because a faulty sensor can corrupt the navigation state before it is isolated.

Thus faster detection can reduce state contamination, but overly aggressive thresholds may increase false alarms.

4.2.26.178 Isolation Time

Detection means knowing that something is wrong.

Isolation means identifying the responsible channel.

If isolation occurs at

\[ t_i, \]

then

\[ T_I=t_i-t_f. \]

In some architectures,

\[ T_I>T_D \]

because additional evidence is needed before the system can determine which sensor is faulty.

4.2.26.179 Recovery Time

After isolation, the navigation system may require time to establish a stable replacement configuration.

If recovery completes at

\[ t_r, \]

then

\[ T_R=t_r-t_f. \]

Recovery may include:

sensor activation,
acquisition,
filter convergence,
covariance stabilization,
and mode validation.

4.2.26.180 Maximum Error During Recovery

Final recovery is not the only metric.

The navigation error during the transient is also important:

\[ e_{\max} = \max_{t\in[t_f,t_r]} \|\tilde x(t)\|. \]

A system may eventually recover but experience an unacceptable transient error.

Therefore, fault-tolerance verification should examine the entire recovery trajectory.

4.2.26.181 Covariance Growth During Failure

After losing a measurement source,

\[ P(t) \]

should generally grow according to the remaining process and measurement information.

An important verification question is whether

\[ P_{\text{reported}} \]

tracks the actual increase in estimation uncertainty.

If error grows but covariance does not, the estimator becomes inconsistent.

4.2.26.182 Redundancy and Reacquisition

A failed or unavailable sensor may later become usable again.

Reacquisition should include:

status validation,
timing validation,
measurement gating,
consistency checks,
dwell time,
and gradual reintegration if appropriate.

A recovered sensor should not automatically regain its previous weight immediately.

4.2.26.183 Recovery Without State Discontinuity

Sensor reintegration should ideally preserve state continuity.

If

\[ \hat x(t^-) \]

is the current estimate and a recovered sensor becomes available, the estimator should update according to its statistical information rather than replacing the state arbitrarily.

A large jump should be treated as a diagnostic signal requiring investigation.

4.2.26.184 Redundancy and Covariance Continuity

After sensor exclusion,

\[ P \]

should reflect the loss of information.

After sensor reintegration,

\[ P \]

may decrease as new information is incorporated.

Abrupt artificial covariance resets can create false confidence.

Therefore, both state and covariance continuity matter during redundancy reconfiguration.

4.2.26.185 Redundancy and Sensor Recovery Confidence

A sensor that has just recovered may initially be assigned conservative covariance:

\[ R_{\text{recovery}} > R_{\text{nominal}}. \]

As consistent measurements accumulate,

\[ R_{\text{effective}} \rightarrow R_{\text{nominal}}. \]

This provides a gradual return to nominal influence.

4.2.26.186 Redundancy and Sensor Blacklisting

Some severe or repeated faults may justify preventing a sensor from re-entering automatically.

The sensor may be placed in

\[ \text{BLACKLISTED} \]

state until:

a reset,
a new mission phase,
explicit supervisory authorization,
or a predefined recovery condition.

This prevents repeatedly failing hardware from destabilizing the estimator.

4.2.26.187 Temporary Versus Permanent Isolation

Not every rejected sensor should be treated as permanently failed.

Temporary isolation may be appropriate for:

temporary obstruction,
poor geometry,
transient interference,
saturation,
or brief quality loss.

Permanent isolation may be appropriate after a confirmed hardware fault.

Sensor health state machines should distinguish these cases.

4.2.26.188 Redundancy and Mode-Dependent Sensor Roles

A sensor's role can change with navigation mode.

For example,

\[ S_A: \text{primary in Mode 1} \]

but

\[ S_A: \text{monitor in Mode 2}. \]

Similarly,

\[ S_B: \text{secondary in Mode 1} \]

may become

\[ S_B: \text{primary in Mode 2}. \]

Thus redundancy management and mode-dependent fusion are naturally coupled.

4.2.26.189 Redundancy Matrix

A useful systems-engineering representation is a matrix mapping sensors to navigation capabilities.

For example,

\[ \begin{array}{c|ccc} &\text{Attitude}&\text{Position}&\text{Relative Range}\\ \hline S_1&\checkmark&&\\ S_2&\checkmark&&\\ S_3&&\checkmark&\\ S_4&&&\checkmark \end{array} \]

Such a matrix helps identify whether apparent sensor redundancy actually provides functional redundancy for each required state.

4.2.26.190 Minimum Cut Sets

A minimum cut set is a smallest combination of failures that causes loss of a required function.

For example,

\[ \{S_1,S_2\} \]

may be a cut set if losing both eliminates attitude reference capability.

Identifying these combinations helps reveal weak points in the navigation architecture.

4.2.26.191 Redundancy and Fault Containment

A fault in one sensor should ideally not corrupt other sensors or the estimator before isolation.

Fault containment may involve:

software partitioning,
interface validation,
memory protection,
bounded data handling,
measurement gating,
and independent health monitoring.

Redundancy is much more effective when failures remain contained.

4.2.26.192 Byzantine-Type Sensor Behaviour

A particularly difficult case occurs when a faulty channel produces plausible but misleading measurements rather than simply becoming unavailable.

Such behaviour can defeat simple availability checks.

Cross-sensor consistency, model-based residuals, and robust estimation become especially important.

The navigation architecture should not assume that every failure is obvious.

4.2.26.193 Redundancy and Outliers

An outlier is not necessarily a sensor failure.

A single abnormal measurement may result from a temporary environmental or processing event.

Therefore,

\[ \text{outlier} \neq \text{confirmed failed sensor}. \]

The system may reject one measurement while keeping the sensor itself healthy.

This distinction prevents excessive sensor isolation.

4.2.26.194 Measurement Rejection Versus Sensor Rejection

These are different actions.

Measurement rejection

Reject one sample:

\[ z_{i,k}\rightarrow\text{discarded}. \]

Sensor rejection

Exclude the channel:

\[ S_i\rightarrow\text{isolated}. \]

A robust system normally requires stronger evidence for sensor rejection than for rejecting one individual measurement.

4.2.26.195 Persistence Logic

A fault counter can accumulate evidence:

\[ C_i(k) = C_i(k-1)+1 \]

when a test fails.

If the test passes,

\[ C_i(k) \]

may decrease or reset.

Sensor isolation occurs when

\[ C_i\geq C_{\max}. \]

This prevents one transient outlier from causing immediate channel removal.

4.2.26.196 Cumulative Statistical Tests

Instead of simple counters, fault detection can accumulate statistical evidence.

For example, a cumulative statistic can respond to persistent small residual shifts that are individually below the instantaneous threshold.

Such methods can improve detection of slowly developing soft faults.

However, threshold selection and reset logic require careful validation.

4.2.26.197 Redundancy and Robust State Estimation

Robust estimation can provide another layer of protection.

Rather than assuming every accepted measurement is perfectly Gaussian, the estimator can reduce the influence of measurements with large residuals.

This is useful when sensor faults are rare but not completely eliminated by preprocessing.

Robust estimation should complement, not replace, explicit sensor-health management.

4.2.26.198 Redundancy and Adaptive Fusion

A redundant sensor architecture becomes adaptive when measurement influence changes according to observed conditions.

For example,

\[ R_i(k+1) = f(R_i(k),\nu_i,Q_i). \]

A sensor experiencing increasing residual variance may receive larger covariance and therefore lower influence.

This leads naturally into Section 4.2.27 Adaptive Sensor Fusion.

4.2.26.199 Sensor Diversity Versus Algorithm Diversity

Redundancy can exist in both hardware and algorithms.

For the same measurements, two different estimators may produce

\[ \hat x_A \]

and

\[ \hat x_B. \]

Disagreement can reveal algorithmic or modelling problems.

However, because both estimators share the same sensor data, they are not independent at the information level.

Algorithm diversity therefore protects against different failure mechanisms than sensor diversity.

4.2.26.200 Redundancy and Model Uncertainty

Multiple sensors may agree with one another yet disagree with the estimator because the dynamics model is wrong.

For example,

\[ \nu_1\gg0, \qquad \nu_2\gg0, \]

with both residuals showing a similar pattern.

This may indicate:

process-model error,
incorrect control input,
timing error,
or common reference error,

rather than simultaneous independent sensor faults.

Fault diagnosis should therefore consider model uncertainty.

4.2.26.201 Process Noise and Fault Diagnosis

If process noise Q is unrealistically small, the estimator may trust its prediction too strongly.

Healthy sensor measurements can then generate large innovations and appear faulty.

Thus

\[ Q \]

affects not only estimation performance but also fault-detection behaviour.

Sensor-health thresholds should be validated together with the complete filter tuning.

4.2.26.202 Measurement Covariance and Fault Diagnosis

Similarly, if

\[ R_i \]

is underestimated, the normalized innovation

\[ \nu_i^TS_i^{-1}\nu_i \]

becomes artificially large.

This can increase false alarms.

If R_i is overestimated, real faults may be harder to detect.

Therefore, accurate covariance modelling is fundamental to reliable FDIR.

4.2.26.203 Redundancy and Filter Tuning

A multi-sensor estimator cannot be tuned one sensor at a time in complete isolation.

Changing

\[ Q \]

or one sensor's

\[ R_i \]

changes:

Kalman gain,
state covariance,
innovation covariance,
sensor weighting,
and potentially fault thresholds.

Therefore, redundancy management and filter tuning should be verified as an integrated system.

4.2.26.204 Redundancy and Sensor Dominance

One sensor may dominate a fused estimate if its information contribution is much stronger.

For example,

\[ R_1\ll R_2. \]

Then the Kalman filter may naturally place much more weight on sensor 1.

Sensor 2 can still be valuable as:

an independent monitor,
a fallback,
a fault detector,
or an observability aid.

A sensor does not have to contribute equal weight to be valuable.

4.2.26.205 Redundancy Without Equal Weighting

It is therefore incorrect to assume that redundant sensors should always receive

\[ w_1=w_2. \]

Their contributions should depend on:

measurement uncertainty,
geometry,
correlation,
health,
and current mission needs.

Equal weighting is justified only under specific assumptions.

4.2.26.206 Redundancy and Sensor Disagreement

When two valid sensors disagree, possible causes include:

one sensor fault,
both sensors degraded,
common model error,
timing mismatch,
frame mismatch,
calibration error,
incorrect covariance,
or genuine unmodelled dynamics.

Therefore,

\[ \boxed{ \text{disagreement is evidence, not diagnosis} } \]

Fault isolation requires context.

4.2.26.207 Sensor Agreement Is Also Not Proof

Similarly,

\[ z_1\approx z_2 \]

does not prove both sensors are correct.

They may share a common bias.

Thus,

\[ \boxed{ \text{agreement does not guarantee correctness} } \]

Independent physical references and diversity strengthen confidence.

4.2.26.208 Redundancy and Independent Truth Sources

During ground testing, external truth systems can evaluate redundant navigation channels.

If truth is

\[ x_{\text{truth}}, \]

then

\[ e_i = \hat x_i-x_{\text{truth}}. \]

This allows direct evaluation of:

accuracy,
bias,
covariance consistency,
fault detection,
and isolation logic.

Such truth may not be available in flight, making ground verification especially important.

4.2.26.209 Hardware-in-the-Loop Testing

Hardware-in-the-loop testing can evaluate real sensor or processor behaviour under simulated spacecraft dynamics.

It can expose issues not visible in purely mathematical simulations, such as:

latency,
packet loss,
timing jitter,
processor load,
interface faults,
and sensor reset behaviour.

These effects are highly relevant to redundant multi-sensor systems.

4.2.26.210 Software-in-the-Loop Testing

Software-in-the-loop testing can exercise:

sensor validity logic,
voting,
gating,
covariance changes,
FDIR state machines,
sensor switching,
and estimator reconfiguration.

Large automated fault campaigns can be run before hardware is available.

4.2.26.211 Deterministic Fault Cases

Before Monte Carlo analysis, deterministic tests should verify specific known cases.

Examples include:

nominal all-sensors operation,
loss of Sensor A,
loss of Sensor B,
single measurement outlier,
persistent bias,
noise increase,
delayed measurement,
wrong timestamp,
recovery and reintegration.

These tests make debugging much easier.

4.2.26.212 Monte Carlo Fault Campaign

After deterministic verification, randomized campaigns can vary:

\[ t_f, \quad b_f, \quad \sigma_f, \quad \tau_f, \quad x_0, \quad P_0. \]

This evaluates whether redundancy management remains reliable over a broad range of conditions.

4.2.26.213 Fault Coverage

Fault coverage describes the fraction of relevant faults that the system can successfully detect, isolate, or tolerate.

Conceptually,

\[ C_F = \frac{ \text{covered credible faults} }{ \text{total credible faults considered} }. \]

The exact definition depends on the system.

A claim of fault tolerance should therefore always be associated with a specified fault set.

4.2.26.214 Redundancy and Verification Traceability

Each redundancy requirement should map to a verification method.

For example:

Loss of any single sensor shall not cause loss of navigation capability in Mode M.

Verification can then inject each single-sensor loss and check:

\[ P\preceq P_{\max,M}, \]

\[ H_{nav}=\text{valid}, \]

and required state errors remain within limits.

This creates traceability from architecture to evidence.

4.2.26.215 Fault-Tolerance Requirement Example

A generic requirement might be:

The navigation subsystem shall tolerate the loss of any one sensor from the defined redundant sensor set without loss of the minimum navigation capability required for the current operational mode.

This requirement must then define:

which sensors belong to the set,
what “loss” means,
what navigation capability is required,
and how long recovery may take.

Without those definitions, the requirement is difficult to verify.

4.2.26.216 Redundancy and Performance Requirements

Fault tolerance should be specified quantitatively.

For example,

\[ \sigma_r<\sigma_{r,\max}, \]

\[ \sigma_v<\sigma_{v,\max}, \]

\[ \sigma_\theta<\sigma_{\theta,\max}. \]

Nominal and degraded limits may differ.

This makes graceful degradation measurable.

4.2.26.217 Redundancy and Integrity Requirements

An integrity requirement may specify that the system detect navigation conditions exceeding a defined uncertainty or error bound within a maximum time.

Conceptually,

\[ \text{unsafe navigation} \Rightarrow \text{alert within }T_A. \]

Redundant measurements provide the independent evidence needed for such monitoring.

4.2.26.218 Redundancy and Fault Response Time

A fault-tolerant architecture must respond before the fault can create unacceptable downstream consequences.

Thus

\[ T_D+T_I+T_R \]

should be compatible with the time available before navigation error exceeds allowable limits.

Fault response therefore depends on both estimator dynamics and mission dynamics.

4.2.26.219 Redundancy and Navigation Memory

After temporary loss of absolute measurements, inertial or model-based propagation retains some information about the previous state.

This acts as short-term analytical redundancy.

However, uncertainty grows with time.

Therefore, the duration for which navigation can coast safely is finite and should be quantified.

4.2.26.220 Coasting Capability

Suppose all absolute measurements are temporarily lost.

The estimator propagates:

\[ \hat x_{k+1}^{-} = f(\hat x_k^{+},u_k), \]

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

The navigation solution remains usable while

\[ P(t)\preceq P_{\max}. \]

This defines a coasting interval.

Redundant sensors can extend availability by reducing the probability that all external updates disappear simultaneously.

4.2.26.221 Redundancy and Reacquisition Before Covariance Limit

If the allowable coasting time is

\[ T_{\text{coast,max}}, \]

a backup sensor should ideally become valid within

\[ T_{\text{reacquire}} < T_{\text{coast,max}}. \]

This links sensor acquisition time directly to navigation requirements.

A backup sensor that requires too long to become operational may not provide useful fault tolerance for a fast-changing mission phase.

4.2.26.222 Redundancy and Criticality

Not every navigation mode has the same tolerance for outage.

A slowly varying mode may permit a longer coasting interval.

A highly dynamic precision mode may require nearly continuous measurements.

Therefore, redundancy requirements should be mode dependent.

4.2.26.223 Redundancy and Operational Hold

If navigation redundancy is reduced but not completely lost, the system may stop progression and hold the current operation.

This can be safer than either continuing nominally or immediately aborting.

Conceptually,

\[ \text{reduced redundancy} \rightarrow \text{HOLD} \rightarrow \text{recover/revalidate}. \]

This allows time for sensor reacquisition or fault diagnosis.

4.2.26.224 Redundancy and Abort Logic

If navigation uncertainty or sensor availability falls below the minimum required for safe continuation,

\[ P>P_{\max} \]

or

\[ \mathcal S_{\text{valid}} \not\supseteq \mathcal S_{\min}, \]

the mission logic may invoke a predefined abort or retreat action.

The exact action is mission specific.

The general principle is that redundancy status should feed higher-level safety logic.

4.2.26.225 Sensor Redundancy Is Not Control Redundancy

Redundant navigation sensors protect the estimation chain.

They do not automatically provide redundancy in:

actuators,
flight computers,
power,
communication,
or guidance logic.

A complete fault-tolerant GNC architecture must consider all these layers separately and together.

4.2.26.226 Redundancy and System Architecture

A useful end-to-end view is

\[ \boxed{ \text{Sensors} \rightarrow \text{Validation} \rightarrow \text{Redundancy Management} \rightarrow \text{Fusion} \rightarrow \text{Navigation State} \rightarrow \text{Guidance/Control} } \]

with a parallel path:

\[ \boxed{ \text{Sensor Health} + \text{Innovations} + \text{Covariance} \rightarrow \text{FDIR / Mode Management} } \]

This shows that redundancy is not a standalone block.

It is embedded in the complete GNC information architecture.

4.2.26.227 Practical Multi-Sensor Fusion Architecture

A practical architecture may process every sensor through the following stages.

Stage 1 — Acquisition

Receive

\[ z_i. \]

Stage 2 — Metadata validation

Check timestamp, frame, units, status, and quality.

Stage 3 — Physical plausibility

Verify measurement limits and rate limits.

Stage 4 — Statistical validation

Compute

\[ \nu_i, \qquad S_i, \qquad \epsilon_i. \]

Stage 5 — Cross-sensor checking

Compare redundant information.

Stage 6 — Health assessment

Update

\[ H_i. \]

Stage 7 — Sensor management

Accept, down-weight, reject, isolate, or recover the sensor.

Stage 8 — Fusion

Update

\[ \hat x,\qquad P. \]

Stage 9 — Navigation integrity assessment

Determine whether the resulting state is safe for the current operational mode.

4.2.26.228 Redundancy Management State Machine

A generic sensor state machine can be

\[ \boxed{ \text{OFF} \rightarrow \text{ACQUIRING} \rightarrow \text{VALID} \rightarrow \text{DEGRADED} \rightarrow \text{SUSPECT} \rightarrow \text{ISOLATED} } \]

with recovery transitions such as

\[ \text{ISOLATED} \rightarrow \text{ACQUIRING} \rightarrow \text{VALID}. \]

Each transition should have explicit guards.

4.2.26.229 Example Transition Guards

For

\[ \text{ACQUIRING}\rightarrow\text{VALID}, \]

require

\[ H_{\text{sensor}}=1, \]

\[ Q>Q_{\min}, \]

\[ \epsilon<\gamma, \]

\[ N_{\text{good}}\geq N_{\min}. \]

For

\[ \text{VALID}\rightarrow\text{SUSPECT}, \]

require persistent inconsistency:

\[ N_{\text{bad}}\geq N_{\text{bad,min}}. \]

This makes redundancy logic deterministic and testable.

4.2.26.230 Sensor Fusion Decision Hierarchy

A useful hierarchy is:

\[ \boxed{ \text{Available?} \rightarrow \text{Valid?} \rightarrow \text{Consistent?} \rightarrow \text{Informative?} \rightarrow \text{Fuse} } \]

A sensor that is merely producing data has passed only the first test.

This hierarchy prevents availability from being confused with usability.

4.2.26.231 Redundancy and Information Quality

For a sensor to contribute useful redundancy, it should provide information that is:

available,
valid,
sufficiently accurate,
correctly timed,
correctly framed,
sufficiently independent,
observable for the required states.

This is a stronger criterion than simply counting operational hardware.

4.2.26.232 Sensor Count Is a Poor Redundancy Metric

Consider two architectures:

\[ \text{Architecture A}: 5\text{ nearly identical sensors} \]

and

\[ \text{Architecture B}: 3\text{ diverse sensors}. \]

Architecture A has more hardware.

Architecture B may provide greater resilience if its sensors have independent failure modes and complementary geometry.

Therefore,

\[ \boxed{ \text{redundancy quality matters more than sensor count alone} } \]

4.2.26.233 Redundancy and Information Independence

A useful conceptual measure of redundancy should consider both

\[ \text{alternative capability} \]

and

\[ \text{independence}. \]

Two sensors that always fail together provide little fault tolerance.

Two sensors with independent failure mechanisms and independent information provide much stronger redundancy.

4.2.26.234 Redundancy and Complementarity Together

The strongest navigation architectures often combine:

\[ \text{homogeneous redundancy} \]

for fault isolation,

with

\[ \text{heterogeneous complementary sensing} \]

for observability and diversity.

For example, several inertial channels can protect against individual sensor failure, while an external absolute reference bounds long-term inertial drift.

These mechanisms solve different problems and work together.

4.2.26.235 When Voting Is Appropriate

Voting is most appropriate when:

sensors measure equivalent quantities,
their accuracy is broadly comparable,
faults are expected to be independent,
and a majority of channels is assumed healthy.

Voting is less suitable when:

sensors have very different precision,
measurements are heterogeneous,
errors are strongly correlated,
or state observability must be considered.

In those cases, statistical fusion is usually more appropriate.

4.2.26.236 When Weighted Fusion Is Appropriate

Weighted fusion is appropriate when:

measurements are valid,
uncertainties are known,
correlations are known or negligible,
and all measurements contain useful information.

The weighting should emerge from covariance and measurement geometry.

Weighted fusion should not be used to hide unresolved sensor faults.

4.2.26.237 When Sensor Selection Is Appropriate

Selection may be preferable when:

one sensor is clearly superior,
processing resources are limited,
sensors are mutually incompatible,
only one source is required,
or fusion would introduce difficult correlation problems.

A secondary sensor can still monitor the selected primary source.

4.2.26.238 When Covariance Intersection Is Appropriate

Covariance Intersection is useful when:

multiple state estimates must be fused,
cross-correlation is unknown,
conservative consistency is more important than maximum covariance reduction.

It is particularly relevant to decentralized systems where tracking all shared information is impractical.

4.2.26.239 When Robust Fusion Is Appropriate

Robust fusion is useful when:

occasional outliers are expected,
hard rejection is undesirable,
sensor faults are not always binary,
and residual distributions may be heavier-tailed than Gaussian.

However, severe confirmed faults should still be explicitly isolated.

4.2.26.240 Sensor Redundancy and Autonomy

Autonomous spacecraft must manage sensor failures without continuous ground intervention.

This requires onboard logic for:

health assessment,
sensor selection,
estimator reconfiguration,
recovery,
and operational-mode decisions.

Redundancy is therefore a fundamental enabler of autonomous GNC.

4.2.26.241 Explainability of Redundancy Logic

Safety-critical sensor management should be understandable.

If a sensor is rejected, the system should ideally be able to report why:

\[ \text{reason} = \text{innovation failure}, \]

or

\[ \text{reason} = \text{hardware status invalid}. \]

Transparent state machines and statistical thresholds are often easier to verify than opaque switching logic.

4.2.26.242 Redundancy and Telemetry

Useful telemetry includes:

active sensor set,
rejected sensor set,
sensor health states,
innovations,
NIS values,
measurement covariance,
quality indicators,
navigation covariance,
mode transitions,
fault counters,
and recovery events.

This information is essential for debugging and post-flight analysis.

4.2.26.243 Redundancy and Logging

A navigation system should record not only fused state outputs but also the information needed to reconstruct sensor-management decisions.

Without measurement-level logs, an unexpected state transition may be impossible to diagnose.

Logging is therefore part of verification architecture.

4.2.26.244 Redundancy and Determinism

Some redundancy-management decisions should be deterministic for identical inputs.

For example,

\[ \epsilon_i>\gamma \]

for the required persistence interval should produce a defined health transition.

Deterministic logic improves repeatability and verification.

Probabilistic estimation can still operate within this deterministic supervisory structure.

4.2.26.245 Redundancy and Adaptive Behaviour

Not every decision should be fixed.

Measurement covariance may adapt continuously according to sensor quality.

Therefore a useful architecture can combine:

\[ \text{discrete health states} \]

with

\[ \text{continuous statistical adaptation}. \]

This hybrid structure provides both clear supervisory behaviour and flexible estimation.

4.2.26.246 Redundancy and Sensor Confidence Decay

When measurements disappear, confidence in the propagated state should gradually decrease through covariance growth.

Similarly, confidence in a sensor that has recently become unreliable may be reduced gradually rather than instantly.

This avoids artificial discontinuities in navigation confidence.

4.2.26.247 Redundancy and Mission-Phase Transitions

At a mission-phase transition, the sensor suite may change:

\[ \mathcal S_A \rightarrow \mathcal S_A\cup\mathcal S_B \rightarrow \mathcal S_B. \]

This creates temporary redundancy during the overlap.

A well-designed system uses this interval to verify the incoming sensor before removing the outgoing information source.

Thus redundancy and handover are strongly interconnected.

4.2.26.248 Redundancy and Navigation Readiness

A navigation mode should not be declared ready simply because its primary sensor is online.

A stronger condition is

\[ \boxed{ \text{Ready} = \text{sensor validity} + \text{covariance requirement} + \text{consistency} + \text{observability} + \text{required redundancy} } \]

The final term becomes increasingly important for safety-critical operations.

4.2.26.249 Redundancy Readiness Metric

A conceptual redundancy readiness flag can be

\[ R_{\text{ready}} = H_{\text{primary}} \land H_{\text{backup}} \land C_{\text{consistent}} \land O_{\text{adequate}}. \]

This does not mean every mission must require two simultaneously valid sensors.

Rather, it illustrates how redundancy can become an explicit part of operational readiness.

4.2.26.250 Redundancy Margin

A useful conceptual idea is redundancy margin.

If a mode requires at least

\[ N_{\min} \]

independent information sources and currently has

\[ N_{\text{valid}}, \]

then

\[ M_R = N_{\text{valid}}-N_{\min}. \]

A positive margin indicates spare capability.

But because sensor information is not always equivalent, this simple count should be supplemented by observability and quality analysis.

4.2.26.251 Information-Based Redundancy Margin

A more meaningful concept considers whether the remaining sensor set satisfies an information requirement.

For active sensor set \mathcal S,

\[ \mathcal I(\mathcal S) = \sum_{i\in\mathcal S} H_i^TR_i^{-1}H_i. \]

After loss of sensor j,

\[ \mathcal I(\mathcal S\setminus j) \]

can be evaluated.

If required state directions remain sufficiently constrained, the architecture possesses useful functional redundancy against loss of j.

4.2.26.252 Redundancy and Worst-Case Sensor Loss

A common design question is:

What happens if the most informative sensor fails?

Testing only the least important sensor can give a misleading impression of robustness.

Therefore, evaluate

\[ \forall j\in\mathcal S: \qquad \mathcal S\setminus j. \]

This is an N-1 sensor-loss analysis.

4.2.26.253 N-1 Capability

An N-1 redundant architecture can tolerate the loss of any one element from a defined set while preserving a specified minimum function.

The phrase should always be accompanied by the required function.

For example,

\[ N-1 \]

for basic attitude knowledge is different from

\[ N-1 \]

for precision relative navigation.

4.2.26.254 N-2 Capability

Some architectures may require tolerance to two failures.

However, hardware and information requirements grow rapidly.

Moreover, two failures may not be independent.

Therefore, N-2 capability should be justified by mission criticality and credible fault scenarios rather than adopted automatically.

4.2.26.255 Redundancy and Fault Sequence

The order of failures can matter.

Suppose sensor A fails first, causing sensor B to become primary.

If B later fails before A recovers, the system may lose navigation capability.

Therefore, verification should consider sequences:

\[ F_A\rightarrow F_B \]

as well as simultaneous failures.

4.2.26.256 Redundancy and Recovery Sequence

Recovery order can also matter.

A backup sensor may require initialization using another still-valid sensor.

If that reference has already failed, recovery may become impossible.

Therefore, redundancy analysis should consider dependencies during recovery, not only during nominal operation.

4.2.26.257 Redundancy and Sensor Startup Dependencies

Suppose Sensor B requires initial attitude knowledge from Sensor A for acquisition.

Then B is not fully independent during startup.

This hidden dependency should be captured in the architecture.

Functional independence must be evaluated across the entire operational lifecycle.

4.2.26.258 Redundancy and Calibration Dependencies

A backup sensor may depend on calibration parameters estimated while another sensor is operating.

If those calibration parameters are invalid after a long standby interval, immediate failover may not achieve nominal performance.

Therefore, backup readiness includes calibration readiness.

4.2.26.259 Redundancy and Thermal State

A cold standby sensor may require time to reach a stable thermal condition.

Its measurement covariance during warm-up may be larger:

\[ R_{\text{warm-up}} > R_{\text{nominal}}. \]

Thus backup availability should distinguish

\[ \text{powered} \]

from

\[ \text{navigation-ready}. \]

4.2.26.260 Redundancy and Health Monitoring Independence

If all sensors are monitored by one faulty health algorithm, multiple healthy sensors could be incorrectly rejected.

Therefore, the health-management system itself can become a common point of failure.

Redundancy architecture should consider supervisory logic as well as sensors.

4.2.26.261 Redundancy and Threshold Robustness

A threshold tuned only for one operating condition may perform poorly elsewhere.

For example, expected innovation statistics can change with:

geometry,
state uncertainty,
sensor quality,
and dynamics.

Normalized statistical tests help, but their assumptions should still be validated across the operational envelope.

4.2.26.262 Redundancy and Environmental Transitions

A temporary environmental transition can degrade several sensors simultaneously without any hardware failure.

For example, an illumination change may affect multiple optical measurements.

The navigation system should distinguish such expected environmental behaviour from independent hardware faults where possible.

Mode-dependent sensor models and quality metrics can help.

4.2.26.263 Redundancy and Operational Envelope

For sensor i, define an operating envelope

\[ \Omega_i. \]

Redundancy exists at operating condition x only if enough valid sensors satisfy

\[ x\in\Omega_i. \]

Therefore, redundancy is not a single global property.

It varies across the mission envelope.

4.2.26.264 Redundancy Coverage Map

A useful design tool is to map the number and quality of available navigation sources over:

range,
attitude,
illumination,
geometry,
relative rate,
thermal conditions,
and mission mode.

Regions with only one valid information source reveal potential vulnerability.

4.2.26.265 Redundancy Gap

A redundancy gap occurs when a required navigation capability depends on only one valid information source over part of the operational envelope.

Conceptually,

\[ N_{\text{independent}}=1. \]

This does not necessarily make the architecture unacceptable, but the risk should be understood and justified.

4.2.26.266 Designing Sensor Overlap

A robust architecture attempts to create overlap between sensor envelopes:

\[ \Omega_A\cap\Omega_B \neq\varnothing. \]

The overlap should be large enough to allow:

acquisition,
validation,
cross-checking,
and transition

before one sensor reaches the boundary of its useful region.

4.2.26.267 Redundancy and Performance Diversity

A backup sensor may have lower accuracy but wider operating coverage.

A primary sensor may have high precision but a narrow envelope.

This combination can be highly effective:

\[ \text{robust coarse sensor} + \text{precise narrow-range sensor}. \]

Redundancy should therefore be evaluated in terms of mission capability, not identical specifications.

4.2.26.268 Redundancy and Sensor Cost Trade-Off

Adding another sensor has system-level cost.

It may require:

mass,
power,
thermal accommodation,
structural mounting,
data interfaces,
calibration,
software,
verification,
procurement,
and qualification.

Therefore, each redundant element should provide a clear reliability, integrity, observability, or performance benefit.

4.2.26.269 Redundancy and Complexity

Redundancy can paradoxically create new failure opportunities through:

more interfaces,
more switching logic,
more software states,
more calibration parameters,
more communication traffic.

Therefore,

\[ \boxed{ \text{redundancy improves robustness only when its management complexity is controlled} } \]

A simpler well-understood redundant architecture may be preferable to a highly complex architecture that is difficult to verify.

4.2.26.270 Verification Before Optimization

Before optimizing fusion weights or adaptive logic, first verify that:

every sensor uses the correct frame,
timestamps are correct,
units and sign conventions are correct,
covariance models are reasonable,
health flags are handled correctly,
unavailable measurements are excluded correctly,
single-sensor faults can be detected,
the estimator remains stable after sensor loss,
covariance grows appropriately,
recovery and reintegration are deterministic.

Only then should more advanced fusion logic be introduced.

4.2.26.271 Practical Design Questions

For every redundant sensor architecture, ask:

What state information does each sensor provide?
Which information is genuinely independent?
What errors are common between sensors?
What happens if each sensor fails individually?
Can the failure be detected?
Can it be isolated?
What sensor becomes primary afterward?
How long does recovery take?
What happens to covariance?
Is the remaining state sufficiently observable?
What mission capability remains?
Are common-cause failures possible?
Can the failed sensor recover?
How is reintegration performed?
How is the architecture verified?

If these questions have explicit answers, the redundancy architecture is much easier to implement and validate.

4.2.26.272 A Strong Design Philosophy

A robust multi-sensor navigation system should not ask:

“Which sensor do I trust?”

as though trust were permanently assigned.

Instead, it should ask:

“What information is currently available, how uncertain is it, how independent is it, is it statistically consistent, and what navigation capability does that information support?”

That changes redundancy from a hardware-counting problem into an information-management problem.

The strongest design philosophy is therefore:

\[ \boxed{ \text{validate} \rightarrow \text{cross-check} \rightarrow \text{assess uncertainty} \rightarrow \text{fuse} \rightarrow \text{monitor consistency} \rightarrow \text{reconfigure when necessary} } \]

4.2.26.273 Key Takeaways

Redundancy and sensor fusion are related but different. Redundancy provides alternative information paths; fusion combines information.
Redundancy can be homogeneous or heterogeneous. Multiple identical sensors support direct cross-checking, while diverse sensors provide protection against different failure mechanisms.
More sensors do not automatically mean better navigation. Correlation, common-mode errors, geometry, and covariance modelling determine the real information gain.
Dual redundancy can detect disagreement but often cannot isolate the faulty source. Additional independent information is required.
Triple redundancy enables majority-based fault isolation under suitable failure assumptions.
Voting and statistical fusion solve different problems. Voting is useful for fault management; covariance-based fusion is useful for estimation.
Valid sensors should normally be weighted according to uncertainty and geometry rather than arbitrary fixed weights.
Unknown correlation is dangerous. State estimates sharing common information must not be fused as though they were independent.
Covariance Intersection provides a conservative method when cross-correlation is unknown.
Sensor validation must accompany fusion. A faulty sensor with incorrectly high confidence can corrupt the complete fused solution.
FDIR and sensor fusion are tightly coupled. Innovations, cross-sensor residuals, quality indicators, and health flags all contribute to fault detection and isolation.
Sensor disagreement is evidence, not diagnosis. Timing, frames, calibration, dynamics models, and common errors must also be considered.
Sensor agreement does not guarantee correctness. Several sensors can share the same common-mode error.
Graceful degradation is a central objective. After sensor loss, navigation may remain valid at reduced performance.
Navigation covariance must reflect sensor loss and recovery. State continuity without covariance consistency is insufficient.
Redundancy should be evaluated at the functional level. Different sensor types may provide equivalent navigation capability without measuring the same quantity.
Observability matters more than sensor count. A large number of sensors can still leave important state directions weakly constrained.
Overlapping sensor operating envelopes strengthen both redundancy and handover.
The complete information path must be considered. Shared power, communication, processors, clocks, software, and reference data can defeat apparent hardware redundancy.
Verification must include realistic faults. Dropouts, biases, noise increases, timing errors, frame errors, common-mode faults, recovery, and multiple fault sequences should be tested.
Redundancy should be mode dependent. The minimum sensor set and required navigation performance depend on the current operation.
Control and mission logic should respond to actual navigation capability. A state estimate existing numerically does not mean it is sufficiently certain for every operation.
Backup availability is not the same as backup readiness. Acquisition, calibration, thermal stabilization, and validation may all be required.
A good redundant architecture balances fault tolerance with complexity, mass, power, processing, and verification effort.
The central principle is:

\[ \boxed{ \text{Robust multi-sensor fusion is not about having the largest number of sensors.} } \]

It is about maintaining independent, valid, observable, statistically consistent information about the spacecraft state when individual measurements, sensors, or parts of the navigation chain become degraded or unavailable.

The next topic, 4.2.27 Adaptive Sensor Fusion, builds directly on this foundation by considering what happens when the sensors remain available but their noise characteristics and measurement quality change with time.

Next: 4.2.27 Adaptive Sensor Fusion

After developing redundancy, sensor diversity, voting, covariance-aware fusion, cross-checking, fault isolation, graceful degradation, correlation management, and verification of redundant navigation architectures, the next section examines how the estimator can adapt online when sensor noise, quality, geometry, and operating conditions change with time.

4.2.27 Adaptive Sensor Fusion

Online modification of process and measurement covariance, measurement-quality-dependent weighting, adaptive noise estimation, innovation-based adaptation, changing sensor conditions, and robust spacecraft navigation.

Continue to Adaptive Sensor Fusion →