Book A.

Book B.
7150 Requirements Guidance

Book C.

References, & Terms

(NASA Only)

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.
Wiki Markup
{tabsetup:1. The Requirement|2. Rationale|3. Guidance|4. Small Projects|5. Resources|6. Lessons Learned}


h1. 1. Requirements The project, in conjunction with the Safety and Mission Assurance organization, shall determine the software safety criticality in accordance with NASA-STD-8739.8.

h2. {color:#003366}{*}1.1 Notes{*}{color}

Software safety criticality is initially determined in the formulation phase using the NASA Software Safety Standard, NASA-STD-8719.13. As the software is developed or changed and the computer software configuration items (CSCI), models, and simulations are identified, the safety-critical software determination can be reassessed and applied at lower levels. The software safety assessment and planning are performed for each software acquisition, development, and maintenance activity, and for changes to legacy\heritage systems. When software in a system or subsystem is found to be safety critical, additional requirements in the NASA Software Safety Standard will augment those associated with the software class requirements found in this document. The software assurance organization is required by NASA Software Assurance Standard, NASA-STD-8739.8, to perform an independent software safety criticality assessment and work with the project to resolve any differences. Engineering and software assurance must reach agreement on safety-critical determination of software. Disagreements are elevated via both the Engineering Technical Authority and Safety and Mission Assurance Technical Authority chains.

h2. 1.2 Applicability Across Classes

Appendix D of NPR 7150.2A does not include any notes for this requirement.


h1. 2. Rationale

Each project, with the responsible Software Assurance organization, evaluates the project software to determine if the software is safety-critical.  If the software is determined to be safety-critical, the software safety requirements within this NPR and NASA-STD-8719.13 are applied to the safety critical project software.

h1. 3. Guidance

The NASA Software Safety Standard, NASA-STD-8719.13, requires the software safety criticality to be re-assessed periodically -- typically at each major milestone review---by the project's responsible software assurance engineer.  This individual evaluates the project software for determination of safety criticality utilizing the Software Safety Litmus Test within NASA-STD-8719.13.  This allows the software safety requirements to be refined and applied to the required areas (preventing a possibly costly over-application or a non-compliant and risky under application).  It also assures that requirements are met and/or changes to the software are addressed and checked for safety criticality.

The software safety critically assessment process and the location of the assessment results are documented within the Software Safety Plan (or equivalent).  Most projects document the software safety criticality with the software classification.  The project's system safety documentation also addresses it.

A best practice is to document the software safety criticality assessment results with the software classification assessment, with local S&MA and the Engineering Technical Authority both approving the results.  An [example form is provided in [NASA-STD-8719.13 NASA Software Safety Standard|].

h1. 4. Small Projects

This requirement does not have any special guidance relative to small projects.

h1. 5. Resources

# NASA Technical Standard, "[NASA Software Safety Standard|]", NASA-STD-8719.13B, 2004. Includes the Software Safety Litmus Test and an example form. 
# NASA Technical Standard, "[NASA Software Safety Guidebook|]", NASA-GB-8719.13, 2004.
# STEP Level 2 Overview of Software Safety course, SMA-SA-WBT-230, [SATERN|] (need user account to access SATERN courses).
# STEP Level 3 Software Safety for Practitioners course, SMA-SOFT-NSC-1005, [SATERN|] (need user account to access SATERN courses).


h2. 6. Lessons Learned

*Mars Global Surveyor (MGS) Spacecraft Loss of Contact.* *Lesson Number:* 1805.  Contact was lost with the Mars Global Surveyor (MGS) spacecraft in November 2006 during its 4th extended mission. A routine memory load command sent to an incorrect address 5 months earlier corrupted positioning parameters, and their subsequent activation placed MGS in an attitude that fatally overheated a battery and depleted spacecraft power. The report by the independent MGS Operations Review Board listed 10 key recommendations to strengthen operational procedures and processes, correct spacecraft design weaknesses, and assure that economies implemented late in the course of long-lived missions do not impose excessive risks.  []