Attitude Reference Validation Software

SWITCH TO API

Description

The Attitude Reference Validation Software is a software module that evaluates whether a spacecraft’s pointing task has been achieved within a specified tolerance. It compares the current attitude error against a configurable threshold and outputs a device status message indicating whether the pointing requirement has been satisfied. This module is commonly used to trigger downstream systems or payloads that require precise pointing before activation.

---

Example Use Cases

• Payload Activation: Enable a science instrument or communication antenna only when the spacecraft has achieved the required pointing accuracy.
• Imaging Operations: Validate that the spacecraft attitude is within tolerance before commanding a camera to capture an image.
• Mission Sequencing: Use the validation flag to gate subsequent mission operations that depend on precise attitude control.
• ADCS Performance Verification: Monitor and log when pointing requirements are first achieved during a slew maneuver.

---

Module Implementation

The Attitude Reference Validation Software is a Software component that processes incoming attitude error data and produces a device status output. It operates as a simple threshold comparator with hysteresis tracking for first-time activation events.

Attitude Error Evaluation

The module receives an Attitude Error Message containing the attitude error expressed as a Modified Rodrigues Parameter (MRP) vector ${\mathbf{\sigma }}_{B/R}$, which represents the rotation error between the spacecraft body frame $\mathcal{B}$ and the reference frame $\mathcal{R}$.

The scalar error metric is computed as the Euclidean norm of the MRP vector:

$$e=\Vert {\mathbf{\sigma }}_{B/R}\Vert =\sqrt{{\sigma }_1^2+{\sigma }_2^2+{\sigma }_3^2}$$

where ${\sigma }_1$, ${\sigma }_2$, and ${\sigma }_3$ are the components of the MRP error vector.

Threshold Comparison

The computed error is compared against the user-defined ErrorTolerance parameter $ϵ$. The device status is determined by:

$$\text{IsActive}=\{\begin{array}{ll}\text{true}& \text{if }e\le ϵ\\ \text{false}& \text{otherwise}\end{array}$$

This comparison is performed at each simulation update step, allowing the output status to dynamically reflect the current pointing accuracy.

First Activation Flag

The module maintains a persistent flag IsDeviceFlagged that is set to true the first time the pointing tolerance is achieved. This flag is not reset if the error subsequently exceeds the tolerance, providing a record of whether the pointing requirement was ever satisfied during the simulation.

The flag logic is defined as:

$$\text{IsDeviceFlagged}=\text{IsDeviceFlagged}\vee (\neg {\text{IsActive}}_{\text{prev}}\wedge {\text{IsActive}}_{\text{curr}})$$

where ${\text{IsActive}}_{\text{prev}}$ is the device status from the previous time step and ${\text{IsActive}}_{\text{curr}}$ is the newly computed status.

Update Sequence

At each simulation time step, the module performs the following operations:

1. Check Input Availability: If the incoming attitude error message is not connected, the update is skipped.
2. Compute Error Magnitude: Calculate the Euclidean norm of the MRP error vector.
3. Skip Initial Conditions: If time, step, and error are all zero, the update is skipped to avoid false triggering at simulation initialization.
4. Store Previous State: Record the current device active status before updating.
5. Update Device Status: Set the output device status based on the threshold comparison.
6. Set Activation Flag: If the device transitions from inactive to active, set the first-activation flag.

Output Message

The module outputs a Device Status Message containing the IsActive field, which can be consumed by downstream components to conditionally enable operations based on pointing accuracy.

---

Assumptions/Limitations

• The attitude error is assumed to be provided as a Modified Rodrigues Parameter (MRP) vector in the incoming message.
• The error metric is a scalar norm; directional error components are not individually evaluated.
• The tolerance comparison uses a less-than-or-equal condition; boundary cases where $e=ϵ$ are considered valid.
• The IsDeviceFlagged flag is a one-way latch and cannot be reset without reinitializing the module.
• The module does not implement hysteresis on the tolerance threshold; rapid toggling may occur if the error oscillates near the boundary.
• No filtering or smoothing is applied to the error signal; high-frequency noise may cause spurious state transitions.
• The initial condition check (time, step, and error all zero) assumes the simulation starts at $t=0$ with a zeroed error state.
• The module does not account for rate constraints; only instantaneous position error