Complete Spacecraft Sensor-Fusion Architecture

4.2.32 Complete Spacecraft Sensor-Fusion Architecture

A spacecraft sensor-fusion system is not simply a Kalman filter connected to several sensors. It is a complete navigation architecture that begins with the physical spacecraft and its environment, passes through sensor hardware and measurement processing, estimates the spacecraft state and associated uncertainty, evaluates the health and integrity of that estimate, and finally provides navigation information to guidance, control, autonomy, and mission-management functions.

The complete chain can be represented conceptually as

\[ \boxed{ \text{Truth Dynamics} \rightarrow \text{Sensors} \rightarrow \text{Signal Processing} \rightarrow \text{Measurement Validation} \rightarrow \text{State Estimation} \rightarrow \text{Navigation Solution} \rightarrow \text{Guidance and Control} } \]

However, an operational spacecraft architecture contains many additional paths:

\[ \boxed{ \begin{aligned} &\text{Environment}\\ &\downarrow\\ &\text{Spacecraft Truth Dynamics}\\ &\downarrow\\ &\text{Sensor Physics}\\ &\downarrow\\ &\text{Sensor Electronics / Interfaces}\\ &\downarrow\\ &\text{Time Synchronization}\\ &\downarrow\\ &\text{Calibration and Preprocessing}\\ &\downarrow\\ &\text{Measurement Validation and FDIR}\\ &\downarrow\\ &\text{Sensor Fusion / State Estimation}\\ &\downarrow\\ &\text{Navigation State + Covariance + Health}\\ &\downarrow\\ &\text{Guidance / Control / Autonomy} \end{aligned} } \]

At the same time, information travels in the opposite direction. Mission mode determines which sensors are enabled, guidance determines what navigation accuracy is required, attitude control determines pointing geometry, and estimator health may restrict what guidance or control functions are permitted.

Therefore, spacecraft sensor fusion is fundamentally a closed information architecture, not a one-way signal-processing chain.

4.2.32.1 Purpose of the Complete Architecture

The purpose of the complete sensor-fusion architecture is to transform imperfect, asynchronous, noisy, biased, and sometimes unavailable sensor measurements into a navigation solution that is sufficiently accurate, timely, consistent, observable, and reliable for spacecraft operations.

The architecture must answer several questions simultaneously:

• What is the spacecraft state?
• How uncertain is that estimate?
• Which sensors contributed to it?
• Are those sensors healthy?
• Are the measurements mutually consistent?
• Is the state sufficiently observable?
• Is the navigation solution valid for the present mission mode?
• Is the information recent enough for control?
• Can the spacecraft continue operating if one sensor disappears?
• Should guidance or control be restricted because navigation quality has degraded?

Thus the navigation output is not merely

\[ \hat{\mathbf x}. \]

A more realistic output is

\[ \boxed{ \mathcal N = \left\{ \hat{\mathbf x}, \mathbf P, t, NavValid, NavMode, SensorHealth, QualityFlags \right\}. } \]

Engineering interpretation: the estimator output is only one part of the navigation product. A flight architecture must also communicate whether that estimate is fresh, valid, sufficiently observable, and suitable for the current operational mode.

4.2.32.2 The Physical Truth Layer

Every sensor-fusion problem begins with a physical system.

Let the true spacecraft state be represented by

\[ \mathbf x_{true} = \begin{bmatrix} \mathbf r\\ \mathbf v\\ \mathbf q\\ \boldsymbol{\omega}\\ \mathbf b\\ \mathbf p \end{bmatrix}, \]

where the exact states depend on the mission.

Possible states include position, velocity, attitude quaternion, angular velocity, gyro bias, accelerometer bias, clock states, sensor calibration parameters, relative states, environmental parameters, and other quantities required by the estimator.

The truth dynamics may be written generally as

\[ \boxed{ \dot{\mathbf x}_{true} = f_{true} ( \mathbf x_{true}, \mathbf u_{actual}, \mathbf d, \mathbf p_{true}, t ). } \]

The truth model represents what the spacecraft is physically doing.

It must be distinguished from the estimator propagation model.

4.2.32.3 Truth Model Versus Estimator Model

A critical architectural principle is

\[ \boxed{ f_{true} \neq f_{est} } \]

in realistic verification.

The estimator may propagate

\[ \dot{\hat{\mathbf x}} = f_{est} ( \hat{\mathbf x}, \mathbf u, \mathbf p_{nom} ). \]

The real spacecraft contains modeling errors, disturbances, parameter uncertainty, sensor imperfections, actuator uncertainty, and environmental effects that cannot be represented perfectly onboard.

If truth and estimator models are identical during simulation, the navigation problem can become artificially easy.

The difference between them is one of the reasons process uncertainty

\[ \mathbf Q \]

is required.

4.2.32.4 Environment Layer

Sensors do not observe spacecraft states in isolation. Their measurements depend on the surrounding physical environment.

Relevant environmental quantities may include

\[ \boxed{ \text{Gravity} + \text{Magnetic Field} + \text{Sun Direction} + \text{Atmosphere} + \text{Celestial Geometry} + \text{Target Geometry} + \text{RF Environment}. } \]

For example, a magnetometer requires a magnetic-field model, a Sun sensor depends on Sun-spacecraft geometry, a star tracker requires star visibility, GNSS depends on transmitting satellite geometry and signal availability, and optical relative-navigation sensors depend on target illumination and line of sight.

Consequently,

\[ \boxed{ \text{Sensor Measurement} = f( \text{Spacecraft State}, \text{Environment}, \text{Sensor Physics} ). } \]

4.2.32.5 Reference Frames

Before measurements can be fused, every quantity must have an unambiguous reference frame.

Typical frames can include inertial, orbital/local, Earth-fixed, spacecraft body, sensor, camera, antenna, target, and relative-navigation frames.

A sensor measurement obtained in sensor frame S may require transformation into body frame B:

\[ \mathbf v^B = \mathbf C_S^B\mathbf v^S. \]

If the mounting transformation is wrong, the estimator may interpret a frame error as a physical state error.

Therefore every sensor interface should explicitly define:

\[ \boxed{ \text{Frame} + \text{Origin} + \text{Axis Convention} + \text{Rotation Convention} + \text{Units}. } \]

4.2.32.6 Sensor Layer

The sensor layer converts physical quantities into measurements.

