Sensor Fusion Architectures

4.2.2 Sensor Fusion Architectures

Section 4.2.1 introduced the fundamental state-estimation cycle:

\[ \boxed{\text{Predict}} \rightarrow \boxed{\text{Measure}} \rightarrow \boxed{\text{Compare}} \rightarrow \boxed{\text{Correct}}. \]

That cycle explains how an estimator combines a dynamic model with sensor information.

A real spacecraft, however, may contain many different sensors and navigation subsystems.

A representative spacecraft sensor suite may contain

\[ \boxed{ \text{IMU} + \text{GNSS} + \text{Star Tracker} + \text{Sun Sensor} + \text{Magnetometer} + \text{Camera} + \text{LiDAR} +\cdots }. \]

The engineering problem therefore becomes larger than simply choosing a filtering algorithm.

We must also determine

• where sensor information should be combined,
• which measurements should enter which estimator,
• whether individual subsystems should estimate states independently,
• how uncertainty should be transferred between estimators,
• how statistical correlations should be handled,
• how sensor failures should be isolated,
• how navigation should reconfigure when sensors become unavailable.

These choices define the sensor-fusion architecture.

Fusion Algorithm vs Fusion Architecture

A fusion algorithm and a fusion architecture are not the same thing.

\[ \boxed{ \text{Fusion Algorithm} \neq \text{Fusion Architecture} }. \]

A fusion algorithm describes the mathematical method used to estimate the state.

Examples include

• Complementary Filter,
• Kalman Filter,
• Extended Kalman Filter,
• Error-State Kalman Filter,
• Multiplicative EKF,
• Unscented Kalman Filter,
• Particle Filter.

A fusion architecture describes how sensors, preprocessing functions, local estimators, master estimators, health monitoring, and guidance/control interfaces are interconnected.

The same EKF could therefore be used inside several completely different sensor-fusion architectures.

What Information Can Be Fused?

Before distinguishing centralized and decentralized systems, it is useful to determine what level of information is being combined.

Sensor information normally passes through several processing levels:

\[ \boxed{\text{Raw Measurements}} \rightarrow \boxed{\text{Extracted Features}} \rightarrow \boxed{\text{State Estimates}} \rightarrow \boxed{\text{Decisions}}. \]

Fusion can therefore occur at several levels.

Measurement-Level or Data-Level Fusion

Measurement-level fusion occurs when raw or minimally processed sensor measurements enter a common estimator.

Examples include

• gyroscope angular-rate measurements,
• accelerometer specific-force measurements,
• GNSS pseudoranges,
• GNSS Doppler or pseudorange-rate measurements,
• star-vector measurements,
• camera line-of-sight measurements,
• LiDAR range measurements.

Conceptually,

\[ \boxed{ \mathbf z_{IMU}, \mathbf z_{GNSS}, \mathbf z_{ST}, \mathbf z_{CAM}, \mathbf z_{LiDAR} } \]

\[ \downarrow \]

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

\[ \downarrow \]

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

Why Measurement-Level Fusion Can Be Powerful

The estimator receives information before another subsystem has compressed it into a navigation solution.

Consider GNSS.

A loosely integrated system may receive only

\[ \boxed{ \mathbf r_{GNSS}, \mathbf v_{GNSS} }. \]

A more tightly integrated estimator may instead receive

\[ \boxed{ \text{Pseudorange} + \text{Doppler} + \text{Other Raw GNSS Observables} }. \]

Lower-level measurements may retain information that would otherwise be lost when a complete standalone navigation solution is generated.

This can improve observability and allow useful measurements to be used even when a complete local sensor solution cannot be formed.

The trade-off is greater estimator complexity.

Feature-Level Fusion

Feature-level fusion is particularly important for camera, LiDAR, radar, and other perception-based navigation systems.

A navigation filter does not necessarily process raw camera pixels or a complete LiDAR point cloud directly.

Instead, lower-level processing extracts useful geometric features.

Camera Example

\[ \boxed{\text{Camera Image}} \rightarrow \boxed{\text{Image Processing}} \rightarrow \boxed{ \begin{array}{c} \text{Centroid}\\ \text{Edges}\\ \text{Corners}\\ \text{Keypoints}\\ \text{Line of Sight}\\ \text{Pose Features} \end{array}} \]

LiDAR Example

\[ \boxed{\text{LiDAR Point Cloud}} \rightarrow \boxed{\text{Point-Cloud Processing}} \rightarrow \boxed{ \begin{array}{c} \text{Range}\\ \text{Surface Features}\\ \text{Target Geometry}\\ \text{Relative Pose} \end{array}} \]

These features can then be combined.

For example,

\[ \boxed{\text{Camera Bearing}} + \boxed{\text{LiDAR Range}} \rightarrow \boxed{\text{Improved Relative Position / Pose}}. \]

This form of fusion is highly relevant to rendezvous, proximity operations, docking, and robotic capture.

State-Level Fusion

In state-level fusion, individual navigation subsystems first estimate their own state solutions.

For example,

\[ \boxed{\text{GNSS}} \rightarrow \boxed{ \hat{\mathbf x}_{GNSS}, \mathbf P_{GNSS} } \]

\[ \boxed{\text{Vision Navigation}} \rightarrow \boxed{ \hat{\mathbf x}_{VIS}, \mathbf P_{VIS} } \]

\[ \boxed{\text{LiDAR Navigation}} \rightarrow \boxed{ \hat{\mathbf x}_{LIDAR}, \mathbf P_{LIDAR} }. \]

These solutions are then supplied to another fusion stage:

