Purpose

This 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. Unless the evaluation proves that the software is not involved in the system safety, this Standard is to be followed. See section 1.2 for guidance, and section 4.1 for requirements (and definition), on the determination of safety-critical software.

The purpose of this Standard is to provide 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. How these requirements are met will vary with the program, project, facility, Mission, and Center. The NASA-GB-8719.13, Software Safety Guidebook, provides additional information on how to implement software safety and software safety related activities in a manner consistent with the software's role in system safety. The risk posed by safety-critical software will vary with the system safety criticality (e.g., type of hazard) and the level of control or influence the software has on system safety factors. While the requirements of this Standard cannot be tailored, the specific activities and depth of analyses needed to meet the requirements can, and should, 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 should 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. Appendix A shows how an example medium-sized project might meet the requirements of this Standard. A compliance matrix listing all of the requirements in this Standard along with the personnel roles and responsibilities required for each requirement, is available in Appendix B. This matrix can used by the program, project, or facility as a checklist to ensure coverage of all requirements in the Standard

There are two kinds of safety requirements: process oriented and technical. Both need to be addressed and properly documented within a program, project, or facility. This Standard contains process oriented requirement (what needs to be done to ensure software safety). Technical requirements are those that specify what the system must include or implement (e.g., two-fault tolerance). Use of this Standard does not preclude the necessity to follow applicable technical standards.

Software safety activities occur within the context of system safety, system development, and software development and assurance. In an ideal system environment, information flows freely among all elements of the program/project, and concerns are appropriately addressed. Providing the needed information to the concerned parties in a timely manner is key to any successful exchange.

The requirements specified in this Standard will:

• Identify when software plays a part in system safety and generate appropriate requirements to ensure safe operation of the system.

• Ensure that software is considered within the context of system safety, and that appropriate measures are taken to create safe software.

• Ensure that software safety is addressed in project planning, management, and control activities.

• Ensure that software safety is considered throughout the system life cycle, including generation of requirements, design, coding, test, and operation of the software.

• Ensure that software acquisitions, whether off-the-shelf or contracted, have evaluated, assessed, and addressed the software for its safety contributions and limitations.

• Ensure that software verification activities include software safety verifications.

• Ensure that proper certification requirements are in place and accomplished prior to the actual operational use of the software.

• During operational use of the software, ensure that all changes and reconfigurations of the software are analyzed for their impacts to system safety.

Applicability

This Standard applies to all safety-critical software acquired or developed by NASA. Section 4.1 (and section 3, Glossary) defines what software is considered safety-critical. Section 4.1 also details the "litmus test" that all projects must apply to their software, to determine if it is safety-critical and therefore subject to this Standard.

The NPR 8715.3 NASA Safety Manual specifies the methodology for determining whether a system is safety-critical. This software safety standard further defines whether the software in a safety-critical system is also safety-critical.

This Standard applies to software that resides in hardware (i.e., firmware). This Standard also applies to government furnished software, purchased software (including commercial-off-the-shelf (COTS) software), and any other reused software when included in a safety-critical NASA system. Safety-critical software can be found in all types of systems, including Flight, Ground Support, and Facilities.

If the system is already in development or is a legacy system, then the software within the system should be assessed for its contribution to the safety of the system. If the software is found to be safety-critical, a plan should be worked out with the safety personnel on how the system will or will not meet the requirements in this Standard. Legacy systems will be addressed on a case-by-case basic and the decisions should be documented. Systems in the maintenance and operation phase should at least have the safety requirements marked during the routine maintenance cycle.

In addition, COTS software cannot be ignored in safety-critical systems. The COTS software should be assessed before use and verified within the system it is contained to ensure the COTS cannot do something inadvertent to cause a hazard (see NASA-GB-8719.13 NASA Software Safety Guidebook).

A key factor to keep in mind when determining the applicability of this Standard is that the presence of non-software hazard controls or mitigations (e.g., operator intervention, hardware overrides) reduces, but does not normally eliminate, the software safety risk. Hence, the need for applying this Standard is not removed. The NASA Software Safety Guidebook, NASA-GB-8719.13, should be used to create a set of activities and analyses tailored to meet the requirements of this Standard.

This Standard does not discourage the use of software in safety-critical systems. When designed and implemented correctly, software is often the first, and sometimes the best, hazard detection and prevention mechanism in the system. Software can be used to prevent problems before they lead to hazardous conditions. This Standard provides requirements that will ensure that the safety-critical software receives the required levels of attention throughout the project life cycle.