A general sensor model is

\[ \boxed{ \mathbf z = h(\mathbf x) + \mathbf b + \mathbf n + \boldsymbol{\epsilon}. } \]

Here,

\[ h(\mathbf x) \]

represents the ideal measurement relationship,

\[ \mathbf b \]

represents bias,

\[ \mathbf n \]

represents stochastic noise, and

\[ \boldsymbol{\epsilon} \]

collects calibration, alignment, scale-factor, timing, nonlinear, or other imperfections.

Different spacecraft sensors observe different parts of the state and therefore contribute different information to the fused solution.

4.2.32.7 Inertial Measurement Unit

An IMU commonly contains gyroscopes and accelerometers.

The gyroscope measurement can be represented as

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

The accelerometer measurement can be represented as

\[ \mathbf f_m = \mathbf f + \mathbf b_a + \mathbf n_a. \]

More complete models may include scale factors, axis non-orthogonality, temperature dependence, quantization, saturation, random walk, bias instability, and mounting misalignment.

The important architectural characteristic of an IMU is that it usually provides high-rate propagation information, but its errors accumulate with time.

Thus,

\[ \boxed{ \text{IMU} \rightarrow \text{High Rate} + \text{Excellent Short-Term Continuity} + \text{Long-Term Drift}. } \]

This makes inertial sensing particularly valuable when combined with absolute or externally referenced measurements.

4.2.32.8 GNSS Measurements

Where GNSS signals are available and suitable for the mission, GNSS can provide absolute navigation information.

Depending on architecture, the estimator may use a processed navigation solution,

\[ \mathbf z_{GNSS} = \begin{bmatrix} \mathbf r_{GNSS}\\ \mathbf v_{GNSS} \end{bmatrix}, \]

or more fundamental measurements such as pseudorange and Doppler.

The distinction leads naturally to loose and tight coupling.

GNSS can constrain long-term inertial drift, while the IMU provides high-rate propagation between GNSS measurements.

4.2.32.9 Star Tracker

A star tracker provides an externally referenced attitude measurement.

Conceptually,

\[ q_m = q_{true}\otimes\delta q. \]

It can strongly constrain attitude drift accumulated through gyro propagation.

However, practical architecture must consider acquisition time, field of view, update rate, blinding, lost-in-space conditions, processing latency, measurement validity, and quaternion conventions.

A common conceptual relationship is therefore

\[ \boxed{ \text{Gyroscope} \rightarrow \text{High-Rate Attitude Propagation} } \]

combined with

\[ \boxed{ \text{Star Tracker} \rightarrow \text{Absolute Attitude Correction}. } \]

4.2.32.10 Sun Sensors

Sun sensors provide direction information relative to the Sun.

A normalized measurement may be represented as

\[ \mathbf s_m^B \approx \mathbf C_I^B\mathbf s^I + \mathbf n_s. \]

Sun sensors may provide coarse or precise attitude information depending on the sensor type.

Their usefulness depends on visibility and geometry, so eclipse conditions and field-of-view constraints must be incorporated into the architecture.

4.2.32.11 Magnetometer

A magnetometer measures the local magnetic-field vector:

\[ \mathbf B_m^B = \mathbf C_I^B\mathbf B^I + \mathbf b_m + \mathbf n_m. \]

When combined with an environmental magnetic-field model, it can contribute attitude information.

Magnetometers are also sensitive to spacecraft-generated magnetic disturbances, calibration errors, hard-iron and soft-iron effects, and mounting uncertainty.

Therefore the measurement must be calibrated and validated before fusion.

4.2.32.12 Camera Measurements

Cameras can provide angular, feature, landmark, centroid, line-of-sight, or relative-pose information.

A fundamental pinhole projection is

\[ u=f_x\frac{X}{Z}+c_x, \]

\[ v=f_y\frac{Y}{Z}+c_y. \]

The estimator generally should not treat the image itself as a state measurement without appropriate processing.

The processing chain may instead be

\[ \boxed{ \text{Image} \rightarrow \text{Calibration} \rightarrow \text{Feature Detection} \rightarrow \text{Association} \rightarrow \text{Geometric Measurement} \rightarrow \text{Fusion}. } \]

Camera performance depends strongly on geometry, illumination, calibration, target appearance, feature quality, processing latency, and field of view.

4.2.32.13 LiDAR and Range Sensors

LiDAR may provide range, range-rate, point-cloud, bearing, or relative-pose information depending on the hardware and processing architecture.

A basic range measurement is

\[ \rho_m = \|\mathbf r_{target}-\mathbf r_{sensor}\| + n_\rho. \]

More advanced processing may produce

\[ \mathbf z_{LiDAR} = \begin{bmatrix} \mathbf r_{rel}\\ \mathbf q_{rel} \end{bmatrix}. \]

The measurement covariance should reflect actual geometric and processing uncertainty rather than treating every LiDAR solution as equally accurate.

4.2.32.14 Other Navigation Sensors

A complete architecture may also accommodate horizon sensors, optical navigation sensors, laser rangefinders, radar, RF ranging, inter-satellite links, Doppler measurements, celestial-navigation measurements, altimeters, or mission-specific payload-derived navigation information.

The architecture should therefore be modular.

A sensor should ideally enter through a standardized interface containing

\[ \boxed{ \mathbf z_j,\; \mathbf R_j,\; t_j,\; valid_j,\; health_j,\; frame_j,\; mode_j. } \]

This prevents the estimator from being tightly coupled to a particular hardware implementation unless such coupling is deliberately required.

4.2.32.15 Sensor Hardware Interface Layer

Before estimation begins, raw measurements pass through physical and software interfaces.

These may include serial links, CAN, SpaceWire, Ethernet, SPI, UART, custom buses, or other spacecraft communication interfaces.

The navigation architecture must handle more than the numerical measurement value.

It must also manage timestamps, packet validity, sequence counters, status words, sensor modes, CRC or communication errors, stale data, missing packets, and initialization state.

Thus,

\[ \boxed{ \text{Sensor Packet} \neq \text{Measurement Value Alone}. } \]

4.2.32.16 Time as Part of the Measurement

Every measurement must be associated with the time at which it represents the physical state.

A measurement can be written more correctly as

\[ \boxed{ \mathbf z(t_m) } \]

rather than simply \mathbf z.

If it arrives at

\[ t_a=t_m+\tau, \]

