AFOP-8715.3-005-2.pdf

Before use, check the Master List to verify that this is the current version. For reference only when printed. This document does not contain export-controlled content and may be distributed outside the

Center.

Armstrong Flight Research Center AFOP-8715.3-005, Revision E-10 Edwards, California 93523 Expires September 1, 2021

Compliance is mandatory.

SUBJECT:

Hazard Management Procedure

RESPONSIBLE OFFICE:

Flight Research & Test Safety Branch

Hazard Management Procedure AFOP-8715.3-005, Revision E-10 Expires September 1, 2021

Before use, check the Master List to verify that this is the current version. For reference only when printed. This document does not contain export-controlled content and may be distributed outside the

Center.

AFOP-8715.3-005, Hazard Management Procedure Concurrence Signatures

By signing this concurrence, I accept the requirements that apply to my organization.

Before use, check the Master List to verify that this is the current version. For reference only when printed. This document does not contain export-controlled content and may be distributed outside the

CONTENTS

1.0 PURPOSE OF DOCUMENT

2.0 SCOPE, APPLICABILITY, & WAIVER

2.1 Scope

2.1.1 Scope Exceptions

2.2 Applicability

2.3 Waiver

3.0 OBJECTIVES & METRICS

4.0 HAZARD MANAGEMENT

5.0 HAZARD MANAGEMENT PROCESS FLOWCHART

6.0 HAZARD INDENTIFICATION & RECORDING

6.1 Hazard Reports

7.0 HAZARD CLASSIFICATION

7.1 General Guidance

7.2 Hazard Action Matrix (HAM)

7.3 Hazard Probability

7.4 Hazard Severity

7.5 Failure Tolerance

7.6 Residual Risk Reporting

7.7 Accepted Risk

7.8 Tailoring of the Hazard Action Matrix (HAM)

8.0 HAZARD MITIGATION & ANALYSIS

8.1 Hazard Mitigation

8.2 Hazard Analysis

9.0 HAZARD MANAGEMENT & TRACKING

9.1 Configuration Control

9.2 Hazard Tracking

9.3 Center Management Review

9.4 Exceptions

9.5 Lesson Learned

10.0 RELEVANT DOCUMENTS

10.1 Authority Documents

10.2 Reference Documents

10.3 Forms

10.4 Templates

11.0 MANAGEMENT RECORDS & RECORDS RETENTION

APPENDIX A, Definitions

APPENDIX B, Acronyms

Before use, check the Master List to verify that this is the current version. For reference only when printed. This document does not contain export-controlled content and may be distributed outside the

Center.

APPENDIX C, Hazard Mitigation Order of Precedence

APPENDIX D: Residual Risk Reporting

Before use, check the Master List to verify that this is the current version. For reference only when printed. This document does not contain export-controlled content and may be distributed outside the

1.0 PURPOSE OF DOCUMENT

This document describes the Hazard Management processes, methods, and techniques for eliminating or minimizing the occurrence of accidents and mishaps and is intended to help projects manage hazards throughout the project life cycle by improving their ability to make risk-informed decisions. It presents the System Safety Engineering techniques that are used at Armstrong Flight Research Center (AFRC) (hereinafter referred to as the Center) to help preclude occurrence of personal injury, loss of test article, or loss of mission during the conduct of aerospace projects.

2.0 SCOPE, APPLICABILITY, & WAIVER

2.1 Scope

This procedure applies to aerospace and ground systems for which the Center assumes ground / range / flight safety, mission success, and/or airworthiness responsibility, including that of customers or support contractors. It includes contractor furnished equipment (CFE), government furnished equipment (GFE), and ground support equipment (GSE) that is either unique to the project or program, has not had previous safety analysis, or is being used in an application not covered in previous analysis. Its specific application to flight research operations will include, at a minimum, the test article or vehicle, support subsystems or vehicles, and ground research capabilities.

This procedure will be followed for all new capabilities and projects at the Center except where specifically waived by the appropriate technical authority or the Center Director.

2.1.1 Scope Exceptions

This procedure is not intended to address project schedule, staffing, or budget risks (i.e., programmatic risks)

2.2 Applicability

This procedure applies to the Flight Research & Test Safety Branch and to all Center organizations involved in the operation and approval of flight or ground research projects (e.g., Office of the Director, Programs and Projects Directorate, Research and Engineering Directorate, Flight Operations Directorate, etc.).

Before use, check the Master List to verify that this is the current version. For reference only when printed. This document does not contain export-controlled content and may be distributed outside the

2.3 Waiver

Waivers and variances granted to this procedure will be documented in accordance with AFPR-7123.2-001, Waivers and Deviations to Technical Requirements and Standards, and maintained in the project’s documentation system. Waivers will be submitted by the project or research lead during the formulation phase.

A. The Project Manager is responsible for ensuring waivers and variances to the content of the Center Hazard Management Procedure have been obtained.

B. The System Safety Engineer will review and evaluate request for waivers or variance and make recommendations, based on findings, to the Flight Research & Test Safety Branch chief.