\[ \boxed{ \hat{\mathbf x}_{GNSS}, \hat{\mathbf x}_{VIS}, \hat{\mathbf x}_{LIDAR} } \]

\[ \downarrow \]

\[ \boxed{\text{Master Fusion}} \]

\[ \downarrow \]

\[ \boxed{ \hat{\mathbf x}_{NAV}, \mathbf P_{NAV} }. \]

This approach is common in decentralized, federated, and hierarchical architectures.

The Important Correlation Problem

The local estimates should not automatically be assumed statistically independent.

Two local filters may share

• the same IMU measurements,
• the same process model,
• the same initial state,
• the same previous fused estimate,
• the same disturbance assumptions.

Their errors may therefore be correlated.

If the master filter ignores this correlation, the same information may be counted more than once.

This is called information double counting.

Decision-Level Fusion

Fusion can also occur above the state-estimation level.

Instead of supplying measurements or state estimates, subsystems may provide decisions or validity indicators.

Examples include

\[ \boxed{\text{Star Tracker 1}} \rightarrow \boxed{\text{VALID}} \]

\[ \boxed{\text{Star Tracker 2}} \rightarrow \boxed{\text{VALID}} \]

and a supervisor may determine

\[ \boxed{\text{Attitude Solution Trusted}}. \]

During RPO, decision-level outputs may include

• Target Detected,
• Pose Valid,
• Navigation Quality Acceptable,
• Capture Corridor Valid,
• Capture Ready,
• Abort Required.

Decision-level fusion normally interacts closely with mission management and fault-detection logic.

Main Families of Sensor-Fusion Architectures

At the estimator-organization level, the most common architectural families are

\[ \boxed{ \begin{array}{c} \text{Centralized}\\ \text{Decentralized}\\ \text{Federated}\\ \text{Cascaded / Hierarchical} \end{array} }. \]

These terms describe where estimation occurs and how information moves between estimation subsystems.

Centralized Sensor Fusion

In a centralized architecture, measurements from multiple sensors enter one common navigation estimator.

Conceptually,

\[ \begin{array}{c} \boxed{\text{IMU}}\\ \boxed{\text{GNSS}}\\ \boxed{\text{Star Tracker}}\\ \boxed{\text{Camera}}\\ \boxed{\text{LiDAR}} \end{array} \longrightarrow \boxed{\text{Central Estimator}} \longrightarrow \boxed{\hat{\mathbf x},\mathbf P}. \]

The estimator maintains a common state vector.

For example,

\[ \mathbf x = \begin{bmatrix} \mathbf r\\ \mathbf v\\ \mathbf q\\ \mathbf b_a\\ \mathbf b_g\\ \mathbf r_{rel}\\ \mathbf v_{rel}\\ \mathbf q_{rel}\\ \cdots \end{bmatrix}. \]

Each sensor has an independent measurement model:

\[ \boxed{ \mathbf z_i = h_i(\mathbf x) + \mathbf v_i }. \]

Thus,

\[ \mathbf z_{GNSS} = h_{GNSS}(\mathbf x) + \mathbf v_{GNSS}, \]

\[ \mathbf z_{ST} = h_{ST}(\mathbf x) + \mathbf v_{ST}, \]

\[ \mathbf z_{CAM} = h_{CAM}(\mathbf x) + \mathbf v_{CAM}, \]

\[ \mathbf z_{LiDAR} = h_{LiDAR}(\mathbf x) + \mathbf v_{LiDAR}. \]

Whenever a valid measurement arrives, the same estimator updates the common state.

Centralized Fusion Does Not Require Synchronous Sensors

A centralized architecture does not mean that all sensors must produce measurements at the same instant.

The estimator may continuously propagate

\[ \hat{\mathbf x}_{k-1}^{+} \rightarrow \hat{\mathbf x}_{k}^{-} \]

while processing sensor updates whenever they become available.

For example,

\[ t_1:\quad \text{IMU} \]

\[ t_2:\quad \text{IMU} \]

\[ t_3:\quad \text{Star Tracker} \]

\[ t_4:\quad \text{IMU} \]

\[ t_5:\quad \text{GNSS} \]

\[ t_6:\quad \text{Camera}. \]

Therefore,

\[ \boxed{\text{Centralized}} \]

describes where estimation occurs, not whether sensors share the same sampling rate.

Advantages of Centralized Fusion

One of the strongest advantages of centralized estimation is that the full state covariance can be maintained inside one estimator.

For example,

\[ \mathbf P = \begin{bmatrix} P_{rr} & P_{rv} & P_{rq} & \cdots\\ P_{vr} & P_{vv} & P_{vq} & \cdots\\ P_{qr} & P_{qv} & P_{qq} & \cdots\\ \vdots & \vdots & \vdots & \ddots \end{bmatrix}. \]

These cross-covariance terms allow information from one sensor update to influence states that are not directly measured by that sensor.

For example, a GNSS velocity residual may directly constrain velocity but may also provide information about

\[ \boxed{\text{Accelerometer Bias}} \]

and, depending on the dynamics and motion,

\[ \boxed{\text{Attitude Error}}. \]

Similarly, a star-tracker update can improve attitude and indirectly help estimate gyro bias.

Other potential advantages include

• consistent common-state representation,
• direct measurement-level innovation testing,
• strong use of cross-state statistical relationships,
• no need to combine separately estimated states,
• potentially high information efficiency.

Disadvantages of Centralized Fusion

Centralized estimation can become computationally and operationally complex.

For an \(n\)-state estimator,

\[ \mathbf P \in \mathbb R^{n\times n}. \]

As the state dimension increases, covariance propagation and measurement processing become more expensive.

