1. Minimum Recommended Content

  The Software Safety Plan(s) shall be developed per NASA-STD-8719.13, Software Safety Standard.            

2. Rationale

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

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 developing a software safety plan.

"The purpose of this Standard is to define the requirements to implement a systematic approach to software safety as an integral part of system safety and the overall safety program of a program, project, or facility. This Standard specifies the software activities, data, and documentation necessary for the acquisition and development of software in a safety critical system. These activities may be performed by a collaboration of various personnel in the program, project, or facility, and Safety and Mission Assurance (SMA) organizations. Safety critical systems that include software are evaluated for software’s contribution to the safety of the system during the concept phase, and repeated at each major milestone as the design matures.

This Standard describes the activities required to ensure and promote safety processes that are utilized for software that is created, acquired, or maintained by or for NASA. The NASA-GB-8719.13, NASA Software Safety Guidebook, provides additional information on acceptable approaches for implementing software safety. While the requirements of this Standard must be met, the implementation and approach to meeting these requirements will vary to reflect the system to which they are applied." ²⁷¹

3. Guidance

Software engineering and the software safety disciplines jointly are responsible for providing project management with the optimal solution for software to meet the engineering, safety, quality, and reliability needs of the project. The project team creates the Software Safety Plan (SSP) to define the processes, risks, resources, stakeholders, interfaces, and safety design methodologies, necessary for the development of the software.

Effective planning assures that adequate safety features are included within the system and software. Developing a plan early in the project ensures that software safety will be an integral part of the software development or acquisition process.

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.

Based on the project's size and complexity, the 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 Software Safety Plan (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. See Topic 7.08 - Maturity of Life-Cycle Products at Milestone Reviews to determine the state of maturity of the Software Safety Plan at the various 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. “Timeframe for initial SSCA [software safety criticality assessment] and re-evaluations throughout the life cycle...
3. “Schedule of periodic evaluation and reporting of acquirer adherence to the acquirer software safety plan (based on phase, milestones, or, for larger long term projects, every two years at a minimum).
4. “General software safety and any unique qualifications or training required.
5. “Traceability matrix to for the requirements of ... [NASA-STD-8719.13] showing the relationship between the acquirer's requirements of ... [NASA-STD-8719.13] and the activities specified in the software safety plan.
6. “Acquirer Safety and Mission Assurance (SMA) evaluation process for provider adherence to the provider software safety plan (e.g., traceability review, process audits, etc.).
7. “Resources required to meet the acquirer software safety plan, resources to actually be applied, and resulting reasoning, including indication of any waivers or deviations.
8. “Performance of periodic assessment of the provider problem or change reporting system to ensure software safety issues and discrepancies are correctly identified, elevated, and tracked to closure.
9. “Process and participation responsibilities in system and facility safety reviews and any specific software safety reviews. This may be in a system or facility safety plan.
10. “Acquirer safety analysis approach (including methods for identifying hazards, conditions, and events, assessing risks, implementing controls, and verifying and validating risk reduction) and how the analysis fit in with the overall acquirer system safety analysis, airworthiness flight safety, or flight readiness approach; list of acquirer software safety deliverables.” ²⁷¹
11. The interrelationships and external agreements among organizations and disciplines, including configuration management, system safety, software safety, software assurance, and software engineering.
12. Methodology for configuration management and problem reporting to ensure that software safety issues and discrepancies are correctly identified, analyzed, elevated, and tracked to closure.
13. Software safety approaches for commercial off-the-shelf (COTS), reused software, and complex electronic devices.
14. Software safety approaches during maintenance, operations, and retirement.
15. Procedures for ensuring prompt follow-up 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 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. “Software classification (as per NPR 7150.2) and safety criticality ...This includes documenting risk level, requirements applicability per Appendix A, and assumptions...
4. “General software safety training and any unique qualifications or training required for or about the specific system and operational environment.
5. “Schedule of periodic provider program, project, or facility evaluations and reviews and software safety evaluations and reviews addressing software in safety critical system functions...
6. “Safety analysis approach (including methods for identifying hazards, conditions, and events, assessing risks, implementing controls, and verifying and validating risk reduction) and how the analysis fit in with the overall system safety analysis approach; list of software safety deliverables...
7. “Problem and 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.
8. “Relative schedule of periodic SMA assessments to ensure the validity and execution of the provider’s software safety plan throughout the entire software life cycle...
9. “Traceability and compliance matrix showing the relationship between requirements of ... [NASA-STD-8719.13] and the activities specified in the provider’s software safety plan.
10. “Documentation of the resource requirements and the allocation of those resources to software safety tasks.” ²⁷¹
11. Definition of risk levels and assumptions.
12. The interrelationships and external agreements among organizations and disciplines, including configuration management, system safety, software safety, software assurance, and software engineering.
13. Methodology for configuration management and problem reporting to ensure that software safety issues and discrepancies are correctly identified, analyzed, elevated, and tracked to closure.
14. Software safety approaches for COTS, reused software, and complex electronic devices.
15. Software safety approaches during maintenance, operations, and retirement.
16. Procedures for ensuring prompt follow-up and satisfactory resolution of software safety concerns and recommendations. 

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

 6. Lessons Learned

• 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 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." ⁵⁶⁸