9.17 Toggle Commands

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.

As used here, the term “command” should be interpreted to include any function or mechanism used to alter the state of any spacecraft component.

2.1 Additional Guidance

Links to Additional Guidance materials for this subject have been compiled in the Relevant Links table. Click here to see the Additional Guidance in the Resources tab.

3. Inputs

3.1 ARC

  • 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


3.3 JPL

  • 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

  • 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

4.2 Additional Guidance

Additional guidance related to this requirement may be found in the following materials in this Handbook:

Related Links

4.3  Center Process Asset Libraries

SPAN - Software Processes Across NASA
SPAN contains links to Center managed Process Asset Libraries. Consult these Process Asset Libraries (PALs) for Center-specific guidance including processes, forms, checklists, training, and templates related to Software Development. See SPAN in the Software Engineering Community of NEN. Available to NASA only.  197

See the following link(s) in SPAN for process assets from contributing Centers (NASA Only). 

SPAN Links

5. Lessons Learned

5.1 NASA Lessons Learned

The NASA Lesson Learned  439  database contains the following lessons learned related to toggle commands:

  • Stepping Commands Cause Positioning Problems (1970/76)Lesson Learned 0405:  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."

  • No labels