1. Requirements

5.1.9.1 The Software Safety Plan(s) shall be developed per NASA-STD-8719.13, Software Safety Standard. [SWE-138]

1.1 Notes

NPR 7150.2, NASA Software Engineering Requirements, does not include any specific notes for this requirement.

1.2 Applicability Across Classes

This requirement applies to all classes and safety criticalities, including Safety Critical Classes F through H, with exceptions noted in the following table:

2. Rationale

NASA-STD-8719.13 ²⁷¹ provides a common framework for consistent practices across NASA programs.  It contains requirements for safety-critical software that pertain to the planning activities and provides the rationale applied to this SWE. 

"The reason for a software safety plan is to document the how, why, where and when of software safety for a project.  Software safety is a complex set of processes and interactions. There are many changes from project to project, facility to facility, about who is responsible for the analyses, who is responsible for documenting hazards and their controls and mitigations, how those hazards are documented, who reviews the hazard analyses and tracks them to completion, what type of safety reviews and when they are to be scheduled, and more.  Planning is necessary to meet the NASA Software Safety Standard.  This planning is documented in the Software Safety Plan.  This allows all stakeholders to understand and agree upon what processes are needed, what deliverables are needed and when and where they are delivered, as well as the interactions with systems safety, engineering, Safety and Mission Assurance, and project/facility management. 

"This Standard was developed by the NASA Office of Safety and Mission Assurance to provide the requirements for software safety across all NASA Centers, programs and facilities. It describes the activities necessary to ensure that safety is designed into the software that is acquired or developed by NASA.  The magnitude and depth of software safety activities typically reflect the risk posed by the software while fulfilling the requirements of the Software Safety Standard.

"The NASA Software Safety Standard specifies the software safety activities, data, and documentation necessary for the acquisition or development of software in a safety-critical system. Safety-critical systems that include software must be evaluated for software's contribution to the safety of the system during the concept phase, and prior to the start, or in the early phases, of the acquisition or planning for the given software. Typically, Class F through H software is not considered safety critical; however, a piece of non-engineering software (Class F through H) could have a safety critical nature to it. One example is an emergency notification system for natural disasters. In this example, if the software did not work it could result in loss of life or injury or significant impact to assets. For this reason, this requirement includes applicability for safety critical software Class F through H.

"The NASA Software Safety Standard provides requirements to implement a systematic approach to software safety as an integral part of the project's overall system safety program, software development, and software assurance processes. It describes the activities necessary to ensure that safety is designed into software that is acquired or developed by NASA and that safety is maintained throughout the software and system life cycle.

"While the requirements of the NASA Software Safety Standard cannot be tailored, the specific activities and depth of analyses needed to meet the requirements can and are to be tailored to the software safety risk. That is, while the requirements must be met, the implementation and approach to meeting these requirements may and will vary to reflect the system to which they are applied. Substantial differences may exist when the same software safety requirements are applied to dissimilar projects." ²⁷¹

3. Guidance

Based on the project's size and complexity, the Software Safety Plan (SSP) can be an independent document or part of another software document, such as a Software Assurance Plan (SAP), Software Development Plan (SDP), or Software Management Plan (SMP). The System Safety Project Plan is another example of where the software safety plan can be captured for small projects.

The format for an SSP is not mandated by NPR 7150.2 or NASA-STD-8719.13. ²⁷¹  It is recommended to check with the Center's Safety and Mission Assurance (SMA) office for possible format requirements. The SSP contents are defined in NASA-STD-8719.13.  This Standard ²⁷¹ also defines who approves/concurs on the SSP.

If a project transitions from non-safety-critical to safety-critical, the SSP needs to be created and include the past, the transition, and the forward plan for meeting software safety requirements.

The responsible software assurance engineer is a great asset in the development and maintenance of the SSP.  Because the SSP covers the life cycle of the project, it needs to be periodically evaluated as the project matures, to verify accuracy and continued implementation approaches. Typically, the evaluation is performed by the responsible software assurance engineer and the project at major milestone reviews.

The acquirer SSP includes:

