1. Principle

1.1 Rationale

Assuming preconditions and post-conditions are met can lead to hazardous situations and system malfunction.

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.

3. Inputs

3.1 ARC

None

3.2 GSFC

None

3.3 JPL

None

3.4 MSFC

None

4. Resources

4.1 References

• (SWEREF-439)
  NASA Public Lessons Learned System
  The NASA Lessons Learned system. The system provides access to official, reviewed lessons learned from NASA programs and projects.
• (SWEREF-530)
  MPL Uplink Loss Timer Software/Test Errors (1998)
  Public Lessons Learned Entry: 939.

5. Lessons Learned

5.1 NASA Lessons Learned

The NASA Lesson Learned  ⁴³⁹  database contains the following lessons learned related to safe transitions:

• MPL Uplink Loss Timer Software/Test Errors (1998)  Lesson Learned 0939:  ⁵³⁰ "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."