A large centralized system may also introduce

• large software complexity,
• increased verification burden,
• strong coupling between subsystems,
• complex timing and interface requirements,
• difficult ownership between engineering teams,
• potential sensitivity to invalid measurements if validation is weak.

It can also create a

\[ \boxed{\text{Single Point of Failure}} \]

if all navigation depends on one estimator or processor.

Therefore,

\[ \boxed{\text{Maximum Information Integration}} \]

may come at the cost of

\[ \boxed{\text{Complexity + Coupling}}. \]

Decentralized Sensor Fusion

A decentralized architecture distributes estimation across multiple local estimators.

For example,

\[ \boxed{\text{GNSS}} \rightarrow \boxed{\text{GNSS Filter}} \rightarrow \boxed{\hat{\mathbf x}_{GNSS}} \]

\[ \boxed{\text{Camera}} \rightarrow \boxed{\text{Vision Filter}} \rightarrow \boxed{\hat{\mathbf x}_{VIS}} \]

\[ \boxed{\text{LiDAR}} \rightarrow \boxed{\text{LiDAR Filter}} \rightarrow \boxed{\hat{\mathbf x}_{LIDAR}}. \]

These estimators may operate independently or may later pass their state information to another fusion stage.

Why Decentralization Is Natural in Spacecraft

A spacecraft is often already divided into functional subsystems such as

\[ \boxed{\text{ADCS}} \qquad \boxed{\text{Absolute Navigation}} \qquad \boxed{\text{Relative Navigation}} \qquad \boxed{\text{Vision Processing}}. \]

Each subsystem may have its own

• processor,
• software team,
• sensor interfaces,
• update rate,
• health monitoring,
• verification process.

A decentralized fusion architecture can therefore align naturally with spacecraft hardware and software modularity.

Advantages of Decentralized Fusion

Modularity

Each local estimator can be designed, implemented, tested, and qualified independently.

Fault Isolation

Failure of one navigation source does not necessarily destroy the complete navigation system.

For example,

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

need not imply

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

Distributed Processing

Computational load can be shared between several processors.

Scalability

New navigation subsystems may sometimes be added without redesigning the complete estimator.

Graceful Degradation

The spacecraft may continue operating using a reduced sensor set after a partial failure.

This is particularly valuable for autonomous spacecraft and RPO missions.

The Correlation Problem in Decentralized Fusion

The main mathematical difficulty in distributed state-level fusion is that local estimates may not be statistically independent.

Suppose two local filters both use the same IMU:

\[ \boxed{\text{IMU}} \rightarrow \boxed{\text{Filter A}} \]

and

\[ \boxed{\text{IMU}} \rightarrow \boxed{\text{Filter B}}. \]

Their estimates

\[ \hat{\mathbf x}_A \qquad \text{and} \qquad \hat{\mathbf x}_B \]

share information from the same inertial sensor.

Their errors may therefore contain common components caused by

\[ \boxed{ \text{Shared IMU Noise} + \text{Shared Bias} + \text{Shared Process Model} }. \]

Therefore,

\[ \boxed{ \mathbf P_{AB} \neq 0 } \]

in general.

If the master estimator incorrectly assumes

\[ \mathbf P_{AB} = 0, \]

it may treat correlated information as though it were independent.

The fused covariance can then become artificially small:

\[ \boxed{ P_{\text{reported}} < P_{\text{actual}} }. \]

The estimator becomes overconfident and inconsistent.

Information Double Counting

Consider two local navigation filters.

Filter A receives

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

while filter B receives

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

Both filters therefore contain information derived from the same IMU.

If their state estimates are later combined as though they were completely independent,

\[ \boxed{\text{IMU Information}} \]

may effectively enter the global solution twice.

This is known as information double counting.

Conceptually,

\[ \boxed{\text{Common IMU Information}} \rightarrow \begin{cases} \boxed{\text{Filter A}}\\ \boxed{\text{Filter B}} \end{cases} \]

and both paths later return to

\[ \boxed{\text{Master Fusion}}. \]

Correct distributed fusion must therefore account for correlation or use conservative methods when the correlation is not known.

Cross-Covariance Between Local Estimates

Let two local estimates be

\[ \hat{\mathbf x}_1 \qquad \text{and} \qquad \hat{\mathbf x}_2. \]

Their estimation errors are

\[ \mathbf e_1 = \mathbf x - \hat{\mathbf x}_1 \]

and

\[ \mathbf e_2 = \mathbf x - \hat{\mathbf x}_2. \]

The cross-covariance is

\[ \boxed{ \mathbf P_{12} = E \left[ \mathbf e_1 \mathbf e_2^T \right] }. \]

If

\[ \mathbf P_{12} = 0, \]

the errors are uncorrelated.

If

\[ \mathbf P_{12} \neq 0, \]

the estimates contain correlated error.

Correct state-level fusion may therefore require knowledge of

\[ \boxed{ \mathbf P_1, \mathbf P_2, \mathbf P_{12} }. \]

This concept becomes important in federated and distributed filtering.

Federated Sensor Fusion

Federated filtering is a structured form of distributed estimation.

The architecture normally contains

\[ \boxed{\text{Local Filters}} + \boxed{\text{Master Fusion Stage}}. \]

For example,

\[ \boxed{\text{IMU + GNSS}} \rightarrow \boxed{\text{Local Filter 1}} \]

\[ \boxed{\text{IMU + Camera}} \rightarrow \boxed{\text{Local Filter 2}} \]

\[ \boxed{\text{IMU + LiDAR}} \rightarrow \boxed{\text{Local Filter 3}}. \]

