1. Principle

1.1 Rationale

Making assumptions about the system state can lead to malfunctions.

2. Examples and Discussion

This principle is often formulated in terms of a prohibition against “toggle” commands pertaining to the spacecraft. Both the JPL and Marshall Space Flight Center (MSFC) standards are written in that manner. The underlying problem is maintaining knowledge of the spacecraft’s state. If the command to turn a component on or off, for example, is simply defined as a command to switch state from the current state to the opposite state, ground controllers must keep track of how many times the command has been used to ensure that the correct state is commanded. Use of toggle commands also complicates the development of command sequences that may be invoked in parallel. This may occur as either part of planned commanding, as with the use of so-called “background” sequences and their supporting utility sequences, or asynchronously with planned commanding, as in the case of a sequence that is invoked to implement a recovery procedure. In these cases a race condition is created, with the behavior of the command sequences being dependent on relative timing of execution. Command sequences that execute in parallel are still vulnerable to interference, but prohibiting toggle commands eliminates a particularly difficult source of commanding bugs.

Both JPL and MSFC standards allow the use of toggle commands if information exists to determine the current state of the spacecraft. The Ames Research Center (ARC) formulation of this principle does not grant this allowance, and requires the desired state to be explicitly specified as part of the command. The ARC formulation was preferred in the development of these design principles.

However, none of the Center standards explicitly take into account the practice of generating commands internal to flight software. The design principle as presented here extends the prohibition of toggle commands to internally generated commands.

3. Inputs

3.1 ARC

• 3.6.2.1 Explicit Commanding of States - Commands that are intended to place spacecraft in a specific known state, shall explicitly specify the target state.
  
  Note: This requirement precludes the use of toggle commands, which have a target state implicitly defined by the current state.
  
  Note: Elements to consider when establishing state include inertial, temporal, device capability or configuration, file allocation tables, and boot code in RAM.

3.2 GSFC

None

3.3 JPL

• 4.4.4.1 Use of toggle and step commands - Toggle commands and step commands shall be permitted only if absolute position commands and telemetry also exist for the same function(s).

Rationale: To avoid needing to predict the s/c state that will exist at the time of command execution.

3.4 MSFC

• 4.12.1.10 Toggle commands and step commands shall be permitted if the capability exists to determine absolute position for the commanded function.

Rationale: To avoid needing to predict the vehicle state that will exist at the time of command execution.

4. Resources

4.1 References

5. Lessons Learned

5.1 NASA Lessons Learned

The NASA Lesson Learned 

• Stepping Commands Cause Positioning Problems (1970/76).  Lesson Learned 0405: 

  Swerefn
  refnum 673

  "Unlike explicit commands, stepping or incremental commands, however, simply cause the device to move by the commanded increment from its current position to the new position. If the current position is incorrect, the next position and all subsequent positions will be incorrect. The use of explicit commands is recommended whenever no significant operational advantage exists using incremental commands. Should an incremental command capability be desired for other reasons, the system design should consider also implementing the explicit command capability to ensure fault tolerance."