9.15 Safe Transitions

2. Examples and Discussion

When a system transitions from one state to another, the hardware configuration may change, software controls may be enabled or disabled, or both. For example, a transition from test mode to launch mode may enable the system to execute commands to power on transmitters, fire pyrotechnic devices, deploy mechanisms, and other potentially hazardous operations. When the system transitions back to test mode, commands to execute them can be inadvertently processed, and harm to personnel and equipment can ensue if these operations are not completely disabled. Unverified assumptions about system state can threaten mission success.

Useful development practice is to itemize the desired/required state of all aspects of the system at each state transition, and then ensure that all items on the list are implemented and verified. Desired/required states can be asserted by explicit command, or where this is not safe or practical, by verifying via other telemetry (e.g., a valve position might be verified by downstream pressure). Where additional safeguards are required or desired, another design option to consider would be to enforce a man-in-the-loop checkpoint that requires manual operator intervention before a system can transition to a potentially hazardous state.

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


3.2 GSFC


3.3 JPL


3.4 MSFC


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 safe transitions:

  • MPL Uplink Loss Timer Software/Test Errors (1998)  Lesson Learned 0939:  530 "Prelaunch tests and verification of software and hardware used to switch to a redundant string should include assumed failures in either string during all mission phases. MPL did not verify the ability of the Lander to switch to the redundant uplink string after landing assuming a failure in the primary string had occurred during earlier entry, descent, and landing phases. Recognize that transitions to another mission phase are high-risk sequences and that database changes that impact logic decisions should be retested."

  • No labels