the estimator must distinguish measurement time from arrival time.

This becomes especially important when combining high-rate IMU data with slower cameras, GNSS receivers, star trackers, or LiDAR systems.

4.2.32.17 Time Synchronization

Sensor clocks may not be perfectly synchronized.

Possible timing errors include clock offset, drift, jitter, processing latency, communication delay, timestamp quantization, and scheduling uncertainty.

A timing error

\[ \delta t \]

can become a state error.

Approximately,

\[ \delta\mathbf r \approx \mathbf v\,\delta t, \]

and

\[ \delta\boldsymbol{\theta} \approx \boldsymbol{\omega}\,\delta t. \]

Therefore timing is part of navigation accuracy.

Why this matters: timing errors are state errors in disguise. Even a precise sensor can degrade navigation if its data are associated with the wrong epoch, especially during rapid translation or rotation.

4.2.32.18 Multi-Rate Architecture

Spacecraft sensors generally operate at different rates:

\[ f_{IMU}\neq f_{GNSS}\neq f_{camera}\neq f_{LiDAR}\neq f_{star}. \]

The estimator must therefore support asynchronous updates.

Propagation may occur at a high rate:

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

while a sensor update is performed only when its measurement becomes available.

Thus the correct concept is

\[ \boxed{ \text{Continuous/High-Rate Propagation} + \text{Event-Driven Measurement Updates}. } \]

4.2.32.19 Calibration Layer

Raw sensor outputs should normally pass through calibration before fusion.

A generic calibrated measurement may be written as

\[ \mathbf z_{cal} = \mathbf C_{align} \mathbf S^{-1} ( \mathbf z_{raw}-\mathbf b ). \]

Calibration can account for bias, scale factor, non-orthogonality, mounting alignment, boresight error, lever arms, temperature effects, camera intrinsics, camera distortion, and other sensor-specific effects.

A poorly calibrated measurement can be precise but wrong.

4.2.32.20 Preprocessing Layer

Preprocessing converts sensor-specific raw information into estimator-ready measurements.

Possible operations include filtering, coordinate transformation, unit conversion, feature extraction, centroiding, image processing, point-cloud processing, synchronization, compensation, interpolation, quality assessment, and packet validation.

A useful architectural separation is

\[ \boxed{ \text{Raw Sensor Data} \rightarrow \text{Sensor-Specific Processing} \rightarrow \text{Estimator Measurement}. } \]

This prevents sensor-specific implementation details from unnecessarily contaminating the estimator core.

4.2.32.21 Measurement Model Layer

For every sensor,

\[ \boxed{ \mathbf z_j = h_j(\mathbf x) + \mathbf v_j. } \]

For nonlinear estimators, the measurement Jacobian may be

\[ \mathbf H_j = \frac{\partial h_j}{\partial\mathbf x}. \]

The measurement model is the mathematical bridge between the physical quantity measured by a sensor and the state being estimated.

Incorrect measurement models can produce apparently reasonable but systematically biased navigation solutions.

4.2.32.22 Measurement Covariance

Each measurement should be accompanied by an uncertainty representation

\[ \mathbf R_j. \]

This covariance determines how strongly the estimator should trust the measurement relative to its predicted state.

It should represent the uncertainty of the actual estimator input, not merely a sensor datasheet number copied without considering preprocessing.

For example, a pose solution derived from an image may contain uncertainty from pixel noise, feature extraction, calibration, geometry, and pose-solution conditioning.

Practical interpretation: covariance should describe the uncertainty of the quantity actually entering the estimator after calibration and preprocessing. Using a raw datasheet noise number for a processed pose, feature, or fused sensor product can make the filter systematically overconfident.

4.2.32.23 Measurement Validity

Before fusion, every measurement should pass basic validity checks.

A measurement can conceptually have

\[ valid_j\in\{0,1\}. \]

Validity may depend on hardware status, field of view, signal strength, feature count, geometry, range, timestamp age, saturation, processing convergence, quality flags, or communication integrity.

Invalid data should not automatically reach the estimator merely because a packet was received.

4.2.32.24 Plausibility Checking

Measurements should also be checked against physically reasonable limits.

For example,

\[ z_{min}\le z_m\le z_{max}. \]

Rate-of-change limits may also be applied:

\[ |\dot z_m|\le\dot z_{max}. \]

These checks can detect obvious corruption before statistical innovation testing.

4.2.32.25 Innovation Generation

For a predicted state

\[ \hat{\mathbf x}^{-}, \]

the predicted measurement is

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

The innovation is

\[ \boxed{ \boldsymbol{\nu} = \mathbf z-\hat{\mathbf z}. } \]

This quantity represents the disagreement between the incoming sensor information and the estimator prediction.

4.2.32.26 Innovation Covariance

The expected innovation covariance is

\[ \boxed{ \mathbf S = \mathbf H\mathbf P^{-}\mathbf H^T+\mathbf R. } \]

A large innovation is not automatically bad.

Its significance depends on how uncertain the predicted state and measurement are.

This is why innovation magnitude should normally be interpreted together with \mathbf S.

4.2.32.27 Statistical Measurement Gating

The Normalized Innovation Squared is

\[ \boxed{ \epsilon_\nu = \boldsymbol{\nu}^T \mathbf S^{-1} \boldsymbol{\nu}. } \]

A measurement can be compared against a statistical threshold

\[ \epsilon_\nu\le\gamma. \]

Measurements outside the gate may be rejected, down-weighted, flagged, or passed to fault-management logic depending on the architecture.

A single rejected measurement need not imply sensor failure. Persistent inconsistency is generally more informative.

4.2.32.28 Outlier Rejection

Real sensors can occasionally produce outliers.

Therefore the architecture should distinguish

\[ \boxed{ \text{Normal Measurement} \neq \text{Outlier} \neq \text{Persistent Sensor Fault}. } \]

Outlier protection prevents one abnormal measurement from causing a disproportionate navigation-state correction.

Repeated outliers may instead indicate calibration problems, timing errors, geometry problems, or hardware degradation.

4.2.32.29 Navigation State Propagation

Between measurement updates, the estimator propagates its state:

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

For an EKF-type formulation, covariance propagation can be written

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

Propagation provides continuity even when external measurements are temporarily unavailable.

4.2.32.30 Measurement Update

When a valid measurement becomes available,

