5.1.9.1 The Software Safety Plan(s) shall be developed per NASA-STD-8719.13, Software Safety Standard. [SWE-138] NPR 7150.2, NASA Software Engineering Requirements, does not include any specific notes for this requirement. This requirement applies to all classes and safety criticalities, including Safety Critical Classes F through H, with exceptions noted in the following table: 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 NASA-STD-8719.13 271 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." 271 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. 271 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 271 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: *The provider SMA verifies that the following items are included in the provider's SSP:* 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. 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. 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. 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." 568
See edit history of this section
Post feedback on this section
1. Requirements
1.1 Notes
1.2 Applicability Across Classes
X - Applicable with details, read above for more | P(C) - P(Center), follow center requirements or procedures2. Rationale
3. Guidance
4. Small Projects
5. Resources
5.1 Tools
6. Lessons Learned
SWE-138 - Software Safety Plan Contents
Web Resources
View this section on the websiteUnknown macro: {page-info}
0 Comments