C. The Director of Safety and Mission Assurance and the Center Chief Engineer are the independent Technical Authority (TA) Board. The TA Board has the approval authority for waivers and variances to the content of the Center Hazard Management Procedure.

D. The Project Manager will ensure that the official waiver or variance is properly filed and maintained with the project records.

3.0 OBJECTIVES & METRICS

Objective: Ensure a preliminary hazard analysis (PHA) is performed to identify the generic hazards for the mission and concepts being considered.

Target: PHA is completed prior to the preliminary design review (PDR).

Metric: The number of days late to deliver the PHA.

Metric data collection and formulation: Flight Assurance Matrix (FAM).

Where reported: FAM PHA column.

How often reported: Prior to the PDR.

Objective: Ensure a system/subsystem hazard analysis (SHA/SSHA) is performed, including causes and controls that cross system boundaries.

Target: SHA/SSHA is delivered no later than 30 days after the critical design review

(CDR).

Metric: The number of days late to deliver the SHA/SSHA.

Metric data collection and formulation: Flight assurance matrix (FAM).

Where reported: FAM SHA/SSHA column.

Before use, check the Master List to verify that this is the current version. For reference only when printed. This document does not contain export-controlled content and may be distributed outside the

Center.

How often reported: No later than 30 days after the CDR or project equivalent.

Objective: Ensure the final hazard analysis or operating & support hazard analysis (O&SHA) (when applicable) is complete.

Target: The final hazard analysis or O&SHA is complete prior to the flight request Tech Brief.

Metric: The number of days late to deliver the final hazard analysis including the O&SHA, when applicable.

Metric data collection and formulation: Flight assurance matrix (FAM).

Where reported: FAM O&SHA column.

How often reported: The number of days late to deliver the final hazard analysis including the O&SHA, when applicable.

4.0 HAZARD MANAGEMENT

Historically, the Center approach to Hazard Management has been to tailor industry, government, and NASA Headquarters accepted processes (including Mil Spec and NASA Handbooks) that are relevant, practical, and efficient. Because of the variety of aerospace projects at the Center, projects may have varied risk baselines. The level of analysis will be commensurate with the overall risk profile as determined by project safety issues, complexity, and size. The application of the processes in this procedure establishes a graduated severity / probability matrix. Projects with relatively little risk will require a modest amount of effort to document that fact. Projects with significant risk are able to identify hazards early in the design process and design them out, provide for mitigation to an acceptable level of risk, or present them to the Center management to become accepted risks.

In this context, the conduct of a project means from its beginning to its end (formulation to closeout). It is expected that every project conducted under Center purview will have a system safety plan that specifies the project’s approach to hazard management. It is further expected that the project will review and make use of lesson learned as well as contribute to the Lessons Learned Information System (LLIS). These processes are used by Center Management as a measure of the risk that will be accepted for the conduct of a mission, and they assist a project team to continuously work to minimize mission risk. Responsibility for implementation of these processes rests with the Center project team, particularly the project team leads: the project manager, chief engineer, operations engineer, and system safety engineer. As the leader of the team, the Project Manager will ensure that these hazard management processes are appropriately integrated into project activities, and the team leads will assist in this effort.

Development plans and procurement contracts for project related hardware, software, or services address hazards associated with deliverable items. Project plans, Before use, check the Master List to verify that this is the current version. For reference only when printed. This document does not contain export-controlled content and may be distributed outside the

Center.

configuration management plans, and system safety plans will provide an integrated documentation basis for these hazard management processes (e.g., establish a configuration control board, establish how the mitigation and verification actions are managed and tracked). Flight planning and briefings will address risks associated with conduct of the mission. To ensure that these processes are effective in maintaining safe operations, the entire project team, including the project pilot, the operations support team, and the technical disciplinary or subject matter experts, will actively participate in the hazard management process.

The hazard management flowchart (Section 5.0) represents the highest level and intent of the Center hazard management process. The project formulation stage addresses the conceptual phase of the project, where it is imperative to have early safety involvement so hazards may be mitigated by design when applicable, thereby, saving time and expense. The remainder of the flowchart traces the formal process for hazard management by laying out the steps from hazard identification through the documentation of any lessons learned during the process, as well as stressing the importance of communication and documentation throughout the process.

Three items constitute the foundation of this procedure:

• Form AFRC 80328, Hazard Report (HR), including instructions;

• Hazard Mitigation Order of Precedence (Appendix C);

• Hazard Action Matrix (HAM) (TEM-001a/b).

The following hazard management flowchart incorporates the fundamentals of continuous risk management (identify, analyze, plan, track, and control), each supporting the effort to properly document and communicate the hazards associated with the project’s activities. Projects may require varying degrees of system safety support. Exceptions to the flowchart will be documented in the system safety Plan and/or project plan.

Before use, check the Master List to verify that this is the current version. For reference only when printed. This document does not contain export-controlled content and may be distributed outside the

5.0 HAZARD MANAGEMENT PROCESS FLOWCHART