Their local solutions are then supplied to

\[ \boxed{\text{Master Fusion}} \rightarrow \boxed{\hat{\mathbf x}_{global}}. \]

Federated approaches are attractive when modularity, fault isolation, and local autonomy are important.

Information Representation of State Estimates

Distributed and federated fusion can also be expressed using an information representation.

For covariance

\[ \mathbf P, \]

define the information matrix

\[ \boxed{ \mathbf Y = \mathbf P^{-1} }. \]

Define the information vector

\[ \boxed{ \mathbf y = \mathbf P^{-1} \hat{\mathbf x} }. \]

A small covariance corresponds to high information, while a large covariance corresponds to low information.

Combining Independent Information

For appropriately independent estimates,

\[ \boxed{ \mathbf Y_f = \sum_i \mathbf Y_i } \]

and

\[ \boxed{ \mathbf y_f = \sum_i \mathbf y_i }. \]

Therefore,

\[ \boxed{ \mathbf P_f = \mathbf Y_f^{-1} } \]

and

\[ \boxed{ \hat{\mathbf x}_f = \mathbf P_f \mathbf y_f }. \]

This representation provides a convenient mathematical framework for distributed fusion.

However, direct addition of information is valid only when the information sources are sufficiently independent or their correlations have been handled correctly.

Federated Filter Feedback

A major architectural decision in federated systems is whether the global estimate should be sent back to the local filters.

No-Feedback Architecture

In a no-feedback configuration,

\[ \boxed{\text{Local Filters}} \rightarrow \boxed{\text{Master}} \]

but

\[ \boxed{\text{Master}} \nrightarrow \boxed{\text{Local Filters}}. \]

This preserves greater independence between local filters.

Feedback / Reset Architecture

After master fusion,

\[ \hat{\mathbf x}_{global}, \mathbf P_{global} \]

may be returned to the local estimators.

This can improve local estimates and keep them aligned with the global navigation solution.

However, feedback also creates additional statistical dependence.

Therefore,

\[ \boxed{\text{More Feedback}} \Rightarrow \boxed{\text{More Information Sharing}} \]

but also potentially

\[ \boxed{\text{More Correlation Complexity}}. \]

Cascaded Sensor Fusion

Cascaded fusion occurs when the output from one estimator is used as an input to another estimator.

For example,

\[ \boxed{\text{Gyro + Star Tracker}} \rightarrow \boxed{\text{Attitude Estimator}} \rightarrow \boxed{\hat{\mathbf q}} \]

followed by

\[ \boxed{\hat{\mathbf q}} + \boxed{\text{GNSS}} + \boxed{\text{Accelerometer}} \rightarrow \boxed{\text{Translational Navigation Estimator}}. \]

Thus,

\[ \boxed{\text{Estimator 1}} \rightarrow \boxed{\text{Estimator 2}}. \]

Why Cascaded Architectures Are Common

Cascaded architectures allow functional separation.

Attitude determination can be developed independently from translational or relative navigation.

This can simplify software development and verification.

The Important Uncertainty Issue

Suppose estimator 2 receives

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

If estimator 2 treats this value as perfect, attitude-estimation uncertainty is ignored.

In reality,

\[ \hat{\mathbf q} = \mathbf q + \text{Estimation Error} \]

conceptually.

Therefore, uncertainty from the upstream estimator should ideally be propagated through the interface.

This is called uncertainty propagation across estimator interfaces.

Hierarchical Fusion

Hierarchical fusion extends cascaded processing into multiple information-processing layers.

Level 1 — Sensor Processing

\[ \boxed{\text{Camera}} \rightarrow \boxed{\text{Feature Extraction}} \]

\[ \boxed{\text{LiDAR}} \rightarrow \boxed{\text{Point-Cloud Processing}}. \]

Level 2 — Local Navigation

\[ \boxed{\text{Vision Pose Estimator}} \qquad \boxed{\text{LiDAR Pose Estimator}}. \]

Level 3 — Navigation Fusion

\[ \boxed{\text{Relative Navigation Filter}}. \]

Level 4 — Mission Decision Logic

\[ \boxed{\text{Capture Ready}} \qquad \boxed{\text{Continue}} \qquad \boxed{\text{Abort}}. \]

Hierarchical architectures are particularly natural for autonomous rendezvous and docking systems because perception, navigation, and mission decisions are naturally separated into processing layers.

Loose, Tight, and Deep Coupling

Centralized, decentralized, federated, and cascaded describe where estimation occurs.

Another architecture dimension is how deeply navigation subsystems are integrated.

A common example is GNSS/INS integration.

The usual progression is

\[ \boxed{\text{Loose Coupling}} \rightarrow \boxed{\text{Tight Coupling}} \rightarrow \boxed{\text{Deep Coupling}}. \]

As coupling depth increases,

\[ \boxed{\text{Information Sharing}} \uparrow \]

but generally

\[ \boxed{\text{Complexity}} \uparrow \]

and

\[ \boxed{\text{Subsystem Independence}} \downarrow. \]

Loosely Coupled Fusion

In loosely coupled fusion, one subsystem first produces a complete navigation solution.

For GNSS,

\[ \boxed{\text{GNSS Measurements}} \rightarrow \boxed{\text{GNSS Receiver}} \rightarrow \boxed{ \mathbf r_{GNSS}, \mathbf v_{GNSS} }. \]

These outputs are then fused with inertial navigation:

\[ \boxed{ \mathbf r_{GNSS}, \mathbf v_{GNSS} } + \boxed{\text{INS}} \rightarrow \boxed{\text{Fusion Filter}}. \]

