9.01 Software Design Principles Making assumptions about the system state can lead to malfunctions. 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. 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. None Additional guidance related to this requirement may be found in the following materials in this Handbook: SPAN - Software Processes Across NASA See the following link(s) in SPAN for process assets from contributing Centers (NASA Only). The NASA Lesson Learned 439 database contains the following lessons learned related to toggle commands:
See edit history of this section
Post feedback on this section
1. Principle
1.1 Rationale
2. Examples and Discussion
2.1 Additional Guidance
3. Inputs
3.1 ARC
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
Rationale: To avoid needing to predict the s/c state that will exist at the time of command execution.3.4 MSFC
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
Related Links 4.3 Center Process Asset Libraries
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. https://nen.nasa.gov/web/software/wiki 197SPAN Links 5. Lessons Learned
5.1 NASA Lessons Learned
9.17 Toggle Commands
Web Resources
View this section on the websiteUnknown macro: {page-info}