2. Layer of protection analysis (LOPA) is a semi-
quantitative tool for analyzing and assessing
risk.
History of LOPA
In a typical chemical process, various protection layers
are in place to lower the frequency of undesired
consequences:
• The process design (including inherently safer concepts);
• The basic process control system;
• Safety instrumented systems;
• Passive devices (such as dikes and blast walls);
• Active devices (such as relief valves);
• Human intervention; etc.
3. Decisions regarding the number of and
strength of protection layers were made
using subjective arguments, emotional
appeals, and occasionally simply by the
loudness or persistence of an individual.
KEY QUESTIONS FOR PROTECTION LAYERS
• How safe is safe enough?
• How many protection layers are needed?
• How much risk reduction should each layer
provide?
4. LOPA answers the key questions about the
number and strength of protection layers
by
• Providing rational, semi-quantitative, risk-
based answers,
• Reducing emotionalism,
• Providing clarity and consistency,
• Documenting the basis of the decision,
• Facilitating understanding among plant
personnel.
5. Use of LOPA in the Process Life Cycle
• The design stage when the process flow
diagram and the P&IDs are essentially
complete. LOPA is used to examine
scenarios, often generated by other
process hazard analysis (PHA) tools,
such as HAZOP, what-if, checklist, etc.
• Modifications to an existing process or
its control or safety systems (i.e.,
management of change).
7. LOPA can also be used in all phases of the process life
cycle such as:
• Initial conceptual process design.
• Regular cycle of process hazard analyses (PHAs)
performed on a process.
• To determine if the risk is tolerable for a process, or If
an SIF is required.
• Reliability of equipments used in a process.
• To identify operator actions and responses that are
critical to the safety of the process.
• Also used for risk assessment of transportation
studies (road, rail, pipelines etc.) , auditing, loss
prevention, insurance issues etc.
8. What is LOPA?
LOPA is a simplified form of risk assessment.
LOPA typically uses order of magnitude
categories for initiating event frequency,
consequence severity, and the likelihood of
failure of independent protection layers (IPLs)
to approximate the risk of a scenario.
The primary purpose of LOPA is to determine
if there are sufficient layers of protection against
an accident scenario.
10. What LOPA Does
Provides a method to reproducibly evaluate
the risk of selected accident scenarios.
A scenario is typically identified during a
qualitative hazard evaluation (HE), such as a
PHA, management of change evaluation, or
design review.
LOPA is limited to evaluating a single cause–
consequence pair as a scenario.
12. When to Use LOPA
• LOPA is typically applied after a qualitative
hazard evaluation (e.g., PHA) using the
scenarios identified by the qualitative
hazard review team.
• LOPA can also be used as a screening tool
prior to a more rigorous quantitative risk
assessment (CPQRA) method.
• The decision to proceed to CPQRA is
typically based on the risk level determined
by LOPA or based on the opinion of the
LOPA analyst.
14. How LOPA Works
1. Identify the consequence to screen the
scenarios.
2. Select an accident scenario.
3. Identify the initiating event of the scenarios and
determine the initiating event frequency.
4. Identify the IPLs and estimate the probability of
failure on demand of each IPL.
5. Estimate the risk of the scenario by
mathematically combining the consequence,
initiating event, and IPL data.
6. Evaluate the risk to reach a decision concerning
the scenario.
16. How to Implement LOPA
• LOPA can be applied in a team setting, such as
during or immediately following a HAZOP- or
What-If–based review (e.g., PHA) used to
identify accident scenarios.
• LOPA can also be applied by a single analyst;
in this case, the scenarios have typically
already been identified for the analyst (such
as by a hazard evaluation team).
• Mostly companies practice LOPA with a sub-
team composed of the analyst and a process
engineer or production specialist.
17. Limitations of LOPA
• Risk comparisons of scenarios are valid only if the
comparisons are based on the same risk tolerance
criteria.
• The numbers generated by a LOPA calculation are not
precise values of the risk of a scenario.
• LOPA requires more time to reach a risk-based decision
than qualitative methods such as HAZOP and What-if.
• LOPA is not intended to be a hazard identification tool.
• Due to differences in risk tolerance criteria and in LOPA
implementation between organizations , the results
cannot be compared directly from one organization to
another.
18. Benefits of LOPA
• LOPA requires less time than quantitative
risk analysis.
• LOPA helps resolve conflicts in decision
making by providing a consistent, simplified
framework for estimating the risk.
• LOPA can improve the efficiency of hazard
evaluation meetings by providing a tool to
help reach risk judgments quicker.
• Determination of more precise cause–
consequence pairs.
19. • LOPA provides a means of comparing risk from
unit to unit or plant to plant.
• Provides more defensible comparative risk
judgments than qualitative methods.
• LOPA can be used to help an organization decide
if the risk is “as low as reasonably practicable”
(ALARP).
• LOPA helps identify operations and practices with
sufficient safeguards.
• LOPA helps provide the basis for a clear,
functional specification for an IPL.
• Information from LOPA helps an organization
decide which safeguards to focus on during
operation, maintenance, and related training.
20. Estimating the Consequence and Severity
Purpose
• Various types of consequence analysis are
used in LOPA to facilitate comparison of risk.
• The consequences are estimated to an order
of magnitude of severity.
Consequences of Interest
• Loss of containment of hazardous material
and energy by a variety of mechanisms such
as a leak from a vessel, rupture of a pipeline,
and lifting of a relief valve.
21. Consequence Evaluation Approaches for
LOPA
Consequence evaluation is an integral part of
any risk assessment methodology.
The different types of consequence evaluation
are:
• Release size/characterization
• Simplified injury/fatality estimates
• Simplified injury/fatality estimates with
adjustments
• Detailed injury/fatality estimates
22. Method 1: Category Approach without
Direct Reference to Human Harm
• This method typically uses matrices to
differentiate consequences into various
categories.
• Avoids any overt appearance that injuries
and fatalities are tolerable.
• Helps the team to make more accurate
judgments about relative risk.
23. Advantages:
• The method is simple and easy to
use because the size and properties
of the release are relatively easy to
assess.
• The method allows visual assessment
of where a given risk lies in relation
to the organization’s guidelines.
26. Method 2: Qualitative Estimates with Human
Harm
• This method uses the final impact to humans
as the consequence of interest, but arrives at
the value using purely qualitative judgment.
• The resulting risk of an injury/fatality can be
compared directly to a fatality risk tolerance
criterion for an individual event.
Advantages:
• Simplicity of understanding.
• Direct comparison with corporate guidelines.
29. Method 3: Qualitative Estimates with Human
Harm with Adjustments for Post-release
Probabilities
The LOPA analyst can initially estimate the
magnitude of a release “qualitatively” similar to
Method 2 and then later adjust the event
frequency by the probability that:
• The event will result in a flammable or toxic
cloud;
• For a flammable cloud, an ignition source will be
present;
• An individual will be present in the area when the
event occurs;
• The individual will experience a fatal (or injurious)
consequence.
30. Method 4: Quantitative Estimates with Human
Harm
• This method is similar to the qualitative
estimates with human harm method (Method
3), but uses detailed analyses in determining
the effects of a release and its effects upon
individuals and equipment.
• This method involves the use of mathematical
models to simulate the release itself, the
subsequent dispersion, and the toxic or
blast/thermal effect.
31. Developing Scenarios
• Scenario development is the LOPA step in
which the team or analyst constructs a
series of events, including initiating
events and the failure of IPLs
(independent protection layers), that
lead to an undesired consequence.
• A scenario is an unplanned event or
sequence of events that results in an
undesirable consequence.
32. Each scenario consists of at least two elements:
• An initiating event that starts the chain of
events and
• A consequence (the potential for over
pressuring the system, release of toxic or
flammable material to the atmosphere,
fatality, etc.) that results if the chain of events
continues without interruption.
Minimum Requirements for a scenario
33. • Each scenario must have a unique initiating
event/consequence pair.
• If the same initiating event can result in
different consequences, additional scenarios
should be developed.
A scenario may also include:
• Enabling events or conditions that have to
occur or be present before the initiating event
can result in a consequence.
• The failure of safeguards (which may be IPLs)
36. Identifying Candidate Scenarios
The most common source of
information for identifying scenarios
are hazard evaluations (HE)
developed and documented for
existing processes and performed
during the design of new and
modified processes
37. Other sources for identifying candidate
scenarios for LOPA are:
• Issues related to plant operation.
• incidents in the process, or from other
processes.
• the requirement to change the process.
• Interlock reviews to assess whether the
safety instrumented function (SIF)—
interlock—is required.
38. Scenario Development
Once a scenario has been identified,
it must be developed and
documented to the level where a
basic understanding of the events
and safeguards is achieved.
41. Identifying Initiating Event Frequency
• For LOPA, each scenario has a single
initiating event
• The frequency of the initiating event is
normally expressed in events per year.
Types of Initiating Events
• Initiating events are grouped into three
general types: external events,
equipment failures, and human failures.
43. Root Cause
Defined as an underlying system-related (the
most basic) reason why an incident occurred”
• Initiating events can be the result of various
underlying root causes such as external
events, equipment failures, or human
failures.
• Root causes are not the same as initiating
events
• Root causes can, however, contribute to
determining the frequency of occurrence of
the initiating event.
44. Enabling Events/Conditions
• In some scenarios, the initiating event
may not be obvious.
• In complex scenarios (where initiating or
triggering event is not clear), there may
be other factors that are neither failures
nor protection layers.
• These factors are called enabling events
or conditions.
45. Frequency Estimation
Failure Rate Data
• Guidelines for Chemical Process Quantitative Risk
Analysis (CCPS)
• Guidelines for Process Equipment Reliability Data
(CCPS)
• IEEE
• EuReData
• OREDA
• Company experience (including hazard analysis team
experience)
• Vendor data
46. Selection of Failure Rates
• Failure rates should be consistent with
the basic design of the facility.
• All the failure rates used should be from
the same location in the data range.
• The failure rate data selected should be
representative of the industry or
operation under consideration.
48. Expression of Failure Rates
• Decimal systems,
• Scientific notation- or exponent-based systems.
• Integer systems.
49. Independent Protection Layers
An IPL is a device, system, or action
that is capable of preventing a scenario
from proceeding to its undesired
consequence, independent of the
initiating event or the action of any other
layer of protection associated with the
scenario.
51. All IPLs are safeguards, but not all
safeguards are IPLs.
• A safeguard is any device, system, or
action that would likely interrupt the chain
of events following an initiating event.
Safeguards can be classified as:
• Active or passive,
• Preventive (prerelease) or mitigating (post
release)
52. Protection Layers in LOPA
• Process Design
• Basic Process Control Systems
• Critical Alarms and Human Interventions
• Safety Instrumented Function (SIF)
• Physical Protection (Relief Valves, Rupture
Discs, etc.)
• Post-release Protection (Dikes, Blast Walls,
etc.)
• Plant Emergency Response
• Community Emergency Response
53. Process Design
• Inherently safer design of the process
equipment
• Scenarios are eliminated by the inherently
safer design
• Some inherently safer process design
features are considered to have a non-zero
PFD. They do have possible failure modes
that have been observed in industry. These
companies consider such inherently safer
process design features as IPLs.
54. • Whether process design should be
credited as an IPL, or considered as a
method of eliminating a scenario,
depends upon the method employed
within a particular organization
55. Basic Process Control Systems
• The basic process control system (BPCS),
including normal manual controls, is the first
level of protection during normal operation
• The normal operation of a BPCS control loop
can be credited as an IPL
• Failure of the BPCS can be an initiating event
• When using the BPCS as an IPL, the analyst
must evaluate the effectiveness of the access
control and security systems as human error
can degrade the performance of the BPCS
56. Critical Alarms and Human Intervention
• These systems are the second level of
protection during normal operation and
should be activated by the BPCS
• Operator action, initiated by alarms or
observation, can be credited as an IPL
• Company procedures and training may
improve the performance of humans in
the system, but procedures themselves
are not an IPL
57. Safety Instrumented Function (SIF)
• A SIF is a combination of sensors, logic
solver, and final elements with a specified
safety integrity level that detects an out-of-
limit (abnormal) condition and brings the
process to a functionally safe state.
• SIF is normally considered to be an IPL
• The design of the system, the level of
redundancy, and the amount and type of
testing will determine the PFD the SIF
receives in LOPA
58. Physical Protection (Relief Valves, Rupture
Discs, etc.)
• These devices, when appropriately sized,
designed and maintained, are IPLs which can
provide a high degree of protection
Post-release Protection (Dikes, Blast Walls, etc.)
• These IPLs are passive devices which provide a
high level of protection if designed and
maintained correctly.
• Failure rates are low, but should be included in
the scenarios
59. Plant Emergency Response
• These features (fire brigade, manual
deluge systems, facility evacuation, etc.)
are not normally considered as IPLs since
they are activated after the initial release
• There are too many variables (e.g., time
delays) affecting their overall
effectiveness in mitigating a scenario.
60. Community Emergency Response
• These measures, which include
community evacuation and shelter-in-
place, are not normally considered as IPLs
since they are activated after the initial
release
• There are too many variables affecting
their effectiveness in mitigating a
scenario.
• They provide no protection for plant
personnel
62. IPL Rules
In order to be considered an IPL, a device,
system, or action must be:
• Effective in preventing the consequence
when it functions as designed,
• Independent of the initiating event and the
components of any other IPL
• Auditable; the assumed effectiveness in
terms of consequence prevention and PFD
must be capable of validation in some
manner.
63. Effectiveness
• A device, system or action must be effective in
preventing the undesired consequence
associated with the scenario.
Independence
• To assure that the effects of the initiating event,
or of other IPLs, do not interact with a specific IPL
Independence requires that an IPL’s effectiveness
is independent of:
• the occurrence, or consequences, of the initiating
event;
• the failure of any component of an IPL already
credited for the same scenario.
64. Auditability
• A component, system or action must be
auditable to demonstrate that it meets
the risk mitigation requirements of a
LOPA IPL.
• The audit should also confirm that the
IPL design, installation, functional
testing, and maintenance systems are in
place to achieve the specified PFD for the
IPL.
65. PFD Value for an IPL
The PFD for an IPL is the probability that,
when demanded, it will not perform the
required task. Failure to perform could be
caused by
• A component of an IPL being in a failed or
unsafe state when the initiating event occurs
• A component failing during the performance
of its task
• Human intervention failing to be effective, etc.
66. Examples of IPLs
• Passive IPLs
• Active IPLs
• Instrumented Systems
• Basic Process Control System (BPCS)
• Safety Instrumented Systems (SIS)
• Vendor Installed Safeguards
• Deluges, Sprays, Foam Systems, and other
Firefighting Mitigation Systems
• Pressure Relief Devices
• Human IPLs
67. Passive IPLs
• A passive IPL is not required to take an action
in order for it to achieve its function in
reducing risk.
• These achieve the intended function if their
process or mechanical design is correct and if
constructed, installed, and maintained
correctly.
• Examples are tank dikes, blast walls or
bunkers, fireproofing, flame or detonation
arrestors, etc.
69. Active IPLs
Active IPLs are required to move from one state
to another in response to a change in a
measurable process property (e.g., temperature
or pressure), or a signal from another source
(such as a push-button or a switch).
Example:-
• a sensor of some type (instrument, mechanical,
or human),
• a decision-making process (logic solver, relay,
spring, human, etc.),
• an action (automatic, mechanical, or human).
71. Instrumented Systems
These systems are a combination of sensors, logic
solvers, process controllers, and final elements that
work together, either to automatically regulate plant
operation, or to prevent the occurrence of a specific
event within a chemical manufacturing process.
Types of instrumented systems:-
• Continuous controller (e.g., the process
controller that regulates flow, temperature, or
pressure)
• State controller (the logic solver which takes
process measurements and executes on–off
changes to alarm indicators and to process
valves)
72. Basic Process Control System (BPCS)
It is the control system that continuously
monitors and controls the process in day-to-
day plant operation.
The BPCS may provide three different types of
safety functions that can be IPLs:
• continuous control action.
• state controllers providing information to
operators.
• state controllers providing automatic actions.
73. Safety Instrumented System (SIS)
A safety instrumented system (SIS) is a combination
of sensors, logic solvers and final elements that
performs one or more safety instrumented functions
(SIFs)
SIFs are state control functions, sometimes called
safety interlocks and safety critical alarms.
Each of the SIFs will have its own PFD value based
on
• the number and type of sensors, logic solvers, and
final control elements; and
• the time interval between periodic functional tests
of system components.
74. International standards have grouped SIFs for
application in the chemical process industry into
categories called Safety Integrity Levels (SILs).
SIL 1: PFD ≥ 1 × 10–2 to <1 × 10–1 (implemented
with a single sensor)
SIL 2: PFD ≥ 1 × 10–3 to <1 × 10–2 (fully
redundant from the sensor through the SIS
logic solver)
SIL 3: PFD ≥ 1×10–4 to <1 × 10–3
SIL 4 PFD ≥ 1×10–5 to <1 × 10–4 (These SIFs are
included in the IEC 61508 and 61511
standards)
76. Deluges, Sprays, Foam Systems, and Other
Firefighting Mitigation Systems
• Deluges, water sprays, foam systems may
be considered as IPLs for preventing the
ultimate release (e.g., a BLEVE, or
exothermic runaway reaction initiated by
external heat input)
• If the possibility of damage from the fire or
explosion could render them ineffective
then they should usually be considered
safeguards rather than IPLs
77. Pressure Relief Devices
• Pressure relief valves open when the
pressure under the valve exceeds the
pressure exerted by the spring holding
the valve closed
78. Human IPLs
• Human IPLs involve the reliance on
operators, or other staff, to take action to
prevent an undesired consequence, in
response to alarms or following a routine
check of the system
• (Guidelines for Preventing Human Error
in Process Safety; CCPS 1994b, and Swain
1983)
80. PREVENTIVE IPLs Versus MITIGATION IPLs
• Some IPLs are intended to prevent the scenario
from occurring and may be termed preventive
IPLs.
• IPLs intended to reduce the severity of the
consequence of the initiating event is termed as
mitigation IPLs.
• Examples of preventive IPLs are SIFs (e.g., steam
valve closure, emergency cooling water flow,
inhibitor addition.)
• Examples of mitigation IPLs is Pressure Relief
Devices.
81. Determining the Frequency of Scenarios
Quantitative Calculation of Risk and Frequency
Frequency of scenario = Initiating event
frequency multiplied by product of IPL PFDs.
82. Calculating the Frequency of Additional
Outcomes
• Flammable effects such as fire or
explosion.
• Toxic effects where applicable.
• Exposure to flammable or toxic effects.
• Injury or fatality.
83. To calculate the frequency of additional
outcomes, Equation is modified by multiplying
the frequency of the release scenario by the
appropriate probabilities for the outcome of
interest.
These include:
• The probability of ignition (Pignition)—for
flammable releases,
• The probability that personnel are in the affected
area (Pperson present )—a precursor parameter for
calculating exposures and injuries, and
• The probability that injury occurs (Pinjury)— for
injury or fatality.
84. • Frequency of a fire for a single scenario for a
single system.
• Frequency of a person exposed to a fire
85. • Frequency of a person injured in a fire
• Toxic effects by omitting the probability
of ignition
86. Calculation of Risk
RC
k = risk index of incident outcome of interest
k, expressed as a magnitude of consequences
per unit time.
fC
k = is the frequency of the incident outcome
of interest k, in year-1
Ck = factor related to the magnitude of the
consequences of incident outcome of interest
k. Ck might be expressed as a category
87. Using LOPA to make Risk Decision
• Decision making takes place after the
scenarios have been fully developed and
the existing risk has been calculated,
whether qualitative or quantitative
• The decisions regarding risk normally fall
into one of three general categories:
88. 1. Manage the residual risk—continue the
management systems that maintain the
risk at its current (presumably tolerable)
level.
2. Modify (mitigate) the risk to make it
tolerable.
3. Abandon the risk (businesses, process,
etc.) because it is too high.
{Decisions to abandon operations are normally made as a
result of other studies such as quantitative risk assessment
(CPQRA)}
89. Three basic types of risk judgment are
used in conjunction with LOPA:
1. Compare the calculated risk with a
predetermined risk tolerance criteria.
2. Expert judgment by a qualified risk
analyst, (is not recommended by the
authors but is included for completeness.)
3. Relative comparison among competing
alternatives for risk reduction, using either
of the methods described above.
90. Comparing Calculated Risk to
Scenario Risk Tolerance Criteria
a) Matrix Methods
Method of visually showing the
frequency tolerable for a scenario based on
the consequence severity and the scenario
frequency
92. b) Numerical Criteria Method (Maximum
Tolerable Risk per Scenario)
• Risk criteria based on a maximum
tolerable risk per scenario
• For example, an organization can establish
as its criteria a maximum frequency (per
year or per 1000 hours) of a single fatality.
• Frequency of releases of hazardous
materials, fires, or property damage dollar
loss.
93. c) Number of IPL Credits
• Specify the number of IPL credits for
scenarios of certain consequence levels
and frequency
• Tabular values are provided for the
number of IPL credits for ranges of
initiating event frequency
• Tolerable criteria are not shown explicitly
• An IPL Credit is defined as a reduction in
event frequency of 1 × 10–2.
95. Expert Judgment
• When specific risk tolerance criteria are not
available
• The expert would compare the IPLs and other
features of the scenario to industry practice,
similar processes, or other points of reference
in his or her experience.
• Should not be a “Lone Ranger” approach
• Decisions should result from group
consultations, not from one or two people
operating in isolation.
96. Cost–Benefit for Relative Comparison
• Compares the cost of the avoided
consequence at its frequency versus the
cost of the IPL improvements to reduce
the risk
• Cost–benefit analysis is generally the
method used to select the IPLs for risk
reduction from among the candidate IPLs