The fusion estimator does not process the individual GNSS satellite observations directly.

Advantages

• simple subsystem interfaces,
• high modularity,
• lower integration complexity,
• easier replacement of GNSS hardware,
• independent operation of the GNSS receiver.

Main Limitation

If the GNSS receiver cannot form a valid position/velocity solution,

\[ \boxed{\text{No GNSS Navigation Solution}} \]

then the fusion filter may receive

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

Individual satellite measurements that still contain useful information may therefore be unavailable to the integrated estimator.

Tightly Coupled Fusion

In tightly coupled GNSS/INS fusion, lower-level GNSS observables are processed directly inside the navigation estimator.

Instead of receiving only

\[ \boxed{ \mathbf r_{GNSS}, \mathbf v_{GNSS} }, \]

the estimator may process

\[ \boxed{\rho_i} \]

and

\[ \boxed{\dot{\rho}_i} \]

for individual GNSS satellites.

Conceptually,

\[ \boxed{\text{GNSS Raw Observables}} + \boxed{\text{IMU}} \rightarrow \boxed{\text{Integrated Navigation Filter}}. \]

Pseudorange Measurement Example

A simplified GNSS pseudorange model is

\[ \boxed{ \rho_i = \left\| \mathbf r - \mathbf r_i^{sat} \right\| + c\delta t + \epsilon_i }. \]

where

• \(\mathbf r\) is receiver position,
• \(\mathbf r_i^{sat}\) is satellite \(i\) position,
• \(c\delta t\) represents receiver clock bias,
• \(\epsilon_i\) collects remaining measurement errors.

The navigation state may therefore need to include receiver clock states.

Why Tight Coupling Can Be Better

Because individual observables are retained, the estimator may continue using useful GNSS information even when the receiver cannot form a full standalone navigation solution.

Potential benefits include

• better use of available measurements,
• improved operation with reduced satellite visibility,
• direct measurement-level residual testing,
• stronger integration with inertial states.

The cost is greater measurement-model, timing, software, and verification complexity.

Deeply Coupled / Ultra-Tightly Coupled Fusion

Deep integration moves the interaction between navigation and GNSS even further toward the receiver signal-processing level.

Inertial or navigation predictions may assist the internal GNSS tracking loops.

Conceptually,

\[ \boxed{\text{IMU / Navigation Prediction}} \rightarrow \boxed{\text{GNSS Signal Tracking}} \rightarrow \boxed{\text{Improved Code / Carrier Tracking}}. \]

This creates a feedback relationship between navigation estimation and signal tracking.

Deep integration may offer benefits under difficult signal dynamics or degraded signal conditions, but it also produces strong hardware, software, timing, and verification coupling.

Detailed receiver-loop mathematics is beyond the scope of this architecture page.

Centralized vs Decentralized Is Not the Same as Loose vs Tight

These architecture terms describe different design dimensions and should not be confused.

Architecture Distribution

Centralized and decentralized describe

where the estimation computations occur.

\[ \boxed{ \text{Centralized} \leftrightarrow \text{Distributed} }. \]

Coupling Depth

Loose, tight, and deep coupling describe

how low in the information-processing chain integration occurs.

\[ \boxed{\text{Loose}} \rightarrow \boxed{\text{Tight}} \rightarrow \boxed{\text{Deep}}. \]

Therefore,

\[ \boxed{ \text{Centralization} \neq \text{Coupling Depth} }. \]

A centralized estimator could use tightly coupled GNSS measurements, while a decentralized system could combine loosely coupled state solutions.

Sequential Versus Combined Measurement Updates

Measurements from several sensors may become available at the same epoch.

One approach is to stack them into a single measurement vector:

\[ \mathbf z = \begin{bmatrix} \mathbf z_{GNSS}\\ \mathbf z_{LiDAR} \end{bmatrix} \]

with measurement matrix

\[ \mathbf H = \begin{bmatrix} \mathbf H_{GNSS}\\ \mathbf H_{LiDAR} \end{bmatrix}. \]

This gives a combined update.

Another approach is

\[ \boxed{\text{GNSS Update}} \rightarrow \boxed{\text{LiDAR Update}}. \]

For appropriately independent measurement errors in a linear Gaussian formulation, sequential and stacked processing can produce equivalent results when implemented consistently.

Sequential updates are often convenient for asynchronous spacecraft sensors.

Parallel Versus Sequential Estimator Organization

Parallel Estimation

Several local estimators operate simultaneously:

\[ \begin{cases} \boxed{\text{Filter 1}}\\ \boxed{\text{Filter 2}}\\ \boxed{\text{Filter 3}} \end{cases} \rightarrow \boxed{\text{Master Fusion}}. \]

Sequential Estimation

Information passes through multiple estimation stages:

\[ \boxed{\text{Sensor}} \rightarrow \boxed{\text{Estimator 1}} \rightarrow \boxed{\text{Estimator 2}}. \]

Therefore, parallel decentralized fusion and sequential cascaded fusion represent different architectural concepts.

Homogeneous Versus Heterogeneous Fusion

Homogeneous Fusion

Homogeneous fusion combines sensors that provide similar measurements.

Examples include

\[ \boxed{\text{Star Tracker A}} + \boxed{\text{Star Tracker B}} \]

or

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

This is commonly associated with redundancy and fault tolerance.

Heterogeneous Fusion

Heterogeneous fusion combines sensors based on different physical measurement principles.

For example,

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

Heterogeneous fusion is valuable because different sensors provide complementary observability and different error characteristics.

Static Versus Adaptive Fusion Architectures

