bannera

Book A.
Introduction

Book B.
7150 Requirements Guidance

Book C.
Topics

Tools,
References, & Terms

SPAN
(NASA Only)

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 22 Next »

Error rendering macro 'alias'

null

SWE-133 - Software Safety Determination
Unknown macro: {div3}

1. Requirements

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

1.1 Notes">1.1 Notes

Software safety criticality is initially determined in the formulation phase using the NASA Software Assurance Standard, NASA-STD-8739.8. 278As 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 271 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, 278to 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.

1.2 Applicability Across Classes

Class

  A_SC 

A_NSC

  B_SC 

B_NSC

  C_SC 

C_NSC

  D_SC 

D_NSC

  E_SC 

E_NSC

     F      

     G      

     H      

Applicable?

   

   

   

   

   

   

   

   

   

   

   

   

   

Key:    A_SC = Class A Software, Safety Critical | A_NSC = Class A Software, Not Safety Critical | ... | - Applicable | - Not Applicable
X - Applicable with details, read above for more | P(C) - P(Center), follow center requirements or procedures

Unknown macro: {div3}

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 NPR 7150.2, NASA Software Engineering Requirements, and NASA-STD-8719.13, NASA Software Safety Standard, 271 are applied to the safety-critical project software.

Unknown macro: {div3}

3. Guidance

The project can use NASA-STD-8739.8 278to perform its determination of the software safety criticality. The software safety litmus test in Appendix A.1 of the Standard is applicable to all projects. The software is considered safety critical if it meets any of the three major criteria listed in the appendix. If the project is determined to be safety critical, then the project must adhere to the applicable statements in NASA-STD-8719.13.  271
As noted in NASA-STD-8719.13, 271non safety-critical software residing with safety-critical software is a concern because it may fail in a way that it disables or impairs the functioning of the safety-critical software. When methods to separate the code, such as partitioning, can't be used to limit the software defined as safety critical, care must be exercised to assure safety for a block of software (multiple CSCI) where only a portion are safety critical, and or for individual safety critical CSC's within a larger CSCI.

NASA-STD-8719.13 271requires 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. 271This 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 criticality 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 TA both approving the results.  An example form is provided in NASA-STD-8719.13. 271

Unknown macro: {div3}

4. Small Projects

No additional guidance is available for small projects. The community of practice is encouraged to submit guidance candidates for this paragraph.

Unknown macro: {div3}

5. Resources

5.1 Tools

Tools relative to this SWE may be found in the table below. You may wish to reference the Tools Table in this handbook for an evolving list of these and other tools in use at NASA. Note that this table should not be considered all-inclusive, nor is it an endorsement of any particular tool. Check with your Center to see what tools are available to facilitate compliance with this requirement.

No tools have been currently identified for this SWE. If you wish to suggest a tool, please leave a comment below.

Unknown macro: {div3}

6. Lessons Learned

A documented lesson from the NASA Lessons Learned database notes the following: 

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

  • No labels