\[ \mathbf K = \mathbf P^{-}\mathbf H^T \left( \mathbf H\mathbf P^{-}\mathbf H^T+\mathbf R \right)^{-1}, \]

followed by

\[ \hat{\mathbf x}^{+} = \hat{\mathbf x}^{-} + \mathbf K\boldsymbol{\nu}. \]

The covariance is then updated consistently.

This illustrates the central principle of sensor fusion:

\[ \boxed{ \text{Model Prediction} + \text{Measurement Information} \rightarrow \text{Improved State Estimate}. } \]

4.2.32.31 Attitude Estimation Branch

Attitude estimation may combine gyroscopes with star trackers, Sun sensors, magnetometers, horizon sensors, cameras, or other attitude references.

A typical architecture is

\[ \boxed{ \text{Gyro} \rightarrow \text{Attitude Propagation} } \]

with external measurements providing corrections.

Possible estimated states include

\[ \mathbf x_{att} = \begin{bmatrix} \delta\boldsymbol{\theta}\\ \mathbf b_g \end{bmatrix}. \]

For quaternion-based systems, the architecture must preserve quaternion normalization and handle the attitude error using an appropriate multiplicative representation.

4.2.32.32 Translational Navigation Branch

Translational navigation estimates position and velocity.

A generic state is

\[ \mathbf x_{trans} = \begin{bmatrix} \mathbf r\\ \mathbf v \end{bmatrix}. \]

Depending on the spacecraft and operating environment, measurements may come from GNSS, inertial sensing, ranging systems, optical navigation, radar, altimeters, inter-satellite measurements, or other navigation sources.

The architecture may estimate translation independently or jointly with attitude.

4.2.32.33 Coupling Between Attitude and Translation

Attitude and translation are not always independent.

For example, accelerometer measurements must be transformed using attitude:

\[ \mathbf a^I = \mathbf C_B^I\mathbf f^B+\mathbf g^I. \]

An attitude error therefore produces an acceleration-direction error.

Similarly, camera or LiDAR measurements depend on sensor pointing.

Thus,

\[ \boxed{ \text{Attitude Error} \rightarrow \text{Measurement Geometry Error} \rightarrow \text{Translation Error}. } \]

The architecture must decide whether to maintain separate estimators or a coupled state estimator.

4.2.32.34 Absolute and Relative Navigation

Some spacecraft operations require both absolute and relative navigation.

Absolute navigation may estimate

\[ \mathbf r,\mathbf v,q,\boldsymbol{\omega}, \]

with respect to an inertial, Earth-fixed, or orbital reference.

Relative navigation may estimate

\[ \mathbf r_{rel}, \mathbf v_{rel}, q_{rel}, \boldsymbol{\omega}_{rel} \]

between two objects.

The two solutions can coexist within the same navigation architecture.

4.2.32.35 General RPO Navigation Architecture

For general rendezvous and proximity operations, sensor usefulness changes with geometry, range, illumination, visibility, and required accuracy.

A conceptual progression can be

\[ \boxed{ \text{Absolute Navigation} \rightarrow \text{Long-Range Relative Information} \rightarrow \text{Optical/Relative Navigation} \rightarrow \text{Precision Relative Navigation}. } \]

This should not be interpreted as a universal sensor sequence. Actual missions select sensors according to their operational environment and design.

The important architecture principle is that the estimator must support changing measurement availability while maintaining a continuous, uncertainty-aware navigation solution.

4.2.32.36 Sensor Handover

Sensor handover occurs when one measurement source becomes less useful and another becomes more informative.

A robust handover should avoid

\[ \text{State Jump}, \qquad \text{Covariance Discontinuity}, \qquad \text{False Innovation Rejection}. \]

Ideally,

\[ \boxed{ \hat{\mathbf x}(t^-)\approx\hat{\mathbf x}(t^+) } \]

while the information sources contributing to that estimate change.

Overlap between sensors can be valuable because it allows consistency to be checked before one source becomes dominant.

4.2.32.37 Estimator Handover

Sensor handover and estimator handover are not identical.

A system may keep one estimator and change its measurement set.

Alternatively, different mission phases may use different estimators.

If estimator handover is required, state, covariance, frame conventions, timestamps, bias states, validity, and uncertainty must all be transferred consistently.

Therefore,

\[ \boxed{ \text{Estimator Handover} > \text{Copy State Vector Only}. } \]

Handover requirement: continuity must be preserved in both the state and its uncertainty. Transferring only the state vector while discarding covariance, bias-state knowledge, frame definitions, or time history can create an apparently smooth but statistically inconsistent transition.

4.2.32.38 Centralized Architecture

A centralized estimator receives multiple measurement sources and estimates a common state.

\[ \boxed{ z_1,z_2,\ldots,z_n \rightarrow \text{Central Estimator} \rightarrow \hat x,P. } \]

Advantages include direct use of cross-state correlations and a conceptually unified solution.

Disadvantages may include computational concentration, interface complexity, larger state dimension, and stronger coupling among sensor implementations.

4.2.32.39 Decentralized Architecture

In a decentralized architecture, local estimators process subsets of information.

\[ Sensor_i \rightarrow LocalFilter_i. \]

Their outputs are subsequently combined or used independently.

This can improve modularity, fault isolation, processing distribution, and graceful degradation.

However, correlations between local estimates must be handled carefully.

4.2.32.40 Federated Architecture

A federated system contains multiple local filters whose information is combined by a master fusion process.

Conceptually,

\[ \boxed{ \begin{array}{ccc} Filter_1 & Filter_2 & Filter_3\\ \downarrow & \downarrow & \downarrow\\ & Master\ Fusion & \end{array} } \]

The architecture must define information sharing, covariance treatment, reset or feedback behavior, and cross-correlation assumptions.

4.2.32.41 Cascaded Architecture

In a cascaded architecture, one estimator's output becomes another estimator's input.

For example,

\[ \boxed{ \text{Sensor Processing} \rightarrow \text{Local Pose Estimate} \rightarrow \text{Navigation Filter}. } \]

The important requirement is to propagate uncertainty correctly.

Treating an estimated quantity as a perfect measurement can make the downstream filter overconfident.

4.2.32.42 Loose, Tight, and Deep Coupling

Fusion depth can also be classified independently of centralized or distributed organization.

Loose coupling uses processed sensor solutions.

Tight coupling uses more fundamental measurements.