A static architecture uses essentially the same set of measurements and estimator configuration throughout operation.

Real spacecraft missions often experience changing sensor quality, geometry, availability, and mission phase.

An adaptive architecture may therefore modify

• which sensors are active,
• measurement covariance,
• measurement weighting,
• state definition,
• estimator configuration.

For example, if camera image quality deteriorates,

\[ \boxed{ \mathbf R_{camera} \uparrow } \]

may be used to reduce the influence of camera measurements.

If the target leaves the field of view,

\[ \boxed{\text{Camera Update}} \rightarrow \boxed{\text{Disabled}}. \]

Detailed adaptive filtering methods are developed later in the chapter.

Mode-Dependent Fusion for Rendezvous and Proximity Operations

RPO provides a particularly useful example because the useful sensor suite changes significantly with range.

Far Range

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

Absolute or relative GNSS can dominate translational navigation while the IMU maintains high-rate propagation.

Mid Range

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

Camera measurements begin providing line-of-sight or target-relative information while GNSS remains available for cross-checking.

Close Range

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

LiDAR can strengthen range and pose observability while optical navigation becomes increasingly important.

Capture

The estimator may need accurate estimates of

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

Sensor transitions should preferably contain overlap regions rather than abrupt switching.

For example,

\[ \boxed{\text{GNSS Dominant}} \rightarrow \boxed{\text{GNSS + Vision}} \rightarrow \boxed{\text{Vision + LiDAR}}. \]

Overlap supports

• cross-validation,
• bias detection,
• smooth covariance transition,
• consistency checking,
• safer handover.

Sensor Handover Versus Estimator Handover

These two concepts should be distinguished.

Sensor Handover

The same estimator remains active while the available measurement set changes.

For example,

\[ \boxed{\text{EKF}} : \quad \text{GNSS} \rightarrow \text{GNSS + Camera} \rightarrow \text{Camera + LiDAR}. \]

Estimator Handover

Different estimators become responsible for navigation during different mission phases.

\[ \boxed{\text{Far-Range Navigation Filter}} \rightarrow \boxed{\text{Close-Range Relative Navigation Filter}}. \]

Estimator handover is more difficult because

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

must be transferred consistently into

\[ \boxed{ \hat{\mathbf x}_B, \mathbf P_B }. \]

This requires careful handling of

• state definitions,
• coordinate frames,
• covariance mapping,
• timestamps,
• bias states,
• relative-state conventions.

Fault-Tolerant Fusion Architecture

Sensor failures should be considered when designing the architecture, not only after the estimator has been implemented.

Suppose the nominal close-range navigation architecture is

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

If the camera fails, the system may reconfigure to

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

provided the remaining sensors still satisfy observability and mission accuracy requirements.

A fault-tolerant architecture therefore includes more than the estimator itself:

\[ \boxed{\text{Sensors}} \rightarrow \boxed{\text{Health Monitoring}} \rightarrow \boxed{\text{Measurement Validation}} \rightarrow \boxed{\text{Fusion Manager}} \rightarrow \boxed{\text{Estimator}}. \]

The fusion manager determines which measurement sources are currently trusted.

Sensor Fusion and FDIR

The navigation estimator itself can provide useful information for fault detection, isolation, and recovery.

For each sensor,

\[ \boxed{ \mathbf y_i = \mathbf z_i - \hat{\mathbf z}_i }. \]

If the innovation becomes persistently inconsistent with its expected uncertainty, the measurement source may be

• degraded,
• biased,
• misaligned,
• incorrectly timestamped,
• faulty.

Therefore,

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

This is especially powerful in architectures containing redundant sensors.

Redundancy Does Not Guarantee Independence

Two sensors may be redundant without being truly independent.

For example, two star trackers may share

• the same power supply,
• the same software implementation,
• the same thermal environment,
• the same structural mounting region,
• similar fields of view.

A common environmental or system failure may therefore affect both.

Similarly, two navigation filters that share the same IMU do not provide completely independent navigation.

Architecture design should therefore distinguish

\[ \boxed{\text{Redundancy}} \]

from

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

Computational Architecture

Sensor-fusion architecture is not only mathematical.

The estimator must execute on actual flight hardware.

Single-Processor Architecture

\[ \boxed{\text{All Sensor Data}} \rightarrow \boxed{\text{Single Flight Computer}}. \]

Distributed Processing

A spacecraft may instead contain

\[ \boxed{\text{Vision Processor}} \qquad \boxed{\text{GNSS Receiver}} \qquad \boxed{\text{ADCS Computer}} \qquad \boxed{\text{Main OBC}}. \]

These processors communicate through spacecraft data buses and interfaces.

The physical processor architecture influences

• communication latency,
• available bandwidth,
• clock synchronization,
• fault containment,
• processor load,
• software interfaces,
• redundancy strategy.

Mathematical fusion architecture and flight-computer architecture should therefore be designed together.

Communication Requirements for Fusion

A distributed estimator needs substantially more interface information than only the numerical sensor value.

A useful navigation interface should normally identify

\[ \boxed{ \text{Data} + \text{Timestamp} + \text{Frame} + \text{Units} + \text{Uncertainty} + \text{Validity} + \text{Status} }. \]

For example, transmitting

\[ \mathbf r = \begin{bmatrix} x\\ y\\ z \end{bmatrix} \]

is not sufficient by itself.

The receiving estimator also needs to know

• which coordinate frame is used,
• the measurement timestamp,
• the measurement units,
• the uncertainty or covariance,
• whether the solution is currently valid,
• whether the measurement is delayed,
• what status or health flags apply.

Interface Control for Sensor Fusion

