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

Compare with Current View Page History

« Previous Version 7 Next »

Copy of 8.20 - Safety Specific Activities in Each Phase

1. Safety Specific Activities in Each Phase 

This topic provides a summary of the safety-specific activities that should be performed for any safety-critical software. The activities are grouped into the approximate life cycle phases where they will be performed. 

All Phases: 

  • Ensure that software safety is considered throughout the system life-cycle, including mission concept, generation of requirements, design, coding, test, maintenance, and operation of the software.
  • Develop and maintain a software safety analysis throughout the life cycle.
  • Participate in software reviews affecting safety-critical software products.
  • Confirm that the identified safety-critical software components and data have implemented the safety-critical software assurance requirements listed in the standard, NASA-STD-8739.8 278
  • Review all safety-related technical issues, risks, and/or assurance findings and ensure that the project is aware of any items needing attention and is addressing them.
  • All safety-critical items (e.g. requirements, design, code, test plans, test procedures, hazard reports, data uploads, documentation, etc.) should be kept under configuration management.  Safety personnel need to verify that their safety products are in the configuration management system and they should ensure that they are using the correct versions of the products.

Concept Phase:

  • The first safety analysis is performed during system concept and beginning requirements phase. A common assessment tool used during this beginning activity is the Preliminary Hazard Analysis (PHA). The results of the PHA are a list of hazard causes and a set of candidate hazard controls, that are taken forward as inputs to the system and software safety requirements flow-down process.
  • Review the lists of known software-based hazards, hazard contributions and hazard controls to determine whether any of these might be applicable for this project.
  • Review the project’s Concept Development and any available Operational Concept information to become aware of any potential security threats and risks that may affect safety. Assure that mitigations are being planned for these.
  • Software Safety personnel should develop a good working relationship with any IV&V team on the project to provide more focus any safety-related issues on the project. 


  • Ensure that software safety is addressed in project acquisition, planning, management, and control activities.
  • Ensure that the acquisition of software, whether off-the-shelf or contracted, includes evaluation, assessment, and planning for addressing and mitigating risks due to the software’s contribution to safety and any limitations of the software.
  • The Engineering Technical Authority and S&MA Technical Authority will jointly determine if the software is designated as “safety-critical”. See criteria in NASA-STD-8739.8A,  278 Appendix A.
  • Software Safety personnel need to develop a Safety Plan, including safety activities, requirements, effort estimates and schedule. The Safety Plan may be part of the Software Assurance Plan.
    • Additional planning activities may need to be done whenever heritage, reused or COTS software are planned for use, for example:
      • Hazard analysis may need to be done for this software.
      • Additional analysis, testing, and verification may need to be done, depending on the documentation and other information available with the COTS, reused, heritage code.
      • Additional functionality may need to be added; Unused functions may need to be removed.

See Topic  8.8 - COTS Software Safety Considerations in this Handbook for more information on using COTS.


  • Usually, the initial project specific safety requirements are derived from:
    • the identified regulatory and standard safety requirements and
    • the available specific system information and the initial analysis done (probably the PHA) 
  • Assess that hazard analyses (including hazard reports) identify the software components associated with the system hazards per the criteria defined in NASA-STD- 8739.8,   278  Appendix A:
    • Consider functions of software that cause, control mitigate or contribute to hazard.
    • Provides control or mitigation for a system hazardous condition/event,
    • Controls safety-critical functions,
    • Mitigates damage if a hazardous condition/event occurs,
    • Detects, reports, and takes corrective action, if the system reaches a potentially hazardous state.

Note:  Software is classified as safety-critical if the software is determined by and traceable to hazard analysis. See appendix A for guidelines associated with addressing software in hazard definitions. See SWE-205. Consideration for other independent means of protection (software, hardware, barriers, or administrative) should be a part of the system hazard definition process. 

  • System hazard controls should be traceable to system requirements. 
  • If controls identified by the PHA are not in the system specification, safety requirements to control the hazards should be added to that document. 
  • Assure that the software specification derived from the system specification will include these necessary safety requirements.
  • Assure that at least one software requirement is generated for each software hazard control. Each of these requirements is incorporated into the Software Requirements Specification (SRS) as a safety-critical software requirement.
  • Assure that the requirements include acceptable mitigations for any safety-related security threats or risks and that any regulatory security requirements that may affect system/software safety are included in the requirements.
  • Confirm software (safety) requirements are bi-directionally traced to system hazards. 
  • Analyze that the software requirements documentation contains the software related safety constraints, controls, mitigations, and assumptions between the hardware, operator, and the software.
  • Analyze the software requirements and the software design and work with the project to implement NPR 7150.2, SWE-134 requirement items "a" through "l."

SWE-134 - Safety Critical Software Design Requirements
3.7.3 If a project has safety-critical software or mission-critical software, the project manager shall implement the following items in the software:

a. The software is initialized, at first start and restarts, to a known safe state.

b. The software safely transitions between all predefined known states.

c. Termination performed by the software functions is performed to a known safe state.

d. Operator overrides of software functions require at least two independent actions by an operator.

e. The software rejects commands received out of sequence when the execution of those commands out of sequence can cause a hazard.

f. The software detects inadvertent memory modification and recovers to a known safe state.

g. The software performs integrity checks on inputs and outputs to/from the software system.

h. The software performs prerequisite checks prior to the execution of safety-critical software commands.

i. No single software event or action is allowed to initiate an identified hazard.

j. The software responds to an off-nominal condition within the time needed to prevent a hazardous event.

k. The software provides error handling.    

l. The software can place the system into a safe state.

  • Perform (or review) the requirements analysis portion of the safety analysis and assure that any findings or issues are closed out.
  • Review the interface documentation for consistency and completeness and identify any potential vulnerabilities that may affect system/software safety. Consider interfaces with other software components, with hardware, or with human operators. Interface characteristics to be addressed should include inter-process communication methods, data encoding, error checking, synchronization, fault management, cybersecurity considerations, input validation, and issues with hardware startup (initialization).

2. Resources

2.1 References

No references have been currently identified for this Topic. If you wish to suggest a reference, please leave a comment below.

2.2 Tools

Tools to aid in compliance with this SWE, if any, may be found in the Tools Library in the NASA Engineering Network (NEN). 

NASA users find this in the Tools Library in the Software Processes Across NASA (SPAN) site of the Software Engineering Community in NEN. 

The list is informational only and does not represent an “approved tool list”, nor does it represent an endorsement of any particular tool.  The purpose is to provide examples of tools being used across the Agency and to help projects and centers decide what tools to consider.

  • No labels