Deep coupling allows the navigation estimator and sensor signal-processing functions to interact more directly.

Increasing coupling can retain more information but usually increases implementation complexity and dependency between subsystems.

4.2.32.43 Navigation Mode Management

A complete navigation architecture generally requires explicit modes.

Conceptually,

\[ NavMode \in \{ Initialization, Nominal, Relative, Degraded, Reacquisition, Safe \}. \]

The exact modes are mission dependent.

Mode management determines which sensors are expected, which measurement models are active, which thresholds apply, and what navigation quality is required.

4.2.32.44 Mode Transition Logic

Mode transitions should depend on measurable conditions rather than arbitrary time alone.

Inputs may include sensor availability, range, geometry, covariance, innovation statistics, estimator convergence, mission phase, health flags, and navigation quality.

Therefore,

\[ \boxed{ NavMode_{k+1} = g( NavMode_k, SensorHealth, P, NIS, Geometry, MissionState ). } \]

Hysteresis and dwell times can prevent rapid switching between modes.

4.2.32.45 Covariance as an Operational Output

Covariance is not merely an internal Kalman-filter matrix.

\[ \mathbf P = E[ (\mathbf x-\hat{\mathbf x}) (\mathbf x-\hat{\mathbf x})^T ]. \]

Its diagonal elements provide state uncertainty:

\[ \sigma_i=\sqrt{P_{ii}}. \]

Guidance and autonomy can use this uncertainty to decide whether a maneuver or mission transition is safe to perform.

Thus,

\[ \boxed{ \text{Navigation State Without Navigation Uncertainty Is Incomplete}. } \]

Operational significance: covariance can directly support autonomy. A maneuver may be geometrically feasible but still be disallowed if the relevant state uncertainty exceeds the navigation requirement.

4.2.32.46 Navigation Integrity

Accuracy answers:

How close is the estimate to truth?

Integrity addresses:

Can the system recognize when the navigation solution should not be trusted?

A navigation architecture should therefore monitor covariance, innovation behavior, sensor consistency, stale data, estimator numerical state, sensor health, and observability-related degradation.

Integrity becomes especially important for autonomous spacecraft.

4.2.32.47 Navigation Validity

A navigation-valid flag may be defined conceptually as

\[ NavValid = f( P, SensorHealth, EstimatorHealth, MeasurementAge, Consistency, Mode ). \]

This prevents downstream systems from treating every numerical state estimate as equally trustworthy.

A filter can continue producing numbers even when the underlying information is inadequate.

Therefore,

\[ \boxed{ \text{Estimator Running} \neq \text{Navigation Valid}. } \]

4.2.32.48 Sensor Health Monitoring

Each sensor may have a health state such as

\[ Health_j \in \{ Healthy, Suspect, Degraded, Failed \}. \]

Health assessment can use hardware status, communication integrity, measurement availability, innovation statistics, signal quality, internal diagnostics, and consistency with other sensors.

Sensor health should influence fusion logic.

4.2.32.49 FDIR Integration

Fault Detection, Isolation, and Recovery should operate alongside sensor fusion.

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

Detection identifies abnormal behavior.

Isolation identifies the likely source.

Recovery modifies the architecture, for example by excluding a sensor, switching modes, increasing uncertainty, enabling another sensor, or restricting spacecraft operations.

4.2.32.50 Redundancy

Redundancy can improve reliability but only when the redundant information is sufficiently independent.

Two sensors may appear redundant while sharing the same power source, clock, processor, algorithm, environmental sensitivity, or common calibration error.

Therefore,

\[ \boxed{ \text{Multiple Sensors} \neq \text{Independent Redundancy}. } \]

Common-mode failures must be considered at system level.

4.2.32.51 Graceful Degradation

A robust navigation system should not necessarily transition immediately from fully operational to completely unavailable when one sensor fails.

Instead,

\[ \boxed{ Nominal \rightarrow Degraded \rightarrow Restricted \rightarrow Unavailable } \]

may represent a more realistic hierarchy.

During degraded operation, covariance may increase, accuracy may decrease, some mission operations may be prohibited, and remaining sensors may carry greater responsibility.

4.2.32.52 Sensor Dropout

When a sensor becomes unavailable, the estimator should stop incorporating its measurements but continue propagation where possible.

During prolonged loss,

\[ \mathbf P(t)\uparrow \]

for states that are no longer adequately observed.

This covariance growth is expected and useful because it communicates the loss of information.

4.2.32.53 Sensor Reacquisition

When the sensor returns, its first measurement should not automatically be treated as perfectly valid.

Reacquisition may require hardware confirmation, quality checks, timestamp verification, innovation testing, several consistent measurements, or a temporary widened uncertainty model.

The objective is

\[ \boxed{ \text{Sensor Return} \rightarrow \text{Validate} \rightarrow \text{Reintegrate} } \]

rather than immediate unconditional fusion.

4.2.32.54 Observability

A state can only be estimated if the available measurements and dynamics provide information about it.

For a linearized system, observability can be examined through

\[ \mathcal O = \begin{bmatrix} H\\ HF\\ HF^2\\ \vdots \end{bmatrix}. \]

Poor observability can arise from sensor loss, unfavorable geometry, insufficient excitation, or measurement-model structure.

No amount of filter tuning can create information that the sensor system does not contain.

Design implication: weak observability should be addressed through sensor geometry, excitation, measurement selection, or state definition—not merely by increasing filter gain or retuning noise matrices.

4.2.32.55 Geometry-Dependent Observability

Observability can vary throughout a mission.

A bearing-only measurement may constrain some directions much more strongly than others.

Range measurements may have different sensitivity.

Optical pose quality can depend strongly on viewpoint.

GNSS accuracy changes with transmitting-satellite geometry.

Therefore,

\[ \boxed{ \text{Sensor Accuracy} + \text{Geometry} \rightarrow \text{Navigation Information}. } \]

Sensor selection should consider geometry, not merely datasheet precision.

4.2.32.56 Navigation–Guidance Interface

Guidance requires an estimated state:

\[ \hat{\mathbf x}_{nav} \rightarrow \text{Guidance}. \]

But a mature interface should also provide timestamp, covariance or uncertainty metrics, navigation mode, validity, and health information.

Guidance should know whether the navigation state is sufficiently reliable for the requested operation.

4.2.32.57 Navigation–Control Interface