A measurement-level interface may conceptually carry

\[ \boxed{ \{ \mathbf z,\; t,\; \mathbf R,\; FrameID,\; Validity,\; Status \} }. \]

A state-level fusion interface may instead carry

\[ \boxed{ \{ \hat{\mathbf x},\; t,\; \mathbf P,\; FrameID,\; Validity,\; Status \} }. \]

This demonstrates how sensor-fusion architecture directly connects to Interface Control Document design.

Architecture and Observability

Architecture can affect how much useful measurement information reaches the state estimator.

Suppose a camera bearing measurement is processed inside a local subsystem and converted into a partial state estimate before being passed to the master estimator.

Some of the original measurement geometry may no longer be available to the global estimator.

A lower-level tightly integrated estimator may retain more of the original measurement information.

Therefore,

\[ \boxed{\text{Architecture Choice}} \rightarrow \boxed{\text{Available Information}} \rightarrow \boxed{\text{Observability}}. \]

Architecture should therefore not be selected only for software convenience.

Architecture and Latency

Cascaded and distributed navigation systems may introduce significant processing and communication delay.

Consider

\[ \boxed{\text{Camera}} \rightarrow \boxed{\text{Image Processing}} \rightarrow \boxed{\text{Pose Estimator}} \rightarrow \boxed{\text{Navigation Fusion}}. \]

Each stage introduces latency.

The total delay can be represented approximately as

\[ \boxed{ \tau_{total} = \tau_{camera} + \tau_{processing} + \tau_{pose} + \tau_{communication} }. \]

During slow navigation this delay may be acceptable.

During close-range docking,

\[ \boxed{\text{Latency}} \rightarrow \boxed{\text{Navigation Error}} \rightarrow \boxed{\text{Control Error}} \]

can become mission-critical.

Architecture and Update Rate

Different sensors may operate at very different rates.

For example,

\[ f_{IMU} = 200~\text{Hz}, \]

\[ f_{camera} = 20~\text{Hz}, \]

\[ f_{LiDAR} = 10~\text{Hz}, \]

\[ f_{GNSS} = 5~\text{Hz}. \]

The navigation system must still provide a sufficiently high-rate state estimate to guidance and control.

Therefore,

\[ \boxed{\text{High-Rate Propagation}} + \boxed{\text{Asynchronous Corrections}} \]

is normally more appropriate than forcing every sensor onto a single artificial update rate.

Architecture and Navigation Availability

Architecture should not be selected only by asking which configuration produces the lowest nominal estimation error.

A navigation system must also consider

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

Navigation availability answers:

How often is a valid navigation solution available to the spacecraft?

A highly accurate architecture with one critical point of failure may be less desirable than a slightly less accurate architecture capable of graceful degradation.

Architecture evaluation should therefore consider

\[ \boxed{ \text{Accuracy} + \text{Availability} + \text{Integrity} + \text{Continuity} + \text{Robustness} }. \]

Architecture and Navigation Integrity

Accuracy and integrity are not the same.

Accuracy asks:

How close is the navigation estimate to the true state?

Integrity asks:

Can the navigation system determine when its own solution should not be trusted?

This is particularly important during autonomous rendezvous and docking.

A spacecraft should not declare

\[ \boxed{\text{CAPTURE READY}} \]

merely because

\[ \left| \hat{\mathbf r}_{rel} \right| \le r_{capture}. \]

The system should also consider

\[ \left| \hat{\mathbf v}_{rel} \right| \le v_{capture} \]

together with uncertainty requirements such as

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

and

\[ \sigma_v \le \sigma_{v,max}. \]

A navigation-valid flag should also be required.

Conceptually,

\[ \boxed{ \text{Capture Ready} = \text{State Requirements} + \text{Uncertainty Requirements} + \text{Navigation Validity} }. \]

Example: Spacecraft Attitude Fusion Architecture

A representative attitude-determination system may use

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

while

\[ \boxed{\text{Star Tracker}}, \qquad \boxed{\text{Sun Sensor}}, \qquad \boxed{\text{Magnetometer}} \]

provide absolute or reference-vector corrections.

One architecture could use a centralized attitude estimator receiving all measurements.

Another architecture may retain

\[ \boxed{\text{Star Tracker}} \rightarrow \boxed{\text{Primary Attitude Solution}} \]

and

\[ \boxed{\text{Sun Sensor + Magnetometer}} \rightarrow \boxed{\text{Backup Attitude Solution}}. \]

The preferred architecture therefore depends not only on accuracy but also on reliability and fault-tolerance requirements.

Example: IMU/GNSS Navigation Architectures

Loose Coupling

\[ \boxed{\text{GNSS}} \rightarrow \boxed{ \mathbf r_{GNSS}, \mathbf v_{GNSS} } \]

followed by

\[ \boxed{ \mathbf r_{GNSS}, \mathbf v_{GNSS} } + \boxed{\text{INS}} \rightarrow \boxed{\text{EKF}}. \]

Tight Coupling

\[ \boxed{\text{GNSS Pseudorange / Doppler}} + \boxed{\text{IMU}} \rightarrow \boxed{\text{Integrated EKF}}. \]

Deep Coupling

\[ \boxed{\text{INS Prediction}} \leftrightarrow \boxed{\text{GNSS Tracking Loops}}. \]

These architectures demonstrate how increasing coupling depth exposes lower-level sensor information to the navigation system.

Example: RPO Navigation Architecture

Rendezvous and proximity operations often require a navigation architecture that changes progressively with range.

Far Range

