04-05-2012, 01:14 PM
Software System Safety Handbook
Software_System_Safety_Handbook.pdf (Size: 2.15 MB / Downloads: 57)
Introduction
All members of the system development team should read section 2 of the Software System
Safety Handbook (SSSH). This section discusses the following major subjects:
• The major purpose for writing this Handbook
• The scope of the subject matter that this Handbook will present
• The authority by which a SSS program is conducted
• How this Handbook is organized and the best procedure for you to use, to gain its full
benefit.
As a member of the software development team, the safety engineer is critical in the design, and
redesign, of modern systems. Whether a hardware engineer, software engineer, “safety
specialist,” or safety manager, it is his/her responsibility to ensure that an acceptable level of
safety is achieved and maintained throughout the life cycle of the system(s) being developed.
This Handbook provides a rigorous and pragmatic application of SSS planning and analysis to be
used by the safety engineer.
SSS, an element of the total system safety and software development program, cannot function
independently of the total effort. Nor can it be ignored. Systems, both “simple” and highly
integrated multiple subsystems, are experiencing an extraordinary growth in the use of computers
and software to monitor and/or control safety-critical subsystems and functions. A software
specification error, design flaw, or the lack of initial safety requirements can contribute to or
cause a system failure or erroneous human decision. Preventable death, injury, loss of the
system, or environmental damage can result. To achieve an acceptable level of safety for
software used in critical applications, software safety engineering must be given primary
emphasis early in the requirements definition and system conceptual design process. Safetycritical
software must then receive a continuous emphasis from management as well as a
continuing engineering analysis throughout the development and operational life cycles of the
system.
This SSSH is a joint effort. The U.S. Army, Navy, Air Force, and Coast Guard Safety Centers,
with cooperation from the Federal Aviation Administration (FAA), National Aeronautics and
Space Administration (NASA), defense industry contractors, and academia are the primary
contributors. This extensive research captures the “best practices” pertaining to SSS program
management and safety-critical software design. The Handbook consolidates these contributions
into a single, user-friendly resource. It aids the system development team in understanding their
SSS responsibilities. By using this Handbook, the user will appreciate the need for all disciplines
to work together in identifying, controlling, and managing software-related hazards within the
safety-critical components of hardware systems.
Software System Safety Handbook
Introduction to the Handbook
To summarize, this Handbook is a “how-to” guide for use in the understanding of SSS and the
contribution of each functional discipline to the overall goal. It is applicable to all types of
systems (military and commercial), in all types of operational uses.
Purpose
The purpose of the SSSH is to provide management and engineering guidelines to achieve a
reasonable level of assurance that the software will execute within the system context with an
acceptable level of safety risk1.
Scope
This Handbook is both a reference document and management tool for aiding managers and
engineers at all levels, in any government or industrial organization. It demonstrates “how to” in
the development and implementation of an effective SSS process. This process minimizes the
likelihood or severity of system hazards caused by poorly specified, designed, developed, or
operation of software in safety-critical applications.
The primary responsibility for management of the SSS process lies with the system safety
manager/engineer in both the developer’s (supplier) and acquirer’s (customer) organization.
However, nearly every functional discipline has a vital role and must be intimately involved in
the SSS process. The SSS tasks, techniques, and processes outlined in this Handbook are basic
enough to be applied to any system that uses software in critical areas. It serves the need for all
contributing disciplines to understand and apply qualitative and quantitative analysis techniques
to ensure the safety of hardware systems controlled by software.
This Handbook is a guide and is not intended to supersede any Agency policy, standard, or
guidance pertaining to system safety (MIL-STD-882C) or software engineering and development
(MIL-STD-498). It is written to clarify the SSS requirements and tasks specified in
governmental and commercial standards and guideline documents. The Handbook is not a
compliance document but a reference document. It provides the system safety manager and the
software development manager with sufficient information to perform the following:
• Properly scope the SSS effort in the Statement of Work (SOW),
• Identify the data items needed to effectively monitor the contractor’s compliance with the
contract system safety requirements, and
• Evaluate contractor performance throughout the development life cycle.
The Handbook is not a tutorial on software engineering. However, it does address some
technical aspects of software function and design to assist with understanding software safety. It
is an objective of this Handbook to provide each member of the SSS Team with a basic
understanding of sound systems and software safety practices, processes, and techniques.
1 The stated purpose of this Handbook closely resembles Nancy Leveson’s definition of Software
System Safety. The authors would like to provide the appropriate credit for her implicit
contribution.
Software System Safety Handbook
Introduction to the Handbook
Another objective is to demonstrate the importance of each technical and managerial discipline to
work hand-in-hand in defining software safety requirements (SSR) for the safety-critical software
components of the system. A final objective is to show where safety features can be designed
into the software to eliminate or control identified hazards.
Authority/Standards
Numerous directives, standards, regulations, and regulatory guides establish the authority for
system safety engineering requirements in the acquisition, development, and maintenance of
software-based systems. Although the primary focus of this Handbook is targeted toward
military systems, much of the authority for the establishment of Department of Defense (DOD)
system safety, and software safety programs, is derived from other governmental and commercial
standards and guidance. We have documented many of these authoritative standards and
guidelines within this Handbook. First, to establish their existence; second, to demonstrate the
seriousness that the government places on the reduction of safety risk for software performing
safety-critical functions; and finally, to consolidate in one place all authoritative documentation.
This allows a PM, safety manager, or safety engineer to clearly demonstrate the mandated
requirement and need for a software safety program to their superiors.
Department of Defense
Within the DOD and the acquisition corps of each branch of military service, the primary
documents of interest pertaining to system safety and software development include DOD
Instruction 5000.1, Defense Acquisition; DOD 5000.2R, Mandatory Procedures for Major
Defense Acquisition Programs (MDAPs) and Major Automated Information System (MAIS)
Acquisition Programs; MIL-STD-498, Software Development and Documentation; and MILSTD-
882D, Standard Practice for System Safety. The authority of the acquisition professional to
establish a software safety program is provided in the following paragraphs. These paragraphs
are quoted or summarized from various DOD directives and military standards. They clearly
define the mandated requirement for all DOD systems acquisition and development programs to
incorporate safety requirements and analysis into the design, development, testing, and support of
software being used to perform or control critical system functions. The DOD documents also
levy the authority and responsibility for establishing and managing an effective software safety
program to the highest level of program authority.
DODD 5000.1
DODD 5000.1, Defense Acquisition, March 15, 1996; Paragraph D.1.d, establishes the
requirement and need for an aggressive risk management program for acquiring quality products.
d. Risk Assessment and Management. PMs and other acquisition managers shall
continually assess program risks. Risks must be well understood, and risk management
approaches developed, before decision authorities can authorize a program to proceed
into the next phase of the acquisition process. To assess and manage risk, PMs and other
acquisition managers shall use a variety of techniques, including technology
demonstrations, prototyping, and test and evaluation.