SIL/HIL and Flight Validation

4.2.31 SIL/HIL and Flight Validation

Developing a sensor-fusion algorithm in MATLAB or Simulink is only the beginning of the navigation-system development process. A filter may perform extremely well in an offline simulation while still failing when converted into software, executed at real-time rates, connected through actual communication interfaces, or supplied with real sensor data.

For this reason, spacecraft navigation algorithms normally progress through increasingly realistic verification environments.

A useful progression is

\[ \boxed{ \text{Model Simulation} \rightarrow \text{SIL} \rightarrow \text{PIL} \rightarrow \text{HIL} \rightarrow \text{Integrated System Testing} \rightarrow \text{Flight Validation} } \]

Each stage removes some of the assumptions present in the previous stage.

During mathematical simulation, the estimator is mainly being tested as an algorithm. During SIL, the executable software implementation becomes part of the test. During PIL, the target processor becomes part of the test. During HIL, real-time hardware, communication interfaces, timing, sensor emulation, and other physical components enter the loop. Flight validation finally evaluates the navigation system using measurements obtained in the actual operating environment.

The central question therefore changes progressively from

\[ \boxed{\text{Does the estimator mathematics work?}} \]

to

\[ \boxed{\text{Does the implemented navigation system work under realistic hardware and operational conditions?}} \]

4.2.31.1 Verification, Validation, and Qualification

These terms should be distinguished carefully.

Verification asks whether the system was implemented according to its specified design and requirements.

\[ \boxed{\text{Verification: Did we build the system correctly?}} \]

Examples include checking whether the implemented EKF equations match the reference algorithm, whether a sensor message is decoded correctly, whether the covariance matrix is propagated at the intended rate, or whether the estimator meets its execution-time requirement.

Validation asks whether the resulting system is suitable for the intended operational problem.

\[ \boxed{\text{Validation: Did we build the correct system?}} \]

For example, an estimator can be mathematically and computationally correct but still provide insufficient position accuracy for a particular navigation phase.

Qualification goes further and demonstrates that the hardware/software system can satisfy specified requirements under the required operational and environmental conditions.

These concepts overlap during navigation development, but they answer different engineering questions.

4.2.31.2 Why Simulation Alone Is Not Enough

An ideal simulation often assumes perfect execution of the estimator equations. Real systems introduce additional effects:

\[ \boxed{ \text{Real System} = \text{Algorithm} + \text{Software} + \text{Processor} + \text{Interfaces} + \text{Timing} + \text{Hardware} + \text{Environment} } \]

Problems that may not appear in a desktop simulation include execution jitter, finite numerical precision, packet delays, dropped messages, incorrect byte ordering, timestamp errors, task overruns, asynchronous sensor arrival, processor loading, communication latency, driver behavior, initialization sequencing, hardware resets, clock drift, and corrupted data.

Consequently,

\[ \boxed{\text{Successful Simulation} \not\Rightarrow \text{Successful Flight Implementation}} \]

Simulation verifies an important part of the system, but not the complete implementation.

4.2.31.3 Validation Ladder for Sensor Fusion

A useful sensor-fusion validation ladder is

\[ \boxed{ \text{Algorithm Verification} \rightarrow \text{SIL} \rightarrow \text{PIL} \rightarrow \text{HIL} \rightarrow \text{Integrated Avionics Test} \rightarrow \text{Flight Validation} } \]

At each stage, more of the real system replaces simulated components.

The objective is not simply to repeat the same test using more expensive equipment. Each stage should expose a different class of failure.

Engineering interpretation: The value of the ladder is progressive isolation. If a discrepancy first appears at PIL, the investigation can focus on processor, compiler, numerical, or scheduling effects instead of re-opening already verified estimator mathematics.

4.2.31.4 Reference or Golden Model

Before SIL or HIL testing begins, a trusted reference implementation should normally exist.

This may be a MATLAB implementation, validated Simulink model, or another independently verified numerical model.

Let the reference navigation output be

\[ \hat{\mathbf x}_{ref}(t) \]

and the implementation under test produce

\[ \hat{\mathbf x}_{test}(t). \]

The implementation difference can then be evaluated as

\[ \boxed{ \mathbf e_{impl}(t) = \hat{\mathbf x}_{test}(t) - \hat{\mathbf x}_{ref}(t) } \]

within defined numerical tolerances.

The reference model provides a baseline against which later software and hardware implementations can be compared.

4.2.31.5 Software-in-the-Loop — SIL

Software-in-the-loop testing evaluates the actual or representative navigation software while the surrounding spacecraft and sensor environment remains simulated.

Conceptually,

\[ \boxed{ \text{Simulated Dynamics} \rightarrow \text{Simulated Sensors} \rightarrow \text{Flight-Like Navigation Software} \rightarrow \text{Navigation Output} } \]

The important transition is that the estimator is no longer merely represented by convenient simulation blocks. Its software implementation is being exercised.

SIL can reveal errors introduced while translating mathematical equations into software.

4.2.31.6 Objectives of SIL Testing

SIL should verify that the implemented software reproduces the intended estimator behavior.

Important checks include state propagation, covariance propagation, measurement prediction, innovation calculation, Kalman gain calculation, state correction, covariance correction, quaternion updates, normalization, measurement gating, sensor validity logic, mode switching, initialization, reset behavior, and navigation-health logic.

The SIL output should be compared with the reference model:

\[ \boxed{ \hat{\mathbf x}_{SIL} \approx \hat{\mathbf x}_{reference} } \]

and, where applicable,

\[ \boxed{ \mathbf P_{SIL} \approx \mathbf P_{reference}. } \]

Small numerical differences may be acceptable depending on numerical precision and implementation details, but unexplained divergence should be investigated.

4.2.31.7 SIL Test Inputs

SIL should not be limited to nominal trajectories.