\[ \boxed{\text{GNSS}} + \boxed{\text{IMU}} \rightarrow \boxed{ \hat{\mathbf r}_{rel}, \hat{\mathbf v}_{rel} }. \]

Mid Range

Camera measurements can be introduced:

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

GNSS and optical relative navigation can be cross-checked during this transition region.

Close Range

LiDAR may be added:

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

LiDAR strengthens range and relative-pose observability.

Capture

The navigation system may need to maintain

\[ \boxed{ \hat{\mathbf r}_{rel}, \hat{\mathbf v}_{rel}, \hat{\mathbf q}_{rel}, \hat{\boldsymbol{\omega}}_{rel} } \]

together with covariance and validity information.

A useful conceptual architecture is

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

while

\[ \boxed{\text{GNSS}}, \qquad \boxed{\text{Camera}}, \qquad \boxed{\text{LiDAR}} \]

provide phase-dependent corrections.

Architecture Selection Criteria

Sensor-fusion architecture should be selected from mission and system requirements rather than from estimator preference alone.

Important questions include:

• What states must be estimated?
• Which sensors observe those states?
• What are the sensor update rates?
• What are the measurement latencies?
• Which sensors share common information?
• What are the observability requirements?
• What navigation availability is required?
• What fault tolerance is required?
• What processor resources are available?
• How much communication bandwidth is available?
• How difficult will implementation and verification be?

Architecture selection is therefore a system-level engineering problem.

Centralized, Decentralized, Federated, and Cascaded Comparison

The following table gives typical characteristics. These are general tendencies rather than strict rules.

Loose, Tight, and Deep Coupling Comparison

Exact performance depends on sensor quality, measurement models, processing architecture, estimator tuning, and implementation.

Architecture Is a System-Level Trade-Off

There is no universally best sensor-fusion architecture.

A centralized estimator may provide excellent information sharing but increase software coupling and single-point failure risk.

A decentralized architecture may improve modularity and fault isolation but make statistical correlation management more difficult.

Loose coupling may simplify implementation but discard useful lower-level information.

Tight coupling may use measurements more efficiently but increase development and verification complexity.

Therefore,

\[ \boxed{ \text{Best Architecture} = f( \text{Mission}, \text{Sensors}, \text{Dynamics}, \text{Reliability}, \text{Computing}, \text{Verification} ) }. \]

There is no

\[ \boxed{\text{One Architecture Fits Every Spacecraft}}. \]

Practical Architecture Design Principle

A useful engineering principle is:

Fuse information at the lowest practical level that preserves useful measurement information, but not at a level that creates unjustified complexity, unmanageable correlation, or unacceptable verification burden.

This is more useful than assuming that tighter integration is always better.

The correct architecture is the one that satisfies the complete mission requirements with acceptable complexity and risk.

Complete Conceptual Spacecraft Sensor-Fusion Architecture

A realistic flight-navigation architecture can now be assembled from the concepts introduced above.

\[ \boxed{\text{Sensors}} \]

\[ \downarrow \]

\[ \boxed{ \begin{array}{c} \text{Timestamping}\\ \text{Calibration}\\ \text{Frame Transformation}\\ \text{Validity / Health} \end{array} } \]

\[ \downarrow \]

then one or more of

\[ \boxed{\text{Raw Measurement Fusion}} \]

\[ \boxed{\text{Feature Extraction}} \]

\[ \boxed{\text{Local Estimators}} \]

followed by

\[ \boxed{\text{Central / Master Navigation Estimator}} \]

producing

\[ \boxed{ \hat{\mathbf x}, \mathbf P, \text{Navigation Validity}, \text{Sensor Status} }. \]

These outputs are supplied to

\[ \boxed{\text{Guidance}} \rightarrow \boxed{\text{Control}} \rightarrow \boxed{\text{Actuators}}. \]

Parallel Health and FDIR Path

At the same time,

\[ \boxed{\text{Innovation Monitoring}} \rightarrow \boxed{\text{FDIR / Fusion Manager}} \]

determines

\[ \boxed{\text{Which Sensors May Participate in Fusion}}. \]

This architecture is much closer to a real spacecraft navigation system than the simplified representation

\[ \text{Sensor 1} + \text{Sensor 2} \rightarrow \text{Kalman Filter}. \]

Key Takeaways

The most important concepts from this section are:

• A fusion algorithm and a fusion architecture are different design concepts.
• Fusion can occur at measurement, feature, state, or decision level.
• Centralized fusion provides strong information integration but can increase complexity and coupling.
• Decentralized fusion improves modularity but creates correlation and information-management challenges.
• Federated fusion combines local estimators through a master fusion stage.
• Cascaded fusion passes estimated information from one estimator into another.
• Loose, tight, and deep coupling describe integration depth, not estimator distribution.
• State-level fusion must carefully handle cross-covariance and information double counting.
• Timing, latency, coordinate frames, covariance, validity, and health information are all part of the fusion interface.
• RPO navigation architectures should support sensor overlap, phase-dependent measurements, and safe handover.
• The best architecture is mission-dependent rather than universally centralized, decentralized, loose, or tight.

Next: 4.2.3 Complementary Filters

Sensor-fusion architecture determines where and how information is organised.

The next question is how two complementary sensor signals can be combined mathematically.

A classic example is spacecraft attitude estimation:

\[ \boxed{\text{Gyroscope}} + \boxed{\text{Absolute Attitude Reference}} \rightarrow \boxed{\text{Improved Attitude Estimate}}. \]

Section 4.2.3 develops this idea using complementary filtering, frequency separation, high-pass and low-pass behaviour, filter tuning, discrete implementation, and spacecraft attitude examples.