Before use, check the Master List to verify that this is the current version. For reference only when printed. This document does not contain export-controlled content and may be distributed outside the

Before use, check the Master List to verify that this is the current version. For reference only when printed. This document does not contain export-controlled content and may be distributed outside the

Before use, check the Master List to verify that this is the current version. For reference only when printed. This document does not contain export-controlled content and may be distributed outside the

Before use, check the Master List to verify that this is the current version. For reference only when printed. This document does not contain export-controlled content and may be distributed outside the

Before use, check the Master List to verify that this is the current version. For reference only when printed. This document does not contain export-controlled content and may be distributed outside the

6.0 HAZARD INDENTIFICATION & RECORDING

6.1 Hazard Reports

The form, AFRC 80328, Hazard Report, is the primary tool used to document hazards. A compilation of these forms for all the identified hazards associated with a project serves as the primary documentation of the various hazard analyses. All identified hazards will be evaluated for their severity and for the probability of occurrence. The potential mishap is the effect, or outcome, of the hazard. A hazard cause is the condition that contributes to the hazard. It could be an unsafe design, environmental factors, hardware failure, software error, human error, etc.

Hazards are described in a scenario-based statement that addresses the cause (source) and effect (outcome); or source, mechanism, and outcome (i.e., consequence) to characterize the potential harm of the hazard.

Hazard controls are the measures that eliminate a hazard or reduce the probability or severity of the hazard effect (outcome). If the hazard controls change the severity (i.e., the consequence) of the hazard, then a new hazard might be identified that addresses the new consequence (outcome).

During the hazard identification process, it is important for the Hazard Report form to clearly describe the hazard, identify the condition or unsafe act followed by the worst-case consequence, its cause(s) and effect(s), and set initial hazard categories (Section 8.0, Hazard Mitigation and Analysis). Typically, hazards are formally tracked through the project’s system safety working group (SSWG). In some cases, a configuration control board (CCB) process may be used in place of or in conjunction with the SSWG to document, control, and track hazards. The project’s configuration management plan or the system safety plan will explain the process that will be utilized on each specific project.

Hazard reports can be written and submitted to the SSWG by anyone at any time during the conduct of a project. Many of the hazards associated with a project are identified early in the design and development phase using formalized hazard analysis techniques. A preliminary hazard analysis (PHA) will be conducted to identify hazards at the project’s preliminary design review (PDR). Typically, the subsystem hazard analysis (SSHA) and the system hazard analysis (SHA) will be reported no later than 30 days after the critical design review (CDR). When the project elects to perform an O&SHA, the O&SHA will be reported prior to the project’s flight request Tech Brief. These analyses will refine the PHA and identify additional hazards that become apparent as the understanding of a project’s systems and operational requirements mature. Additional hazard analysis techniques and tools are discussed in Section 8.0.

Before use, check the Master List to verify that this is the current version. For reference only when printed. This document does not contain export-controlled content and may be distributed outside the

Usually, a project’s discrepancy reporting system, per AFOP-7120.5-003, Project Managers’ Manual, is an ongoing means of identifying problems that may be hazards. DRs will be reviewed not only to ensure that they are corrected, but will be compared with known hazards to ensure that any new hazards are identified. If a new hazard is identified, a hazard report will be initiated.

If required in the system safety plan and/or project plan, participating hardware/software providers will perform and deliver a hazard analysis of their respective systems. The results of the project’s hazard analyses will be presented at the various design reviews. A copy of all analyses will be part of the system deliverables to be used by the SSWG during the hazard analysis process. Hazard identification, analysis, and reporting do not terminate at delivery.

The hazard analysis process, like the entire safety process, will be an on-going, living process if it is to function correctly. Through the life of the project, analysis will constantly be reviewed for currency and accuracy.

Due to the nature of flight research projects at the Center, flight vehicles are continually undergoing configuration changes.

7.0 HAZARD CLASSIFICATION

Many methods have been developed to quantify the probability of the risk associated with the potential severity of a hazard and its probability of occurrence. The Center has adopted a method tailored after the NPR 8715.3, NASA General Safety Program Requirements.

7.1 General Guidance

This procedure is published to provide each project with a tool that will facilitate their implementation of the hazard risk management process.

Risk management is a project responsibility. Because of the nature of flight research activities, most of the hazards that will be assessed for both severity and probability will deal with one-of-a-kind aerospace vehicles operating in short-term projects during which very few flight hours will be accrued. Because of this, data about components supplied by vendors or project contractors (both failure data and calculated reliability numbers) will be utilized with caution, and the project will consider whether or not that data needs be modified to make it fit their project. The project will not simply take numbers given to them and plug them into the HAM to see where they fit. Serious thought and sound judgment will be utilized in the application of the hazard risk management process. When making qualitative assessments, ensure the controls that are in place are

Before use, check the Master List to verify that this is the current version. For reference only when printed. This document does not contain export-controlled content and may be distributed outside the

Center.

assessed and documented for likelihood of occurrence in accordance with the defined project system safety plan and that clear rationale is used in documenting the justification of the classification of the hazard category.

