Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migration of unmigrated content due to installation of a new plugin
Set Data
01. Principle and Rational
12. Examples
23. Inputs
34. Resources
45. Lessons Learned

1. Principle


Include Page
Principles List
Principles List


Design both internal and external commanding to place the system into an explicitly specified state.

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.


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


3. Inputs

Show If
titleVisible to editors only

Excerpts from three documents are included below but no information on the documents that the excerpts were taken from is available. These documents should be properly referenced.

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


Show If
titleVisible to editors only

Enter the necessary modifications to be made in the table below:

SWEREFs to be addedSWEREFS to be deleted

SWEREFs called out in the text: 439, 673

SWEREFs NOT called out in text but listed as germane: NONE

Include Page

5. Lessons Learned

5.1 NASA Lessons Learned

The NASA Lesson Learned 

 database contains the following lessons learned related to toggle commands:

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