Scribd
Upload
47 views3 pages

Hazards and Risk

A hazard analysis is the first step in assessing risk. It identifies different types of hazards and their potential to cause failures or accidents alone or in combination with other hazards and conditions. Each scenario has a probability of occurrence and is assigned a severity classification based on worst case outcome. Risk is determined by combining probability and severity. The goal of hazard analysis and risk assessment is to control or eliminate risks.

Uploaded by

Dana
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
47 views3 pages

Hazards and Risk

A hazard analysis is the first step in assessing risk. It identifies different types of hazards and their potential to cause failures or accidents alone or in combination with other hazards and conditions. Each scenario has a probability of occurrence and is assigned a severity classification based on worst case outcome. Risk is determined by combining probability and severity. The goal of hazard analysis and risk assessment is to control or eliminate risks.

Uploaded by

Dana
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 3

A hazard analysis is used as the first step in a process used to assess risk.

The result of a hazard analysis is


the identification of different type of hazards. A hazard is a potential condition and exists or not (probability is 1
or 0). It may in single existence or in combination with other hazards (sometimes called events) and conditions
become an actual Functional Failure or Accident (Mishap). The way this exactly happens in one particular
sequence is called a scenario. This scenario has a probability (between 1 and 0) of occurrence. Often a system
has many potential failure scenarios. It also is assigned a classification, based on the worst case severity of the
end condition. Risk is the combination of probability and severity. Preliminary risk levels can be provided in the
hazard analysis. The validation, more precise prediction (verification) and acceptance of risk is determined in
the Risk assessment (analysis). The main goal of both is to provide the best selection of means of controlling or
eliminating the risk. The term is used in several engineering specialties, including avionics, chemical process
safety, safety engineering, reliability engineering and food safety.[1]

Contents

 1Hazards and risk


 2Severity definitions - Safety Related
 3Likelihood of occurrence
 4See also
 5Further reading
 6External links

Hazards and risk[edit]


A hazard is defined as a "Condition, event, or circumstance that could lead to or contribute to an unplanned or
undesirable event." Seldom does a single hazard cause an accident or a functional failure. More often an
accident or operational failure occurs as the result of a sequence of causes. A hazard analysis will consider
system state, for example operating environment, as well as failures or malfunctions.
While in some cases, safety or reliability risk can be eliminated, in most cases a certain degree of risk must be
accepted. In order to quantify expected costs before the fact, the potential consequences and the probability of
occurrence must be considered. Assessment of risk is made by combining the severity of consequence with the
likelihood of occurrence in a matrix. Risks that fall into the "unacceptable" category (e.g., high severity and high
probability) must be mitigated by some means to reduce the level of safety risk.
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-178B. 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.
Recently 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 definitions - Safety Related[edit]


Severity Definition

Catastrophic Results in multiple fatalities and/or loss of the system

Reduces the capability of the system or the operator ability to cope with adverse conditions to
Hazardous the extent that there would be:

 Large reduction in safety margin or functional capability


 Crew physical distress/excessive workload such that operators cannot be relied upon to
perform required tasks accurately or completely
 Serious or fatal injury to small number of occupants of aircraft (except operators)
 Fatal injury to ground personnel and/or general public
Reduces the capability of the system or the operators to cope with adverse operating
conditions to the extent that there would be:

 Significant reduction in safety margin or functional capability


Major  Significant increase in operator workload
 Conditions impairing operator efficiency or creating significant discomfort
 Physical distress to occupants of aircraft (except operator) including injuries
 Major occupational illness and/or major environmental damage, and/or major property
damage
Does not significantly reduce system safety. Actions required by operators are well within
their capabilities. Include:

 Slight reduction in safety margin or functional capabilities


Minor
 Slight increase in workload such as routine flight plan changes
 Some physical discomfort to occupants or aircraft (except operators)
 Minor occupational illness and/or minor environmental damage, and/or minor property
damage
No Safety
Has no effect on safety
Effect

Likelihood of occurrence[edit]
Likelihood Definition

 Qualitative: Anticipated to occur one or more times during the entire


system/operational life of an item.
Probable
 Quantitative: Probability of occurrence per operational hour is greater than
 Qualitative: Unlikely to occur to each item during its total life. May occur several times
in the life of an entire system or fleet.

Remote
 Quantitative: Probability of occurrence per operational hour is less than , but

greater than
 Qualitative: Not anticipated to occur to each item during its total life. May occur a few
times in the life of an entire system or fleet.
Extremely
Remote  Quantitative: Probability of occurrence per operational hour is less than but

greater than
 Qualitative: So unlikely that it is not anticipated to occur during the entire operational
Extremely life of an entire system or fleet.
Improbable
 Quantitative: Probability of occurrence per operational hour is less than

See also[edit]
 Medical Device Risk Management - ISO 14971
 Failure mode and effects analysis
 Fault tree analysis
 Hazard and operability study, also known as HAZOP
 Hazard Potential Case
 SWIFT
 Safety engineering
 Reliability engineering
 Occupational safety and health – Field concerned with the safety, health, and welfare of people at work
 RTCA DO-178B (Software Considerations in Airborne Systems and Equipment Certification)
 RTCA DO-178C
 RTCA DO-254 (similar to DO-178B, but for hardware)
 SAE ARP4761 (System safety assessment process)
 SAE ARP4754 (System development process)
 MIL-STD-882 (Standard practice for system safety)
 ANSI/GEIA-STD-0010-2009 (Standard Best Practices for System Safety Program Development and
Execution)
 IEEE STD 1228-1994 Software Safety Plans
 IEEE STD 1584-2002 IEEE Guide for Performing Arc Flash Hazard Calculations

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.

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.

You might also like