7.2 Hazard Action Matrix (HAM)

There are two Center residual risk hazard action matrices (HAMs) (TEM- 001a/b) that serve as the primary means of communicating safety hazard management classification. The purpose of these templates are to relate human safety hazards, loss of high-dollar value assets, and/or loss of mission in terms of the hazard's severity with its probability in order to identify the associated overall hazard risk. The HAMs identify the level of management approval required for actual acceptance of risks (accepted risks) by the solid red and red cross-hatched areas on the HAMs. The HAM instructions reflect the accepted, Center wording for hazard probability and severity classifications of mishap occurrence. Projects will not change the substance of the HAM presentation if it is planned for use as part of the Center airworthiness process without an approved waiver.

Final hazard classifications are determined after the project or program has exhausted all planned corrective and controlling actions utilizing the Hazard Mitigation Procedures of Section 8.0, Hazard Mitigation & Analysis.

7.3 Hazard Probability

Refer to the hazard probability section in TEM-001a/b.

7.4 Hazard Severity

Refer to the hazard severity section in TEM-001a/b.

7.5 Failure Tolerance

All safety critical single point failures (SPFs) (not including items such as the unmodified basic aircraft or other flight certified hardware/software) and a credible analytical assessment of their probability of failure will be presented at the Airworthiness & Flight Safety Review Board (AFSRB) (or equivalent) and reviewed at all Tech Briefs. Probabilities presented will be quantified when practical.

7.6 Residual Risk Reporting

The HAMs (TEM-001a/b) map the residual risks that are to be reported.

The solid red shaded areas on the HAM are regarded as primary risk areas and, as a matter of policy, will not normally be accepted at the Center level. The red cross-hatched areas on the HAM are regarded as

Before use, check the Master List to verify that this is the current version. For reference only when printed. This document does not contain export-controlled content and may be distributed outside the

Center.

accepted risk areas and as such require acceptance and approval as accepted risks by the Center Director (or designee) with appropriate rationale. The white areas on the HAM are the hazard/residual risk areas for which the project and/or project management has resources and methodology to manage all corrective and mitigating actions.

Template TEM-001a: Residual risk levels in the primary risk areas, as a matter of policy, will not normally be accepted at the Center level and will be further mitigated. In event that a human safety hazard falls within the primary risk area after reasonable mitigations have occurred, and cannot be mitigated further, acceptance will normally require a higher authority than the Center Director for approval. If such approval is granted, these hazards will constitute “accepted risks.”

Template TEM-001b: Residual risk levels in the primary risk areas, as a matter of policy, will not normally be accepted at the Center Director level and will be further mitigated. In event that loss of asset/mission (mission success) hazard falls within the primary risk area after reasonable mitigations have occurred, and cannot be mitigated further, it may be accepted by the Center Director with appropriate rationale. If such approval is granted, these hazards/residual risks will constitute accepted risks.

Reporting a hazard on the HAM is a proactive process of communication that gives Center senior management a clear understanding of the level of safety residual risk.

7.7 Accepted Risk

The accepted risk method is a means to establish a formal, closed loop, risk acceptance process to identify, document and track hazards with residual risk. In all cases where a decision is made to accept a risk, that decision will be coordinated with the governing Safety & Mission Assurance (S&MA) organization and communicated to the next higher level of management for review. Reporting the accepted risks to the Center Director, the S&MA Director, and Center Chief Engineer is accomplished as part of the hazard management process. Accepted Risk documentation:

A. Will state all hazards that have been identified as accepted risks on the

HAM.

B. Will be presented at the AFSRB (or equivalent) and every Tech Brief.

C. Will be presented for the Center Director’s concurrence in a Center

Chief Engineer’s memorandum, which is maintained as part of the review board package.

Before use, check the Master List to verify that this is the current version. For reference only when printed. This document does not contain export-controlled content and may be distributed outside the

Center.

The AFSRB/Tech Brief Chair will retain a copy of the memorandum as a record of the project’s accepted risk.

7.8 Tailoring of the Hazard Action Matrix (HAM)

The definitions of probability, severity, and accepted risks on the Center HAM (TEM-001a/b) satisfy the requirements of the majority of Center aerospace research projects. In some instances, however, projects may feel the need to tailor the matrix. In all cases of tailoring the HAM, the project will specify the procedures to be used in the system safety plan and will brief the S&MA Director and the Center Chief Engineer (AFSRB Chair) early in the project to gain approval for the process to be used. The system safety plan clearly documents any areas where participating organizations have different definitions of accepted risk categories or approval requirements. The most restrictive Center requirements will always apply to areas of Center responsibility.

8.0 HAZARD MITIGATION & ANALYSIS

8.1 Hazard Mitigation

The hazard mitigation order of precedence is provided in Appendix C. In general, the order of precedence has been derived from experience that has shown time and again that eliminating a hazard is the most positive means of preventing it from causing a mishap. That same experience has shown that when special procedures are used to mitigate a hazard's risk, it is likely that the procedures may be misapplied and a mishap may occur, anyway. The order of precedence is as follows:

