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 E. Example Hazard Report

1. Hazard reports (HR`s) for safety hazards shall be written prior to each major milestone to document residual risks identified in the hazard analysis process against program requirements. The HR is a tool by which residual risks are identified in such a manner that each level of technical management in a program can evaluate the risks and formally accept them based on documented rationale. HR`s will be updated to reflect program changes and modifications that affect the identified risk.

2. Specific data requirements will vary among programs, but the HR data elements within a program will be standardized. The following is recommended as a minimum data element set. This process is not intended to apply to those Federally-mandated requirements, e.g., OSHA, DOT, FAA, etc.

a. Report Number. Each HR will be given a unique alpha-numeric number that identifies the system/subsystem for which it is written. Provision will be made for a revision letter and Document Control Number (DCN).

b. Date. Date of preparation/revision of the HR.

c. Status.

Closed: Corrective action to eliminate or control the hazard has been implemented or scheduled for implementation before the effectivity identified in the HR. Program management accepts the risk pending completion of corrective action and verification. Baselining (written approval of the HR within the configuration management system) is required to approve an HR as closed.

Open: An HR status is open when corrective action to eliminate or control the hazard has not been completed and the corrective action is not scheduled to be performed.

d. Title. Provide a short descriptive (not generic) title for the hazard.

e. System. Identify the system/subsystem/component at the level at which the hazard is being written.

f. Effectivity. This element helps to narrow and define the applicability of the hazard. It will vary by type of program and could be specific to a test, flight, or vehicle. It could also be applicable to a series (or fleet) of tests, vehicles, or flights.

g. Operation Phase. A discrete period defined by the program for tests or operations during which the hazard could occur. A hazard could occur during one or more phases such as pre-launch, stage one, on-orbit, recovery, etc.

h. Description of the Hazardous Condition. Describe the condition which can/will lead to loss of flight or ground personnel, loss of safety-critical system, loss of life or injury to the public, loss of equipment/flight vehicle, or loss of public property. The hazardous condition shall be described in terms of one or more generic hazards, such as fire/explosion, impact, etc. The description should explicitly specify the equipment involved, e.g., "Impact between separating upper stages could result in loss of trajectory control for final stage."

i. Risk Acceptance Rationale. Provide a brief summary of the technical rationale for accepting the residual risks identified in the HR.

j. Submittal Signatures. The specific signatures required on a HR will vary with the size of the program and whether it is contracted or performed in-house at NASA. The following signatures should be required as a minimum:

(1) Originating activity design engineer.

(2) Originating activity safety engineering manager.

(3) Assigned NASA Field Installation system/subsystem engineer.

(4) Assigned NASA Field Installation safety engineer.

k. Risk Assessment Section. The risk assessment section of the HR comprises several linked data elements. These are: cause(s), effect(s), safety requirements, control(s), verification(s), classification, severity, and likelihood of occurrence. While an HR is generated to address one hazardous condition, the condition may result from several related or mutually exclusive hazard causes. In turn, each cause could result in multiple effects and multiple safety requirements. Multiple controls may be required to control the cause, the effect, or both, and each control may use several verification methods to assure the control is in place. Each discrete effect, safety requirement, and control will be hard-linked to its cause, and each discrete verification method will be hard-linked to its control. Based on the data, the risk (severity and likelihood of occurrence) will be assessed for each cause, and the cause will be assigned a classification based on the risk. For each hazard cause, the worst case effect will determine the severity level to be assigned. For each hazard cause, the controls that are in place are assessed to determine the likelihood of occurrence from the program risk assessment matrix when the likelihood of occurrence has been derived using probabilistic methods, the numerical probability will be used. Eliminated hazard cause will not be documented in this part of the HR, but should be included in background data to maintain visibility of improvements made during the hazard analysis and reporting process. The assigned reference number of the eliminated cause and linked data will not be deleted, but will be annotated as "Eliminated."

l. Causes. Describe the unsafe acts or conditions that may lead to the hazardous event. Hazard causes shall be identified down to the level at which controls are to be applied and shall consider environments, hardware failures, secondary failures/conditions, software errors, procedural errors, operationally induced external and internal failures, and human errors/limitations. In addition to the program engineering and operations data, generation of the causes and linked data should consider waivers and deviations with safety impact; test, processing, and operational problems/anomalies; alerts and, trending data; and interface/integrated hours.

m. Effect(s). Describe the potential worst case outcomes of the hazard cause.

n. Requirement(s). Provide narrative descriptions of the requirement(s) that define criteria to be met when controlling the hazard. In addition to listing safety requirements used to control the hazard, provide other requirements used to control each cause and effect. The reference must include document number and title. The lowest level requirements should be used as primary references and the higher level requirements as secondary priority.

o. Control(s). Provide narrative description(s) of the appropriate design, safety devices, alarm/caution and warning devices, or special automatic/manual procedures used to control the hazard. Documentation references by document number and title are required for each control.

p. Verification(s). Identify the method(s) used to verify the hazard control(s). Verification methods include analyses, tests, inspections, and operations and maintenance requirements. Verification reference documents will be identified by number and title. Procedures and/or specifications will be referenced to document verification.

q. Severity. Describe severity for each cause by assessing the most severe effect and documenting it as catastrophic, critical, moderate, or negligible (see Chapter 3 for more information).

r. Likelihood of Occurrence. This part of the HR is completed for each cause.

(1) When probabilistic risk assessment methods are used, list the numerical probability of occurrence for this cause.

(2) When qualitative risk assessment methods are used, the controls that are in place must be assessed and documented for likelihood of occurrence in accordance with the defined program risk assessment matrix. The following are recommended probability definitions (see Chapter 3 for more information).

s. Classification. Each hazard cause will be assigned a classification of controlled, accepted risk, or (extremely rare) unacceptable risk. A risk of the latter magnitude should never reach the HR baseline stage, but provision is made for its use when the HR is used for information reporting. See the Glossary for definition of the classification terms.

3. Overall HR Risk Assessment and Closure.

a. Quantitative.

(1) The quantitative approach involves the use of probabilistic risk assessment methods to compute the risk probability for the hazard.

(2) A numerical probability alone may not be sufficient to make a closure determination. Extremely low probabilities are easy to call, but higher probabilities may require further controls. The program shall devise a method/policy for determining closure.

b. Qualitative.

(1) When qualitative risk assessment methods are used, a risk picture, using a program-defined risk assessment matrix, shall be included as part of the HR and presented to program management as a check to ensure the proper severity and likelihood of occurrence. An example of the risk assessment matrix is shown in figure 3-1. This matrix uses the severity and suggested likelihood of occurrence definitions from Chapter 3. The risk matrix will be completed by documenting each hazard cause severity and likelihood of occurrence in the appropriate block. The controls are considered to be in place when the matrix is marked.

(2) Hazard closure classifications will be either eliminated, accepted as is, or controlled. Unacceptable risks require reduction prior to HR baselining and are a constraint to tests and operations.

4. Interfaces. Identify system interface(s) that are affected by and cause hazard conditions within the report, including facilities, ground support equipment (GSE), and other parts of the program.

5. References. Include pertinent reference information to other program documentation that affect, and are affected by, data elements within the HR. These include, but are not limited to, FMEA/CIL, requirement and specification documents, procedures, test and operational limitation and criteria rules, and flight rules.

6. Background/Remarks. Include information that increases understanding of the hazard, describes changes to the hazard, and identifies supportive documentation, etc. Use it to document the chronology of major events associated with the hazard, including related flight history, test and check-out, failure summaries, changes to the design or operation, etc.

7. Status of Open Work. Identify open work, responsible agency, action required, and the due date. Completion due dates will be supplied only for open work that is a constraint to a critical milestone in the program.

8. Preparing Engineer and Date. Identify the preparing engineer/analyst and the date the HR was prepared.

DISTRIBUTION:
NODIS