Attachmnet_J5_MIL-STD-882E.PDF

NOT MEASUREMENT

SENSITIVE

MIL-STD-882E

11 May 2012

SUPERSEDING

MIL-STD-882D

10 February 2000

DEPARTMENT OF DEFENSE

STANDARD PRACTICE

SYSTEM SAFETY

AMSC N/A AREA SAFT

Downloaded from http://www.everyspec.com ii

FOREWORD

1. This Standard is approved for use by all Military Departments and Defense Agencies within the Department of Defense (DoD).

2. This system safety standard practice is a key element of Systems Engineering (SE) that provides a standard, generic method for the identification, classification, and mitigation of hazards.

3. DoD is committed to protecting personnel from accidental death, injury, or occupational illness and safeguarding defense systems, infrastructure, and property from accidental destruction, or damage while executing its mission requirements of national defense. Within mission requirements, the DoD will also ensure that the quality of the environment is protected to the maximum extent practical. Integral to these efforts is the use of a system safety approach to identify hazards and manage the associated risks. A key DoD objective is to expand the use of this system safety methodology to integrate risk management into the overall SE process rather than addressing hazards as operational considerations. It should be used not only by system safety professionals, but also by other functional disciplines such as fire protection engineers, occupational health professionals, and environmental engineers to identify hazards and mitigate risks through the SE process. It is not the intent of this document to make system safety personnel responsible for hazard management in other functional disciplines. However, all functional disciplines using this generic methodology should coordinate their efforts as part of the overall SE process because mitigation measures optimized for only one discipline may create hazards in other disciplines.

4. This system safety standard practice identifies the DoD approach for identifying hazards and assessing and mitigating associated risks encountered in the development, test, production, use, and disposal of defense systems. The approach described herein conforms to Department of

Defense Instruction (DoDI) 5000.02. DoDI 5000.02 defines the risk acceptance authorities.

5. This revision incorporates changes to meet Government and industry requests to reinstate task descriptions. These tasks may be specified in contract documents. When this Standard is required in a solicitation or contract, but no specific task is identified, only Sections 3 and 4 are mandatory. The definitions in 3.2 and all of Section 4 delineate the minimum mandatory definitions and requirements for an acceptable system safety effort for any DoD system. This revision aligns the standard practice with current DoD policy; supports DoD strategic plans and goals; and adjusts the organizational arrangement of information to clarify the basic elements of the system safety process, clarify terminology, and define task descriptions to improve hazard management practices. This Standard strengthens integration of other functional disciplines into

SE to ultimately improve consistency of hazard management practices across programs. Specific changes include:

a. Reintroduced task descriptions:

(1) 100-series tasks – Management.

(2) 200-series tasks – Analysis.

iii

(3) 300-series tasks – Evaluation.

(4) 400-series tasks – Verification.

b. Emphasized the identification of applicable technical requirements.

c. Included additional tasks:

(1) Hazardous Materials Management Plan.

(2) Functional Hazard Analysis.

(3) Systems-of-Systems Hazard Analysis.

(4) Environmental Hazard Analysis.

d. Applied increased dollar values for losses in severity descriptions.

e. Added “Eliminated” level for probability.

f. Added software system safety techniques and practices.

g. Updated appendices.

6. Comments, suggestions, or questions on this document should be addressed to

Headquarters Air Force Materiel Command/SES (System Safety Office), 4375 Chidlaw Road, Wright-Patterson Air Force Base, OH 45433-5006 or emailed to afmc.se.mailbox@wpafb.af.mil.

Since contact information can change, you may want to verify the currency of this address information using the Acquisition Streamlining and Standardization Information System

(ASSIST) online database at https://assist.dla.mil.

Downloaded from http://www.everyspec.com mailto:afmc.se.mailbox@wpafb.af.mil https://assist.dla.mil/ iv

CONTENTS

PARAGRAPH PAGE

FOREWORD ......................................................................................................................ii

1. SCOPE

1.1 Scope

2. APPLICABLE DOCUMENTS

2.1 General

2.2 Government documents

2.2.1 Specifications, standards, and handbooks

2.2.2 Other Government documents, drawings, and publications

2.3 Order of precedence

3. DEFINITIONS

3.1 Acronyms

3.2 Definitions

4. GENERAL REQUIREMENTS

4.1 General

4.2 System safety requirements

4.3 System safety process

4.3.1 Document the system safety approach

4.3.2 Identify and document hazards

4.3.3 Assess and document risk

4.3.4 Identify and document risk mitigation measures

4.3.5 Reduce risk

4.3.6 Verify, validate, and document risk reduction

4.3.7 Accept risk and document

4.3.8 Manage life-cycle risk

4.4. Software contribution to system risk

4.4.1 Software assessments

4.4.2 Software safety criticality matrix

4.4.3 Assessment of software contribution to risk

5. DETAILED REQUIREMENTS

5.1 Additional information

5.2 Tasks

5.3 Task structure

6. NOTES

6.1 Intended use

6.2 Acquisition requirements

6.3 Associated Data Item Descriptions (DIDs)

v

6.4 Subject term (key word) listing

6.5 Changes from previous issue

TASK SECTION 100 - MANAGEMENT

TASK 101 HAZARD IDENTIFICATION AND MITIGATION EFFORT USING THE

SYSTEM SAFETY METHODOLOGY

TASK 102 SYSTEM SAFETY PROGRAM PLAN

TASK 103 HAZARD MANAGEMENT PLAN

