NASA Procedures and Guidelines
This Document is Obsolete and Is No Longer Used. Check the NODIS Library to access the current version: http://nodis3.gsfc.nasa.gov
NPR 8715.3 Eff. Date: January 24, 2000 Cancellation Date: September 12, 2006	NASA Safety Manual w/Change 2, 03/31/04
| TOC | Change | Preface | Chapter1 | Chapter2 | Chapter3 | Chapter4 | Chapter5 | Chapter6 | Chapter7 | Chapter8 | Chapter9 | AppendixA | AppendixB | AppendixC | AppendixD | AppendixE | AppendixF | AppendixG | AppendixH | AppendixI | AppendixJ | AppendixK | ALL |

APPENDIX D: Analysis Techniques

The purpose of safety analysis is to provide a means to systematically and objectively identify hazards, determine their risk level, and provide the mechanism for their elimination or control. Safety analysis is an iterative process that begins with the concept and extends throughout the life cycle including disposal.

1. Functions supported by the analysis include the following:

a. Providing the foundation for the development of safety criteria and requirements.

b. Determining whether and how the safety criteria and requirements provided to engineering have been included in the design.

c. Determining whether the safety criteria and requirements created for design and operations have provided an acceptable level of risk for the system.

d. Providing part of the means for imposing pre-established safety goals.

e. Providing a means for demonstrating that safety goals have been met.

The extent and depth of analysis required to meet these five functions will be determined by system complexity and loss potential.

2. During the hazard identification process, it is essential to remain nonjudgmental about the associated probability, severity, and corrective actions. Once identified, hazards shall then be ranked by severity, probability of occurrence, and program impact (risk assessment). Sufficient analysis must be performed to assess the likelihood of occurrence (usually qualitative for early assessments) for each identified undesired event.

3. There are several types of analyses necessary to identify all the hazards; some are specialized and others, as designs mature, build on previously accomplished analyses.

4. Analyses such as the ones described below shall be employed to the extent and depth determined by the system safety manager as necessary to fully assess the risk to personnel, equipment, and property.

a. Preliminary Hazard Analysis (PHA). In many ways the PHA is the most important of the safety analyses because it is the foundation on which the rest of the safety analyses and the system safety tasks are built. It documents which generic hazards are associated with the design and operational concept. This provides the initial framework for a master listing (or hazard catalog) of hazards and associated risks that require tracking and resolution during the course of the program design and development. The PHA also may be used to identify safety-critical systems that will require the application of failure modes and effects analysis and further hazard analysis during the design phases.

b. The program shall require and document a PHA to obtain an initial listing of risk factors for a system concept. The PHA effort shall be started during the concept exploration phase or earliest life cycle phases of the program. A PHA considers hardware, software, and the operational concepts. Hazards identified in the PHA will be assessed for risk based on the best available data, including mishap data from similar systems, other lessons learned, and hazards associated with the proposed design or function. Mishap and lessons learned information are available in the Incident Reporting Information System (IRIS) and the Lessons Learned Information System (LLIS). The risk assessment developed from the PHA will be used to ensure safety considerations are included in tradeoff studies of design alternatives; development of safety requirements for program and design specifications, including software for safety-critical monitor and control; and definition of operational conditions and constraints.

