1. The thief who forgot who he was

Hannu Rajaniemi’s The Quantum Thief opens with a protagonist who has had his memory edited so many times that he is not sure what is real. An ADCS that has not been tested is in a similar state. It may have sensors and actuators, but it does not know whether its idea of “up” is the right one. Testing is how it recovers its memory.

2. Why ADCS testing is different

ADCS failures are subtle. A power fault is usually on or off. A communications fault is usually a dropped link. An ADCS fault can look like correct behavior pointing in the wrong direction. The platform can be stable, power-positive, and in communication, yet useless because it is aimed at the wrong part of the sky.

Testing matters because:

  • Sensors behave differently in orbit. Stray light, magnetic fields, and thermal gradients are hard to replicate perfectly on the ground.
  • Control laws are sensitive to model errors. A small mistake in inertia, center of mass, or actuator alignment can turn a stable controller into an oscillator.
  • Faults cascade. A star tracker that reports bad data can fool the filter, which can command the wheels, which can saturate, which can trigger a safe mode.
  • Operations depend on timing. Slew windows, communication passes, and propulsion burns all assume the ADCS can meet deadlines.

3. What the test must prove

At minimum, the ADCS test campaign must prove:

  • The platform can determine its attitude from a lost-in-space state.
  • It can hold each required pointing mode within specification.
  • It can slew between modes within time and power budgets.
  • It can detect and reject faulty sensor data.
  • It can dump momentum and recover from actuator saturation.
  • It can enter and exit safe mode autonomously.

4. What the Resident is not trying to do

Test every possible attitude and rate combination. The goal is to qualify the ADCS for the operational envelope, not to explore the entire state space.

5. The opening posture

The test campaign will combine component tests, software-in-the-loop simulation, and hardware-in-the-loop tests. Each has its place. Component tests verify sensors and actuators. Simulation verifies the control laws. Hardware-in-the-loop verifies that the real software behaves correctly with real hardware.