TASK 104 SUPPORT OF GOVERNMENT REVIEWS/AUDITS

TASK 105 INTEGRATED PRODUCT TEAM/WORKING GROUP SUPPORT

TASK 106 HAZARD TRACKING SYSTEM

TASK 107 HAZARD MANAGEMENT PROGRESS REPORT

TASK 108 HAZARDOUS MATERIALS MANAGEMENT PLAN

TASK SECTION 200 - ANALYSIS

TASK 201 PRELIMINARY HAZARD LIST

TASK 202 PRELIMINARY HAZARD ANALYSIS

TASK 203 SYSTEM REQUIREMENTS HAZARD ANALYSIS

TASK 204 SUBSYSTEM HAZARD ANALYSIS

TASK 205 SYSTEM HAZARD ANALYSIS

TASK 206 OPERATING AND SUPPORT HAZARD ANALYSIS

TASK 207 HEALTH HAZARD ANALYSIS

TASK 208 FUNCTIONAL HAZARD ANALYSIS

TASK 209 SYSTEM-OF-SYSTEMS HAZARD ANALYSIS

TASK 210 ENVIRONMENTAL HAZARD ANALYSIS

TASK SECTION 300 - EVALUATION

TASK 301 SAFETY ASSESSMENT REPORT

TASK 302 HAZARD MANAGEMENT ASSESSMENT REPORT

TASK 303 TEST AND EVALUATION PARTICIPATION

TASK 304 REVIEW OF ENGINEERING CHANGE PROPOSALS, CHANGE NOTICES,

DEFICIENCY REPORTS, MISHAPS, AND REQUESTS FOR

DEVIATION/WAIVER

TASK SECTION 400 - VERIFICATION

TASK 401 SAFETY VERIFICATION

TASK 402 EXPLOSIVES HAZARD CLASSIFICATION DATA

TASK 403 EXPLOSIVE ORDNANCE DISPOSAL DATA

vi

APPENDIX A GUIDANCE FOR THE SYSTEM SAFETY EFFORT

APPENDIX B SOFTWARE SYSTEM SAFETY ENGINEERING AND ANALYSIS

FIGURES PAGE

1. Eight elements of the system safety process

B-1. Assessing software’s contribution to risk

TABLES PAGE

I. Severity categories

II. Probability levels

III. Risk assessment matrix

IV. Software control categories

V. Software safety criticality matrix

VI. Relationship between SwCI, risk level, LOR tasks, and risk

A-I. Task application matrix

A-II. Example probability levels

B-I. Software hazard causal factor risk assessment criteria

1. SCOPE

1.1 Scope. This system safety standard practice identifies the Department of Defense

(DoD) Systems Engineering (SE) approach to eliminating hazards, where possible, and minimizing risks where those hazards cannot be eliminated. DoD Instruction (DoDI) 5000.02 defines the risk acceptance authorities. This Standard covers hazards as they apply to systems / products / equipment / infrastructure (including both hardware and software) throughout design, development, test, production, use, and disposal. When this Standard is required in a solicitation or contract but no specific task is identified, only Sections 3 and 4 are mandatory. The definitions in 3.2 and all of Section 4 delineate the minimum mandatory definitions and requirements for an acceptable system safety effort for any DoD system.

2. APPLICABLE DOCUMENTS

2.1 General. The documents listed in this section are specified in Sections 3, 4, or 5 of this Standard. This section does not include documents cited in other sections of this Standard or recommended for additional information or as examples. While every effort has been made to ensure the completeness of this list, document users are cautioned that they must meet all specified requirements of documents cited in sections 3, 4, or 5 of this standard, whether or not they are listed.

2.2 Government documents.

2.2.1 Specifications, standards, and handbooks. The following specifications, standards, and handbooks form a part of this document to the extent specified herein. Unless otherwise specified, the issues of these documents are those cited in the solicitation or contract.

INTERNATIONAL STANDARDIZATION AGREEMENTS

AOP 52 - North Atlantic Treaty Organization (NATO) Allied

Ordnance Publication (AOP) 52, Guidance on

Software Safety Design and Assessment of

Munitions Related Computing Systems

(Copies of this document are available online at https://assist.dla.mil/quicksearch/ or from the

Standardization Document Order Desk, 700 Robbins Avenue, Building 4D, Philadelphia, PA

19111-5094.)

DEPARTMENT OF DEFENSE HANDBOOKS

No Designator - Joint Software Systems Safety Engineering

Handbook

