Contents

Hazard analysis

A Simple Hazard Analysis[edit]

The first step in hazard analysis is to identify the hazards. If an automobile is an object performing an activity such as driving over a bridge, and that bridge may become icy, then an icy bridge might be identified as a hazard. If this hazard is encountered, it could cause or contribute to the occurrence of an automobile accident, and the outcome of that occurrence could range in severity from a minor fender-bender to a fatal accident.^{[citation needed]}

Managing Risk through Hazard Analysis[edit]

A hazard analysis may be used to inform decisions regarding the mitigation of risk. For instance, the probability of encountering an icy bridge may be reduced by adding salt such that the ice will melt. Or, risk mitigation strategies may target the occurrence. For instance, putting tire chains on a vehicle does nothing to change the probability of a bridge becoming icy, but if an icy bridge is encountered, it does improve traction, reducing the chance of a sliding into another vehicle. Finally, risk may be managed by influencing the severity of outcomes. For instance, seatbelts and airbags do nothing to prevent bridges from becoming icy, nor do they prevent accidents caused by that ice. However, in the event of an accident, these devices lower the probability of the accident resulting in fatal or serious injuries.^{[citation needed]}

Software Hazard Analysis[edit]

IEEE STD-1228-1994 Software Safety Plans prescribes industry best practices for conducting software safety hazard analyses to help ensure safety requirements and attributes are defined and specified for inclusion in software that commands, controls or monitors critical functions. When software is involved in a system, the development and design assurance of that software is often governed by DO-178C. The severity of consequence identified by the hazard analysis establishes the criticality level of the software. Software criticality levels range from A to E, corresponding to the severity of Catastrophic to No Safety Effect. Higher levels of rigor are required for level A and B software and corresponding functional tasks and work products is the system safety domain are used as objective evidence of meeting safety criteria and requirements.^{[citation needed]}

In 2009^[1] a leading edge commercial standard was promulgated based on decades of proven system safety processes in DoD and NASA. ANSI/GEIA-STD-0010-2009 (Standard Best Practices for System Safety Program Development and Execution) is a demilitarized commercial best practice that uses proven holistic, comprehensive and tailored approaches for hazard prevention, elimination and control. It is centered around the hazard analysis and functional based safety process.

Severity category examples[edit]

When used as part of an aviation hazard analysis, "Severity" describes the outcome (the degree of loss or harm) that results from an occurrence (an aircraft accident or incident). When categorized, severity categories must be mutually exclusive such that every occurrence has one, and only one, severity category associated with it. The definitions must also be collectively exhaustive such that all occurrences fall into one of the categories. In the US, the FAA includes five severity categories as part of its safety risk management policy. ^[2]

(medical devices)

Likelihood category examples[edit]

When used as part of an aviation hazard analysis, a "Likelihood" is a specific probability. It is the joint probabilty of a hazard occurring, that hazard causing or contributing to an aircraft accident or incident, and the resulting degree of loss or harm falling within one of the defined severity categories. Thus, if there are five severity categories, each hazard will have five likelihoods. In the US, the FAA provides a continuous probabilty scale for measuring likelihood, but also includes seven likelihood categories as part of its safety risk management policy. ^[2]

Likelihood	Definition
Likelihood A - Frequent	Probability < 1 but >= ${\displaystyle 1\times 10^{-5}}$
Likelihood B - Infrequent	Probability < ${\displaystyle 1\times 10^{-5}}$ but >= ${\displaystyle 1\times 10^{-6}}$
Likelihood C - Extremely Infrequent	Probability < ${\displaystyle 1\times 10^{-6}}$ but >= ${\displaystyle 1\times 10^{-7}}$
Likelihood D - Remote	Probability < ${\displaystyle 1\times 10^{-7}}$ but >= ${\displaystyle 1\times 10^{-8}}$
Likelihood E - Extremetly Remote	Probability < ${\displaystyle 1\times 10^{-8}}$ but >= ${\displaystyle 1\times 10^{-9}}$
Likelihood F - Improbable	Probability < ${\displaystyle 1\times 10^{-9}}$ but >= ${\displaystyle 1\times 10^{-10}}$
Likelihood G - Extremely Improbable	Probability < ${\displaystyle 1\times 10^{-10}}$ but > 0

(medical devices)

See also[edit]

• Environmental hazard – Harmful substance, a condition or an event
• Failure mode and effects analysis – Analysis of potential system failures
• Fault tree analysis – Failure analysis system used in safety engineering and reliability engineering
• Hazard and operability study (HAZOP) – Study of risks in a plan or operation
• Layers of protection analysis (LOPA) – Technique for evaluating the hazards, risks and layers of protection of a system
• Medical Device Risk Management - ISO 14971 – ISO standard
• Occupational safety and health – Field concerned with the safety, health and welfare of people at work
• Reliability engineering – Sub-discipline of systems engineering that emphasizes dependability
• RTCA DO-178B – RTCA standard for safety-critical software (Software Considerations in Airborne Systems and Equipment Certification)
• RTCA DO-178C – International aeronautics software standard
• RTCA DO-254 – Document for guidance of airborne electronic hardware (similar to DO-178B, but for hardware)
• SAE ARP4754 – Aerospace Practice (System development process)
• SAE ARP4761 – Aerospace recommended practice from SAE International (System safety assessment process)
• Safety engineering – Engineering discipline which assures that engineered systems provide acceptable levels of safety
• Structured what-if technique (SWIFT) – Method of prospective hazards analysis

Further reading[edit]

• Center for Chemical Process Safety (1992). Guidelines for Hazard Evaluation Procedures, with Worked Examples (2nd ed.). Wiley-American Institute Of Chemical Engineers. ISBN 0-8169-0491-X.
• Bahr, Nicholas J. (1997). System Safety Engineering and Risk Assessment: A Practical Approach (Chemical Engineering) (1st ed.). Taylor & Francis Group. ISBN 1-56032-416-3.
• Kletz, Trevor (1999). Hazop and Hazan (4th ed.). Taylor & Francis. ISBN 0-85295-421-2.

Notes[edit]

References[edit]

FAA (September 29, 2023). "Safety Risk Management Policy (FAA Order 8040.4C)" (PDF). Retrieved May 6, 2024.

External links[edit]

• CFR, Title 29-Labor, Part 1910--Occupational Safety and Health Standards, § 1910.119
  U.S. OSHA regulations regarding "Process safety management of highly hazardous chemicals" (especially Appendix C).
• FAA Order 8040.4 establishes FAA safety risk management policy.
• The FAA publishes a System Safety Handbook that provides a good overview of the system safety process used by the agency.
• IEEE 1584-2002 Standard which provides guidelines for doing arc flash hazard assessment.