A. Design to eliminate the hazard or to minimize risk (e.g., electrical fire eliminated by using a pneumatic system or using redundancy to lower the probability of occurrence).

B. Incorporate safety features and/or safety devices to minimize risk (e.g., safety lock-out, inhibit devices, software assurance).

C. Incorporate warning/caution/protective devices to minimize risk (e.g., flashing light with a sign to indicate that there is a radiation hazard present).

D. Use special procedures/training/personal protective equipment to minimize risk (e.g., mission rules/operating limits, test procedures that contain warnings and precautions with regard to test being performed, high pressure systems training, hearing protection, safety glasses, gloves, hard hats, etc).

Before use, check the Master List to verify that this is the current version. For reference only when printed. This document does not contain export-controlled content and may be distributed outside the

Center.

E. Use of placards to minimize risk (e.g., High voltage label placed on a panel over a high voltage area with intent to prevent unqualified personnel from opening panel).

NOTE

Many hazards may require a combination of these approaches to fully mitigate.

8.2 Hazard Analysis

Advanced hazard analysis tools include the

A. Fault tree analysis (FTA) B. Failure modes and effects analysis (FMEA) C. Failure modes and effects criticality analysis (FMECA) D. Event tree analysis (ETA) E. Sneak circuit analysis (SCA) F. Probabilistic risk assessment (PRA)

One key aspect of many of these approaches is the development of a system safety working group (SSWG) to ensure early involvement of system safety, subject matter experts, and operations engineers, as well as pilots, when applicable. In addition, a SSWG provides for the early involvement of system design engineers to identify the hazards associated with the design.

The FTA can model the failure of a single event or multiple failures that lead to a system failure. The FTA is a top down analysis versus the bottom up approach of the FMEA or event tree analysis. The FTA method identifies an undesirable event and the contributing elements (faults and/or conditions) that would precipitate it. The contributing elements are interconnected with the undesirable event using network paths through Boolean logic gates. The FTA is a potential source of analytical probabilities.

The FTA, or equivalent logic analyses, is preferred for evaluating the effects of ground and flight hardware in conjunction with software faults, interfaces, environmental conditions, and human error on the system. The top-level fault tree will be based on the top undesired event, loss of vehicle and/or personnel during aerospace operations. The top-level fault tree will be developed in a manner that will identify the project’s operational and mission phases as they relate to the top undesired event. The mission phase events will most probably be based on preliminary hazard analyses.

The top-level fault tree may also include other basic analyses such as

Before use, check the Master List to verify that this is the current version. For reference only when printed. This document does not contain export-controlled content and may be distributed outside the

Center.

subsystem hazard analyses (SSHAs), operating and support hazard Analyses (O&SHAs), and any other advanced reliability analyses (i.e., failure modes and effects analyses [FMEAs]) that will support the further development of the detailed trees.

The following basic steps are used to conduct FTA:

A. Define the top event and/or system failure of interest.

B. Define the physical and analytical boundaries.

C. Define the treetop structure.

D. Develop the path of failures for each branch to the logical initiating failure.

Once the fault tree has been developed to the desired degree of detail, the various paths can be evaluated to arrive at a probability of occurrence.

Cut sets are combinations of component failures causing system failure (i.e., causing the top event of the tree). Minimal cut sets are the smallest combinations causing system failure. The technique is universally applicable to systems of all kinds, with the following ground rules:

A. The undesirable system events that are to be analyzed and abated (and their contributors) need to be foreseen.

B. Each of those undesirable system events will be analyzed individually.

The FMEA is a bottoms-up systematic, inductive, methodical analysis performed to identify and document all identifiable failure modes at a prescribed level and to specify the resultant effect of the modes of failure.

It is usually performed to identify critical single failure points (CSFPs) in hardware. In relation to formal hazard analyses, FMEA is a subsidiary analysis.

In many projects, the research vehicle contractor will conduct system safety analyses in order to correct and control identified hazards prior to the delivery of the vehicle or test article. The results of the hazard analyses is presented at the various design reviews. A copy of all contractor analyses is included as part of the contract deliverables. The project and/or program managers will ensure that the contractors perform required hazard analyses to identify hazards and ensure their proper disposition. Hazard analyses will address design and operational hazards associated with hardware, software, operations, and operational environments.

Before use, check the Master List to verify that this is the current version. For reference only when printed. This document does not contain export-controlled content and may be distributed outside the

Any programs or projects classified as project priority Category I will be required to generate a PRA per NPR 8705.5.

9.0 HAZARD MANAGEMENT & TRACKING

9.1 Configuration Control

The Project Manager is responsible for tracking all hazards and putting a process in place that ensures that all mitigating actions are implemented.