Inputs should include deterministic cases, noisy sensor data, biased measurements, initialization errors, sensor dropout, measurement latency, outliers, asynchronous measurements, invalid packets, mode transitions, sensor reacquisition, and dynamic manoeuvres.

The same Monte Carlo cases developed in Section 4.2.30 can also become SIL regression cases.

This provides continuity:

\[ \boxed{ \text{Monte Carlo Simulation Cases} \rightarrow \text{SIL Regression Cases} } \]

4.2.31.8 Automatically Generated Code

When Simulink code generation is used, SIL provides an important opportunity to compare model behavior against generated code.

The desired relationship is

\[ \boxed{ \text{Simulink Reference} \approx \text{Generated-Code SIL} } \]

The comparison should cover more than final state estimates. Intermediate quantities such as innovations, covariance, gains, validity flags, estimator modes, and reset events should also be compared.

This helps isolate discrepancies before processor hardware is introduced.

Engineering interpretation: Generated code should be treated as a new implementation artifact rather than assumed equivalent to the model. Equivalence testing is strongest when intermediate estimator quantities are compared at identical timestamps and update events.

4.2.31.9 Numerical Precision in SIL

A desktop model may use double-precision arithmetic while flight software may use single precision or another constrained numerical representation.

Therefore tests should examine

\[ \text{double precision} \quad\text{vs}\quad \text{flight implementation precision}. \]

Quantities especially sensitive to numerical precision include covariance matrices, very small process-noise values, quaternion normalization, matrix factorization, innovation covariance, and nearly singular geometries.

An estimator that works in double precision should not automatically be assumed to behave identically under the flight numerical architecture.

4.2.31.10 Processor-in-the-Loop — PIL

PIL introduces the target or representative processor.

The architecture becomes

\[ \boxed{ \text{Host Simulation} \leftrightarrow \text{Target Processor Running Navigation Software} } \]

The physical spacecraft and sensors may still be simulated, but the estimator executes on hardware representative of the onboard computer.

This allows verification of both numerical equivalence and computational performance.

4.2.31.11 Why PIL Is Important

PIL can expose processor-specific effects that SIL cannot reproduce completely.

These include execution time, compiler behavior, optimization effects, processor architecture, floating-point implementation, memory limitations, task scheduling, and data representation.

The navigation software must not only produce the correct answer; it must produce it before its deadline.

If an estimator has an update period

\[ T_{nav}, \]

its worst-case execution time should satisfy an appropriate timing margin such as