c. Extensions and refinements of the PHA should coincide with the development of the design after the conceptual phase. A system generally consists of several discrete subsystems that should be individually analyzed in subsystem hazard analysis (SSHA). The results of the SSHA`s in turn feed into the SHA, which will integrate its subsystems and identify hazards that cross the subsystem interfaces. The number of systems and subsystems in a program is a function of the complexity of individual projects and will be determined by the program. In relatively simple programs, the SHA may also serve as the integrated hazard analysis (IHA) if it also addresses risks. The hazard listing in the safety assessment report (SAR) must be updated to indicate the closure of hazards and newly identified hazards. The SHA should be completed coincidentally with the critical design review (CDR).

d. Operating and Support Hazard Analysis (O&SHA). The O&SHA is performed primarily to identify and evaluate the hazards associated with the use of environment, personnel interface, procedures including automated command and control, and supporting facilities/equipment involved in the operation of a system/element. "Operation" for the purposes of this appendix may include, but is not limited to, activities such as testing, installation, maintenance, transportation, contingency operations, and others. This analysis considers the planned system configuration or state at each phase of activity, the facility interfaces, the planned environments (or their ranges), the supporting tools or other equipment specified for use, operational/task sequence, concurrent task effects and limitations, biotechnological factors, regulatory or specified personnel safety and health requirements, and the potential for unplanned events including hazards introduced by human errors (see paragraph g., Human Factor Engineering Analysis). The O&SHA shall identify the safety requirements (i.e., constraints, limitations, conditions) to eliminate hazards or to reduce the associated risk to a level that is acceptable under either regulatory or specified criteria. An O&SHA is also used to validate design safety by verifying that the system will perform as expected if the operator correctly performs each step of approved procedures. The O&SHA should be updated when any system design or operational changes are included to ensure any needed hazard control changes.

e. Integrated Hazard Analysis (IHA). A complex program will require analysis of the widely divergent elements or system designs that must be assembled and operated together. The IHA ensures that hazards, along with their causes and controls, that cross element, system, or operational interfaces are identified, assessed, and resolved to an acceptable level. For purposes of the IHA, integration should be considered an element of a system. This analysis should start with an integrated PHA and progress in parallel with other system or element safety analyses. This analysis is broader in scope in that it looks at an entire program rather than a portion of it. The IHA process should act as a conduit to facilitate notification of affected systems or elements when a hazard, cause, or control crosses an interface.

f. System Hazard Analysis (SHA). An SHA is a top-level hazards analysis to verify system compliance with safety requirements contained in system specifications and other applicable documents. It is used to identify previously unidentified hazards associated with the subsystem interfaces and system functional faults; assess the risk associated with the total system design, including software, and specifically of the subsystem interfaces; and recommend actions necessary to eliminate identified hazards and/or control their associated risk to acceptable levels.

g. Software Safety Analysis (SSA). A PHA identifies the safety-critical characteristics of a system. If the PHA identifies hazards that are functions assigned to an inhibit or software control of the system undergoing analysis, that software must undergo safety analysis. When a system software component has been identified as safety-critical, the software safety analysis process shall begin with the development of safety objectives. The safety objectives shall be derived by examining the properties of each critical function and expressing them in terms of system responses and consequences. These objectives shall be unique to each safety-critical software component. Software safety analysis verifies that the software contains no errors or deficiencies that could contribute to risks to people or property. Software safety analysis consists of four phases: requirements analysis, design analysis, code analysis, and testing. The safety analysis effort shall begin with the requirements analysis phase of software development. This will ensure that all safety-critical requirements are specified and designed into the final software product. This approach to software safety analysis will provide optimum software safety with the least impact to the cost and schedule of the software development effort. The analysis techniques must be structured to allow for revisions and updates as the system matures.

h. Subsystem Hazard Analysis (SSHA). An SSHA is a hazards analysis to verify subsystem compliance with safety requirements contained in subsystem specifications and other applicable documents. It is used to identify previously unidentified hazards associated with the design of subsystems including component failure modes, critical human error inputs, and hazards resulting from functional relationships between components and equipment comprising each subsystem, and to recommend actions necessary to eliminate identified hazards or control their associated risk to acceptable levels.

i. Human Factors Engineering Analysis. The program manager should apply human factors engineering analysis for human error avoidance during the development and acquisition of NASA systems, equipment, software, and facilities to achieve the effective integration of the human element into system performance. A human error avoidance effort shall be provided to develop or improve the crew-equipment/software interface; to achieve required effectiveness of human performance during system operation and maintenance; to make economical use of personnel resources, skills, and training; and to minimize the possibility of human-induced error. Two-fault tolerance is required for all human errors that could result in a catastrophic hazard. The human error avoidance assessment shall be an integral part of the PHA, SHA, SSHA, and O&SHA as required. Human engineering principles shall be applied to the design to eliminate or mitigate potential hazards associated with the man-machine interface. Extensions or transformations of the results of system safety efforts for use in the human error avoidance task are not considered duplication.

5. The following tools and techniques shall be selected as appropriate to help identify the primary causes of an identified hazard:

a. Failure Modes and Effects Analysis (FMEA)/Critical Items List (CIL). The FMEA is usually performed by the assigned reliability office to identify critical items in hardware. The FMEA should be used to assist safety personnel to perform hazard analyses and supplement, not replace, hazard analyses. Safety personnel can use the FMEA to help verify that all safety-critical hardware has been addressed in the hazard analyses. The FMEA in hardware systems is an important technique for evaluating the design and documenting the review process. All credible failure modes and their resultant effects at the component and system levels are identified and documented. Items which meet defined criteria are identified as critical items and are placed on the CIL. Each entry of the CIL is then evaluated to see if design changes can be implemented so the item can be deleted from the CIL. Items that cannot be deleted from the CIL must be accepted by the program/project based on the rationale for acceptance of the identified risk. The analysis follows a well-defined sequence of steps that encompasses (1) failure mode, (2) failure effects, (3) causes, (4) detectability, (5) corrective or preventative actions, and (6) rationale for acceptance.

b. Fault Tree Analysis (FTA). The FTA is a technique by which the system safety engineer can rigorously evaluate specific hazardous events. It is a type of logic tree that is developed by deductive logic from a top undesired event to all subevents that must occur to cause it. It is primarily used as a qualitative technique for studying hazardous events in systems, subsystems, components, or operations involving command paths. The FTA can be used to verify that the FMEA has identified all Critical Single Failure Points (CSFPs) consistent with the Top Event hazardous condition. It also can be used for quantitatively evaluating the probability of the top event and all subevent occurrences when sufficient and accurate data are available. Quantitative analyses shall be performed only when it is reasonably certain that the data for part/component failures and human errors for the operational environment exist. The individual failure paths or minimal cut sets shall be generated and evaluated for acceptable risk.

c. Sneak Circuit Analysis (SCA). The SCA is a technique by which the system safety engineer can identify latent conditions (e.g. electrical, hydraulic, or other control systems) not caused by component failure that can inhibit desired functions or cause undesired functions to occur. A full-scale SCA may not be feasible depending on project constraints. Therefore, an SCA can be done on catastrophic hazards as identified by system-level FMEA or hazards analyses.

d. Event Tree Analysis (ETA). The ETA is a technique by which the system safety engineer can evaluate possible outcomes using a type of logic tree. It is an inductive logic method for identifying the various possible outcomes of a given initiating event.

DISTRIBUTION:
NODIS