Typically, hazards are formally tracked through the project’s SSWG, which normally includes the project manager, pilot (if required), project chief engineer, operations engineer, and the system safety engineer, as a minimum. In some cases, a CCB process may be used in place of or in conjunction with the SSWG to document and track hazards. In either case, the process to be utilized on each specific project will be documented in the system safety plan. These plans address how hazards are entered into the system, who reviews hazards, and the process used to determine if all required and/or appropriate mitigating actions have been identified and implemented. In many cases, the resolution of a hazard may require a change in configuration. If the configuration of a flight vehicle is changed to resolve a hazard, the configuration change process will be utilized. For projects utilizing a SSWG to track hazards, it will be clearly identified in the configuration management plan and the system safety plan as to how all the participants submit hazards, where the official HRs are kept, and how the interface with the project CCB works. The project may elect to tailor the hazard report form to suit unique project needs.

9.2 Hazard Tracking

Hazards are documented and tracked using the Center Hazard Report form. The project may use the standard AFRC 80328, Hazard Report, or may tailor a project-specific form. Any form changes are explained in the system safety plan. The configuration management plan specifies how the project handles hazard reports.

When all possible mitigating actions for a hazard have been implemented and verified, the HR will be characterized as “Mitigated”. Once an HR is mitigated, the final hazard categories will be identified on the HAM. The final hazard classification of a mitigated hazard is the classification after all mitigating actions are complete (i.e., the final classification reflects the

Before use, check the Master List to verify that this is the current version. For reference only when printed. This document does not contain export-controlled content and may be distributed outside the

Center.

residual risk of the hazard after all planned mitigations are complete). All applicable hazards for the project will be shown on the HAM. The goal is to mitigate all hazards, prior to flight, to their lowest possible risk level. A hazard report can be eliminated if, for example, the hazard is found to no longer exist because of either redesign, the discovery of improper analysis or the HR is combined with another like HR. Eliminated may also mean that any residual risk falls in the less than 10-9 chance of occurrence and documented data backs this probability. All open hazards that are identified as Category I or II, Probability (A) through (D), which have been eliminated between Tech Briefs, will be presented to Center management, along with the closing action, at the next Tech Brief.

In some cases, a Hazard Report may be classified as “open” during flight/test operations if any of the hazard mitigations can only be verified during that phase.

9.3 Center Management Review

As part of the hazard management process, Center management will be made aware of the hazards associated with any project.

In all cases where a decision is made to accept a risk, that decision will be coordinated with the governing S&MA organization and then communicated to the next higher level of management for review. Center management will be aware of the hazards associated with any project.

For example, prior to the first flight of a research vehicle, HAMs (TEM- 001a/b) will be prepared by the project and presented to both the Flight Readiness Review (FRR) committee and the Airworthiness and Flight Safety Review Board (AFSRB). The project will present their accepted risks to the S&MA Director and Center Chief Engineer directly and/or through the FRR committee. Accepted risks are documented for the Center Director’s concurrence in a memorandum from the Center Chief Engineer. The Center Chief Engineer will retain a copy of the memorandum as a record of the project’s accepted risks. During the duration of the flight project, the accepted risks will be presented at each subsequent Tech Brief. The accepted risk presentation normally includes:

A. A clear statement of all accepted risks with titles, mitigation actions, and the residual risk severity level and probability of occurrence.

B. A very brief discussion on how the residual risk levels were derived for all accepted risks. Present these in the order of preferred mitigation types, i.e., design, safety devices, warning devices, procedures/training, and/or placards.

Before use, check the Master List to verify that this is the current version. For reference only when printed. This document does not contain export-controlled content and may be distributed outside the

Center.

C. HAMs showing the accepted risks and remaining residual hazards based on phase of project. Separate HAMs are presented for multiple phases of operations (e.g., ground, range, captive carry, flight, etc.), if appropriate.

D. An assessment of the probability of achieving the technical objectives from the test / test block being briefed.

Mission success is defined as those activities performed in line and under the control of the program or project that are necessary to provide assurance that the program or project will safely achieve its objectives.

The project plan will define quantifiable (e.g., using a percent as a base of measurement) mission success and partial mission success criteria (if applicable), and the specific accomplishments that need to be met for each. In addition, the project will define mission failure with respect to not achieving the above success criteria. The overall mission success activities will typically include risk assessments, system safety engineering, reliability analysis, quality assurance, electronic and mechanical parts control, software validation, failure reporting and resolution, complexity scaling factors (see list below), and other activities that are normally part of a program or project work structure. The projects will perform an overall mission success risk assessment with the tailored definitions for likelihood and consequence for mission success. This assessment will consider the cumulative effect of the positive and negative influences of the projects. The mission success assessment will be made from the conception of the objectives through the completion (a continuous risk management process). Management reviews occur at different intervals and the project is expected to report on the likelihood of mission success at each review.

The complexity scaling factors can include, but are not limited to,

1) Design heritage

2) Requirement changes

3) Contractor experience

4) Mission design

5) Range/duration

6) Total thrust

7) Number of engines

8) Structure material

9) Existing structure

10) Static margin

11) Factors of safety

Before use, check the Master List to verify that this is the current version. For reference only when printed. This document does not contain export-controlled content and may be distributed outside the

Center.