1. Identification of relevant stakeholders (including SMA, system safety, and development organizations) with responsibilities and general information, including activities, resulting products, and schedules.
2. Time frame for initial software safety criticality assessment and re-evaluations throughout the life cycle.
3. Schedule of periodic evaluation of acquirer adherence to the acquirer SSP, based on milestones or, for larger long term projects, every 2 years at a minimum.
4. General software safety and any unique qualifications or training required.
5. Traceability matrix to NASA-STD-8719.13 showing the relationship between the acquirer's requirements of this Standard and the activities specified in the SSP. 
6. Acquirer SMA evaluation process for provider adherence to the provider SSP, e.g., traceability review, process audits.
7. Resources required to meet the acquirer SSP.
8. Performance of periodic assessment of the provider problem/change reporting system to ensure software safety issues and discrepancies are correctly identified, elevated, and tracked to closure.
9. The interrelationships and external agreements among organizations and disciplines, including configuration management, system safety, software safety, software assurance, and software engineering.
10. Methodology for configuration management and problem reporting to ensure that software safety issues and discrepancies are correctly identified, analyzed, elevated, and tracked to closure.
11. Software safety approaches for commercial off-the-shelf (COTS), reused software, and complex electronic devices.
12. Software safety approaches during maintenance, operations, and retirement.
13. Procedures for ensuring prompt followup and satisfactory resolution of software safety concerns and recommendations.

*The provider SMA verifies that the following items are included in the provider's SSP:*

1. Designation of responsible organization implementing the provider software safety requirements (process and technical) and the provider SMA requirements. These can be different organizations or a shared responsibility where one organization addresses the process safety requirements and SMA requirements while another organization addresses the technical safety requirements.
2. Relevant stakeholders (including acquirer and acquirer SMA, system safety, and development organizations) with responsibilities and general information, including activities, resulting products, and schedules.
3. Definition of risk levels and assumptions.
4. The interrelationships and external agreements among organizations and disciplines, including configuration management, system safety, software safety, software assurance, and software engineering.
5. Methodology for configuration management and problem reporting to ensure that software safety issues and discrepancies are correctly identified, analyzed, elevated, and tracked to closure.
6. Software safety approaches for COTS, reused software, and complex electronic devices.
7. Software safety approaches during maintenance, operations, and retirement.

8. Procedures for ensuring prompt followup and satisfactory resolution of software safety concerns and recommendations.

     As the program/project/facility matures, the software classification, safety criticality, and risk may change or shift according to design. The SSP will need to be updated to reflect the changes.

9. General software safety and any unique qualifications or training required for or about the specific system and operational environment.
10. Schedule of periodic provider software safety evaluations/reviews addressing software in safety-critical system functions.  Minimum evaluations/reviews performed at major milestone reviews. For small projects, software Classes D and E, e.g., experiments, this item may be performed at concept, design, and before acceptance or any test runs.
11. List of software safety deliverables.
12. Problem/change reporting, evaluation, and tracking system utilized by provider SMA to ensure that the software safety issues and discrepancies are correctly identified, analyzed, elevated, and tracked to closure.  
13. Relative schedule of periodic SMA assessments to verify the validity and execution of the SSP throughout the entire software life cycle. At a minimum, this will be performed by the provider with results available to the acquirer at each major milestone review, before delivery, and before retirement.  Facilities will need to assess the projects that use them during proposal and before usage.
14. Traceability/compliance matrix for NASA-STD-8719.13 showing the relationship between requirements NASA-STD-8719.13 and the activities specified in the SSP.
15. Documentation of the resource requirements and the allocation of those resources to software safety tasks.

4. Small Projects

For small projects, the safety plan may be part of another plan such as the SAP, SDP, or SMP. While the requirements of NASA-STD-8719.13 can only be tailored out via the SMA Technical Authority, the specific activities and depth of analyses needed to meet the requirements can be tuned to meet the software safety risk.

5. Resources

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

6. Lessons Learned

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

Erroneous Onboard Status Reporting Disabled IMAGE's Radio. Lesson Number 1799: "The loss of the IMAGE satellite was attributed to a Single Event Upset-induced "instant trip" of the Solid State Power Controller (SSPC) that supplies power to the single-string Transponder. The circuit breaker was not reset because this hybrid device incorrectly reported the circuit breaker as closed, and ground could not command a reset because the satellite's single telemetry receiver had been disabled by the SSPC. The SSPC's problematic state reporting characteristic was an intentional design feature that was not reflected in any part documentation, and three similar "instant trips" on other NASA satellites had not been reported in the GIDEP (Government-Industry Data Exchange Program) system. Consider hardwiring receiver power to the power bus, or build redundancy into the power switching or into the operational status sensing. Ensure that GIDEP reports or NASA Alerts are written and routed to mission operations (as well as to hardware developers), and that flight software responds to command loss with a set of timed spacecraft-level fault responses." ⁵⁶⁸