 |
| Purchase Information |
| Use this form to request purchase information on NASA online subscriptions. |
|
|
Document NASA NASA-STD-8719.13 is offered by IHS as part of an online subscription. This subscription contains many documents on the same topic.
You may also purchase this document alone from the IHS Standards Store.
NASA NASA-STD-8719.13 Document Information:
Title
SOFTWARE SAFETY STANDARD WITH CHANGE 1 DATED 07/28/2004
NASA - National Aeronautics and Space Administration
Publication Date:
Jul 8, 2004
Scope:
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.
About IHS
IHS (NYSE: IHS) is a leading global provider of critical technical information, decision-support tools and related services in a number of industries including aerospace and defense, automotive, construction, electronics, and energy. IHS serves customers ranging from large governments and multinational corporations to smaller companies and technical professionals in more than 100 countries. IHS been in business for more than 45 years and employ more than 2,300 people around the world.