(Copies of this document are available online at http://www.system-safety.org/links/) https://assist.dla.mil/quicksearch/

2.2.2 Other Government documents, drawings, and publications. The following other

Government documents, drawings, and publications form a part of this document to the extent specified herein. Unless otherwise specified, the issues of these documents are those cited in the solicitation or contract.

DEPARTMENT OF DEFENSE INSTRUCTIONS

DoDI 5000.02 - Operation of the Defense Acquisition System

DoDI 6055.07 - Mishap Notification, Investigation, Reporting, and

Record Keeping

(Copies of these document are available online at http://www.dtic.mil/whs/directives/)

2.3 Order of precedence. In the event of a conflict between the text of this document and the references cited herein, the text of this document takes precedence, with the exception of

DoDI 5000.02. Nothing in this document supersedes applicable laws and regulations unless a specific exemption has been obtained.

3. DEFINITIONS

3.1 Acronyms.

AFOSH Air Force Occupational Safety and Health

ANSI American National Standards Institute

AOP Allied Ordnance Publication

AMSC Acquisition Management Systems Control

ASSIST Acquisition Streamlining and Standardization Information System

ASTM American Society for Testing and Materials

AT Autonomous

CAS Chemical Abstract Service

CDR Critical Design Review

CFR Code of Federal Regulations

COTS Commercial-Off-the-Shelf

DAEHCP Department of Defense Ammunition and Explosives Hazard Classification

Procedures

DID Data Item Description

DoD Department of Defense

DoDI Department of Defense Instruction

DODIC Department of Defense Identification Code

DOT Department of Transportation

DT Developmental Testing

E3 Electromagnetic Environmental Effects

ECP Engineering Change Proposal

EHA Environmental Hazard Analysis

EMD Engineering and Manufacturing Development

EO Executive Order

EOD Explosive Ordnance Disposal

ESD Electrostatic Discharge

ESOH Environment, Safety, and Occupational Health

FHA Functional Hazard Analysis

FMECA Failure Modes and Effects Criticality Analysis

FTA Fault Tree Analysis

GFE Government-Furnished Equipment

GFI Government-Furnished Information

GOTS Government-Off-the-Shelf

HAZMAT Hazardous Material

HERO Hazards of Electromagnetic Radiation to Ordnance

HHA Health Hazard Analysis

HMAR Hazard Management Assessment Report

HMMP Hazardous Materials Management Plan

HMP Hazard Management Plan

HSI Human Systems Integration

HTS Hazard Tracking System

IEEE Institute of Electrical and Electronics Engineers

IM Insensitive Munitions

IMS Integrated Master Schedule

IPT Integrated Product Team

ISO International Organization for Standardization

IV&V Independent Verification and Validation

JCIDS Joint Capabilities Integration and Development System

LOR Level of Rigor

MANPRINT Manpower and Personnel Integration

MIL-HDBK Military Handbook

MIL-STD Military Standard

MSDS Material Safety Data Sheet

NATO North Atlantic Treaty Organization

NAVMC Navy and Marine Corps

NDI Non-Developmental Item

NEPA National Environmental Policy Act

NSI No Safety Impact

NSN National Stock Number

O&SHA Operating and Support Hazard Analysis

OSH Occupational Safety and Health

OSHA Occupational Safety and Health Administration

OT Operational Testing

PESHE Programmatic Environment, Safety, and Occupational Health Evaluation

PDR Preliminary Design Review

PHA Preliminary Hazard Analysis

PHL Preliminary Hazard List

PM Program Manager

PPE Personal Protective Equipment

RAC Risk Assessment Code

RF Radio Frequency

RFP Request for Proposal

RFR Radio Frequency Radiation

RFT Redundant Fault Tolerant

SAR Safety Assessment Report

SAT Semi-Autonomous

SCC Software Control Category

SCF Safety-Critical Function

SCI Safety-Critical Item

SDP Software Development Plan

SE Systems Engineering

SEMP Systems Engineering Management Plan

SHA System Hazard Analysis

SMCC Special Material Content Code

SoS System-of-Systems

SOW Statement of Work

SRHA System Requirements Hazard Analysis

SRF Safety-Related Function

SRI Safety-Related Items

SRR System Requirements Review

SSF Safety-Significant Function

SSCM Software Safety Criticality Matrix

SSHA Subsystem Hazard Analysis

SSPP System Safety Program Plan

SSSF Safety-Significant Software Function

STP Software Test Plan

SwCI Software Criticality Index

T&E Test and Evaluation

TEMP Test and Evaluation Master Plan

TES Test and Evaluation Strategy

WDSSR Waiver or Deviation System Safety Report

WG Working Group

3.2 Definitions. The following mandatory definitions apply when using this Standard.

3.2.1 Acceptable Risk. Risk that the appropriate acceptance authority (as defined in

DoDI 5000.02) is willing to accept without additional mitigation.

3.2.2 Acquisition program. A directed, funded effort that provides a new, improved, or continuing materiel, weapon, or information system or service capability in response to an approved need.

3.2.3 Causal factor. One or several mechanisms that trigger the hazard that may result in a mishap.

3.2.4 Commercial-off-the-shelf (COTS). Commercial items that require no unique

Government modifications or maintenance over the life-cycle of the product to meet the needs of the procuring agency.

3.2.5 Contractor. An entity in private industry that enters into contracts with the

Government to provide goods or services. In this Standard, the word also applies to

Government-operated activities that develop or perform work on acquisition defense programs.

3.2.6 Environmental impact. An adverse change to the environment wholly or partially caused by the system or its use.

3.2.7 ESOH. An acronym that refers to the combination of disciplines that encompass the processes and approaches for addressing laws, regulations, Executive Orders (EO), DoD policies, environmental compliance, and hazards associated with environmental impacts, system safety (e.g., platforms, systems, system-of-systems, weapons, explosives, software, ordnance, combat systems), occupational safety and health, hazardous materials management, and pollution prevention.

3.2.8 Event risk. The risk associated with a hazard as it applies to a specified hardware/software configuration during an event. Typical events include Developmental

Testing/Operational Testing (DT/OT), demonstrations, fielding, post-fielding tests.

3.2.9 Fielding. Placing the system into operational use with units in the field or fleet.

3.2.10 Firmware. The combination of a hardware device and computer instructions or computer data that reside as read-only software on the hardware device. The software cannot be readily modified under program control.

3.2.11 Government-furnished equipment (GFE). Property in the possession of or acquired directly by the Government, and subsequently delivered to or otherwise made available to the contractor for use.

3.2.12 Government-furnished information (GFI). Information in the possession of or acquired directly by the Government, and subsequently delivered to or otherwise made available to the contractor for use. Government furnished information may include items such as lessons learned from similar systems or other data that may not normally be available to non-

Government agencies.

3.2.13 Government-off-the-shelf (GOTS). Hardware or software developed, produced, or owned by a government agency that requires no unique modification over the life-cycle of the product to meet the needs of the procuring agency.

3.2.14 Hazard. A real or potential condition that could lead to an unplanned event or series of events (i.e. mishap) resulting in death, injury, occupational illness, damage to or loss of equipment or property, or damage to the environment.

3.2.15 Hazardous material (HAZMAT). Any item or substance that, due to its chemical, physical, toxicological, or biological nature, could cause harm to people, equipment, or the environment.

3.2.16 Human systems integration (HSI). The integrated and comprehensive analysis, design, assessment of requirements, concepts, and resources for system manpower, personnel, training, safety and occupational health, habitability, personnel survivability, and human factors engineering.

3.2.17 Initial risk. The first assessment of the potential risk of an identified hazard.

Initial risk establishes a fixed baseline for the hazard.

3.2.18 Level of rigor (LOR). A specification of the depth and breadth of software analysis and verification activities necessary to provide a sufficient level of confidence that a safety-critical or safety-related software function will perform as required.

3.2.19 Life-cycle. All phases of the system’s life, including design, research, development, test and evaluation, production, deployment (inventory), operations and support, and disposal.

3.2.20 Mishap. An event or series of events resulting in unintentional death, injury, occupational illness, damage to or loss of equipment or property, or damage to the environment.

For the purposes of this Standard, the term “mishap” includes negative environmental impacts from planned events.

3.2.21 Mitigation measure. Action required to eliminate the hazard or when a hazard cannot be eliminated, reduce the associated risk by lessening the severity of the resulting mishap or lowering the likelihood that a mishap will occur.

3.2.22 Mode. A designated system condition or status (e.g., maintenance, test, operation, storage, transport, and demilitarization).

3.2.23 Monetary Loss. The summation of the estimated costs for equipment repair or replacement, facility repair or replacement, environmental cleanup, personal injury or illness, environmental liabilities, and should include any known fines or penalties resulting from the projected mishap.

3.2.24 Non-developmental item (NDI). Items (hardware, software, communications/ networks, etc.) that are used in the system development program, but are not developed as part of the program. NDIs include, but are not limited to, COTS, GOTS, GFE, re-use items, or previously developed items provided to the program “as is”.

3.2.25 Probability. An expression of the likelihood of occurrence of a mishap.

3.2.26 Program Manager (PM). The designated Government individual with responsibility for and authority to accomplish program objectives for development, production, and sustainment of the system/product/equipment to meet the user’s operational needs. The PM is accountable for credible cost, schedule, and performance reporting to the Milestone Decision

Authority.

3.2.27 Re-use items. Items previously developed under another program or for a separate application that are used in a program.

3.2.28 Risk. A combination of the severity of the mishap and the probability that the mishap will occur.

3.2.29 Risk level. The characterization of risk as either High, Serious, Medium, or Low.

3.2.30 Safety. Freedom from conditions that can cause death, injury, occupational illness, damage to or loss of equipment or property, or damage to the environment.

3.2.31 Safety-critical. A term applied to a condition, event, operation, process, or item whose mishap severity consequence is either Catastrophic or Critical (e.g., safety-critical function, safety-critical path, and safety-critical component).

3.2.32 Safety-critical function (SCF). A function whose failure to operate or incorrect operation will directly result in a mishap of either Catastrophic or Critical severity.

3.2.33 Safety-critical item (SCI). A hardware or software item that has been determined through analysis to potentially contribute to a hazard with Catastrophic or Critical mishap potential, or that may be implemented to mitigate a hazard with Catastrophic or Critical mishap potential. The definition of the term "safety-critical item" in this Standard is independent of the definition of the term "critical safety item" in Public Laws 108-136 and 109-364.

3.2.34 Safety-related. A term applied to a condition, event, operation, process, or item whose mishap severity consequence is either Marginal or Negligible.

3.2.35 Safety-significant. A term applied to a condition, event, operation, process, or item that is identified as either safety-critical or safety-related.

3.2.36 Severity. The magnitude of potential consequences of a mishap to include:

death, injury, occupational illness, damage to or loss of equipment or property, damage to the environment, or monetary loss.

3.2.37 Software. A combination of associated computer instructions and computer data that enable a computer to perform computational or control functions. Software includes computer programs, procedures, rules, and any associated documentation pertaining to the operation of a computer system. Software includes new development, complex programmable logic devices (firmware), NDI, COTS, GOTS, re-used, GFE, and Government-developed software used in the system.

3.2.38 Software control category. An assignment of the degree of autonomy, command and control authority, and redundant fault tolerance of a software function in context with its system behavior.

3.2.39 Software re-use. The use of a previously developed software module or software package in a software application for a developmental program.

3.2.40 Software system safety. The application of system safety principles to software.

3.2.41 System. The organization of hardware, software, material, facilities, personnel, data, and services needed to perform a designated function within a stated environment with specified results.

3.2.42 System-of-systems (SoS). A set or arrangement of interdependent systems that are related or connected to provide a given capability.

3.2.43 System safety. The application of engineering and management principles, criteria, and techniques to achieve acceptable risk within the constraints of operational effectiveness and suitability, time, and cost throughout all phases of the system life-cycle.

3.2.44 System safety engineering. An engineering discipline that employs specialized knowledge and skills in applying scientific and engineering principles, criteria, and techniques to identify hazards and then to eliminate the hazards or reduce the associated risks when the hazards cannot be eliminated.

3.2.45 System safety management. All plans and actions taken to identify hazards;

assess and mitigate associated risks; and track, control, accept, and document risks encountered in the design, development, test, acquisition, use, and disposal of systems, subsystems, equipment, and infrastructure.

3.2.46 System/subsystem specification. The system-level functional and performance requirements, interfaces, adaptation requirements, security and privacy requirements, computer resource requirements, design constraints (including software architecture, data standards, and programming language), software support, precedence requirements, and developmental test requirements for a given system.

3.2.47 Systems engineering. The overarching process that a program team applies to transition from a stated capability to an operationally effective and suitable system. Systems

Engineering involves the application of SE processes across the acquisition life-cycle (adapted to every phase) and is intended to be the integrating mechanism for balanced solutions addressing capability needs, design considerations, and constraints. SE also addresses limitations imposed by technology, budget, and schedule. SE processes are applied early in material solution analysis and continuously throughout the total life-cycle.

3.2.48 Target risk. The projected risk level the PM plans to achieve by implementing mitigation measures consistent with the design order of precedence described in 4.3.4.

3.2.49 User representative. For fielding events, a Command or agency that has been formally designated in the Joint Capabilities Integration and Development System (JCIDS) process to represent single or multiple users in the capabilities and acquisition process. For non-fielding events, the user representative will be the Command or agency responsible for the personnel, equipment, and environment exposed to the risk. For all events, the user representative will be at a peer level equivalent to the risk acceptance authority.

4. GENERAL REQUIREMENTS

4.1 General. When this Standard is required in a solicitation or contract, but no specific tasks are included, only Sections 3 and 4 apply. The definitions in 3.2 and all of Section 4 delineate the minimum mandatory definitions and requirements for an acceptable system safety effort for any DoD system.

4.2 System safety requirements. Section 4 defines the system safety requirements throughout the life-cycle for any system. When properly applied, these requirements should enable the identification and management of hazards and their associated risks during system developmental and sustaining engineering activities. It is not the intent of this document to make system safety personnel responsible for hazard management in other functional disciplines.

However, all functional disciplines using this generic methodology should coordinate their efforts as part of the overall SE process because mitigation measures optimized for only one discipline may create hazards in other disciplines.

4.3 System safety process. The system safety process consists of eight elements. Figure 1 depicts the typical logic sequence of the process. However, iteration between steps may be required.

Element 1:

Document the System

Safety Approach

Element 5:

Reduce Risk

Element 2:

Identify and

Document Hazards

Element 6:

Verify, Validate and

Document Risk Reduction

Element 3:

Assess and

Document Risk

Element 7:

Accept Risk and Document

Element 4:

Identify and Document

Risk Mitigation Measures

Element 8:

Manage Life-Cycle Risk

FIGURE 1. Eight elements of the system safety process

4.3.1 Document the system safety approach. The PM and contractor shall document the system safety approach for managing hazards as an integral part of the SE process. The minimum requirements for the approach include:

a. Describing the risk management effort and how the program is integrating risk management into the SE process, the Integrated Product and Process Development process, and the overall program management structure.

b. Identifying and documenting the prescribed and derived requirements applicable to the system. Examples include Insensitive Munitions (IM) requirements, Electromagnetic

Environmental Effects (E3) requirements, pollution prevention mandates, design requirements, technology considerations, and occupational and community noise standards. Once the requirements are identified, ensure their inclusion in the system specifications and the flow-down of applicable requirements to subcontractors, vendors, and suppliers.

c. Defining how hazards and associated risks are formally accepted by the appropriate risk acceptance authority and concurred with by the user representative in accordance with DoDI

5000.02.

d. Documenting hazards with a closed-loop Hazard Tracking System (HTS). The HTS will include, as a minimum, the following data elements: identified hazards, associated mishaps, risk assessments (initial, target, event(s)), identified risk mitigation measures, selected mitigation measures, hazard status, verification of risk reductions, and risk acceptances. Both the contractor and Government shall have access to the HTS with appropriate controls on data management.

The Government shall receive and retain “government purpose rights” of all the data recorded in the HTS and any other items (i.e., studies, analyses, test data, notes or similar data) generated in the performance of the contract with respect to the HTS.

4.3.2 Identify and document hazards. Hazards are identified through a systematic analysis process that includes system hardware and software, system interfaces (to include human interfaces), and the intended use or application and operational environment. Consider and use mishap data; relevant environmental and occupational health data; user physical characteristics; user knowledge, skills, and abilities; and lessons learned from legacy and similar systems. The hazard identification process shall consider the entire system life-cycle and potential impacts to personnel, infrastructure, defense systems, the public, and the environment.

Identified hazards shall be documented in the HTS.

4.3.3 Assess and document risk. The severity category and probability level of the potential mishap(s) for each hazard across all system modes are assessed using the definitions in

Tables I and II.

a. To determine the appropriate severity category as defined in Table I for a given hazard at a given point in time, identify the potential for death or injury, environmental impact, or monetary loss. A given hazard may have the potential to affect one or all of these three areas.

TABLE I. Severity categories

SEVERITY CATEGORIES

Description Severity Category

Mishap Result Criteria

Catastrophic 1 Could result in one or more of the following: death, permanent total disability, irreversible significant environmental impact, or monetary loss equal to or exceeding $10M.

Critical 2

Could result in one or more of the following: permanent partial disability,injuries or occupational illness that may result in hospitalization of at least three personnel, reversible significant environmental impact, or monetary loss equal to or exceeding $1M but less than $10M.

Marginal 3 Could result in one or more of the following: injury or occupational illness resulting in one or more lost work day(s), reversible moderate environmental impact, or monetary loss equal to or exceeding $100K but less than $1M.

Negligible 4 Could result in one or more of the following: injury or occupational illness not resulting in a lost work day, minimal environmental impact, or monetary loss less than $100K.

b. To determine the appropriate probability level as defined in Table II for a given hazard at a given point in time, assess the likelihood of occurrence of a mishap. Probability level

F is used to document cases where the hazard is no longer present. No amount of doctrine, training, warning, caution, or Personal Protective Equipment (PPE) can move a mishap probability to level F.

TABLE II. Probability levels

PROBABILITY LEVELS

Description Level Specific Individual Item Fleet or Inventory

Frequent A Likely to occur often in the life of an item. Continuously experienced.

Probable B Will occur several times in the life of an item. Will occur frequently.

Occasional C Likely to occur sometime in the life of an item. Will occur several times.

Remote D Unlikely, but possible to occur in the life of an item.

Unlikely, but can reasonably be expected to occur.

Improbable E So unlikely, it can be assumed occurrence may not be experienced in the life of an item.

Unlikely to occur, but possible.

Eliminated F Incapable of occurence. This level is used when potential hazards are identified and later eliminated.

Incapable of occurence. This level is used when potential hazards are identified and later eliminated.

(1) When available, the use of appropriate and representative quantitative data that defines frequency or rate of occurrence for the hazard, is generally preferable to qualitative analysis. The Improbable level is generally considered to be less than one in a million. See

Appendix A for an example of quantitative probability levels.

(2) In the absence of such quantitative frequency or rate data, reliance upon the qualitative text descriptions in Table II is necessary and appropriate.

c. Assessed risks are expressed as a Risk Assessment Code (RAC) which is a combination of one severity category and one probability level. For example, a RAC of 1A is the combination of a Catastrophic severity category and a Frequent probability level. Table III assigns a risk level of High, Serious, Medium, or Low for each RAC.

TABLE III. Risk assessment matrix

RISK ASSESSMENT MATRIX

SEVERITY

PROBABILITY

Catastrophic (1)

Critical (2)

Marginal (3)

Negligible (4)

Frequent (A)

High High Serious Medium

Probable (B)

High High Serious Medium

Occasional (C)

High Serious Medium Low

Remote (D)

Serious Medium Medium Low

Improbable (E)

Medium Medium Medium Low

Eliminated (F)

Eliminated

d. The definitions in Tables I and II, and the RACs in Table III shall be used, unless tailored alternative definitions and/or a tailored matrix are formally approved in accordance with

DoD Component policy. Alternates shall be derived from Tables I through III.

e. The Program shall document all numerical definitions of probability used in risk assessments as required by 4.3.1. Assessed risks shall be documented in the HTS.

4.3.4 Identify and document risk mitigation measures. Potential risk mitigation(s) shall be identified, and the expected risk reduction(s) of the alternative(s) shall be estimated and documented in the HTS. The goal should always be to eliminate the hazard if possible. When a hazard cannot be eliminated, the associated risk should be reduced to the lowest acceptable level within the constraints of cost, schedule, and performance by applying the system safety design order of precedence. The system safety design order of precedence identifies alternative mitigation approaches and lists them in order of decreasing effectiveness.

a. Eliminate hazards through design selection. Ideally, the hazard should be eliminated by selecting a design or material alternative that removes the hazard altogether.

b. Reduce risk through design alteration. If adopting an alternative design change or material to eliminate the hazard is not feasible, consider design changes that reduce the severity and/or the probability of the mishap potential caused by the hazard(s).

c. Incorporate engineered features or devices. If mitigation of the risk through design alteration is not feasible, reduce the severity or the probability of the mishap potential caused by the hazard(s) using engineered features or devices. In general, engineered features actively interrupt the mishap sequence and devices reduce the risk of a mishap.

d. Provide warning devices. If engineered features and devices are not feasible or do not adequately lower the severity or probability of the mishap potential caused by the hazard, include detection and warning systems to alert personnel to the presence of a hazardous condition or occurrence of a hazardous event.

e. Incorporate signage, procedures, training, and PPE. Where design alternatives, design changes, and engineered features and devices are not feasible and warning devices cannot adequately mitigate the severity or probability of the mishap potential caused by the hazard, incorporate signage, procedures, training, and PPE. Signage includes placards, labels, signs and other visual graphics. Procedures and training should include appropriate warnings and cautions.

Procedures may prescribe the use of PPE. For hazards assigned Catastrophic or Critical mishap severity categories, the use of signage, procedures, training, and PPE as the only risk reduction method should be avoided.

4.3.5 Reduce risk. Mitigation measures are selected and implemented to achieve an acceptable risk level. Consider and evaluate the cost, feasibility, and effectiveness of candidate mitigation methods as part of the SE and Integrated Product Team (IPT) processes. Present the current hazards, their associated severity and probability assessments, and status of risk reduction efforts at technical reviews.

4.3.6 Verify, validate, and document risk reduction. Verify the implementation and validate the effectiveness of all selected risk mitigation measures through appropriate analysis, testing, demonstration, or inspection. Document the verification and validation in the HTS.

4.3.7 Accept risk and document. Before exposing people, equipment, or the environment to known system-related hazards, the risks shall be accepted by the appropriate authority as defined in DoDI 5000.02. The system configuration and associated documentation that supports the formal risk acceptance decision shall be provided to the Government for retention through the life of the system. The definitions in Tables I and II, the RACs in Table III, and the criteria in Table VI for software shall be used to define the risks at the time of the acceptance decision, unless tailored alternative definitions and/or a tailored matrix are formally approved in accordance with DoD Component policy. The user representative shall be part of this process throughout the life-cycle of the system and shall provide formal concurrence before all Serious and High risk acceptance decisions. After fielding, data from mishap reports, user feedback, and experience with similar systems or other sources may reveal new hazards or demonstrate that the risk for a known hazard is higher or lower than previously recognized. In these cases, the revised risk shall be accepted in accordance with DoDI 5000.02.

NOTE: A single system may require multiple event risk assessments and acceptances throughout its life-cycle. Each risk acceptance decision shall be documented in the HTS.

4.3.8 Manage life-cycle risk. After the system is fielded, the system program office uses the system safety process to identify hazards and maintain the HTS throughout the system’s life-cycle. This life-cycle effort considers any changes to include, but not limited to, the interfaces, users, hardware and software, mishap data, mission(s) or profile(s), and system health data.

Procedures shall be in place to ensure risk management personnel are aware of these changes, e.g., by being part of the configuration control process. The program office and user community shall maintain effective communications to collaborate, identify, and manage new hazards and modified risks. If a new hazard is discovered or a known hazard is determined to have a higher risk level than previously assessed, the new or revised risk will need to be formally accepted in accordance with DoDI 5000.02. In addition, DoD requires program offices to support system-related Class A and B (as defined in Department of Defense Instruction 6055.07) mishap investigations by providing analyses of hazards that contributed to the mishap and recommendations for materiel risk mitigation measures, especially those that minimize human errors.

4.4 Software contribution to system risk. The assessment of risk for software, and consequently software-controlled or software-intensive systems, cannot rely solely on the risk severity and probability. Determining the probability of failure of a single software function is difficult at best and cannot be based on historical data. Software is generally application-specific and reliability parameters associated with it cannot be estimated in the same manner as hardware.

Therefore, another approach shall be used for the assessment of software’s contributions to system risk that considers the potential risk severity and the degree of control that software exercises over the hardware.

4.4.1 Software assessments. Tables IV through VI shall be used, unless tailored alternative matrices are formally approved in accordance with DoD Component policy. The degree of software control is defined using the Software Control Categories (SCC) in Table IV

(or approved tailored alternative). Table V provides the Software Safety Criticality Matrix

(SSCM) based on Table I severity categories (or approved tailored severity categories) and Table

IV SCCs. The SSCM establishes the Software Criticality Indices (SwCIs) used to define the required LOR tasks. Table VI provides the relationship between the SwCI, the LOR tasks, and how not meeting the LOR task requirements affects software’s contribution to risk.

a. All SCCs should be re-evaluated if legacy software functions are included in a SoS environment. The legacy functions should be evaluated at both the functional and physical interfaces for potential influence or participation in top-level SoS mishap and hazard causal factors.

b. The system safety and software system safety hazard analysis processes identify and mitigate the exact software contributors to hazards and mishaps. The successful execution of pre-defined LOR tasks increases the confidence that the software will perform as specified to software performance requirements, while reducing the number of contributors to hazards that may exist in the system. Both processes are essential in reducing the likelihood of software initiating a propagation pathway to a hazardous condition or mishap. Appendix B provides guidance for developing acceptable LOR tasks.

TABLE IV. Software control categories

SOFTWARE CONTROL CATEGORIES

Level Name Description

Autonomous

(AT)

Software functionality that exercises autonomous control authority over potentially safety-significant hardware systems, subsystems, or components without the possibility of predetermined safe detection and intervention by a control entity to preclude the occurrence of a mishap or hazard.

(This definition includes complex system/software functionality with multiple subsystems, interacting parallel processors, multiple interfaces, and safety-critical functions that are time critical.)

Semi-

Autonomous

(SAT)

Software functionality that exercises control authority over potentially safety-significant hardware systems, subsystems, or components, allowing time for predetermined safe detection and intervention by independent safety mechanisms to mitigate or control the mishap or hazard.

(This definition includes the control of moderately complex system/software functionality, no parallel processing, or few interfaces, but other safety systems/mechanisms can partially mitigate. System and software fault detection and annunciation notifies the control entity of the need for required safety actions.)

Software item that displays safety-significant information requiring immediate operator entity to execute a predetermined action for mitigation or control over a mishap or hazard.

Software exception, failure, fault, or delay will allow, or fail to prevent, mishap occurrence.

(This definition assumes that the safety-critical display information may be time-critical, but the time available does not exceed the time required for adequate control entity response and hazard control.)

Redundant

Fault Tolerant

(RFT)

Software functionality that issues commands over safety-significant hardware systems, subsystems, or components requiring a control entity to complete the command function.

The system detection and functional reaction includes redundant, independent fault tolerant mechanisms for each defined hazardous condition.

(This definition assumes that there is adequate fault detection, annunciation, tolerance, and system recovery to prevent the hazard occurrence if software fails, malfunctions, or degrades. There are redundant sources of safety-significant information, and mitigating functionality can respond within any time-critical period.)

Software that generates information of a safety-critical nature used to make critical decisions. The system includes several redundant, independent fault tolerant mechanisms for each hazardous condition, detection and display.

4 Influential Software generates information of a safety-related nature used to make decisions by the operator, but does not require operator action to avoid a mishap.

No Safety

Impact

(NSI)

Software functionality that does not possess command or control authority over safety-significant hardware systems, subsystems, or components and does not provide safety-significant information. Software does not provide safety-significant or time sensitive data or information that requires control entity interaction. Software does not transport or resolve communication of safety-significant or time sensitive data.

4.4.2 Software Safety Criticality Matrix. The SSCM (Table V) uses Table I severity categories for the columns and Table IV software control categories for the rows. Table V assigns SwCI numbers to each cross-referenced block of the matrix. The SSCM shall define the

LOR tasks associated with the specific SwCI. Although it is similar in appearance to the Risk

Assessment Matrix (Table III), the SSCM is not an assessment of risk. The LOR tasks associated with each SwCI are the minimum set of tasks required to assess the software contributions to the system-level risk.

TABLE V. Software safety criticality matrix

SOFTWARE SAFETY CRITICALITY MATRIX

SEVERITY CATEGORY

SOFTWARE

CONTROL

CATEGORY

Catastrophic (1)

Critical (2)

Marginal (3)

Negligible (4)

1 SwCI 1 SwCI 1 SwCI 3 SwCI 4

2 SwCI 1 SwCI 2 SwCI 3 SwCI 4

3 SwCI 2 SwCI 3 SwCI 4 SwCI 4

4 SwCI 3 SwCI 4 SwCI 4 SwCI 4

5 SwCI 5 SwCI 5 SwCI 5 SwCI 5

SwCI Level of Rigor Tasks

SwCI 1 Program shall perform analysis of requirements, architecture, design, and code; and conduct in-depth safety-specific testing.

SwCI 2 Program shall perform analysis of requirements, architecture, and design; and conduct in-depth safety-specific testing.

SwCI 3 Program shall perform analysis of requirements and architecture; and conduct in-depth safety-specific testing.

SwCI 4 Program shall conduct safety-specific testing.

SwCI 5 Once assessed by safety engineering as Not Safety, then no safety specific analysis or verification is required.

NOTE: Consult the Joint Software Systems Safety Engineering Handbook and AOP 52 for additional guidance on how to conduct required software analyses.

4.4.3 Assessment of software contribution to risk. All software contributions to system risk, including any results of Table VI application, shall be documented in the HTS.

a. The Table V LOR tasks shall be performed to assess the software contributions to the system-level risk. Results of the LOR tasks provide a level of confidence in safety-significant software and document causal factors and hazards that may require mitigation. Results of the

LOR tasks shall be included in the risk management process. Appendix B provides an example of how to assign a risk level to software contributions to system risk identified by completing the

LOR analysis.

b. If the required LOR tasks are not performed, then the system risk(s) contributions associated with unspecified or incomplete LOR tasks shall be documented according to Table

VI. Table VI depicts the relationship between SwCI, risk levels, completion of LOR tasks, and risk assessment.

c. All software contributions to system risk, including any results of Table VI application, shall be documented in the HTS. Perform risk acceptance in accordance with DoDI

5000.02.

TABLE VI. Relationship between SwCI, risk level, LOR tasks, and risk

RELATIONSHIP BETWEEN SwCI, RISK LEVEL, LOR Tasks, AND RISK

Software Criticality

Index (SwCI)

Risk Level

Software LOR Tasks and Risk Assessment/Acceptance

SwCI 1 High

If SwCI 1 LOR tasks are unspecified or incomplete, the contributions to system risk will be documented as HIGH and provided to the PM for decision. The PM shall document the decision of whether to expend the resources required to implement SwCI 1 LOR tasks or prepare a formal risk assessment for acceptance of a HIGH risk.

SwCI 2 Serious

If SwCI 2 LOR tasks are unspecified or incomplete, the contributions to system risk will be documented as SERIOUS and provided to the PM for decision.

The PM shall document the decision of whether to expend the resources required to implement SwCI 2 LOR tasks or prepare a formal risk assessment for acceptance of a SERIOUS risk.

SwCI 3 Medium

If SwCI 3 LOR tasks are unspecified or incomplete, the contributions to system risk will be documented as MEDIUM and provided to the PM for decision. The PM shall document the decision of whether to expend the resources required to implement SwCI 3 LOR tasks or prepare a formal risk assessment for acceptance of a MEDIUM risk.

SwCI 4 Low

If SwCI 4 LOR tasks are unspecified or incomplete, the contributions to system risk will be documented as LOW and provided to the PM for decision. The PM shall document the decision of whether to expend the resources required to implement SwCI 4 LOR tasks or prepare a formal risk assessment for acceptance of a LOW risk.

SwCI 5 Not Safety No safety-specific analyses or testing is required.

5. DETAILED REQUIREMENTS

5.1 Additional information. Individual tasks, Appendix A, and Appendix B contain optional information for developing program-specific requirements.

5.2 Tasks. The tasks in this Standard can be selectively applied to fit a tailored system safety effort. The 100-series tasks apply to management. The 200-series tasks apply to analysis.

The 300-series tasks apply to evaluation. The 400-series tasks apply to verification. Each desired task shall be specifically called out in a contract because the task descriptions do not include requirements for any other tasks.

5.3 Task structure. Each individual task is divided into three parts—purpose, task description, and details to be specified.

a. The purpose explains the rationale for performing the task.

b…