Control may require attitude, angular velocity, position, velocity, relative state, and sometimes estimated disturbances or biases.

For example,

\[ \mathbf e_r = \mathbf r_{ref}-\hat{\mathbf r}, \]

\[ \mathbf e_v = \mathbf v_{ref}-\hat{\mathbf v}. \]

Navigation error therefore directly becomes control error.

A controller cannot distinguish perfectly between physical state error and navigation-estimation error.

4.2.32.58 Control-to-Navigation Feedback

The relationship is bidirectional.

Control commands change spacecraft motion, which changes future measurements.

\[ \boxed{ Navigation \rightarrow Guidance \rightarrow Control \rightarrow Spacecraft \rightarrow Sensors \rightarrow Navigation. } \]

This is the complete closed-loop GNC chain.

4.2.32.59 Actuator Interaction

Actuator behavior can influence sensor fusion indirectly.

Thruster firing, reaction-wheel operation, structural vibration, magnetic torquers, gimbals, mechanisms, and other actuators can change dynamics or disturb sensors.

For example, a magnetic torquer may interfere with magnetometer measurements.

A thruster maneuver may require different process-noise assumptions.

Thus estimator mode and actuator mode may need coordination.

4.2.32.60 Maneuver Awareness

The estimator should know when commanded dynamics change substantially.

During a maneuver,

\[ \mathbf u\neq0. \]

If the estimator ignores known control input, prediction error may increase unnecessarily.

Therefore commanded or reconstructed actuator information may be incorporated into state propagation.

Uncertainty should still represent the difference between commanded and actual actuation.

4.2.32.61 Navigation Initialization

Before nominal fusion begins, the estimator requires an initial state

\[ \hat{\mathbf x}_0 \]

and covariance

\[ \mathbf P_0. \]

Initialization may use stored orbital information, GNSS, star-tracker attitude, coarse attitude sensors, ground-provided states, relative-navigation acquisition, or other mission-specific information.

The covariance must represent how uncertain that initialization actually is.

4.2.32.62 Alignment and Bias Initialization

Some states require time to become observable.

Gyro bias, accelerometer bias, alignment error, or other calibration states may not be immediately known.

The estimator may therefore pass through

\[ \boxed{ Initialization \rightarrow Alignment \rightarrow Convergence \rightarrow Navigation Valid. } \]

Declaring navigation valid before these states have converged can create hidden systematic error.

4.2.32.63 Process Noise

Process noise

\[ \mathbf Q \]

represents uncertainty in state propagation.

It can account for unmodeled disturbances, bias evolution, uncertain accelerations, model truncation, actuator uncertainty, or other dynamic effects.

Too little process noise can make the estimator overconfident.

Too much can make it excessively responsive to measurement noise.

Therefore \mathbf Q should have physical justification.

4.2.32.64 Measurement Noise

Measurement covariance

\[ \mathbf R \]

represents expected measurement uncertainty.

Different sensors should naturally have different \mathbf R_j.

Moreover, measurement quality may change with geometry, signal strength, range, feature quality, illumination, or sensor mode.

Thus some systems use

\[ \boxed{ \mathbf R_j=\mathbf R_j(\text{quality},\text{geometry},\text{mode}). } \]

4.2.32.65 Adaptive Sensor Weighting

When measurement quality changes significantly, fixed weighting may be insufficient.

An adaptive architecture can modify measurement covariance or sensor usage based on quality metrics.

However, adaptation must itself be bounded and verified.

Arbitrary covariance inflation can hide modeling errors instead of solving them.

4.2.32.66 Numerical Robustness

A flight estimator must remain numerically valid.

Checks may include

\[ \|q\|\approx1, \]

\[ \mathbf P=\mathbf P^T, \]

\[ \mathbf P\succeq0, \]

and absence of

\[ NaN,\qquad Inf. \]

Covariance symmetry, positive semi-definiteness, matrix conditioning, quaternion normalization, and stable matrix factorization should be treated as architecture requirements rather than debugging details.

Implementation interpretation: these checks should be monitored continuously or at least exercised through verification. Numerical invalidity can silently corrupt an otherwise correct estimator long before a visible divergence appears.

4.2.32.67 Navigation Data Products

The navigation subsystem may publish several data products rather than one state vector.

For example,

\[ \boxed{ \begin{aligned} &\text{Attitude Solution}\\ &\text{Angular Rate}\\ &\text{Absolute Position/Velocity}\\ &\text{Relative Position/Velocity}\\ &\text{Bias Estimates}\\ &\text{Covariance}\\ &\text{Sensor Health}\\ &\text{Navigation Validity}\\ &\text{Navigation Mode}\\ &\text{Timestamp}. \end{aligned} } \]

Different spacecraft subsystems may subscribe to different products.

4.2.32.68 Interface Control

Every navigation interface should specify units, coordinate frame, timestamp convention, update rate, latency, covariance convention, validity flags, numerical representation, data type, initialization behavior, and behavior during sensor failure.

This belongs in an Interface Control Document.

Many apparent “filter problems” are actually interface problems.

4.2.32.69 Latency Budget

The age of navigation information matters.

The total navigation latency may be decomposed as

\[ \boxed{ \tau_{nav} = \tau_{sensor} + \tau_{interface} + \tau_{processing} + \tau_{estimator} + \tau_{communication}. } \]

A highly accurate but old state can be less useful to control than a slightly noisier but timely state.

4.2.32.70 Computational Architecture

Sensor fusion must fit within onboard computational constraints.

Relevant quantities include estimator execution time, CPU utilization, memory, bus load, sensor-processing load, scheduling jitter, worst-case execution time, and numerical precision.

The algorithm must complete within its allocated execution window:

