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.

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  in the Resources tab.

3. Inputs

3.1 ARC

None

3.2 GSFC

None

3.3 JPL

None

3.4 MSFC

None

4. Resources

4.1 References

Enter necessary modifications to be made in the table below: SWEREFs to be added SWEREFS to be deleted SWEREFs called out in text: 439, 530 SWEREFs NOT called out in text but listed as germane: NONE Related Links Pages Refstable Topic

4.2 Additional Guidance

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

4.3 Center Process Asset Libraries

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

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."