Filter Consistency and Performance Metrics

4.2.20 Filter Consistency and Performance Metrics

Designing and tuning a spacecraft estimator is only part of the problem. After the filter has been implemented, initialized, and tuned, the next question is:

\[ \boxed{ \text{How do we know that the estimator is actually performing correctly?} } \]

A state estimator produces two closely related outputs:

\[ \boxed{ \text{Estimated State} + \text{Estimated Uncertainty} } \]

For example,

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

represents the estimated spacecraft state, while

\[ \mathbf P_k \]

represents the filter's estimate of the uncertainty associated with that state.

A filter is therefore not fully validated simply because

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

looks close to the truth in one simulation.

It must also be established that:

• estimation errors are sufficiently small,
• the covariance realistically represents those errors,
• innovations behave statistically as expected,
• the filter converges within an acceptable time,
• performance remains acceptable across uncertainty,
• failures are not hidden by averages,
• the estimator remains credible across the operating envelope.

The central distinction is between accuracy and consistency.

\[ \boxed{ \text{Accuracy} = \text{How close is the estimate to truth?} } \]

whereas

\[ \boxed{ \text{Consistency} = \text{Does the estimator's stated uncertainty agree with its actual error?} } \]

A filter can be accurate but inconsistent.

A filter can also be consistent but insufficiently accurate.

A flight-quality navigation estimator should ideally be both.

4.2.20.1 What Is Estimation Error?

Let the true state be

\[ \mathbf x_k \]

and the estimated state be

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

The estimation error is

\[ \boxed{ \tilde{\mathbf x}_k = \mathbf x_k-\hat{\mathbf x}_k } \]

or, depending on the adopted sign convention,

\[ \tilde{\mathbf x}_k = \hat{\mathbf x}_k-\mathbf x_k. \]

Either convention is acceptable provided it is used consistently.

For a spacecraft navigation state,

\[ \mathbf x = \begin{bmatrix} \mathbf r\\ \mathbf v\\ \mathbf q\\ \boldsymbol\omega\\ \mathbf b_g\\ \mathbf b_a\\ \cdots \end{bmatrix}, \]

the error vector may contain:

• position error,
• velocity error,
• attitude error,
• angular-rate error,
• gyroscope-bias error,
• accelerometer-bias error,
• calibration-state error,
• timing-state error.

The error vector is the fundamental quantity from which most accuracy metrics are constructed.

4.2.20.2 Error Is Different from Residual

It is important to distinguish state-estimation error from measurement residual or innovation.

State error is

\[ \boxed{ \tilde{\mathbf x}_k = \mathbf x_k-\hat{\mathbf x}_k } \]

and requires knowledge of the true state.

The innovation is

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

and compares a real measurement with its predicted value.

Therefore,

\[ \boxed{ \text{State Error} \neq \text{Innovation}. } \]

State error is generally available in simulation or when a high-quality truth reference exists.

Innovation is available during normal filter operation.

4.2.20.3 Why Truth Is Important

In simulation, the true state is known.

Therefore we can calculate

\[ \tilde{\mathbf x} \]

directly.

This allows the estimator's actual accuracy to be evaluated.

In flight, however, exact truth is generally unavailable.

Consequently, flight performance assessment relies more heavily on:

• innovation statistics,
• independent reference systems,
• redundant sensors,
• consistency monitoring,
• covariance behaviour.

This is why simulation and Monte Carlo testing are particularly important before deployment.

4.2.20.4 Scalar State Error

For a scalar state \(x\),

\[ e_k = x_k-\hat x_k. \]

The instantaneous absolute error is

\[ |e_k|. \]

This may be appropriate for quantities such as:

• one-axis gyro bias,
• clock bias,
• range,
• scalar temperature-calibration states.

4.2.20.5 Vector State Error

For a vector quantity such as position,

\[ \mathbf e_r = \mathbf r-\hat{\mathbf r}. \]

A scalar position-error magnitude is

\[ \boxed{ e_r = \| \mathbf r-\hat{\mathbf r} \|. } \]

Similarly,

\[ \boxed{ e_v = \| \mathbf v-\hat{\mathbf v} \|. } \]

The vector norm is convenient, but the individual axes should also be examined because the navigation geometry may produce very different accuracy in different directions.

4.2.20.6 Position Error by Axis

For Cartesian position,

\[ \mathbf e_r = \begin{bmatrix} e_x\\ e_y\\ e_z \end{bmatrix}. \]

where

\[ e_x=x-\hat x, \]

\[ e_y=y-\hat y, \]

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

Looking only at

\[ \|\mathbf e_r\| \]

can hide a poor-performing axis.

For example, one direction may be weakly observable even when the total position-error norm remains acceptable.

4.2.20.7 Velocity Error

Velocity estimation error is

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

The norm is

\[ \boxed{ e_v = \|\mathbf e_v\|. } \]

Velocity error is especially important because guidance and control often depend directly on the estimated rate of motion.

In relative navigation, for example, both relative position and relative velocity must be characterized, not position alone.

4.2.20.8 Attitude Error

Quaternion subtraction is not a valid attitude-error definition.

Let the true attitude quaternion be

\[ \mathbf q \]

and the estimate be

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

Define the quaternion attitude error as

\[ \boxed{ \delta\mathbf q = \mathbf q \otimes \hat{\mathbf q}^{-1}. } \]

The equivalent principal-angle error is

\[ \boxed{ \delta\theta = 2\cos^{-1} \left( |\delta q_0| \right). } \]

The absolute value accounts for the quaternion equivalence

\[ \mathbf q \equiv -\mathbf q. \]

4.2.20.9 Small-Angle Attitude Error

For small attitude errors,

\[ \delta\mathbf q \approx \begin{bmatrix} 1\\ \frac12\delta\boldsymbol\theta \end{bmatrix}. \]

Therefore,

\[ \delta\boldsymbol\theta \]

can be used as a three-component attitude-error vector.

This representation is particularly important for:

• MEKF,
• ESKF,
• linearized covariance analysis.

4.2.20.10 Angular-Rate Error

Angular-rate estimation error is

\[ \boxed{ \mathbf e_\omega = \boldsymbol\omega - \hat{\boldsymbol\omega}. } \]

Its norm is

\[ \boxed{ e_\omega = \|\mathbf e_\omega\|. } \]

Good attitude estimation does not automatically imply good angular-rate estimation.

The two should therefore be evaluated separately.

4.2.20.11 Bias-Estimation Error

For gyroscope bias,

\[ \boxed{ \mathbf e_{b_g} = \mathbf b_g - \hat{\mathbf b}_g. } \]

For accelerometer bias,

\[ \boxed{ \mathbf e_{b_a} = \mathbf b_a - \hat{\mathbf b}_a. } \]

Bias accuracy is particularly important because poorly estimated inertial biases can produce long-term navigation drift.

4.2.20.12 Instantaneous Error Does Not Describe Overall Performance

A single value

\[ e_k \]

describes performance at one time.

Navigation performance usually requires characterization across a time interval.

Therefore metrics such as:

• mean error,
• RMSE,
• MAE,
• standard deviation,
• maximum error,
• percentiles,

are required.

4.2.20.13 Mean Error

For \(N\) samples,

\[ \boxed{ \bar e = \frac1N \sum_{k=1}^{N} e_k. } \]

A nonzero mean indicates systematic bias.

Ideally,

\[ \bar e \approx0. \]

However, a zero mean alone does not imply good accuracy because positive and negative errors may cancel.

4.2.20.14 Mean Absolute Error

The Mean Absolute Error is

\[ \boxed{ \mathrm{MAE} = \frac1N \sum_{k=1}^{N} |e_k|. } \]

MAE measures the typical magnitude of the error without allowing positive and negative values to cancel.

It is relatively intuitive and is less sensitive to occasional large errors than RMSE.

4.2.20.15 Root Mean Square Error

The Root Mean Square Error is

\[ \boxed{ \mathrm{RMSE} = \sqrt{ \frac1N \sum_{k=1}^{N} e_k^2 }. } \]

RMSE gives greater weight to large errors because errors are squared.

It is one of the most common navigation-performance metrics.

4.2.20.16 Vector RMSE

For position,

\[ \mathbf e_{r,k} = \mathbf r_k-\hat{\mathbf r}_k. \]

One possible vector RMSE is

\[ \boxed{ \mathrm{RMSE}_r = \sqrt{ \frac1N \sum_{k=1}^{N} \|\mathbf e_{r,k}\|^2 }. } \]

Alternatively, calculate separate axis values:

\[ \mathrm{RMSE}_x, \qquad \mathrm{RMSE}_y, \qquad \mathrm{RMSE}_z. \]

Both representations can be useful.

4.2.20.17 RMSE Is Not the Same as Standard Deviation

RMSE contains both random spread and bias.

Approximately,

\[ \boxed{ \mathrm{RMSE}^2 = \mathrm{Bias}^2 + \sigma_e^2. } \]

Therefore a large RMSE may result from:

• high random noise,
• systematic bias,
• or both.

This distinction is important when diagnosing estimator problems.

4.2.20.18 Error Standard Deviation

The empirical standard deviation is

\[ \boxed{ \sigma_e = \sqrt{ \frac1{N-1} \sum_{k=1}^{N} (e_k-\bar e)^2 }. } \]

This measures the spread of the error around its mean.

Comparing

\[ \sigma_e \]

with

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

helps evaluate covariance credibility.

4.2.20.19 Maximum Error

Maximum absolute error is

\[ \boxed{ e_{\max} = \max_k |e_k|. } \]

Maximum error is useful because a filter can have excellent average performance while occasionally producing an unacceptable error.

Safety- or autonomy-related navigation assessment should therefore not rely on averages alone.

4.2.20.20 Percentile Error

Let

\[ e_{95} \]

denote the \(95^\text{th}\) percentile of absolute error.

Then approximately

\[ P(|e|\le e_{95}) = 0.95. \]

Similarly,

\[ e_{99} \]

characterizes a more extreme portion of the distribution.

Percentiles are particularly useful in Monte Carlo studies.

4.2.20.21 Why Percentiles Are Important

Suppose two filters have identical RMSE.

Filter A produces mostly moderate errors.

Filter B produces smaller errors most of the time but occasionally produces very large excursions.

RMSE may not clearly reveal this distinction.

Metrics such as

\[ e_{95}, \qquad e_{99}, \qquad e_{\max} \]

provide information about the tails of the distribution.

4.2.20.22 Accuracy Versus Precision

Accuracy measures closeness to truth.

Precision measures repeatability or spread.

A filter may produce:

\[ \text{high precision} \]

but

\[ \text{low accuracy} \]

if it has a systematic bias.

Therefore:

\[ \boxed{ \text{Precision} \neq \text{Accuracy}. } \]

4.2.20.23 Filter Consistency

A filter is statistically consistent when its covariance accurately represents the actual distribution of estimation error.

Conceptually,

\[ \boxed{ \text{Actual Error Statistics} \approx \text{Predicted Error Statistics}. } \]

The covariance matrix

\[ \mathbf P \]

is therefore not merely an internal calculation.

It is a statistical claim made by the filter.

4.2.20.24 Overconfident Filter

A filter is overconfident when

\[ \mathbf P \]

is too small compared with the actual error.

Conceptually,

\[ \boxed{ \text{Actual Error} > \text{Predicted Uncertainty}. } \]

This can occur because of:

• underestimated \(Q\),
• underestimated \(R\),
• incorrect Jacobians,
• model mismatch,
• unmodelled biases,
• correlation that has been ignored.

Overconfidence is particularly dangerous because downstream logic may trust an incorrect estimate too strongly.

4.2.20.25 Conservative Filter

A conservative filter has covariance larger than necessary.

Conceptually,

\[ \boxed{ \text{Predicted Uncertainty} > \text{Actual Error}. } \]

Possible causes include:

• excessive process noise,
• excessive measurement noise,
• overly large initialization covariance,
• unnecessary covariance inflation.

A conservative filter is often less dangerous than an overconfident one, but excessive conservatism may reduce usable navigation performance.

4.2.20.26 Covariance Bounds

For scalar state \(i\),

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

Therefore common uncertainty intervals are

\[ \pm\sigma_i, \]

\[ \pm2\sigma_i, \]

and

\[ \pm3\sigma_i. \]

These bounds can be plotted together with actual estimation error.

4.2.20.27 One-Sigma Interpretation

For an ideal Gaussian scalar variable,

\[ P(|e|\le\sigma) \approx68.3\%. \]

Likewise,

\[ P(|e|\le2\sigma) \approx95.4\% \]

and

\[ P(|e|\le3\sigma) \approx99.7\%. \]

These numbers provide a useful intuition for covariance coverage.

4.2.20.28 Three-Sigma Error Plot

A standard estimator validation plot contains:

\[ \tilde x_i(t) \]

and

\[ \pm3\sqrt{P_{ii}(t)}. \]

For a statistically consistent Gaussian estimator, most errors should remain inside the \(3\sigma\) envelope.

Repeated violations suggest that the filter may be overconfident.

4.2.20.29 Why One Three-Sigma Violation Is Not Failure

Even a perfectly Gaussian process can occasionally produce a value outside

\[ 3\sigma. \]

Therefore one excursion does not prove inconsistency.

The relevant quantity is the statistical coverage over many samples or runs.

4.2.20.30 Coverage Probability

Define empirical coverage:

\[ \boxed{ C_{3\sigma} = \frac{ N_{|e_k|\le3\sigma_k} }{ N }. } \]

For an ideal scalar Gaussian process, this should approach approximately

\[ 0.997. \]

Large deviations may indicate covariance mismatch.

4.2.20.31 Covariance Consistency Is Multidimensional

Checking each diagonal covariance element individually is useful but incomplete.

The true covariance also contains cross-correlations.

For a state vector,

\[ \mathbf P = E[ \tilde{\mathbf x} \tilde{\mathbf x}^T ]. \]

A proper multivariate consistency test should therefore account for the full covariance.

This motivates NEES.

4.2.20.32 Innovation

The innovation is

\[ \boxed{ \mathbf r_k = \mathbf z_k - \hat{\mathbf z}_k } \]

where

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

Therefore,

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

The innovation measures disagreement between the incoming measurement and the predicted measurement before the update.

4.2.20.33 Why Innovation Is Important

The innovation contains information about:

• sensor noise,
• process-model accuracy,
• calibration,
• bias,
• timing,
• covariance tuning.

Therefore innovation analysis is one of the most important tools for determining whether an estimator behaves as expected.

4.2.20.34 Innovation Mean

For an unbiased estimator,

\[ \boxed{ E[\mathbf r_k] \approx \mathbf0. } \]

A persistent nonzero innovation may indicate:

• measurement bias,
• dynamic-model bias,
• timing offset,
• frame error,
• calibration error,
• incorrect lever arm,
• poor convergence.

4.2.20.35 Innovation Covariance

The theoretical innovation covariance is

\[ \boxed{ \mathbf S_k = \mathbf H_k \mathbf P_k^- \mathbf H_k^T + \mathbf R_k. } \]

This represents the uncertainty expected in the innovation.

The actual innovation distribution should be broadly compatible with this prediction.

4.2.20.36 Empirical Innovation Covariance

From measured innovations,

\[ \bar{\mathbf r} = \frac1N \sum_{k=1}^{N} \mathbf r_k. \]

The empirical covariance is

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

A consistent filter should produce approximately

\[ \hat{\mathbf S} \approx \mathbf S. \]

4.2.20.37 Innovation Whiteness

An ideal Kalman-filter innovation sequence should be approximately white.

That means

\[ \boxed{ E[ \mathbf r_k \mathbf r_{k-\tau}^T ] \approx 0 \qquad \tau\neq0. } \]

If strong temporal correlation remains, the estimator may not be modelling all relevant dynamics.

4.2.20.38 Innovation Autocorrelation

Define

\[ \boxed{ \mathbf C_r(\tau) = E[ \mathbf r_k \mathbf r_{k-\tau}^T ]. } \]

For a well-modelled estimator,

\[ \mathbf C_r(\tau) \approx0 \]

for nonzero lag.

Persistent structure may indicate:

• unmodelled disturbance,
• missing bias state,
• filtered measurement correlation,
• periodic error,
• timing mismatch.

4.2.20.39 Normalized Residual

For scalar residual \(r_i\),

\[ \boxed{ r_{N,i} = \frac{r_i}{\sqrt{S_{ii}}}. } \]

This expresses residual magnitude relative to predicted uncertainty.

For a consistent Gaussian estimator,

\[ r_{N,i} \]

should broadly behave like a zero-mean unit-variance random variable.

4.2.20.40 Why Normalize Innovations?

A raw residual of

\[ 0.1 \]

cannot be judged without knowing the sensor's expected uncertainty.

If

\[ \sigma=10, \]

the residual is tiny.

If

\[ \sigma=0.001, \]

the same residual is enormous.

Normalization provides statistical context.

4.2.20.41 Normalized Innovation Squared

For a vector measurement,

\[ \boxed{ \mathrm{NIS}_k = \mathbf r_k^T \mathbf S_k^{-1} \mathbf r_k. } \]

This is the squared Mahalanobis distance of the innovation.

NIS simultaneously accounts for:

• innovation magnitude,
• variance,
• covariance between measurement components.

4.2.20.42 Distribution of NIS

If the estimator assumptions are valid and measurement dimension is \(m\),

\[ \boxed{ \mathrm{NIS} \sim \chi_m^2. } \]

Therefore,

\[ E[\mathrm{NIS}] = m. \]

For example, if

\[ m=3, \]

the long-run mean should be approximately

\[ 3. \]

4.2.20.43 NIS Is Not Expected to Equal \(m\) Every Time

The relationship

\[ E[\mathrm{NIS}]=m \]

is an expected value.

Individual NIS values fluctuate.

Therefore:

\[ \boxed{ \mathrm{NIS}_k\neq m } \]

is not automatically a problem.

Long-run statistical behaviour is what matters.

4.2.20.44 Chi-Square Bounds for NIS

For significance level \(\alpha\),

\[ \boxed{ \chi^2_{\alpha/2,m} < \mathrm{NIS}_k < \chi^2_{1-\alpha/2,m}. } \]

These bounds define a statistical consistency interval.

Measurements outside the upper bound occur naturally sometimes, but persistent violations indicate inconsistency.

4.2.20.45 Interpretation of High NIS

If

\[ \mathrm{NIS} \]

is systematically too high, the actual innovation is larger than predicted.

Possible causes include:

• \(Q\) too small,
• \(R\) too small,
• sensor degradation,
• model mismatch,
• bias,
• timing error.

Conceptually,

\[ \boxed{ \text{High NIS} \rightarrow \text{Filter May Be Overconfident}. } \]

4.2.20.46 Interpretation of Low NIS

If

\[ \mathrm{NIS} \]

is systematically too low, predicted uncertainty may be larger than necessary.

Possible causes include:

• \(Q\) too large,
• \(R\) too large,
• excessive covariance inflation.

Therefore:

\[ \boxed{ \text{Low NIS} \rightarrow \text{Filter May Be Too Conservative}. } \]

4.2.20.47 Average NIS

Over \(N\) measurements,

\[ \boxed{ \overline{\mathrm{NIS}} = \frac1N \sum_{k=1}^{N} \mathrm{NIS}_k. } \]

This provides a useful summary.

However, averaging alone may hide transient inconsistency.

Therefore the time history should also be inspected.

4.2.20.48 NIS Acceptance Fraction

Another useful metric is

\[ \boxed{ f_{\mathrm{NIS}} = \frac{ N_{\mathrm{inside\ bounds}} }{ N }. } \]

This can be compared with the expected confidence level.

For a \(95\%\) interval, approximately \(95\%\) of samples should fall within the limits under ideal independent assumptions.

4.2.20.49 NIS in Flight

NIS is especially useful because it does not require true state knowledge.

It uses only:

\[ \mathbf r_k \]

and

\[ \mathbf S_k. \]

Therefore it can support:

• in-flight consistency monitoring,
• sensor validation,
• fault detection,
• adaptive weighting.

4.2.20.50 Normalized Estimation Error Squared

When truth is known, define

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

NEES measures state-estimation error relative to the covariance predicted by the filter.

It is one of the strongest tools for filter-consistency testing in simulation.

4.2.20.51 Distribution of NEES

For an \(n\)-dimensional state,

\[ \boxed{ \mathrm{NEES} \sim \chi_n^2 } \]

under ideal Gaussian assumptions.

Therefore,

\[ \boxed{ E[\mathrm{NEES}] = n. } \]

4.2.20.52 Meaning of NEES

Consider two filters having identical state error.

Filter A reports large covariance.

Filter B reports very small covariance.

Their NEES values will differ strongly.

Thus NEES answers:

\[ \boxed{ \text{Is the actual state error plausible given the covariance claimed by the filter?} } \]

4.2.20.53 High NEES

If

\[ \mathrm{NEES} \gg n \]

persistently, the estimator is generally overconfident.

Actual state errors are larger than the covariance predicts.

Possible causes include:

• underestimated process noise,
• underestimated measurement noise,
• incorrect covariance propagation,
• poor linearization,
• unmodelled disturbances.

4.2.20.54 Low NEES

If

\[ \mathrm{NEES} \ll n, \]

the filter may be unnecessarily conservative.

Covariance is larger than the actual state error would justify.

This may reduce operational performance even though it is generally safer than overconfidence.

4.2.20.55 NIS Versus NEES

NIS operates in measurement space:

\[ \boxed{ \mathrm{NIS} = \mathbf r^T \mathbf S^{-1} \mathbf r. } \]

NEES operates in state space:

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

Therefore:

\[ \boxed{ \text{NIS} \rightarrow \text{Measurement-Space Consistency} } \]

and

\[ \boxed{ \text{NEES} \rightarrow \text{State-Space Consistency}. } \]

4.2.20.56 Why Both NIS and NEES Are Useful

A filter may have acceptable NIS but poor NEES.

This can happen if measurement behaviour appears correct while some state directions remain poorly represented.

Similarly, poor NIS with acceptable NEES may indicate an issue localized to one measurement model.

Therefore the two metrics are complementary.

4.2.20.57 Why NEES Is Mainly a Ground-Test Metric

NEES requires

\[ \mathbf x_{\mathrm{truth}}. \]

Exact truth is generally unavailable in flight.

Therefore NEES is most useful in:

• simulation,
• Monte Carlo analysis,
• hardware testing with an independent high-quality reference.

4.2.20.58 Partial-State NEES

Sometimes consistency is required only for a subset of states.

Suppose position covariance is

\[ \mathbf P_r. \]

Then

\[ \boxed{ \mathrm{NEES}_r = \tilde{\mathbf r}^T \mathbf P_r^{-1} \tilde{\mathbf r}. } \]

Similarly,

\[ \mathrm{NEES}_v, \]

\[ \mathrm{NEES}_{attitude}, \]

or

\[ \mathrm{NEES}_{bias} \]

can be evaluated separately.

This helps identify which state group is inconsistent.

4.2.20.59 Why Full-State NEES Can Hide Problems

Suppose the estimator has:

• excellent position consistency,
• poor gyro-bias consistency.

The full-state NEES may not clearly identify the source of the problem.

Therefore both full-state and state-group NEES should be considered.

4.2.20.60 Monte Carlo Evaluation

One simulation run is one realization of:

• initial error,
• sensor noise,
• sensor bias,
• disturbances,
• geometry,
• dropouts.

It cannot characterize statistical estimator performance.

Therefore repeated randomized runs are required.

\[ \boxed{ \text{Estimator Performance} \rightarrow \text{Monte Carlo Statistics}. } \]

4.2.20.61 Monte Carlo State Error

For run j,

\[ \tilde{\mathbf x}_k^{(j)} = \mathbf x_k^{(j)} - \hat{\mathbf x}_k^{(j)}. \]

For

\[ j=1,\ldots,N_{MC}, \]

these values form an empirical distribution of estimator error.

4.2.20.62 Monte Carlo Mean Error

At time k,

\[ \boxed{ \bar{\mathbf e}_k = \frac1{N_{MC}} \sum_{j=1}^{N_{MC}} \tilde{\mathbf x}_k^{(j)}. } \]

This reveals systematic estimator bias across runs.

Ideally,

\[ \bar{\mathbf e}_k \approx\mathbf0. \]

4.2.20.63 Monte Carlo Error Covariance

The empirical error covariance is

\[ \boxed{ \mathbf P_{\text{emp},k} = \frac1{N_{MC}-1} \sum_{j=1}^{N_{MC}} ( \tilde{\mathbf x}_k^{(j)} - \bar{\mathbf e}_k ) ( \tilde{\mathbf x}_k^{(j)} - \bar{\mathbf e}_k )^T. } \]

This can be compared with the covariance predicted internally by the estimator.

4.2.20.64 Predicted Versus Empirical Covariance

A consistent estimator should produce roughly

\[ \boxed{ \mathbf P_{\text{emp}} \approx \mathbf P_{\text{filter}}. } \]

If

\[ \mathbf P_{\text{emp}} \gg \mathbf P_{\text{filter}}, \]

the filter is overconfident.

If

\[ \mathbf P_{\text{emp}} \ll \mathbf P_{\text{filter}}, \]

the filter is conservative.

4.2.20.65 Monte Carlo Envelope

For a scalar state error, compute percentiles at every time.

For example:

\[ e_{5}(t), \qquad e_{50}(t), \qquad e_{95}(t). \]

Plotting these creates a Monte Carlo envelope.

This shows how uncertainty evolves across the population of runs.

4.2.20.66 Why Monte Carlo Envelopes Are Useful

A single trajectory can look misleadingly clean.

Monte Carlo envelopes immediately reveal:

• spread,
• skew,
• transient failures,
• convergence variability,
• occasional divergence.

They are particularly useful when evaluating filter robustness.

4.2.20.67 Three-Sigma Monte Carlo Envelope

Another approach is to calculate empirical standard deviation:

\[ \sigma_{MC}(t) \]

and plot

\[ \bar e(t) \pm 3\sigma_{MC}(t). \]

This can be compared directly with the filter's predicted covariance envelope.

4.2.20.68 Average NEES Across Monte Carlo Runs

At time k,

\[ \boxed{ \overline{\mathrm{NEES}}_k = \frac1{N_{MC}} \sum_{j=1}^{N_{MC}} \mathrm{NEES}_k^{(j)}. } \]

This is typically more reliable than interpreting the NEES of one run.

4.2.20.69 Monte Carlo Chi-Square Bounds

For \(N_{MC}\) independent runs and state dimension \(n\),

\[ N_{MC} \overline{\mathrm{NEES}} \]

is approximately chi-square distributed with

\[ N_{MC}n \]

degrees of freedom.

Therefore confidence intervals can be formed for average NEES.

This provides a rigorous statistical consistency test.

4.2.20.70 Average NIS Across Monte Carlo Runs

Similarly,

\[ \boxed{ \overline{\mathrm{NIS}}_k = \frac1{N_{MC}} \sum_{j=1}^{N_{MC}} \mathrm{NIS}_k^{(j)}. } \]

For measurement dimension \(m\),

\[ N_{MC} \overline{\mathrm{NIS}} \]

can be compared against a chi-square distribution with approximately

\[ N_{MC}m \]

degrees of freedom.

4.2.20.71 Monte Carlo Success Rate

Define success indicator

\[ I_j = \begin{cases} 1,&\text{run satisfies requirements},\\ 0,&\text{otherwise}. \end{cases} \]

Then

\[ \boxed{ P_{\text{success}} \approx \frac1{N_{MC}} \sum_{j=1}^{N_{MC}} I_j. } \]

This converts estimator performance into an operationally meaningful probability.

4.2.20.72 Success Criteria Must Be Defined

A run should not be called successful only because the filter did not numerically diverge.

Success may require:

\[ \mathrm{RMSE}_r

\[ \mathrm{RMSE}_v

\[ T_{\mathrm{conv}}

and consistency requirements.

Therefore:

\[ \boxed{ \text{Numerical Survival} \neq \text{Navigation Success}. } \]

4.2.20.73 Filter Convergence

A filter is said to converge when its estimate and uncertainty settle to an acceptable level after initialization or disturbance.

Convergence therefore involves both:

\[ \boxed{ \text{Estimation Error} } \]

and

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

A small covariance alone does not prove convergence.

4.2.20.74 Convergence Time

Define convergence time as

\[ \boxed{ T_{\mathrm{conv}} = t_{\mathrm{conv}} - t_0. } \]

The exact definition of \(t_{\mathrm{conv}}\) must be specified.

For example, convergence may require

\[ \|\tilde{\mathbf r}\| < r_{\mathrm{conv}} \]

for a specified dwell time.

4.2.20.75 Convergence Criteria

A convergence declaration may require several conditions:

\[ \|\tilde{\mathbf r}\|

\[ \|\tilde{\mathbf v}\|

\[ \delta\theta<\theta_{\max}, \]

and

\[ \sqrt{P_{ii}} < \sigma_{i,\max}. \]

This prevents declaring convergence based on one state only.

4.2.20.76 Dwell Time in Convergence

To avoid false declaration from momentary threshold crossing, require:

\[ \boxed{ \text{All convergence conditions true for }T_{\mathrm{dwell}}. } \]

This is especially useful for noisy estimates.

4.2.20.77 State-Dependent Convergence Time

Different states converge at different rates.

For example:

\[ T_{\mathrm{att}} < T_{\mathrm{bias}} \]

may occur because attitude is strongly observed while gyro bias is weakly observable.

Therefore one global convergence time can hide important state differences.

4.2.20.78 Bias Convergence Time

Define

\[ \boxed{ T_{b} = \text{time required for bias error to enter its acceptable bound}. } \]

Bias convergence may be much slower than position or attitude convergence.

This should be reported separately where biases affect long-term performance.

4.2.20.79 Recovery Time

After a fault or dropout,

\[ \boxed{ T_{\mathrm{recover}} = t_{\mathrm{restored}} - t_{\mathrm{event}}. } \]

Recovery time characterizes how quickly the estimator returns to required performance.

4.2.20.80 Reacquisition Time

For a lost sensor,

\[ \boxed{ T_{\mathrm{reacquire}} } \]

may measure the time between sensor availability and successful reintegration into the estimator.

Reacquisition and full estimator reconvergence are not necessarily the same.

4.2.20.81 Transient Performance

Performance immediately after:

• startup,
• manoeuvre,
• sensor switching,
• dropout,
• reset,

should be evaluated separately from steady-state behaviour.

Important transient metrics include:

\[ e_{\mathrm{peak}}, \]

\[ P_{\max}, \]

\[ T_{\mathrm{conv}}. \]

4.2.20.82 Steady-State Performance

Once the transient has ended, evaluate a separate steady-state window.

Useful quantities include:

• mean error,
• RMSE,
• covariance,
• NIS,
• innovation bias,
• innovation whiteness.

This prevents startup behaviour from distorting steady-state performance metrics.

4.2.20.83 Peak Error

Peak error is

\[ \boxed{ e_{\mathrm{peak}} = \max_{t\in[t_1,t_2]} |e(t)|. } \]

Peak error is particularly useful during:

• sensor switching,
• manoeuvre transitions,
• reinitialization,
• dropout recovery.

4.2.20.84 Settling Time

A filter settling time can be defined as the time required for error to enter and remain within a specified band.

For example,

\[ |e(t)| < e_{\mathrm{settle}} \]

for all

\[ t>t_s. \]

Then

\[ t_s \]

is the settling time.

4.2.20.85 Overshoot

Estimator correction may temporarily overshoot after a large initialization error or measurement reacquisition.

Define

\[ e_{\mathrm{overshoot}} \]

as the maximum error beyond the eventual converged region.

This is useful when estimator outputs feed directly into closed-loop control.

4.2.20.86 Navigation Availability

Define navigation availability as

\[ \boxed{ A = \frac{ T_{\mathrm{valid\ navigation}} }{ T_{\mathrm{total}} }. } \]

A filter may be highly accurate when operational but unavailable too often.

Therefore availability is a separate performance property.

4.2.20.87 Navigation Validity Flag

A navigation system may produce a logical state:

\[ \texttt{NAV\_VALID} \in \{0,1\}. \]

The flag may depend on:

• covariance thresholds,
• sensor availability,
• consistency tests,
• convergence state,
• numerical health.

Performance assessment should verify that this flag correctly represents estimator usability.

4.2.20.88 Continuity

Continuity measures whether navigation remains valid without interruption over a required interval.

Conceptually,

\[ \boxed{ P( \text{Navigation remains continuously valid over }T ). } \]

A system can have high availability but poor continuity if valid navigation repeatedly drops in and out.

4.2.20.89 Integrity

Integrity concerns whether the navigation system can identify when its error has become unacceptable.

Conceptually,

\[ \boxed{ P( |e|>\text{Alert Limit} \land \text{No Alert} ). } \]

This event is particularly important because the estimator is wrong while still claiming validity.

4.2.20.90 Accuracy, Availability, Continuity and Integrity

These are distinct concepts:

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

asks how close the estimate is to truth.

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

asks how often valid navigation is available.

\[ \boxed{ \text{Continuity} } \]

asks whether that valid navigation remains uninterrupted.

\[ \boxed{ \text{Integrity} } \]

asks whether unacceptable error is detected.

A complete navigation assessment may need all four.

4.2.20.91 Measurement Rejection Rate

Define

\[ \boxed{ f_{\mathrm{reject}} = \frac{ N_{\mathrm{rejected}} }{ N_{\mathrm{received}} }. } \]

Unexpectedly high rejection can indicate:

• poor covariance tuning,
• sensor degradation,
• excessive gating,
• model mismatch.

4.2.20.92 Sensor Utilization Rate

Define

\[ \boxed{ f_{\mathrm{use}} = \frac{ N_{\mathrm{fused}} }{ N_{\mathrm{available}} }. } \]

A sensor may be physically operational but contribute little if it repeatedly fails validation.

This can reveal hidden system-level performance problems.

4.2.20.93 Innovation-Gate Statistics

Track:

• accepted measurements,
• rejected measurements,
• borderline measurements,
• consecutive rejection count.

These statistics help determine whether filtering performance is being maintained because the estimator is healthy or simply because problematic data are being discarded.

4.2.20.94 State-Correction Magnitude

The measurement update changes the state by

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

Repeated large corrections may indicate that prediction and measurement models disagree.

Very small corrections may indicate either excellent prediction or underweighting of measurements.

Therefore correction magnitude is diagnostic rather than a stand-alone performance score.

4.2.20.95 Covariance Reduction at Measurement Update

A measurement typically causes

\[ \mathbf P^+ < \mathbf P^- \]

in the observed directions.

The amount of covariance reduction reveals how much information the measurement contributes.

If covariance barely changes, the measurement may be:

• noisy,
• redundant,
• weakly sensitive to the state.

4.2.20.96 Covariance Trace

A scalar summary is

\[ \boxed{ \operatorname{tr}(\mathbf P). } \]

It represents the sum of state variances.

This is useful for trend monitoring, but it does not preserve directional information.

4.2.20.97 Covariance Determinant

Another scalar metric is

\[ \boxed{ \det(\mathbf P). } \]

For Gaussian uncertainty, this is related to uncertainty-ellipsoid volume.

Because of scaling issues, however, its numerical value should be interpreted cautiously.

4.2.20.98 Largest Covariance Eigenvalue

Let

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

The largest eigenvalue

\[ \boxed{ \lambda_{\max}(\mathbf P) } \]

represents the largest principal uncertainty direction.

This can be more informative than the largest diagonal covariance term.

4.2.20.99 Condition Number

The covariance condition number is

\[ \boxed{ \kappa(\mathbf P) = \frac{ \lambda_{\max} }{ \lambda_{\min} }. } \]

A very large condition number can indicate:

• poorly scaled states,
• weak observability,
• numerical sensitivity.

It is therefore both a numerical and estimation diagnostic.

4.2.20.100 Covariance Symmetry

A valid covariance should satisfy

\[ \boxed{ \mathbf P = \mathbf P^T. } \]

A useful numerical metric is

\[ \boxed{ e_{\mathrm{sym}} = \| \mathbf P-\mathbf P^T \|. } \]

Large symmetry error indicates implementation or numerical problems.

4.2.20.101 Positive Semidefiniteness

A covariance matrix should satisfy

\[ \boxed{ \lambda_i(\mathbf P) \ge0. } \]

Significant negative eigenvalues mean that the covariance is no longer physically meaningful.

This is a critical implementation-health metric.

4.2.20.102 Filter Divergence

Divergence occurs when the estimator no longer tracks the true state appropriately.

Typical indicators include:

• rapidly increasing state error,
• persistent large innovation,
• high NEES,
• high NIS,
• covariance inconsistent with error,
• numerical failure.

Divergence is not simply “large covariance.”

Large covariance may correctly represent high uncertainty.

4.2.20.103 Covariance Divergence Versus State Divergence

It is useful to distinguish:

\[ \boxed{ \text{State Error Divergence} } \]

from

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

Covariance may grow correctly during a sensor outage.

That is not filter failure.

A more serious problem occurs when state error grows while covariance remains small.

4.2.20.104 Covariance Collapse

Covariance collapse occurs when

\[ \mathbf P \rightarrow \text{unrealistically small values} \]

while actual uncertainty remains significant.

Consequences include:

• excessive confidence,
• small Kalman gains,
• measurement rejection,
• poor recovery.

NEES usually becomes large in this condition.

4.2.20.105 Why Smooth State Plots Are Not Enough

A smooth state estimate may result from excessive model trust.

The filter can look visually excellent while being:

• biased,
• overconfident,
• slow to respond,
• statistically inconsistent.

Therefore:

\[ \boxed{ \text{Smooth Plot} \neq \text{Validated Estimator}. } \]

4.2.20.106 Error Histograms

Histogram state errors over time or Monte Carlo runs.

This reveals:

• spread,
• skewness,
• multimodality,
• heavy tails,
• outliers.

A Gaussian filter does not automatically guarantee Gaussian real-world error.

4.2.20.107 Innovation Histograms

Innovation distributions can also be examined.

Ideally, normalized innovations should be approximately centered around zero.

Heavy tails may indicate:

• outliers,
• non-Gaussian measurement noise,
• sensor faults,
• unmodelled operating regimes.

4.2.20.108 Q-Q Plot

A quantile-quantile plot compares empirical residual quantiles with those of a reference Gaussian distribution.

Near-linear behaviour supports approximate Gaussianity.

Strong deviations in the tails suggest that Gaussian assumptions may not fully describe the measurement process.

4.2.20.109 Skewness

Skewness measures distribution asymmetry.

Persistent skew may suggest:

• directional bias,
• saturation,
• nonlinear measurement effects,
• asymmetric outlier behaviour.

This can be useful when mean and variance alone are insufficient.

4.2.20.110 Kurtosis

Kurtosis helps characterize tail heaviness.

Large excess kurtosis can indicate heavy-tailed error distributions.

This is relevant because Gaussian-based covariance bounds may underestimate rare large errors.

4.2.20.111 Autocorrelation Metrics

The residual autocorrelation can be plotted against lag.

A useful normalized form is

\[ \rho(\tau) = \frac{ C_r(\tau) }{ C_r(0) }. \]

For white innovations,

\[ \rho(\tau) \approx0 \]

for nonzero lag.

4.2.20.112 Innovation Spectrum

The power spectral density of innovation may reveal periodic disturbances.

Peaks may correspond to:

• structural vibration,
• reaction-wheel harmonics,
• thermal cycles,
• sensor-processing frequencies,
• orbital-period disturbances.

These may not be obvious from time-domain statistics alone.

4.2.20.113 Performance by Mission Phase

Estimator performance should be evaluated separately for different spacecraft phases.

For example:

• initialization,
• coarse navigation,
• nominal orbit propagation,
• manoeuvres,
• relative navigation,
• degraded navigation.

A single mission-wide RMSE can conceal important phase-specific weaknesses.

4.2.20.114 General RPO Performance Assessment

In spacecraft rendezvous and proximity operations, the same consistency framework applies to relative states.

For example,

\[ \boxed{ \mathbf r_{\mathrm{rel}} = \mathbf r_{\mathrm{chaser}} - \mathbf r_{\mathrm{target}} } \]

and

\[ \boxed{ \mathbf v_{\mathrm{rel}} = \mathbf v_{\mathrm{chaser}} - \mathbf v_{\mathrm{target}}. } \]

Useful general RPO performance metrics include:

\[ \mathrm{RMSE}_{r_{\mathrm{rel}}}, \]

\[ \mathrm{RMSE}_{v_{\mathrm{rel}}}, \]

relative attitude error,

relative angular-rate error,

and the corresponding covariance-consistency statistics.

These are general relative-navigation applications of the same estimator-performance principles.

4.2.20.115 Relative Position Error

For general relative navigation,

\[ \boxed{ e_{r,\mathrm{rel}} = \| \mathbf r_{\mathrm{rel}} - \hat{\mathbf r}_{\mathrm{rel}} \|. } \]

This should be assessed across range and geometry because relative-navigation observability can vary substantially during an approach.

4.2.20.116 Relative Velocity Error

Similarly,

\[ \boxed{ e_{v,\mathrm{rel}} = \| \mathbf v_{\mathrm{rel}} - \hat{\mathbf v}_{\mathrm{rel}} \|. } \]

Relative velocity is often particularly important because small position error combined with poor velocity knowledge can still lead to inaccurate future propagation.

4.2.20.117 Line-of-Sight Error

For optical relative navigation, performance may also be assessed in line-of-sight coordinates.

If

\[ \mathbf u_{LOS} \]

is the line-of-sight unit vector,

\[ \sigma_{LOS}^2 = \boxed{ \mathbf u_{LOS}^T \mathbf P_r \mathbf u_{LOS}. } \]

This can distinguish range-direction uncertainty from lateral uncertainty.

4.2.20.118 Radial, Along-Track and Cross-Track Errors

For orbital navigation, express position and velocity errors in the RTN frame:

• radial,
• transverse/along-track,
• normal/cross-track.

For example,

\[ \mathbf e_{RTN} = \mathbf C_{I\rightarrow RTN} \mathbf e_I. \]

This often provides more physically meaningful interpretation than inertial Cartesian components.

4.2.20.119 Directional Covariance Projection

For any unit direction \(\mathbf u\),

\[ \boxed{ \sigma_u^2 = \mathbf u^T \mathbf P \mathbf u. } \]

This is useful when requirements apply along physically meaningful axes.

4.2.20.120 Error Ellipsoid

For a 3-D position covariance,

\[ \boxed{ ( \mathbf r-\hat{\mathbf r} )^T \mathbf P_r^{-1} ( \mathbf r-\hat{\mathbf r} ) = c. } \]

This defines an uncertainty ellipsoid.

The ellipsoid shape and orientation reveal how navigation geometry affects directional uncertainty.

4.2.20.121 Performance Versus Sensor Geometry

Metrics should be evaluated as a function of geometry.

For example,

\[ \mathrm{RMSE} = f(\rho,\theta). \]

where:

• \(\rho\) may represent range,
• \(\theta\) may represent viewing geometry.

This shows whether a filter meets requirements throughout the expected sensor geometry.

4.2.20.122 Performance Versus Measurement Quality

Similarly,

\[ \mathrm{RMSE} = f(\sigma_z). \]

By varying measurement uncertainty, one can determine:

• sensitivity,
• sensor accuracy requirements,
• margin.

4.2.20.123 Performance Versus Initial Error

A useful map is

\[ T_{\mathrm{conv}} = f( \|\tilde{\mathbf x}_0\| ). \]

This helps determine the filter's convergence basin.

4.2.20.124 Performance Versus Update Rate

Evaluate:

\[ \mathrm{RMSE} = f(f_s) \]

and

\[ T_{\mathrm{conv}} = f(f_s). \]

This can determine the minimum useful measurement update rate.

4.2.20.125 Performance During Sensor Outage

When a measurement source disappears,

\[ \mathbf P \]

normally grows.

Track:

\[ e(t), \qquad P(t), \qquad T_{\mathrm{outage}}. \]

A useful metric is maximum outage duration for which navigation remains within requirements.

4.2.20.126 Maximum Tolerable Outage

Define

\[ \boxed{ T_{\mathrm{out,max}} } \]

such that navigation requirements remain satisfied for

\[ T_{\mathrm{out}} \le T_{\mathrm{out,max}}. \]

This is useful for system-level redundancy analysis.

4.2.20.127 Performance After Sensor Return

After measurement return, evaluate:

• innovation size,
• state correction,
• covariance reduction,
• recovery time,
• revalidation time.

The first measurement should not destabilize the estimator.

4.2.20.128 Sensor-Switching Performance

When switching from sensor A to sensor B, check:

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

across the transition.

Ideally the state estimate remains physically continuous unless a real correction is warranted.

Large artificial jumps may indicate inconsistent calibration or bias between sensors.

4.2.20.129 Algorithm Comparison Metrics

When comparing filters such as:

\[ \text{EKF}, \quad \text{ESKF}, \quad \text{MEKF}, \quad \text{UKF}, \]

evaluate at least:

• RMSE,
• NIS,
• NEES,
• convergence time,
• numerical robustness,
• computational cost.

Accuracy alone is not a sufficient comparison.

4.2.20.130 Computational Performance

A real-time estimator must satisfy

\[ \boxed{ T_{\mathrm{compute}} < T_{\mathrm{update}}. } \]

Therefore measure:

• mean computation time,
• worst-case computation time,
• CPU load,
• memory usage,
• missed deadlines.

An estimator that cannot run in real time does not satisfy system performance regardless of statistical accuracy.

4.2.20.131 Worst-Case Execution Time

Define

\[ \boxed{ T_{\mathrm{WCET}} = \max T_{\mathrm{compute}}. } \]

The condition

\[ T_{\mathrm{WCET}} < T_{\mathrm{cycle}} \]

is often more important than average execution time.

4.2.20.132 Measurement Latency

State quality is affected by data age.

Define

\[ \boxed{ T_{\mathrm{lat}} = t_{\mathrm{use}} - t_{\mathrm{measurement}}. } \]

Performance assessment should account for this latency because an accurate but stale state may be unsuitable for control.

4.2.20.133 Filter Output Age

Similarly, navigation output age can be defined as

\[ T_{\mathrm{state\ age}} = t_{\mathrm{current}} - t_{\mathrm{state\ epoch}}. \]

State age should be monitored separately from computation delay.

4.2.20.134 Numerical Failure Rate

Across Monte Carlo runs, define

\[ \boxed{ P_{\mathrm{num\,fail}} = \frac{ N_{\mathrm{numerical\ failures}} }{ N_{MC} }. } \]

Numerical failures may include:

• Cholesky failure,
• non-positive covariance,
• NaN,
• Inf,
• invalid quaternion.

A flight estimator should exhibit extremely robust numerical behaviour.

4.2.20.135 Divergence Rate

Similarly,

\[ \boxed{ P_{\mathrm{div}} = \frac{ N_{\mathrm{diverged}} }{ N_{MC} }. } \]

The definition of divergence should be explicit.

For example:

\[ \|\tilde{\mathbf x}\| > e_{\mathrm{div}} \]

for longer than a specified interval.

4.2.20.136 Convergence Success Rate

Define

\[ \boxed{ P_{\mathrm{conv}} = \frac{ N_{\mathrm{converged}} }{ N_{MC} }. } \]

This is distinct from general simulation success.

A run can remain numerically stable but never meet the convergence criterion.

4.2.20.137 Statistical Confidence in Success Rate

Suppose

\[ \hat p = \frac{k}{N}. \]

This estimated probability itself has uncertainty.

Therefore reported Monte Carlo success rates should ideally include confidence intervals, especially when the sample count is limited.

4.2.20.138 Why Ten Runs Are Not Enough for Rare-Event Claims

If

\[ N=10 \]

and all runs succeed, that does not establish

\[ 99.9\% \]

reliability.

Rare-event probability estimation requires:

• substantially more samples,
• confidence analysis,
• or specialized methods.

4.2.20.139 Performance Envelope

A performance envelope defines the region of operating conditions where estimator requirements are satisfied.

Conceptually,

\[ \boxed{ \mathcal E = \{ \mathbf c: \text{all navigation requirements satisfied} \}. } \]

where \(\mathbf c\) may include:

• range,
• noise,
• update rate,
• geometry,
• initialization error.

4.2.20.140 Performance Maps

For example,

\[ \boxed{ \mathrm{RMSE}_r = f( \rho, \sigma_z ). } \]

or

\[ \boxed{ P_{\mathrm{success}} = f( \rho, e_0 ). } \]

Performance maps provide far more insight than a single nominal result.

4.2.20.141 Nominal Performance

A nominal scenario should demonstrate expected behaviour under representative conditions.

Metrics should show:

• acceptable accuracy,
• covariance consistency,
• convergence,
• stable innovations,
• correct measurement usage.

Nominal performance is necessary but not sufficient.

4.2.20.142 Off-Nominal Performance

Evaluate situations such as:

• high measurement noise,
• increased process disturbances,
• poor geometry,
• large initial error,
• timing mismatch,
• sensor dropout.

The estimator should either maintain requirements or correctly declare degraded validity.

4.2.20.143 Worst-Case Performance

Worst-case analysis asks:

\[ \boxed{ \text{What is the largest credible navigation error under the permitted uncertainty envelope?} } \]

This complements Monte Carlo, which evaluates probability rather than necessarily the worst combination.

4.2.20.144 Sensitivity Metrics

Let performance metric be

\[ J. \]

Sensitivity to parameter \(p_i\) is

\[ \boxed{ S_i = \frac{\partial J}{\partial p_i}. } \]

Large

\[ |S_i| \]

means the estimator is highly sensitive to that quantity.

4.2.20.145 Performance Margin

Suppose the requirement is

\[ e < e_{\mathrm{req}}. \]

Define margin

\[ \boxed{ M = e_{\mathrm{req}} - e_{\mathrm{observed}}. } \]

A small positive margin indicates fragile compliance.

4.2.20.146 Normalized Margin

A normalized form is

\[ \boxed{ M_N = \frac{ e_{\mathrm{req}} - e_{\mathrm{observed}} }{ e_{\mathrm{req}} }. } \]

This allows easier comparison across different metrics.

4.2.20.147 Statistical Margin

For percentile performance,

\[ \boxed{ M_{95} = e_{\mathrm{req}} - e_{95}. } \]

This is often more meaningful than comparing a requirement with mean error.

4.2.20.148 Requirement-Based Performance Assessment

A metric has meaning only when tied to a requirement.

For example:

\[ \mathrm{RMSE}_r < r_{\mathrm{req}}, \]

\[ \mathrm{RMSE}_v < v_{\mathrm{req}}, \]

\[ T_{\mathrm{conv}} < T_{\mathrm{req}}. \]

Without quantitative acceptance limits, analysis remains descriptive rather than verification-oriented.

4.2.20.149 Example Performance Table

A useful summary format is:

This creates traceability between estimator behaviour and navigation requirements.

4.2.20.150 Why One Overall Score Is Usually Insufficient

It is tempting to create one cost such as

\[ J = w_1\mathrm{RMSE} + w_2T_{\mathrm{conv}} + w_3\mathrm{NEES}. \]

This may help optimization.

However, one number can hide a critical failure.

For example, excellent RMSE can compensate numerically for unacceptable inconsistency.

Therefore individual acceptance criteria should still be maintained.

4.2.20.151 Error-Covariance Agreement

A useful qualitative objective is

\[ \boxed{ \text{Actual Error Distribution} \leftrightarrow \text{Predicted Covariance Distribution}. } \]

This is the essence of filter consistency.

The covariance should neither be unrealistically optimistic nor unnecessarily conservative.

4.2.20.152 Accuracy Without Consistency

Suppose

\[ |\tilde x| = 0.01 \]

but

\[ \sigma = 10^{-4}. \]

The absolute error may be small enough for one application.

However, the estimator believes its uncertainty is two orders of magnitude smaller.

This estimator is highly overconfident.

4.2.20.153 Consistency Without Adequate Accuracy

Suppose

\[ |\tilde x| \approx \sigma \]

so the covariance correctly represents the error.

But if

\[ |\tilde x| > e_{\mathrm{req}}, \]

the estimator still fails the navigation-performance requirement.

Thus:

\[ \boxed{ \text{Consistent} \not\Rightarrow \text{Sufficiently Accurate}. } \]

4.2.20.154 Performance Before and After Tuning

A useful comparison is:

\[ \text{Baseline Filter} \]

versus

\[ \text{Tuned Filter}. \]

Compare:

• RMSE,
• innovation mean,
• NIS,
• NEES,
• convergence time,
• rejection rate.

This provides quantitative evidence of whether tuning improved the estimator.

4.2.20.155 Independent Validation Data

Data used to tune the estimator should ideally not be the only data used to validate it.

Use:

\[ \boxed{ \text{Tuning Data} \neq \text{Validation Data}. } \]

Otherwise the estimator may be effectively over-tuned to one scenario.

4.2.20.156 Cross-Scenario Validation

Validate across different:

• trajectories,
• initial states,
• sensor geometries,
• noise realizations,
• environmental conditions.

This tests whether performance generalizes.

4.2.20.157 Error Distribution Across Runs

For each Monte Carlo run, calculate one summary metric:

\[ J^{(j)}. \]

Then analyze the distribution

\[ \{ J^{(1)},\ldots,J^{(N_{MC})} \}. \]

Report:

• median,
• mean,
• standard deviation,
• percentiles,
• maximum.

4.2.20.158 Median Performance

Median performance corresponds to the \(50^\text{th}\) percentile.

\[ \boxed{ J_{50}. } \]

It is less sensitive to extreme outliers than the mean.

4.2.20.159 95th-Percentile Performance

\[ \boxed{ J_{95} } \]

means approximately \(95\%\) of runs perform at or better than that value.

This is often a useful robust-performance indicator.

4.2.20.160 99th-Percentile Performance

\[ \boxed{ J_{99} } \]

examines deeper into the tail.

However, reliable estimation of extreme percentiles requires sufficiently many Monte Carlo samples.

4.2.20.161 Maximum Observed Error

The largest observed value is

\[ \boxed{ J_{\max} = \max_j J^{(j)}. } \]

This is useful but should not automatically be interpreted as the true worst-case value.

It is only the worst case observed in the sample population.

4.2.20.162 Histograms Across Monte Carlo Runs

A histogram of

\[ \mathrm{RMSE}^{(j)} \]

or

\[ T_{\mathrm{conv}}^{(j)} \]

can reveal:

• multimodal behaviour,
• long tails,
• occasional failures,
• clustering by scenario.

This may reveal information hidden by mean and standard deviation.

4.2.20.163 Correlation Between Performance Metrics

Different metrics may be correlated.

For example:

\[ T_{\mathrm{conv}} \]

may increase when

\[ e_0 \]

increases.

Similarly,

\[ \mathrm{RMSE} \]

may correlate with measurement noise.

These relationships help identify dominant performance drivers.

4.2.20.164 Scatter Plots

Useful examples include:

\[ \mathrm{RMSE} \text{ versus } \sigma_z, \]

\[ T_{\mathrm{conv}} \text{ versus } e_0, \]

\[ \mathrm{NEES} \text{ versus } Q. \]

Scatter plots reveal trends that are difficult to see in time histories.

4.2.20.165 State-Specific Performance

Avoid combining all states into a single metric.

Evaluate independently:

\[ \text{position}, \]

\[ \text{velocity}, \]

\[ \text{attitude}, \]

\[ \text{rate}, \]

\[ \text{bias}. \]

Different state groups may have different operational importance.

4.2.20.166 Axis-Specific Performance

A sensor geometry may strongly constrain one direction but weakly constrain another.

Therefore report:

\[ \mathrm{RMSE}_x, \quad \mathrm{RMSE}_y, \quad \mathrm{RMSE}_z. \]

This is especially important for optical and relative-navigation systems.

4.2.20.167 Phase-Specific Performance

Metrics should also be separated by phase.

For example:

\[ \mathrm{RMSE}_{\mathrm{coast}}, \]

\[ \mathrm{RMSE}_{\mathrm{maneuver}}, \]

\[ \mathrm{RMSE}_{\mathrm{relative}}. \]

Combining phases with very different dynamics may produce misleading averages.

4.2.20.168 Performance Under Weak Observability

Weak observability often appears as:

• large covariance,
• slow convergence,
• high state correlations,
• increased sensitivity.

In this case, large uncertainty may be physically correct.

The objective is not automatically to reduce covariance but to determine whether available information is sufficient for the requirement.

4.2.20.169 Performance Under Sensor Correlation

If correlated measurements are mistakenly treated as independent,

\[ \mathbf P \]

may shrink too quickly.

Then state error may remain moderate while

\[ \mathrm{NEES} \]

increases.

This is a classic signature of double-counted information.

4.2.20.170 Performance Under Model Mismatch

Introduce truth-model effects absent from the estimator.

Then evaluate:

\[ \mathrm{RMSE}, \quad \mathrm{NIS}, \quad \mathrm{NEES}. \]

Model mismatch often appears as both increased error and correlated innovations.

4.2.20.171 Performance Under Timing Error

Introduce timestamp offset

\[ \delta t. \]

Evaluate how:

\[ \mathrm{RMSE}, \quad \bar{\mathbf r}, \quad \mathrm{NIS} \]

change with increasing \(\delta t\).

Fast dynamics can be highly sensitive even to small timing errors.

4.2.20.172 Performance Under Bias

Add controlled sensor bias:

\[ b. \]

Observe:

• innovation mean,
• state error,
• bias-state convergence,
• NIS.

This helps distinguish whether bias is observable and correctly estimated.

4.2.20.173 Performance Under Outliers

Inject occasional measurement outliers.

Evaluate:

• state-error excursion,
• gate response,
• rejection rate,
• recovery time.

A robust estimator should limit the effect of isolated bad measurements.

4.2.20.174 Performance Under Faults

For persistent faults, evaluate:

\[ P_D, \]

\[ P_{FA}, \]

\[ T_D, \]

where:

• \(P_D\) = probability of detection,
• \(P_{FA}\) = false-alarm probability,
• \(T_D\) = detection time.

Filter performance and FDIR performance are closely connected.

4.2.20.175 Fault-Free False Alarm Rate

During nominal operation,

\[ \boxed{ f_{FA} = \frac{ N_{\mathrm{false\ fault\ declarations}} }{ N_{\mathrm{opportunities}} }. } \]

An estimator that frequently declares healthy measurements faulty may have poor covariance consistency or thresholds that are too tight.

4.2.20.176 Detection Probability

For injected faults,

\[ \boxed{ P_D = \frac{ N_{\mathrm{faults\ detected}} }{ N_{\mathrm{faults\ injected}} }. } \]

Detection probability should be evaluated against fault magnitude and type.

4.2.20.177 Detection Delay

Define

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

A detector may eventually find every fault but still be inadequate if the delay is too long.

4.2.20.178 Performance During Degraded Navigation

After sensor loss, evaluate:

• remaining accuracy,
• covariance growth,
• observability,
• availability,
• time until requirement violation.

This determines whether the system can continue operating in a degraded mode.

4.2.20.179 Time-to-Requirement-Violation

After loss of a sensor, define

\[ \boxed{ T_{\mathrm{limit}} = t_{\mathrm{requirement\ violated}} - t_{\mathrm{loss}}. } \]

This gives a useful operational measure of how long navigation can safely coast without that sensor.

4.2.20.180 Closed-Loop Navigation Performance

Estimator performance should ultimately be evaluated with guidance and control connected.

The system becomes

\[ \boxed{ \text{Estimation} \rightarrow \text{Guidance} \rightarrow \text{Control} \rightarrow \text{Dynamics} \rightarrow \text{Measurement}. } \]

Errors can feed back into the vehicle trajectory.

4.2.20.181 Estimation Error and Control Error

A controller typically uses

\[ \hat{\mathbf x} \]

rather than the true state.

Therefore

\[ \tilde{\mathbf x} \]

can produce additional control error.

The estimator should therefore be assessed not only mathematically but also by its effect on control performance.

4.2.20.182 Navigation-Induced Control Activity

Noisy estimates may cause excessive actuator commands.

One possible metric is

\[ \boxed{ J_u = \sum_k \|\mathbf u_k\|. } \]

Compare this with the control effort that would occur with perfect state knowledge.

4.2.20.183 Estimator-Induced Limit Cycling

If the estimate fluctuates around a control deadband,

\[ \hat x \approx x_{\mathrm{threshold}}, \]

the controller may repeatedly switch modes or actuators.

Therefore estimator noise should be assessed around operational thresholds.

4.2.20.184 Performance and Guidance Decisions

Guidance may use both state and covariance.

For example,

\[ \boxed{ \text{Proceed} } \]

may require acceptable state estimate and uncertainty.

Thus an overconfident covariance can be operationally more dangerous than a visibly noisy estimate.

4.2.20.185 Independent Truth Reference

When hardware testing is performed, use the most accurate available independent reference.

Examples may include:

• laboratory motion-capture systems,
• precision rate tables,
• high-grade reference IMUs,
• independent orbital truth solutions.

The reference should be significantly more accurate than the estimator under test.

4.2.20.186 Reference Uncertainty

The truth reference itself may have uncertainty

\[ \mathbf P_{\mathrm{ref}}. \]

Then measured estimator error contains both estimator and reference error.

This should be considered when the reference accuracy is comparable to the estimator accuracy.

4.2.20.187 Reference Independence

Validation becomes less meaningful if the same measurement source contributes to both:

\[ \hat{\mathbf x} \]

and

\[ \mathbf x_{\mathrm{ref}}. \]

Whenever possible, the reference should be independent of the estimator under test.

4.2.20.188 Software-in-the-Loop Metrics

SIL is useful for large-scale evaluation of:

• RMSE,
• NIS,
• NEES,
• convergence time,
• fault response,
• Monte Carlo statistics.

Because SIL is repeatable, it is ideal for filter-performance regression testing.

4.2.20.189 Hardware-in-the-Loop Metrics

HIL introduces real effects such as:

• quantization,
• processor timing,
• bus delay,
• sensor startup,
• packet jitter,
• hardware saturation.

The same performance metrics should be repeated to determine whether hardware effects materially change estimator behaviour.

4.2.20.190 Flight-Test Performance

In flight, exact truth may not be available.

Therefore emphasize:

• innovations,
• NIS,
• redundant sensors,
• independent cross-checks,
• covariance,
• operational outcomes.

Ground-tested truth-based metrics still provide the basis for interpreting these quantities.

4.2.20.191 Filter Health Monitoring

A navigation-health monitor may combine:

\[ \boxed{ \text{NIS} + \text{Covariance} + \text{Sensor Health} + \text{Numerical Health} + \text{Convergence Status}. } \]

No single statistic should normally be used as the sole estimator-health indicator.

4.2.20.192 Example Navigation-Health Logic

A generic rule could be:

\[ \texttt{NAV\_VALID}=1 \]

if:

\[ \operatorname{tr}(\mathbf P) < P_{\max}, \]

\[ \mathrm{NIS} < \gamma_{\max}, \]

required sensors are healthy,

and numerical checks pass.

The precise logic depends on the mission.

4.2.20.193 Error-State Filters and Performance Metrics

For ESKF or MEKF architectures, the covariance refers to the local error state.

Therefore consistency metrics should use the corresponding error coordinates.

For attitude, this typically means comparing

\[ \delta\boldsymbol\theta \]

with its covariance rather than directly comparing four quaternion components.

4.2.20.194 Quaternion Covariance Interpretation

A unit quaternion has four components but only three independent degrees of freedom.

Therefore a covariance on a three-dimensional attitude-error vector is often more physically meaningful than treating all four quaternion components as independent errors.

This is particularly relevant for MEKF consistency analysis.

4.2.20.195 UKF Performance Metrics

For UKF, the same metrics apply:

• state error,
• RMSE,
• NIS,
• NEES,
• covariance consistency.

However, additional care should be taken with:

• sigma-point scaling,
• nonlinear transformations,
• attitude manifold handling.

4.2.20.196 Particle Filter Performance Metrics

For particle filters, covariance-based metrics may still be computed, but additional measures include:

\[ N_{\mathrm{eff}} = \frac1{ \sum_i w_i^2 }. \]

Low

\[ N_{\mathrm{eff}} \]

indicates particle degeneracy.

Other metrics include:

• resampling frequency,
• particle spread,
• multimodal-state representation.

4.2.20.197 Information Filter Performance

For information-form filters,

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

The same consistency concepts apply.

Large information corresponds to small covariance.

Therefore overconfident information matrices can be detected through NEES just as in covariance-form filters.

4.2.20.198 Performance of Federated Filters

For federated architectures, evaluate:

• each local filter,
• master-filter output,
• cross-consistency,
• information sharing,
• fault isolation.

The global estimate may appear accurate even if one local branch is internally inconsistent.

4.2.20.199 Performance of Multi-Rate Filters

For multi-rate sensor fusion, examine metrics around measurement arrivals.

Covariance may:

• grow between low-rate updates,
• reduce sharply after measurements.

This is normal.

Performance should be interpreted with the sensor update schedule in mind.

4.2.20.200 Performance With Delayed Measurements

Delayed measurements may temporarily increase state error.

Metrics should assess:

• state correction after delayed update,
• covariance correction,
• residual consistency,
• output latency.

Delayed-measurement algorithms should be compared against naive current-time updating.

4.2.20.201 Performance With Out-of-Sequence Measurements

When old measurements arrive later than newer data, verify:

• state history consistency,
• covariance history,
• current-state correction,
• numerical stability.

Performance can be quantified by comparing against an ideal correctly ordered solution.

4.2.20.202 Filter Comparison Requires Identical Conditions

When comparing estimator algorithms, all should receive:

• identical truth,
• identical measurement realization,
• equivalent initialization,
• equivalent physical models.

Otherwise differences may arise from the test setup rather than the estimator architecture.

4.2.20.203 Performance Regression Testing

Maintain baseline values for:

\[ \mathrm{RMSE}, \quad \mathrm{NIS}, \quad \mathrm{NEES}, \quad T_{\mathrm{conv}}. \]

After software modification, automatically compare new results against the baseline.

Unexpected degradation indicates a regression.

4.2.20.204 Reproducibility

Record:

• random seed,
• software version,
• estimator version,
• tuning parameters,
• test scenario,
• sensor configuration.

Without this information, performance results may not be reproducible.

4.2.20.205 Reporting Reference Frame

Every vector error should state its frame.

For example:

\[ \mathbf e_r^I \]

for inertial-frame position error,

or

\[ \mathbf e_r^{RTN}. \]

Without the frame, numerical error values can be ambiguous.

4.2.20.206 Reporting Units

Always report units:

\[ \mathrm{m}, \qquad \mathrm{m/s}, \qquad \mathrm{deg}, \qquad \mathrm{deg/s}. \]

A statement such as

“RMSE = 0.05”

is incomplete without units and state definition.

4.2.20.207 Reporting Time Window

RMSE depends on the interval used.

Specify whether it is calculated over:

• initialization,
• steady state,
• complete simulation,
• specific mission phase.

Otherwise two RMSE values may not be directly comparable.

4.2.20.208 Reporting Monte Carlo Population

A Monte Carlo statement should specify

\[ N_{MC}. \]

For example:

“95th-percentile position RMSE over 1000 Monte Carlo runs.”

This is much more meaningful than reporting a percentile without the sample population.

4.2.20.209 Reporting Confidence Level

For NIS or NEES bounds, specify the confidence level.

For example:

\[ 95\% \]

or

\[ 99\%. \]

The corresponding chi-square limits depend on this choice.

4.2.20.210 Performance Dashboard

A practical estimator dashboard may contain:

\[ \boxed{ \begin{array}{c} \text{Position RMSE}\\ \text{Velocity RMSE}\\ \text{Attitude Error}\\ \text{Bias Error}\\ \text{Innovation Mean}\\ \text{NIS}\\ \text{NEES}\\ \text{Covariance}\\ \text{Convergence Time}\\ \text{Availability}\\ \text{Rejection Rate} \end{array} } \]

No single metric provides the complete picture.

4.2.20.211 Essential Plots

A strong filter-performance report should include:

1. truth and estimate,
2. estimation error,
3. error with \(3\sigma\) bounds,
4. innovation,
5. normalized innovation,
6. NIS,
7. NEES,
8. covariance,
9. bias-state error,
10. measurement acceptance/rejection,
11. Monte Carlo percentile envelopes,
12. convergence-time distribution.

4.2.20.212 Truth Versus Estimate Plot

This plot is useful for verifying gross behaviour.

However, when the estimate closely follows truth, the two curves may visually overlap.

Therefore the separate error plot is usually more informative.

4.2.20.213 Error Plot

Plot

\[ \tilde x(t). \]

This directly reveals:

• bias,
• transients,
• drift,
• oscillation,
• sudden jumps.

It should usually accompany any truth-versus-estimate figure.

4.2.20.214 Error With Covariance Bounds

Plot:

\[ \tilde x(t), \]

\[ +3\sigma(t), \]

\[ -3\sigma(t). \]

This is one of the most useful estimator-validation figures because accuracy and consistency can be inspected together.

4.2.20.215 Innovation Plot

Plot each innovation component.

Look for:

• zero-mean behaviour,
• variance changes,
• spikes,
• drift,
• periodic patterns.

These often identify measurement-model problems earlier than state errors do.

4.2.20.216 NIS Plot

Plot

\[ \mathrm{NIS}_k \]

along with the chi-square threshold.

Frequent or sustained threshold exceedance suggests mismatch between observed and predicted measurement uncertainty.

4.2.20.217 NEES Plot

In simulation, plot

\[ \mathrm{NEES}_k \]

with chi-square consistency limits.

Persistent high values indicate overconfidence.

Persistent low values indicate conservatism.

4.2.20.218 Convergence Plot

Plot:

\[ \|\tilde{\mathbf x}(t)\|, \]

or selected state errors together with convergence thresholds.

Mark

\[ t_{\mathrm{conv}}. \]

This makes convergence performance explicit.

4.2.20.219 Monte Carlo Fan Plot

Overlay many trajectories lightly or show percentile envelopes.

This makes run-to-run variability visible.

A single nominal curve does not reveal this information.

4.2.20.220 Performance Heat Map

Useful examples include:

\[ \mathrm{RMSE} = f( \text{range}, \text{sensor noise} ) \]

or

\[ P_{\mathrm{success}} = f( \text{initial error}, \text{update rate} ). \]

Heat maps are effective for showing operating-envelope boundaries.

4.2.20.221 Common Mistake: Judge Only RMSE

A filter can have excellent RMSE yet poor covariance consistency.

Therefore:

\[ \boxed{ \mathrm{RMSE} \text{ alone is insufficient}. } \]

At minimum, combine accuracy metrics with consistency metrics.

4.2.20.222 Common Mistake: Judge Only NIS

NIS evaluates measurement-space consistency.

It does not prove that every state is accurate or observable.

Therefore acceptable NIS does not automatically mean the entire navigation state is valid.

4.2.20.223 Common Mistake: Judge Only NEES

NEES is powerful in simulation, but it still does not fully capture:

• computational latency,
• availability,
• fault recovery,
• sensor rejection behaviour.

A complete system assessment requires additional metrics.

4.2.20.224 Common Mistake: One Monte Carlo Run

A Monte Carlo analysis with one random realization is not Monte Carlo analysis.

Performance distributions require many independent trials.

4.2.20.225 Common Mistake: Use Only Mean Values

Mean values can hide long tails.

Always consider:

\[ \text{median}, \quad 95^\text{th}\text{ percentile}, \quad 99^\text{th}\text{ percentile}, \quad \max. \]

4.2.20.226 Common Mistake: Ignore Transients

Excellent steady-state RMSE can hide poor startup behaviour.

Initialization, reacquisition, and sensor switching should therefore be analyzed separately.

4.2.20.227 Common Mistake: Ignore Correlated Samples

Successive filter errors and innovations are often temporally correlated.

Therefore simple independent-sample statistical assumptions should be used carefully.

This is particularly relevant when interpreting coverage counts.

4.2.20.228 Common Mistake: Confuse Covariance With Actual Error

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

is not the actual error.

It is the predicted standard deviation of error.

The actual error is

\[ |\tilde x_i|. \]

Confusing the two can lead to incorrect performance claims.

4.2.20.229 Common Mistake: Interpret Small Covariance as Good Navigation

Small covariance is desirable only if it is justified.

A covariance of

\[ 10^{-8} \]

is not impressive if actual error is

\[ 10^{-2}. \]

Consistency must always accompany covariance magnitude.

4.2.20.230 Common Mistake: Report Accuracy Without Probability

Statements such as

“Position accuracy is 10 cm”

are incomplete.

Does this mean:

• RMSE?
• \(1\sigma\)?
• \(3\sigma\)?
• \(95^\text{th}\) percentile?
• maximum error?

The statistical meaning should always be specified.

4.2.20.231 Common Mistake: Mix Coordinate Frames

Do not compare truth in one frame with estimates in another.

Both state and covariance must be transformed consistently before comparison.

4.2.20.232 Covariance Transformation

For linear transformation

\[ \mathbf y = \mathbf T\mathbf x, \]

the covariance transforms as

\[ \boxed{ \mathbf P_y = \mathbf T \mathbf P_x \mathbf T^T. } \]

Thus converting error into RTN, body, or another frame requires corresponding covariance transformation.

4.2.20.233 Consistency After Frame Transformation

If covariance and error are transformed correctly, NEES should remain invariant under nonsingular linear coordinate transformations.

This provides a useful conceptual check of implementation correctness.

4.2.20.234 Common Mistake: Mix Degrees and Radians

For attitude covariance, ensure units are consistent.

If attitude error is measured in degrees while covariance is in radians squared, consistency statistics become meaningless.

Always establish unit conventions explicitly.

4.2.20.235 Common Mistake: Quaternion Component RMSE

Raw quaternion component RMSE is generally less intuitive than attitude-angle error.

Because of quaternion normalization and sign ambiguity,

\[ q \]

and

\[ -q \]

represent the same attitude.

Use an attitude-error quaternion or rotation-angle metric instead.

4.2.20.236 Common Mistake: Forget Bias Truth

If simulated IMU bias is part of truth but bias-estimation error is never evaluated, the filter may appear to perform well in navigation states while the underlying bias estimate remains poor.

Bias errors should be plotted explicitly.

4.2.20.237 Common Mistake: Verify Only Final Error

A final-time error can hide severe intermediate excursions.

Performance should be evaluated over the complete required time interval.

4.2.20.238 Common Mistake: Declare Convergence From Covariance Alone

A filter may report small covariance while remaining biased.

Therefore convergence should generally require both:

\[ \boxed{ \text{Small Actual Error} } \]

in test environments and

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

4.2.20.239 Common Mistake: Hide Diverged Runs

When presenting Monte Carlo statistics, failed runs should not simply be removed from the dataset.

The failure fraction is itself an important performance metric.

4.2.20.240 Failed-Run Accounting

Report:

\[ N_{\mathrm{total}}, \]

\[ N_{\mathrm{successful}}, \]

\[ N_{\mathrm{diverged}}, \]

\[ N_{\mathrm{numerical\ failure}}. \]

This makes statistical results transparent.

4.2.20.241 Consistency and Tuning Connection

Section 4.2.19 introduced \(Q\) and \(R\) tuning.

Section 4.2.20 provides the tools for determining whether that tuning is statistically credible.

Conceptually,

\[ \boxed{ Q,R \rightarrow P \rightarrow S \rightarrow NIS/NEES \rightarrow Consistency Assessment. } \]

4.2.20.242 NIS as a Tuning Diagnostic

If NIS is systematically high:

\[ \boxed{ \text{Observed Measurement Error} > \text{Predicted Measurement Error}. } \]

Possible causes include covariance underestimation.

If NIS is systematically low, the estimator may be too conservative.

4.2.20.243 NEES as a Tuning Diagnostic

Similarly:

\[ \mathrm{NEES}\gg n \]

suggests under-predicted state uncertainty.

\[ \mathrm{NEES}\ll n \]

suggests over-predicted state uncertainty.

Therefore NEES provides direct feedback on whether the state covariance is believable.

4.2.20.244 NIS and NEES Diagnosis Matrix

A useful interpretation is:

This table is diagnostic guidance, not an automatic fault classifier.

4.2.20.245 RMSE and NEES Together

Suppose two filters have:

\[ \mathrm{RMSE}_A < \mathrm{RMSE}_B. \]

But:

\[ \mathrm{NEES}_A \gg n, \]

while:

\[ \mathrm{NEES}_B \approx n. \]

Filter A is more accurate in that sample but less statistically credible.

This demonstrates why RMSE alone is not sufficient.

4.2.20.246 Error Budget

Navigation error may arise from several sources.

Conceptually,

\[ \sigma_{\mathrm{nav}}^2 \approx \sigma_{\mathrm{sensor}}^2 + \sigma_{\mathrm{model}}^2 + \sigma_{\mathrm{timing}}^2 + \sigma_{\mathrm{initial}}^2 +\cdots \]

when independence assumptions are reasonable.

An error budget helps identify the dominant performance limitation.

4.2.20.247 Contribution Analysis

If reducing one uncertainty source significantly improves RMSE, that source is a major performance driver.

For example:

\[ \sigma_{\mathrm{camera}} \downarrow \]

may strongly reduce position error but have little effect on attitude bias.

Such analysis can support sensor selection and requirement allocation.

4.2.20.248 Performance Allocation

A top-level navigation requirement can be allocated among:

• sensor error,
• estimation error,
• timing,
• calibration,
• model uncertainty.

This establishes quantitative design margins.

4.2.20.249 Performance Assessment Workflow

A practical workflow is

\[ \boxed{ \begin{array}{c} \text{Define Requirements}\\ \downarrow\\ \text{Generate Truth + Measurements}\\ \downarrow\\ \text{Run Estimator}\\ \downarrow\\ \text{Calculate State Errors}\\ \downarrow\\ \text{Calculate RMSE / MAE / Percentiles}\\ \downarrow\\ \text{Inspect Innovations}\\ \downarrow\\ \text{Calculate NIS / NEES}\\ \downarrow\\ \text{Compare Covariance with Error}\\ \downarrow\\ \text{Run Monte Carlo}\\ \downarrow\\ \text{Evaluate Convergence and Recovery}\\ \downarrow\\ \text{Check Requirements} \end{array} } \]

4.2.20.250 Step 1 — Define the State Being Evaluated

State clearly whether the assessment concerns:

• absolute position,
• relative position,
• velocity,
• attitude,
• angular rate,
• bias,
• calibration.

Metrics are meaningless without defining the state.

4.2.20.251 Step 2 — Define the Reference Frame

Specify:

\[ I, \quad B, \quad RTN, \quad LVLH, \quad \text{relative frame}, \]

or whichever frame is used.

Transform state and covariance consistently.

4.2.20.252 Step 3 — Define the Performance Window

Specify whether metrics are calculated:

• before convergence,
• after convergence,
• during a manoeuvre,
• during steady state,
• during sensor outage.

This prevents ambiguous comparisons.

4.2.20.253 Step 4 — Calculate Accuracy Metrics

Compute:

\[ \bar e, \]

\[ \mathrm{MAE}, \]

\[ \mathrm{RMSE}, \]

\[ e_{\max}, \]

\[ e_{95}, \]

\[ e_{99}. \]

These quantify actual error.

4.2.20.254 Step 5 — Calculate Consistency Metrics

Compute:

\[ \mathrm{NIS}, \]

\[ \mathrm{NEES}, \]

covariance coverage,

innovation mean,

innovation covariance.

These quantify statistical credibility.

4.2.20.255 Step 6 — Evaluate Innovation Whiteness

Check autocorrelation.

Persistent correlation suggests missing model structure.

This step prevents a filter from appearing statistically correct based only on variance.

4.2.20.256 Step 7 — Evaluate Convergence

Measure:

\[ T_{\mathrm{conv}}, \]

state-specific convergence times,

and success rate.

Do not assume every run converges.

4.2.20.257 Step 8 — Perform Monte Carlo

Randomize the uncertainties that are physically expected.

Calculate distributions rather than only averages.

4.2.20.258 Step 9 — Test Off-Nominal Conditions

Include:

• noise increase,
• bias,
• dropout,
• delay,
• poor geometry,
• large initial error.

A robust estimator should be understood beyond nominal operation.

4.2.20.259 Step 10 — Evaluate Closed-Loop Impact

Connect the estimator to guidance and control.

Verify that estimation errors and covariance behaviour do not create unacceptable vehicle response.

4.2.20.260 Step 11 — Generate Requirement Table

For every navigation requirement, record:

• metric,
• threshold,
• test condition,
• measured result,
• margin,
• status.

This turns estimator analysis into formal verification.

4.2.20.261 Key Difference: Estimator Accuracy vs Estimator Credibility

An estimator may produce a value that is accidentally close to truth.

That is accuracy.

But if the estimator's covariance does not correctly describe uncertainty, it is not statistically credible.

Therefore:

\[ \boxed{ \text{Good Navigation} = \text{Accurate Estimate} + \text{Credible Uncertainty}. } \]

4.2.20.262 Performance Assessment Philosophy

The goal is not to demonstrate that the estimator works in one carefully chosen case.

The goal is to establish that:

\[ \boxed{ \text{The estimator performs predictably across the conditions it is expected to encounter.} } \]

That requires both deterministic performance metrics and statistical consistency metrics.

4.2.20.263 Recommended Minimum Metrics

For most spacecraft Kalman-filter studies, I would consider the minimum useful set to be:

1. position/velocity/attitude error as applicable,
2. RMSE,
3. maximum or percentile error,
4. \(3\sigma\) covariance bounds,
5. innovation,
6. NIS,
7. NEES in simulation,
8. convergence time,
9. Monte Carlo percentiles,
10. success/divergence rate.

This gives a substantially more complete picture than RMSE alone.

4.2.20.264 Complete Metric Relationship

The overall relationship can be summarized as

\[ \boxed{ \begin{array}{ccccc} \mathbf x-\hat{\mathbf x} & \rightarrow & \text{RMSE / MAE / Percentiles} & \rightarrow & \text{Accuracy} \\[6pt] \mathbf z-\hat{\mathbf z} & \rightarrow & \text{Innovation / NIS} & \rightarrow & \text{Measurement Consistency} \\[6pt] \tilde{\mathbf x},\mathbf P & \rightarrow & \text{NEES} & \rightarrow & \text{State Consistency} \\[6pt] \text{Monte Carlo} & \rightarrow & \text{Distributions / Envelopes} & \rightarrow & \text{Robustness} \\[6pt] t & \rightarrow & T_{\mathrm{conv}},T_{\mathrm{recover}} & \rightarrow & \text{Operational Performance} \end{array} } \]

4.2.20.265 Key Takeaways

1. Estimation error is the difference between truth and the estimated state.

\[ \boxed{ \tilde{\mathbf x} = \mathbf x-\hat{\mathbf x}. } \]

2. RMSE measures estimator accuracy but does not measure covariance consistency.

\[ \boxed{ \mathrm{RMSE} = \sqrt{ \frac1N \sum e_k^2 }. } \]

3. Innovation evaluates disagreement between measurement and predicted measurement.

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

4. Innovation covariance is

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

5. NIS measures measurement-space consistency.

\[ \boxed{ \mathrm{NIS} = \mathbf r^T \mathbf S^{-1} \mathbf r. } \]

6. NEES measures state-space consistency when truth is available.

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

7. A filter can be accurate but inconsistent.

Small RMSE does not guarantee credible covariance.

8. A filter can be consistent but insufficiently accurate.

Consistency does not automatically mean that mission navigation requirements are satisfied.

9. Covariance should be compared with actual error whenever truth is available.

Error versus \(3\sigma\) plots are especially useful.

10. Monte Carlo analysis is required for statistical performance characterization.

One trajectory is only one random realization.

11. Percentiles and envelopes reveal behaviour hidden by mean values.

\[ e_{50}, \quad e_{95}, \quad e_{99} \]

are useful performance descriptors.

12. Convergence time is an operational navigation metric.

\[ \boxed{ T_{\mathrm{conv}} } \]

should be defined using explicit state and covariance conditions.

13. Recovery after sensor dropout or disturbance should also be quantified.

\[ \boxed{ T_{\mathrm{recover}} } \]

is separate from nominal convergence.

14. Filter performance should be evaluated by state, axis, mission phase, and sensor configuration.

A single overall RMSE is rarely enough.

15. General spacecraft RPO is one application of these same principles.

Relative position, velocity, attitude, and covariance should be assessed using the same consistency and accuracy framework used elsewhere in spacecraft navigation.

16. Statistical consistency should be evaluated using more than one method.

Useful tools include:

• covariance coverage,
• innovation statistics,
• NIS,
• NEES,
• Monte Carlo covariance comparison.

17. Numerical validity is part of estimator performance.

\[ \boxed{ \mathbf P=\mathbf P^T, \qquad \lambda_i(\mathbf P)\ge0. } \]

18. Navigation performance is more than accuracy.

It can include:

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

19. Every reported metric should have a clear definition, frame, units, time interval, and statistical population.

20. The central principle is

\[ \boxed{ \begin{array}{c} \text{A trustworthy estimator does not merely produce a state estimate.}\\[4pt] \text{It produces a state estimate together with uncertainty}\\[4pt] \text{that statistically agrees with the errors actually observed.} \end{array} } \]

This completes the real-world sensor-fusion foundation from 4.2.13 through 4.2.20. The next section, 4.2.21 Attitude Sensor Fusion, can now apply these estimation principles directly to gyroscope, star tracker, Sun sensor, and magnetometer fusion, including quaternion propagation, vector measurements, gyro-bias estimation, safe-mode attitude determination, and fine-pointing estimation.

Next: 4.2.21 Attitude Sensor Fusion

After establishing how estimator accuracy, covariance consistency, innovations, NIS, NEES, Monte Carlo envelopes, convergence, recovery, and navigation validity are assessed, the next section applies those principles directly to spacecraft attitude estimation.