12) Flight controls

13) Landing gear

14) Technological challenges, and

15) Other Influences, as necessary.

9.4 Exceptions

The Center recognizes that the nature of flight-testing innovative, one-of-a-kind aeronautical vehicles often exceeds the standard requirements associated with flight-proven vehicles and technologies. Exceptions to the requirements presented throughout this procedure may be established during the formulation stage of the development of a project. Any such exceptions are identified in the appropriate project documentation and in the project plan and/or system safety plan. The S&MA Director concurs with these exceptions by way of approval of the System Safety Plan. Any exceptions that affect the AFSRB Process, (AFOP-7900.3-023), will require the additional approval of the Center Chief Engineer.

9.5 Lesson Learned

The system safety plan, risk management plan or project plan will document how lessons learned are going to be addressed for the project.

The primary objective of documenting and reviewing lessons learned is to apply the knowledge gained from past experience to current and future projects in order to avoid the repetition of past failures and mishaps, or to employ processes that have proved to be successful in previous applications.

Each program and project will review and apply significant lessons learned from the past, throughout the program or project life cycle, to ensure that appropriate steps are taken to avoid similar consequences. Prior to major project milestones, the NASA’s Lessons Learned Information System (LLIS) (https://nen.nasa.gov/web/ll) can be consulted for additional lessons learned material. In addition throughout the project’s life cycle, each project manager will document and submit any significant lessons learned in a timely manner to the LLIS.

Lessons need to be significant in that it has a real or assumed impact on operations. Lessons need to be valid, in that they are factually and technically correct, and applicable, in that they identify a specific design, process, or decision that reduces or eliminates the potential for failures and mishaps, or reinforces a positive result.

Before use, check the Master List to verify that this is the current version. For reference only when printed. This document does not contain export-controlled content and may be distributed outside the

10.0 RELEVANT DOCUMENTS

The underlying goal of this procedure is shared by many supporting procedures at the Center. In turn, this procedure supports Airworthiness & Flight Safety Review Process, AFOP-7900.3-023, guidelines by providing information needed to accomplish its goals.

The HAMs and accepted risks are prime sources of information for the airworthiness review processes.

• AFOP-8730.5-007, Quality Assurance Procedures, is primary quality procedures that ensure that processes are being used to preclude poor workmanship or low quality components.

• AFOP-8715.3-007, System Safety Support, delineates the process for managing risk and system safety on Center projects.

• AFOP-7150.2-004, Software Assurance and AFG-8739.8-002, Software Assurance Audit and Corrective Action Handbook, are procedures that are designed to preclude software interactions with hardware from creating mishaps. These procedures support this Hazard Management Procedure by providing front line sources of hazard mitigation.

AFRC document can be found at https://odie.ndc.nasa.gov/SitePages/Home.aspx.

10.1 Authority Documents

NPR 7120.5 NASA Space Flight Program and Project Management Requirements

NPR 8621.1

NASA Procedural Requirements for Mishap and Close Call Reporting, Investigating, and Recordkeeping

NPR 8705.5 Technical Probabilistic Risk Assessment (PRA) Procedures for Safety and Mission Success for NASA Programs and Projects

NPR 8715.3 NASA General Safety Program Requirements NASA-STD-8719.7 Facility System Safety Guidebook NASA-GB-8719.13 NASA Software Safety Guidebook AFOP-7150.2-004 Software Assurance AFOP-7900.3-023 Airworthiness & Flight Safety Review Process

10.2 Reference Documents

AFG-8739.8-002 Software Assurance Audit and Corrective Action

Handbook

Before use, check the Master List to verify that this is the current version. For reference only when printed. This document does not contain export-controlled content and may be distributed outside the

Center.

AFOP-1420.1-001 Center Forms Management Program (FMP):

Administration, Implementation, Maintenance, & Oversight

AFOP-7120.5-003 Program and Project Management Manual AFOP-8715.3-007 System Safety Support AFOP-8730.5-007 Quality Assurance Procedure AFPR-7123.2-001 Waivers and Deviations to Technical Requirements and Standards MIL-STD-882 DOD Standard Practice for System Safety

10.3 Forms

NASA forms may be found at https://nef.nasa.gov/nef/.

AFRC 80328 Hazard Report AFRC 80336 Safety & Mission Assurance Checklist for Armstrong

Programs

10.4 Templates

NASA templates may be found under Links and Tools on ODIE at https://odie.ndc.nasa.gov/Templates/Forms/MasterList.aspx.

TEM-001a/b Hazard Action Matrix

11.0 MANAGEMENT RECORDS & RECORDS RETENTION

Destruction of any records, regardless of format, without an approved schedule is a violation of Federal law.

See the Flight Research and Test Safety Branch record plan and inventory for storage location, retention requirements, and ultimate disposition for the following management records associated with this procedure

The HR, FAM weekly status and HAM are quality records generated by this procedure.

FAM weekly status briefings will be retained as part of the Flight Research and Test Safety records and stored on a supported electronic system. The FAM is a web-based application that can be linked-to from the Flight Research and Test Safety section of the Safety and Mission Assurance page of the Center Xnet.

Although generated by a Safety & Mission Assurance Directorate procedure, accomplishment and maintenance of these records are the responsibility of the Project

Before use, check the Master List to verify that this is the current version. For reference only when printed. This document does not contain export-controlled content and may be distributed outside the

Center.

Manager. The Project Manager, in accordance with the process specified in the Program and Project Management Manual, (AFOP-7120.5-003), will keep the official hazard reports. The HAM will be kept in the project’s configuration management file

(AFOP-7120.5-003).

APPENDIX A, Definitions

Accepted risk A risk that senior management has accepted as necessary for the accomplishment of a proposed activity. A hazard whose residual risk falls into an accepted risk category on the Hazard Action Matrix.

Airworthy The test vehicle operates in a safe manner within a prescribed flight envelope and according to prescribed procedures without sustaining damage.

Airworthiness The process of qualifying an air vehicle and related parts as ready for flight.

Flight safety The test vehicle, support aircraft, all crewmembers, and uninvolved aircraft return from the test flight without injury or damage unless the mission is designed to expend the vehicle. The flight starts at launch or at brake release for takeoff and ends after landing when wheels stop. No injury to personnel or damage to property occurs on the ground (e.g., flying too low, sonic booms, dropped objects, or crashes into personnel or property).

Failure modes and effects analysis

(FMEA)

A bottoms-up systematic, inductive, methodical analysis performed to identify and document all identifiable failure modes at a prescribed level and to specify the resultant effect of the modes of failure. It is usually performed to identify critical single failure points in hardware.

In relation to formal hazard analyses, FMEA is a subsidiary analysis.

modes and effects criticality analysis

(FMECA)

Analysis of a system and the working interrelationships of its elements to determine ways in which failures can occur (failure modes) and the effects of each potential failure on the system element in which it occurs, on other system elements, and on the mission, and the study of the relative mission significance or criticality of all potential failure modes. The FMECA generally takes the results of the FMEA and concentrates focus on the Flight / Safety Critical hazards (generally those hazards that fall into severity categories I & II of the HAM).

tolerance

Capability of a system to perform in a predictable manner after a failure of specified hardware or software components.

Before use, check the Master List to verify that this is the current version. For reference only when printed. This document does not contain export-controlled content and may be distributed outside the

Center.

Fail-operational ability

Capability of a system to perform in a fully operational manner after a failure of hardware or software components.

Fail-safe Ability to sustain a failure and retain the capability to safely terminate or control the operation.

Fault tree analysis

An analysis that begins with the definition or identification of an undesired event (failure). The fault tree is a symbolic logic diagram showing the cause-effect relationship between a top undesired event (failure) and one or more contributing causes. It is a type of logic tree that is developed by deductive logic from a top, undesired event to all sub-events that occur to cause it.

Ground safety

No injury to personnel or damage to equipment in any phase of ground operations, which include all activities that are not flight specific. Ground operations end at launch or at brake release for takeoff roll and recommence after landing roll wheels stop.

Hazard A hazard is the presence of a potential risk situation caused by an unsafe act or condition. A hazard is the threat of harm. Mil-Std-882 defines hazard as “Any real or potential condition that can cause injury, illness, or death to personnel; damage to or loss of equipment or property; or damage to the environment.” The NASA General Safety Program Requirements NPR 8715.3 hazard definition is “A Hazard is an existing or potential condition (event), which can result in or contribute to a mishap.”

Hazard

Identification and evaluation of existing and potential hazards and the recommended mitigation for the hazard sources found.

Immediate cause

An act that led to an undesired outcome or mishap.

Mechanism The activity that allows an immediate cause to create a mishap.

Mishap An unexpected, unforeseen, or unintended event that causes injury, loss, or damage to personnel, equipment, property, the environment, or mission accomplishment.

Mission assurance

Providing increased confidence that applicable requirements, processes, and standards for the mission are being fulfilled.

critical

Item or function that retains its operational capability to ensure no mission failure (i.e., for mission success).

Before use, check the Master List to verify that this is the current version. For reference only when printed. This document does not contain export-controlled content and may be distributed outside the

Center.

Mission phase

A discrete functional period in the life cycle of a system. In the context of this procedure, this equates to an interval of exposure to a potential mishap caused by a specific hazard.

Mission rules Those rules that govern the unique project aspects of the planning and conduct of a mission operation. These rules will include changes to limitations or procedures already established as part of NASA- Center or manufacturer-approved control and operating procedures.

These rules will be categorized as Safety Critical Go/No-Go Criteria, Mission Critical Go/No-Go Criteria, or Mission Go/No-Go Criteria.

Safety Critical Go/No-Go Criteria – A set of safety conditions that will be satisfied before a mission operation may begin or continue.

Failure to satisfy these conditions will result in a mission abort and if airborne, a return-to-base (RTB). If failure to satisfy all conditions results in a decision affecting continuation of a specific maneuver, actions will be taken…