\[ t_{exec}

A mathematically superior estimator that cannot meet real-time constraints is not an operational solution.

4.2.32.71 Software Architecture

A modular software architecture may separate

\[ \boxed{ \begin{aligned} &\text{Sensor Drivers}\\ &\downarrow\\ &\text{Sensor Preprocessing}\\ &\downarrow\\ &\text{Measurement Manager}\\ &\downarrow\\ &\text{Estimator Core}\\ &\downarrow\\ &\text{Navigation Health Monitor}\\ &\downarrow\\ &\text{Navigation Output Manager}. \end{aligned} } \]

This separation improves testability, maintainability, fault isolation, and reuse.

4.2.32.72 Measurement Manager

The measurement manager is an important architectural component between sensor processing and the estimator.

It can handle measurement queues, timestamp ordering, sensor availability, quality flags, stale-data rejection, frame checking, measurement selection, gating status, and mode-dependent enable/disable logic.

Thus the estimator core does not need to implement every hardware-specific rule itself.

4.2.32.73 Health and FDIR Parallel Path

Health monitoring should not necessarily be buried inside the estimator.

A useful architecture is

\[ \boxed{ \begin{array}{ccc} \text{Sensor Data} & \rightarrow & \text{Estimator} \\ \downarrow && \downarrow \\ \text{Health/FDIR} & \leftrightarrow & \text{Navigation Integrity} \end{array} } \]

This allows sensor hardware information and estimator residual information to contribute jointly to fault decisions.

4.2.32.74 Navigation Performance Monitoring

The system can continuously monitor quantities such as

\[ \operatorname{trace}(P), \qquad \sigma_r, \qquad \sigma_v, \qquad \sigma_\theta, \qquad NIS, \]

measurement age, rejection rate, sensor count, and estimator status.

These become operational health indicators.

The navigation system therefore estimates not only the spacecraft state but also the quality of its own knowledge.

4.2.32.75 Navigation Requirements

The architecture should ultimately be derived from requirements.

Typical requirements may specify position uncertainty, velocity uncertainty, attitude knowledge, rate knowledge, update rate, latency, availability, integrity, convergence time, recovery time, and fault tolerance.

Therefore the design process should follow

\[ \boxed{ \text{Mission Requirement} \rightarrow \text{Navigation Requirement} \rightarrow \text{Sensor Requirement} \rightarrow \text{Fusion Architecture}. } \]

Starting with a preferred filter and searching afterward for a requirement is the reverse of the desired engineering process.

System-engineering interpretation: the filter architecture should be a consequence of mission information needs. Requirements determine what must be estimated, which sensors are necessary, how quickly the solution must be delivered, and what degraded behavior is acceptable.

4.2.32.76 Accuracy, Precision, Consistency, Availability, and Integrity

These terms should remain distinct.

Accuracy concerns closeness to truth.

Precision concerns measurement or estimate dispersion.

Consistency concerns whether actual error agrees statistically with reported uncertainty.

Availability concerns whether a usable navigation solution exists.

Integrity concerns whether the system can recognize when that solution should not be trusted.

A complete navigation system must consider all five.

4.2.32.77 Verification Architecture

The same modularity used for flight architecture should be reflected in verification.

A useful sequence is

\[ \boxed{ \text{Unit Test} \rightarrow \text{Sensor Model Test} \rightarrow \text{Estimator Test} \rightarrow \text{Integrated Navigation Test} \rightarrow \text{Closed-Loop GNC Test}. } \]

Each level should isolate a different class of problem.

4.2.32.78 Deterministic Verification

The first integrated tests should normally be deterministic.

Known truth and controlled sensor inputs make it easier to identify frame, sign, timing, initialization, propagation, and measurement-model errors.

A deterministic nominal case provides the baseline against which more complicated uncertainty tests can be interpreted.

4.2.32.79 Monte Carlo Verification

After deterministic behavior is established, uncertainty should be randomized.

Relevant quantities may include

\[ \boxed{ \text{Bias} + \text{Noise} + \text{Misalignment} + \text{Timing} + \text{Initialization} + \text{Dropout} + \text{Model Error}. } \]

Monte Carlo verification evaluates the distribution of navigation outcomes rather than one favorable realization.

Important outputs include RMSE, peak error, convergence time, covariance coverage, NIS, NEES, availability, failure rates, and mission-level success criteria.

4.2.32.80 SIL, PIL, and HIL

The complete architecture should progressively move from mathematical simulation toward flight-representative implementation.

\[ \boxed{ MIL \rightarrow SIL \rightarrow PIL \rightarrow HIL \rightarrow \text{Flight Validation}. } \]

Software-in-the-loop verifies implementation logic.

Processor-in-the-loop introduces flight-representative computation.

Hardware-in-the-loop introduces physical interfaces, timing, buses, sensor emulators, processors, and other hardware effects.

Each stage removes another idealization.

4.2.32.81 Recorded-Data Replay

Recorded sensor data can be replayed through the estimator:

\[ \boxed{ \text{Recorded Measurements} \rightarrow \text{Estimator} \rightarrow \text{Navigation Output}. } \]

This is valuable for regression testing because the same input can be applied to different software versions.

It also helps connect simulation-based development with experimental or flight data.

4.2.32.82 Flight Validation

Ultimately, real sensor and spacecraft behavior determines whether the assumptions used during design were valid.

Flight validation examines real timing, calibration, noise, bias, thermal behavior, geometry, dropouts, environmental effects, and interface behavior.

Simulation therefore does not disappear after flight begins.

Instead,

\[ \boxed{ \text{Flight Data} \rightarrow \text{Model Improvement} \rightarrow \text{Updated Verification}. } \]

4.2.32.83 Traceability

Every navigation requirement should be traceable through the architecture.

For example,

\[ \boxed{ \text{Mission Need} \rightarrow \text{Navigation Requirement} \rightarrow \text{Sensor Capability} \rightarrow \text{Estimator Function} \rightarrow \text{Verification Test} \rightarrow \text{Evidence}. } \]

Traceability prevents the navigation architecture from becoming a collection of algorithms without a clear engineering justification.

4.2.32.84 Complete End-to-End Spacecraft Sensor-Fusion Flow

The complete architecture can now be assembled:

\[ \boxed{ \begin{array}{c} \text{Environment + Spacecraft Truth Dynamics}\\ \downarrow\\ \text{Physical Sensors}\\ \downarrow\\ \text{Sensor Electronics and Interfaces}\\ \downarrow\\ \text{Timestamping and Synchronization}\\ \downarrow\\ \text{Calibration}\\ \downarrow\\ \text{Sensor-Specific Preprocessing}\\ \downarrow\\ \text{Coordinate / Frame Transformation}\\ \downarrow\\ \text{Measurement Construction}\\ \downarrow\\ \text{Measurement Quality Assessment}\\ \downarrow\\ \text{Plausibility Checking}\\ \downarrow\\ \text{Measurement Manager}\\ \downarrow\\ \text{Innovation + Statistical Gating}\\ \downarrow\\ \text{Sensor Fusion / State Estimation}\\ \downarrow\\ \hat{\mathbf x},\mathbf P\\ \downarrow\\ \text{Consistency + Integrity Monitoring}\\ \downarrow\\ \text{Navigation Mode + NavValid + Sensor Health}\\ \downarrow\\ \text{Guidance}\\ \downarrow\\ \text{Control}\\ \downarrow\\ \text{Actuators}\\ \downarrow\\ \text{Spacecraft Dynamics} \end{array} } \]

Running in parallel are

\[ \boxed{ \text{FDIR} + \text{Mode Management} + \text{Health Monitoring} + \text{Interface Monitoring} + \text{Performance Monitoring}. } \]

This is the complete spacecraft sensor-fusion system.

Architecture interpretation: this end-to-end chain is the point at which sensor fusion stops being an isolated estimation topic and becomes part of the full GNC system. Every upstream assumption can affect navigation, and every navigation-quality decision can constrain downstream guidance and control.

4.2.32.85 Complete Information Flow

The architecture contains several distinct kinds of information.

Measurement information

\[ \mathbf z_j,\mathbf R_j,t_j. \]

State information

\[ \hat{\mathbf x},\mathbf P. \]

Sensor-health information

\[ Health_j,\quad valid_j. \]

Estimator-health information

\[ NIS,\quad covariance\ status,\quad convergence. \]

Operational information

\[ NavMode,\quad NavValid. \]

GNC information

\[ \mathbf x_{ref},\quad \hat{\mathbf x},\quad \mathbf u_{cmd}. \]

A mature architecture keeps these information types distinguishable rather than hiding everything inside a single estimator output.

4.2.32.86 What Sensor Fusion Does Not Do

Sensor fusion cannot compensate for every system deficiency.

It cannot create observability where the measurements contain no information.

It cannot make an incorrectly calibrated sensor correct simply by adding more sensors.

It cannot eliminate timing errors that are not modeled.

It cannot guarantee robustness from a single nominal simulation.

It cannot make an unrealistic covariance trustworthy.

It cannot replace sensor qualification, system verification, or flight validation.

Most importantly,

\[ \boxed{ \text{More Sensors} \neq \text{Automatically Better Navigation}. } \]

Performance depends on measurement quality, independence, geometry, timing, calibration, observability, fusion design, and verification.

4.2.32.87 Fundamental Design Principle

The architecture should not ask only:

Which estimator should be used?

The more complete engineering questions are:

What states must be known?

Which physical measurements make those states observable?

At what accuracy and rate?

In which frames?

With what latency?

Under which operating conditions?

What happens when measurements disappear?

How is uncertainty represented?

How is bad information detected?

How does the navigation system tell guidance and control that its information is degraded?

Only after these questions are understood should the estimator architecture be finalized.

Thus,

\[ \boxed{ \text{Sensor Fusion} = \text{Physics} + \text{Sensors} + \text{Timing} + \text{Estimation} + \text{Statistics} + \text{Software} + \text{FDIR} + \text{GNC Integration}. } \]

4.2.32.88 Key Takeaways

A complete spacecraft sensor-fusion architecture begins with the physical spacecraft and environment, not with the filter.

Sensors observe different physical quantities and provide information at different rates, in different coordinate frames, with different noise, bias, calibration, latency, availability, and geometric characteristics.

Before fusion, measurements require

\[ \boxed{ \text{Timestamping} + \text{Calibration} + \text{Preprocessing} + \text{Frame Transformation} + \text{Validation}. } \]

The estimator then combines model prediction with valid measurement information to obtain

\[ \boxed{ \hat{\mathbf x},\mathbf P. } \]

But these are not sufficient by themselves.

An operational navigation solution should also communicate

\[ \boxed{ NavValid + NavMode + SensorHealth + Quality + Timestamp. } \]

Attitude, translational, absolute, and relative navigation may be implemented as coupled, centralized, decentralized, federated, or cascaded estimation functions depending on mission requirements.

Sensor availability can change. The architecture must therefore support handover, dropout, reacquisition, degraded modes, redundancy, and graceful degradation.

FDIR operates alongside the estimator to detect abnormal measurements, isolate faults, and reconfigure the navigation system when necessary.

Covariance is an operational quantity. It tells the spacecraft how uncertain its knowledge is and therefore contributes directly to autonomous decision-making.

The navigation system must interface correctly with guidance and control:

\[ \boxed{ \text{Navigation} \rightarrow \text{Guidance} \rightarrow \text{Control} \rightarrow \text{Actuation} \rightarrow \text{Dynamics} \rightarrow \text{Sensors} \rightarrow \text{Navigation}. } \]

The complete architecture must also satisfy real-time computation, timing, communication, numerical stability, interface, software, and hardware constraints.

Finally, the architecture must be verified progressively through deterministic simulation, uncertainty analysis, Monte Carlo testing, SIL, PIL, HIL, recorded-data replay, and ultimately representative or flight data.

The central conclusion of 4.2 Sensor Fusion Basics is therefore:

\[ \boxed{ \begin{aligned} \text{Reliable Spacecraft Navigation} =&\; \text{Correct Sensor Physics}\\ &+ \text{Correct Measurement Models}\\ &+ \text{Time and Frame Consistency}\\ &+ \text{Multi-Sensor Information Fusion}\\ &+ \text{Realistic Uncertainty}\\ &+ \text{Observability}\\ &+ \text{Integrity and FDIR}\\ &+ \text{Robust Software Implementation}\\ &+ \text{GNC Integration}\\ &+ \text{Progressive Verification and Validation}. \end{aligned} } \]

This closes 4.2 Sensor Fusion Basics. The natural next step is 4.3 Estimation Algorithms, where the focus shifts from the overall sensor-fusion system architecture to the mathematical algorithms used to estimate the state and its uncertainty.

Next: 4.3 Estimation Algorithms

Section 4.2 has now assembled the complete sensor-fusion picture: physical sensor behaviour, timing, calibration, preprocessing, measurement models, estimation, covariance, validation, observability, FDIR, mode management, GNC interfaces, implementation, Monte Carlo verification, SIL/HIL, and the complete navigation architecture.

The next major topic moves from the overall sensor-fusion architecture to the mathematical estimation methods used to reconstruct state and uncertainty from models and measurements.