\[ \boxed{ T_{exec,max}

4.2.31.12 Execution-Time Measurement

Average execution time alone is insufficient.

Important quantities include

\[ T_{exec,min},\qquad T_{exec,mean},\qquad T_{exec,max} \]

and preferably the distribution of execution times.

Worst-case behavior may occur during expensive measurement updates, simultaneous sensor arrivals, mode transitions, matrix operations, or fault-handling routines.

The processor load should therefore be examined under realistic worst-case conditions.

Engineering interpretation: Timing should be assessed under representative peak workload, not only during a quiet nominal case. Simultaneous measurement updates, logging, fault logic, and matrix operations often create the longest execution paths.

4.2.31.13 Real-Time Deadline Verification

Suppose the estimator executes at

\[ f_{nav}=100\text{ Hz}. \]

Then

\[ T_{nav}=10\text{ ms}. \]

If a navigation cycle occasionally requires 12 ms, the estimator may be mathematically correct but operationally unsuitable.

Thus,

\[ \boxed{ \text{Correct Numerical Output} + \text{Missed Deadline} = \text{Implementation Failure} } \]

for a real-time task whose result is required within that deadline.

4.2.31.14 Hardware-in-the-Loop — HIL

Hardware-in-the-loop testing introduces real hardware into a real-time simulated environment.

A general architecture is

\[ \boxed{ \text{Real-Time Dynamics Simulator} \rightarrow \text{Sensor Emulator / Interfaces} \rightarrow \text{Flight Computer} \rightarrow \text{Navigation Software} } \]

with appropriate outputs returned to the simulation or other avionics.

HIL moves testing from primarily algorithm/software verification toward system-level behavior.

4.2.31.15 What HIL Adds

HIL can introduce effects such as actual processors, interface boards, real communication protocols, hardware clocks, physical wiring, sensor emulators, real sensor electronics, actuator electronics, network traffic, operating-system scheduling, interrupt behavior, and realistic data latency.

Therefore,

\[ \boxed{ \text{HIL} = \text{Real Hardware} + \text{Real-Time Simulation} + \text{Real Interfaces} } \]

at the appropriate level of system fidelity.

4.2.31.16 Real-Time Simulation

For HIL, the simulated environment must normally execute in real time.

If the physical interval is

\[ \Delta t=1\text{ ms}, \]

the simulator must complete the required computation and I/O within the corresponding real-time interval.

Unlike an offline simulation, it cannot simply slow down when computation becomes difficult.

This requirement makes computational determinism an important part of HIL architecture.

Engineering interpretation: Real-time fidelity requires both correct equations and deterministic scheduling. A simulator that produces accurate states but misses its wall-clock deadlines can invalidate HIL timing, latency, and interface conclusions.

4.2.31.17 Sensor Emulation

A sensor emulator attempts to reproduce what the flight computer would receive from a real sensor.

Instead of passing an ideal Simulink vector directly to the estimator, the chain becomes closer to

\[ \boxed{ \text{Truth Simulation} \rightarrow \text{Sensor Physics/Errors} \rightarrow \text{Sensor Data Format} \rightarrow \text{Physical Interface} \rightarrow \text{Flight Computer} } \]

The emulator may reproduce sensor update rates, quantization, message structure, timestamps, status words, noise, bias, latency, dropout, and fault conditions.

This tests substantially more than the estimator equation alone.

4.2.31.18 Electrical-Level Sensor Emulation

Different HIL configurations can inject data at different levels.

A high-level emulator may transmit already formatted digital messages.

A deeper emulator may reproduce electrical or protocol-level behavior.

The choice depends on what is being verified.

If only estimator mathematics is being tested, high-level injection may be sufficient. If drivers, interfaces, synchronization, and avionics integration are being verified, lower-level emulation becomes more valuable.

Engineering interpretation: The injection level determines what is actually being verified. Injecting already-decoded values can validate estimator logic, but it bypasses physical interfaces, drivers, packet parsing, electrical behavior, and some timing effects.

4.2.31.19 Real Sensors in the Loop

Some tests can use actual sensors rather than emulated measurements.

Examples can include an IMU mounted on a motion platform, a camera viewing a simulated target scene, a star tracker viewing an optical simulator, or a ranging sensor observing a representative target.

The architecture becomes

\[ \boxed{ \text{Physical Stimulus} \rightarrow \text{Real Sensor} \rightarrow \text{Flight Interface} \rightarrow \text{Navigation Computer} } \]

This validates sensor behavior and navigation processing together.

4.2.31.20 IMU HIL Testing

For an IMU, a motion table can provide known angular motion or acceleration.

The sensor reports

\[ \boldsymbol{\omega}_m,\qquad \mathbf f_m \]

while the commanded table motion provides a reference.

Tests can examine scale factor, bias, axis alignment, latency, sampling, saturation, startup behavior, bias stability, and estimator bias convergence.

The objective is not simply to check whether the IMU produces data, but whether the complete navigation chain interprets those data correctly.

4.2.31.21 Camera and Vision HIL

Vision-based navigation requires additional considerations because the measurement depends on scene geometry and image processing.

A test architecture can be

\[ \boxed{ \text{Simulated Geometry} \rightarrow \text{Rendered Optical Scene} \rightarrow \text{Camera} \rightarrow \text{Vision Processing} \rightarrow \text{Estimator} } \]

Tests should consider illumination, field of view, target visibility, image rate, image-processing latency, feature loss, false detections, blur, exposure, and geometry.

The navigation system should receive the same type of processed information expected during operation.

4.2.31.22 Range and LiDAR HIL

Range-based navigation can similarly be tested using physical targets, range simulators, synthetic measurement injection, or hardware emulators.

Relevant effects include minimum and maximum range, range resolution, update rate, field of view, target reflectivity, invalid returns, point-cloud processing latency, and target loss.

For navigation verification, the important output is not merely whether the sensor detects something but whether the resulting measurement produces the expected estimator correction.

4.2.31.23 GNSS Hardware Testing

GNSS receiver testing can use a GNSS signal simulator to reproduce satellite signals corresponding to a prescribed trajectory.

This permits testing of receiver acquisition, tracking, navigation solutions, outages, geometry changes, Doppler behavior, timing, and navigation-software interfaces without requiring the vehicle to execute the actual trajectory.

For tightly coupled architectures, raw measurements such as pseudorange and Doppler can be particularly important.

Engineering interpretation: Receiver-level testing is particularly valuable because it exercises acquisition, tracking, timing, message generation, and the navigation interface together. This is different from injecting an already-computed position and velocity solution.

4.2.31.24 Communication Interfaces

Real navigation systems communicate through defined hardware interfaces and protocols.

Examples include CAN, UART, SPI, I²C, Ethernet, SpaceWire and other mission-specific buses.

Testing should verify message encoding, byte order, packet length, message identifiers, checksums or CRCs, timestamps, sequence counters, status fields, units, scaling, signed/unsigned interpretation, and error handling.

A correct estimator supplied with incorrectly decoded sensor data is still an incorrect navigation system.

4.2.31.25 Interface Control Documents

Each navigation interface should have a clearly defined data contract.

An interface specification should describe quantities such as signal name, physical meaning, units, reference frame, data type, dimensions, scaling, valid range, update rate, timestamp convention, latency expectation, validity flags, and fault/status codes.

For example,

\[ \boxed{ \text{Measurement} = \{\mathbf z,\;t,\;frame,\;units,\;valid,\;status\}. } \]

HIL provides an opportunity to verify that the actual implementation conforms to this interface definition.

4.2.31.26 Timestamp Verification

Correct timestamps are fundamental to sensor fusion.

For a measurement

\[ \mathbf z(t_m) \]

the estimator must know that its physical acquisition time was t_m, even if it arrives later.

HIL testing should therefore distinguish

\[ t_{measurement}, \qquad t_{arrival}, \qquad t_{processing}. \]

These quantities are not interchangeable.

4.2.31.27 End-to-End Latency

Total navigation latency may be decomposed approximately as

\[ \boxed{ \tau_{total} = \tau_{sensor} + \tau_{processing} + \tau_{communication} + \tau_{queue} + \tau_{estimator} } \]

and possibly additional downstream latency.

End-to-end latency should be measured rather than assumed.

For dynamic systems, even a highly accurate measurement can become harmful if it is applied at the wrong time.

4.2.31.28 Timing Jitter

Latency may also vary.

If nominal delay is \bar{\tau}, actual delay may be

\[ \tau_k=\bar{\tau}+\delta\tau_k. \]

The variation

\[ \delta\tau_k \]

is timing jitter.

HIL testing should characterize both average latency and its variability because estimator performance may be sensitive to irregular measurement timing.

4.2.31.29 Clock Synchronization

Different hardware components may maintain different clocks.

For two devices,

\[ t_A \neq t_B \]

unless synchronization is maintained.

Clock offset and drift can create apparent timing errors even when communication latency is small.

Navigation testing should therefore examine clock synchronization, timestamp origin, clock drift, rollover, reset behavior, and synchronization recovery.

4.2.31.30 Asynchronous Sensor Arrival

Real sensors rarely deliver measurements simultaneously.

The navigation computer may receive IMU, GNSS, camera, LiDAR, star-tracker, or other measurements at independent times.

HIL should verify that

\[ \boxed{ \text{New Valid Measurement} \Rightarrow \text{Correct Sensor-Specific Update} } \]

without accidentally reusing old measurements.

Engineering interpretation: Correct asynchronous fusion requires each update to use the state and covariance corresponding to the measurement epoch. Reusing stale data or applying a measurement at arrival time instead of measurement time can create systematic errors.

4.2.31.31 Packet Loss

Communication systems may lose packets.

If measurement k is lost,

\[ \mathbf z_k \rightarrow \varnothing. \]

The estimator should normally continue propagation and process whatever other valid information remains available.

HIL tests should verify both isolated packet loss and burst loss.

Engineering interpretation: Packet loss should be visible to navigation-health logic so that missing information is distinguished from a valid zero-valued measurement. The estimator should also avoid silently reusing an old sample as if it were new.

4.2.31.32 Corrupted Data

Packets can also be corrupted.

Tests may deliberately introduce incorrect CRC, invalid length, impossible values, corrupted timestamps, invalid status fields, NaN/Inf values, or inconsistent sequence counters.

The desired architecture is

\[ \boxed{ \text{Corrupted Input} \rightarrow \text{Detection} \rightarrow \text{Rejection/Isolation} } \]

rather than allowing bad information to silently enter the estimator.

4.2.31.33 Sensor Dropout

Sensor dropout should be tested at the hardware/interface level as well as in simulation.

The navigation system should demonstrate graceful degradation:

\[ \boxed{ \text{Sensor Loss} \rightarrow \text{Prediction / Remaining Sensors} \rightarrow \text{Increasing Uncertainty} } \]

rather than an unexplained estimator failure.

Reacquisition should also be tested.

4.2.31.34 Reacquisition

When a sensor becomes available again, its first measurement should not necessarily be accepted blindly.

A robust sequence may be

\[ \boxed{ \text{Sensor Returns} \rightarrow \text{Health Check} \rightarrow \text{Measurement Validation} \rightarrow \text{Innovation Gate} \rightarrow \text{Update} } \]

This is particularly important after long outages, during which estimator uncertainty and sensor conditions may have changed significantly.

4.2.31.35 Fault Injection in HIL

HIL should support deliberate fault injection.

Useful faults include bias steps, increased noise, frozen output, saturation, delayed packets, dropped packets, corrupted packets, timestamp errors, frame errors, scale-factor errors, sensor resets, communication loss, and intermittent availability.

The objective is to evaluate the response of the complete navigation chain.

Engineering interpretation: A useful fault-injection campaign should define when the fault begins, its magnitude or duration, the expected detection mechanism, the allowed navigation disturbance, and the required recovery behavior.

4.2.31.36 FDIR Interaction

Sensor fusion and Fault Detection, Isolation and Recovery are closely connected.

Estimator residuals can provide evidence of sensor inconsistency:

\[ \mathbf r_k = \mathbf z_k-h(\hat{\mathbf x}_k^-). \]

Large or persistent residuals may trigger monitoring logic.

The architecture can therefore include

\[ \boxed{ \text{Sensor} \rightarrow \text{Estimator Residual} \rightarrow \text{FDIR} \rightarrow \text{Sensor Validity/Mode Logic} } \]

HIL should verify this interaction, including false alarms and missed detections where relevant.

4.2.31.37 Navigation Mode Transitions

Navigation systems may operate in several modes.

For example,

\[ \boxed{ \text{Initialization} \rightarrow \text{Acquisition} \rightarrow \text{Nominal Navigation} \rightarrow \text{Degraded Navigation} \rightarrow \text{Reacquisition} } \]

HIL testing should verify both nominal transitions and unexpected transitions caused by faults or loss of measurements.

4.2.31.38 Sensor Handover

Some missions use different sensor combinations as geometry, environment, or mission phase changes.

The important principle is general:

\[ \boxed{ \text{Sensor Set A} \rightarrow \text{Overlap / Validation} \rightarrow \text{Sensor Set B} } \]

Handover testing should verify continuity of the navigation solution, covariance behavior, residuals, timestamps, and validity logic.

There should not be an artificial state jump simply because the measurement source changes.

4.2.31.39 RPO Navigation Validation

For general rendezvous and proximity operations, the navigation state may contain

\[ \mathbf x_{rel} = \begin{bmatrix} \mathbf r_{rel}\\ \mathbf v_{rel}\\ \mathbf q_{rel}\\ \boldsymbol{\omega}_{rel} \end{bmatrix}. \]

Different sensors can constrain different components of this state depending on range, geometry, visibility, and operating conditions.

A general validation architecture therefore examines

\[ \boxed{ \text{Relative Dynamics} + \text{Available Relative Measurements} \rightarrow \text{Relative Navigation Solution} } \]

without assuming a particular spacecraft, sensor sequence, or mission architecture.

Tests should examine accuracy, continuity, sensor transitions, target loss, reacquisition, latency, relative-state observability, and navigation validity.

4.2.31.40 Closed-Loop HIL

Eventually the estimator should be tested as part of the complete GNC loop.

\[ \boxed{ \text{Real-Time Plant} \rightarrow \text{Sensors} \rightarrow \text{Navigation} \rightarrow \text{Guidance} \rightarrow \text{Control} \rightarrow \text{Actuation} \rightarrow \text{Plant} } \]

This is critical because navigation errors now influence control actions.

A navigation disturbance may produce

\[ \text{Navigation Error} \rightarrow \text{Control Error} \rightarrow \text{Trajectory Change} \rightarrow \text{New Measurements}. \]

Thus the estimator can no longer be evaluated independently of the closed-loop system.

4.2.31.41 Navigation-to-Guidance Interface

The navigation subsystem should provide a well-defined output interface such as

\[ \boxed{ NavBus= \{ \hat{\mathbf x}, \mathbf P, timestamp, NavValid, NavMode, quality \}. } \]

Guidance should consume this interface without requiring access to internal filter variables.

HIL should verify correct units, frames, timing, validity, and update rate across this boundary.

4.2.31.42 Guidance-to-Control and Navigation-to-Control Interaction

Control may use navigation estimates directly.

For translation,

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

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

For attitude,

\[ \mathbf e_q = \mathbf q_{ref}\otimes\hat{\mathbf q}^{-1}. \]

Therefore navigation bias, latency, noise, and dropout can propagate directly into actuator commands.

Integrated HIL testing should explicitly evaluate these effects.

4.2.31.43 Actuator Feedback

Some navigation estimators use knowledge of applied control.

Therefore the distinction between

\[ \mathbf u_{cmd} \]

and

\[ \mathbf u_{actual} \]

remains important.

HIL can expose actuator delays, saturation, deadband, quantization, and command-interface behavior that may not have been represented fully in earlier simulation.

If actuator telemetry is available onboard, its use in the estimator should also be verified.

4.2.31.44 Navigation Accuracy Requirements

Validation should always be linked to requirements.

Typical metrics include position error,

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

velocity error,

\[ e_v=\|\mathbf v_{true}-\hat{\mathbf v}\|, \]

attitude error, angular-rate error, bias-estimation error, and relative-navigation errors.

A test should define pass/fail limits before the test rather than judging plots subjectively afterward.

4.2.31.45 Navigation Availability

Accuracy alone is insufficient.

Navigation availability may be defined as the fraction of required operating time during which a valid navigation solution is available:

\[ \boxed{ A_{nav} = \frac{T_{\text{valid navigation}}} {T_{\text{required operation}}}. } \]

A system that is extremely accurate only intermittently may still be unsuitable.

4.2.31.46 Navigation Continuity

Continuity concerns whether navigation remains available without unexpected interruption during an operation.

Testing should therefore monitor dropouts, estimator resets, invalid-state transitions, covariance excursions, sensor handovers, and processor faults.

This becomes particularly important during time-critical manoeuvres.

Engineering interpretation: Continuity is a time-domain property. It is therefore evaluated by whether a valid solution remains available throughout a required operation, not simply by checking accuracy at isolated timestamps.

4.2.31.47 Navigation Integrity

Navigation integrity concerns confidence that the provided solution is not misleading beyond acceptable limits without appropriate warning.

This introduces a distinction between

\[ \boxed{\text{Estimate Accuracy}} \]

and

\[ \boxed{\text{Trustworthiness of the Reported Navigation Solution}}. \]

Residual monitoring, covariance monitoring, sensor health, consistency checks, and validity logic all contribute to integrity assessment.

4.2.31.48 Covariance Validation

When the estimator outputs covariance,

\[ \mathbf P, \]

HIL and flight-data analysis should compare actual estimation error with predicted uncertainty where truth or sufficiently accurate reference data are available.

For component i,

\[ e_i=x_i-\hat{x}_i \]

can be compared with

\[ \pm3\sqrt{P_{ii}}. \]

Repeated violations can indicate incorrect process noise, measurement noise, unmodelled errors, timing problems, or inconsistent estimator assumptions.

4.2.31.49 Innovation Validation

Innovation should remain a central diagnostic:

\[ \boxed{ \mathbf r_k = \mathbf z_k-h(\hat{\mathbf x}_k^-) } \]

HIL should log innovations for every sensor.

Analysis should examine mean, variance, outliers, temporal correlation, gating events, and behavior around mode transitions or sensor faults.

A state estimate that appears smooth can still hide a badly inconsistent measurement model; innovations often reveal the problem.

4.2.31.50 NIS During Hardware Testing

For innovation

\[ \mathbf r_k \]

and innovation covariance

\[ \mathbf S_k, \]

the normalized innovation squared is

\[ \boxed{ NIS_k = \mathbf r_k^T\mathbf S_k^{-1}\mathbf r_k. } \]

This can be used to evaluate whether innovations are statistically compatible with the uncertainty assumed by the estimator.

It also provides continuity with the Monte Carlo consistency analysis from Section 4.2.30.

4.2.31.51 NEES When Reference Truth Is Available

When sufficiently accurate truth is available,

\[ \tilde{\mathbf x} = \mathbf x_{true}-\hat{\mathbf x}, \]

and

\[ \boxed{ NEES = \tilde{\mathbf x}^{T} \mathbf P^{-1} \tilde{\mathbf x}. } \]

This assesses whether actual state error is compatible with estimated covariance.

In hardware or flight testing, obtaining sufficiently accurate independent truth can itself be a major engineering challenge.

4.2.31.52 Truth and Reference Systems

Ground testing can use high-accuracy reference instrumentation to establish truth.

Depending on the application, reference sources can include precision motion tables, optical tracking systems, metrology systems, external navigation systems, calibrated targets, or high-grade reference sensors.

The reference system should normally be more accurate than the system being validated.

Otherwise,

\[ \boxed{ \text{Measured Test Error} = \text{Navigation Error} + \text{Reference Error} } \]

and the two contributions may be difficult to separate.

4.2.31.53 Recorded-Data Replay

Recorded sensor data provide an important bridge between simulation and flight testing.

A common architecture is

\[ \boxed{ \text{Recorded Sensor Data} \rightarrow \text{Navigation Software} \rightarrow \text{Estimated State} } \]

The same dataset can be replayed repeatedly after software changes.

This makes recorded data extremely valuable for regression testing.

4.2.31.54 Deterministic Replay

For a fixed dataset and deterministic software configuration, repeated execution should ideally produce repeatable outputs within the expected numerical behavior.

If identical data generate different navigation solutions between runs, the cause should be understood.

Possible causes include nondeterministic scheduling, uninitialized memory, asynchronous execution, race conditions, or hidden state.

Engineering interpretation: Deterministic replay is valuable because it turns a complex flight or HIL event into a repeatable software test. Once the same input sequence is preserved, algorithm changes can be compared against identical evidence.

4.2.31.55 Regression Testing

Every corrected software defect should ideally become a regression test.

The philosophy is

\[ \boxed{ \text{Observed Failure} \rightarrow \text{Root Cause} \rightarrow \text{Correction} \rightarrow \text{Permanent Regression Case}. } \]

A growing regression suite prevents previously solved problems from reappearing during later development.

4.2.31.56 Requirement-Based Test Cases

Tests should map directly to requirements.

A useful structure is

\[ \boxed{ \text{Requirement} \rightarrow \text{Test Method} \rightarrow \text{Input} \rightarrow \text{Expected Result} \rightarrow \text{Pass/Fail Evidence}. } \]

For example, a requirement on position accuracy should map to a defined scenario, truth source, evaluation interval, metric, and numerical acceptance limit.

This provides traceability.

4.2.31.57 Test Coverage

Testing should cover more than nominal behavior.

Important categories include nominal cases, boundary conditions, worst-case conditions, initialization, degraded modes, sensor faults, communication faults, timing faults, processor loading, sensor handover, reset/recovery, and invalid inputs.

Coverage should address both functional behavior and numerical behavior.

4.2.31.58 Boundary Testing

Parameters should be tested near operational limits.

Examples include minimum and maximum sensor range, field-of-view boundaries, maximum angular rate, maximum acceleration, maximum expected latency, minimum measurement quality, and covariance thresholds.

Many implementation failures occur near transitions rather than near nominal operating points.

4.2.31.59 Stress Testing

Stress testing intentionally pushes the system beyond ordinary nominal loading.

Examples include unusually high sensor message rates, simultaneous measurements, heavy processor load, repeated packet corruption, long dropouts, rapid mode transitions, and extended operation.

The objective is to understand margins and failure behavior.

Engineering interpretation: Stress tests are not intended to represent the most likely operating condition. They are used to identify margins, bottlenecks, queue growth, missed deadlines, and failure behavior before those effects appear unexpectedly in integrated testing.

4.2.31.60 Long-Duration Testing

Some problems appear only after long execution periods.

Examples include clock drift, timer rollover, memory leakage, accumulated numerical error, slow covariance divergence, thermal effects, or bias evolution.

Long-duration HIL tests can therefore reveal failures that short functional tests cannot.

4.2.31.61 Reset and Restart Testing

Navigation software should be tested through startup, reset, processor restart, sensor restart, and estimator reinitialization.

Questions include:

Does the estimator initialize safely? Are old measurements discarded? Are timestamps re-established? Is covariance initialized correctly? Does navigation validity remain false until sufficient information becomes available?

Reset behavior is part of the navigation architecture, not an exceptional afterthought.

4.2.31.62 Parameter and Configuration Verification

The correct algorithm with the wrong configuration can still fail.

HIL should verify loaded values for

\[ \mathbf Q,\quad \mathbf R,\quad \mathbf P_0, \]

sensor calibration, frame transformations, sample rates, thresholds, and mode-dependent parameters.

Configuration identifiers and software versions should be recorded with every formal test.

4.2.31.63 Software Version Control

Every verification result should be traceable to a specific software build and configuration.

A test record should identify the navigation-software version, model version, generated-code version where applicable, parameter set, hardware version, simulator version, test scenario, and test date.

Otherwise a successful test may not demonstrate the behavior of the final implementation.

Engineering interpretation: Verification evidence is only valid for a known configuration. Software, calibration data, estimator tuning, hardware revision, and simulator configuration should therefore be treated as one controlled test baseline.

4.2.31.64 Data Logging in SIL/PIL/HIL

The logging architecture should preserve enough information to reconstruct estimator behavior.

Important signals include

\[ \mathbf z,\; \hat{\mathbf z},\; \mathbf r,\; \hat{\mathbf x},\; \mathbf P,\; \mathbf K \]

together with timestamps, validity flags, update events, rejection events, navigation modes, sensor status, processor timing, controller outputs, and actuator commands.

Logging only the final navigation solution makes debugging unnecessarily difficult.

4.2.31.65 Event Synchronization in Logs

Signals from different computers or sensors should be synchronized before comparison.

A position error computed from signals with different timestamps is not a valid position error.

Therefore,

\[ \boxed{ \text{Correct Analysis} = \text{Correct Data} + \text{Correct Time Alignment}. } \]

Time synchronization should be treated as part of post-processing as well as real-time operation.

4.2.31.66 Automated Test Execution

Large navigation verification campaigns benefit strongly from automation.

A test framework can automatically configure the scenario, load software, initialize hardware, execute the test, record data, calculate metrics, compare requirements, generate plots, and produce a pass/fail report.

This improves repeatability and reduces manual errors.

4.2.31.67 Automated Pass/Fail Criteria

Where possible, formal tests should use quantitative acceptance criteria.

For example,

\[ RMSE_r < r_{req}, \]

\[ RMSE_v < v_{req}, \]

\[ T_{exec,max}

and defined navigation availability or consistency requirements.

Plots remain useful, but they should support rather than replace quantitative evaluation.

4.2.31.68 Monte Carlo HIL

Not every Monte Carlo run needs physical hardware, because HIL time is expensive.

However, selected uncertainty campaigns can be executed through HIL.

A practical approach is

\[ \boxed{ \text{Large Simulation Monte Carlo} \rightarrow \text{Selected SIL/PIL Campaign} \rightarrow \text{Focused HIL Cases}. } \]

HIL cases should emphasize uncertainties and failures that depend on hardware, timing, interfaces, or real-time execution.

4.2.31.69 Worst-Case Case Selection

Monte Carlo analysis can help identify difficult cases.

These cases can then be replayed through SIL or HIL.

Thus,

\[ \boxed{ \text{Monte Carlo Failure/Boundary Case} \rightarrow \text{Deterministic Replay} \rightarrow \text{HIL Verification}. } \]

This is usually more informative than selecting HIL scenarios arbitrarily.

4.2.31.70 Model Correlation

As testing progresses, simulation results should be compared against hardware measurements.

If the real sensor exhibits different noise, bias, latency, or dropout behavior from the sensor model, the simulation model should be reconsidered.

This creates a useful feedback loop:

\[ \boxed{ \text{Simulation} \rightarrow \text{Hardware Test} \rightarrow \text{Model Correlation} \rightarrow \text{Improved Simulation}. } \]

Engineering interpretation: Correlation closes the loop between simulation and hardware evidence. Differences should be used to improve sensor, timing, and interface models rather than merely adjusting plots after the test.

4.2.31.71 Flight Validation

Flight validation evaluates navigation performance using measurements collected in the actual operating environment.

The architecture becomes

\[ \boxed{ \text{Real Vehicle} + \text{Real Dynamics} + \text{Real Sensors} + \text{Real Environment} + \text{Flight Software}. } \]

This is the highest-fidelity environment, but it is also the least controllable and usually the most expensive.

Therefore flight testing should build upon evidence already obtained through simulation, SIL, PIL, and HIL.

4.2.31.72 Why Flight Validation Is Still Necessary

Ground tests cannot reproduce every operational effect perfectly.

Flight can reveal unmodelled environmental disturbances, actual sensor behavior, structural effects, thermal effects, electromagnetic interactions, real communication behavior, unexpected geometry, and operational procedures.

Flight validation therefore provides evidence that the integrated navigation system behaves correctly in its intended environment.

4.2.31.73 Flight-Test Instrumentation

Where possible, additional instrumentation should provide independent reference information.

The objective is to compare

\[ \hat{\mathbf x}_{flight} \]

with the best available independent reference

\[ \mathbf x_{ref}. \]

Reference quality must be quantified because it limits the accuracy of the validation itself.

4.2.31.74 Flight-Data Time Synchronization

Flight data may originate from multiple clocks and recorders.

Before estimator performance is assessed, data must be aligned to a common time basis.

This may require clock-offset correction, drift correction, packet-time reconstruction, interpolation, or event-based synchronization.

Poor synchronization can falsely appear as navigation error.

4.2.31.75 Flight-Data Reconstruction

Post-flight analysis should reconstruct the complete navigation timeline.

This includes sensor availability, estimator mode, measurements accepted and rejected, innovations, state estimates, covariance, navigation validity, guidance commands, control commands, actuator activity, and important mission events.

The purpose is to understand not merely what the final error was, but why the estimator behaved as it did.

4.2.31.76 Comparison with Pre-Flight Prediction

Flight results should be compared against predicted performance envelopes from simulation and Monte Carlo analysis.

For example,

\[ \boxed{ \text{Flight Error Distribution} \quad\text{vs}\quad \text{Predicted Error Distribution}. } \]

Significant disagreement may indicate unmodelled uncertainty, incorrect sensor characterization, timing differences, or estimator assumptions that were not representative of flight.

4.2.31.77 Flight Residual Analysis

Sensor innovations should be examined using flight data.

Persistent innovation bias can reveal calibration error, frame misalignment, timing error, environmental effects, or model mismatch.

Thus flight residual analysis can be valuable even when a highly accurate independent truth solution is unavailable.

4.2.31.78 Flight Covariance Consistency

If the estimator reports uncertainty, flight data should be used to determine whether that uncertainty was realistic.

When reference truth is sufficiently accurate,

\[ |e_i| \]

can be compared against

\[ k\sqrt{P_{ii}}. \]

When complete truth is unavailable, innovation-based consistency analysis can still provide useful information.

Engineering interpretation: Flight covariance assessment is strongest when an independent truth source exists. Where full truth is unavailable, innovation behavior, cross-sensor comparisons, and known event responses can still reveal inconsistency.

4.2.31.79 Anomaly Investigation

Any navigation anomaly should be reconstructed systematically.

A useful chain is

\[ \boxed{ \text{Observed Anomaly} \rightarrow \text{Timeline Reconstruction} \rightarrow \text{Sensor/Interface Examination} \rightarrow \text{Estimator Internal Analysis} \rightarrow \text{Root Cause} \rightarrow \text{Corrective Action}. } \]

The corresponding case should then be reproduced in simulation or HIL whenever practical.

4.2.31.80 Closing the Verification Loop

Flight observations should feed back into the engineering models.

For example,

\[ \boxed{ \text{Flight Data} \rightarrow \text{Updated Sensor Characterization} \rightarrow \text{Updated Simulation} \rightarrow \text{Regression Testing}. } \]

Thus flight validation is not simply the end of the process; it improves the models used for subsequent development.

4.2.31.81 Complete Sensor-Fusion Verification Flow

The complete development chain can now be summarized as

\[ \boxed{\text{Mathematical Algorithm}} \]

\[ \downarrow \]

\[ \boxed{\text{MATLAB/Simulink Reference Model}} \]

\[ \downarrow \]

\[ \boxed{\text{Monte Carlo Verification}} \]

\[ \downarrow \]

\[ \boxed{\text{Software-in-the-Loop}} \]

\[ \downarrow \]

\[ \boxed{\text{Processor-in-the-Loop}} \]

\[ \downarrow \]

\[ \boxed{\text{Hardware-in-the-Loop}} \]

\[ \downarrow \]

\[ \boxed{\text{Integrated Avionics / GNC Testing}} \]

\[ \downarrow \]

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

\[ \downarrow \]

\[ \boxed{\text{Model Correlation and Continued Regression}} \]

Each stage should preserve traceability to the original navigation requirements.

4.2.31.82 What Should Be Verified at Each Stage

The focus changes progressively.

Model-level testing establishes mathematical correctness, convergence, observability, sensor-model behavior, and expected estimator performance.

SIL establishes software equivalence, logic correctness, initialization, measurement handling, estimator modes, and numerical implementation.

PIL adds target-processor execution, timing, memory, numerical architecture, and computational margin.

HIL adds real-time behavior, hardware interfaces, clocks, communication, sensor emulation, packet faults, latency, and integrated avionics.

Flight validation adds the actual vehicle, environment, sensors, operational geometry, and mission execution.

No single stage completely replaces the others.

Engineering interpretation: The stages are complementary rather than interchangeable. Passing HIL does not remove the need for model-level statistical analysis, and passing simulation does not provide evidence for processor timing or physical interfaces.

4.2.31.83 Common SIL/HIL Mistakes

Several mistakes can make sophisticated test facilities provide misleading confidence:

• using truth signals that would not exist onboard;
• testing only nominal trajectories;
• ignoring measurement timestamps;
• injecting measurements after the interface layer and therefore bypassing drivers that need verification;
• assuming zero communication latency;
• measuring only average processor execution time;
• failing to test simultaneous sensor updates;
• using different parameter sets between simulation and flight software;
• not recording software/hardware versions;
• comparing signals without time alignment;
• testing sensor dropout but not reacquisition;
• testing estimator output but not covariance and innovations;
• failing to test resets and initialization;
• using an inaccurate reference system as unquestioned truth;
• changing multiple system elements simultaneously during debugging;
• performing HIL without first establishing SIL equivalence;
• relying on visual plots without numerical acceptance criteria.

A successful HIL run is meaningful only when the configuration, requirements, reference data, and pass/fail criteria are controlled.

4.2.31.84 Recommended SIL/HIL Development Sequence

A practical progression is

\[ \boxed{\text{Verify Reference Algorithm}} \]

\[ \downarrow \]

\[ \boxed{\text{Verify Generated/Implemented Software in SIL}} \]

\[ \downarrow \]

\[ \boxed{\text{Verify Numerical Equivalence}} \]

\[ \downarrow \]

\[ \boxed{\text{Introduce Target Processor}} \]

\[ \downarrow \]

\[ \boxed{\text{Verify Execution Time and Scheduling}} \]

\[ \downarrow \]

\[ \boxed{\text{Introduce Real Communication Interfaces}} \]

\[ \downarrow \]

\[ \boxed{\text{Introduce Sensor Emulation}} \]

\[ \downarrow \]

\[ \boxed{\text{Inject Timing and Communication Faults}} \]

\[ \downarrow \]

\[ \boxed{\text{Integrate Guidance and Control}} \]

\[ \downarrow \]

\[ \boxed{\text{Execute Closed-Loop HIL}} \]

\[ \downarrow \]

\[ \boxed{\text{Execute Requirement-Based Qualification Cases}} \]

\[ \downarrow \]

\[ \boxed{\text{Validate with Flight Data}}. \]

This incremental progression makes failures much easier to isolate than attempting full-system HIL immediately.

4.2.31.85 Key Takeaways

SIL, PIL, HIL, and flight validation are not merely increasingly sophisticated versions of the same simulation. Each introduces a new class of implementation reality.

The progression can be summarized as

\[ \boxed{ \text{Algorithm} \rightarrow \text{Software} \rightarrow \text{Processor} \rightarrow \text{Hardware} \rightarrow \text{Integrated System} \rightarrow \text{Flight} } \]

SIL verifies that the implemented software reproduces the intended sensor-fusion algorithm.

PIL verifies that the navigation software behaves correctly and within timing constraints on the target or representative processor.

HIL introduces real-time execution, hardware interfaces, sensor emulation or real sensors, communication protocols, latency, clocks, packet behavior, and integrated avionics.

Flight validation finally exposes the navigation system to actual vehicle dynamics, sensors, environment, geometry, and operational conditions.

Throughout the entire process, the same fundamental quantities remain important:

\[ \boxed{ \hat{\mathbf x}, \quad \mathbf P, \quad \mathbf z, \quad \hat{\mathbf z}, \quad \mathbf r, \quad \text{timestamps}, \quad \text{validity}, \quad \text{mode}, \quad \text{health} } \]

and the navigation system must be assessed not only for accuracy, but also for timing, availability, continuity, integrity, robustness, numerical stability, fault response, and closed-loop GNC performance.

Most importantly,

\[ \boxed{ \text{A successful estimator is not merely one that produces a good state estimate in MATLAB.} } \]

It is one whose mathematics, software implementation, processor execution, interfaces, timing, hardware interaction, uncertainty representation, failure response, and operational performance have all been demonstrated systematically.

That completes the transition from sensor-fusion algorithm development to validated spacecraft navigation implementation and provides the natural foundation for 4.2.32 Complete Spacecraft Sensor-Fusion Architecture, where the individual sensor models, preprocessing, estimators, timing architecture, navigation modes, health monitoring, guidance/control interfaces, and validation framework can be assembled into one end-to-end architecture.

Next: 4.2.32 Complete Spacecraft Sensor-Fusion Architecture

SIL, PIL, HIL, and flight validation have now connected estimator mathematics to executable software, target processors, physical interfaces, realistic timing, sensor emulation, integrated GNC behavior, recorded data, and flight evidence.

The next section assembles these verified elements into one end-to-end spacecraft sensor-fusion architecture, combining truth and vehicle dynamics, sensor models and preprocessing, timing, measurement validation, attitude and translational estimation, relative navigation, health and mode management, covariance monitoring, guidance, control, and actuator interaction.