Key Issues with Implementing

LOPA
William Bill Bridges and Tony Clark
Process Improvement Institute, Inc. (PII), 1938 Riversound Drive, Knoxville, TN 37922; wbridges@piii.com
(for correspondence)

Published online 28 April 2010 in Wiley InterScience (www.interscience.wiley.com). DOI 10.1002/prs.10384

This article writen by one of the originators of This article focuses on preventing these problems
LOPA, focuses on problems observed with LOPA. and also summarizes the many benefits LOPA has pro-
duced for the industry. Ó 2010 American Institute of
• One the biggest issues is that organizations use
Chemical Engineers Process Saf Prog 29: 103–107, 2010
LOPA without following the rules for LOPA, espe- Keywords: LOPA, IPL, initiating event, IEF, layer of
cially the rules related to maintaining, testing, protection, protection layer
and record-keeping for each independent protec-
tion layer (IPL) and for each ‘‘optimized’’ initiat-
ing event (IE). BRIEF HISTORY OF LOPA
• Another issue is that many companies and ana- The initial development of layer of protection anal-
lysts overuse LOPA. The LOPA book authors ysis (LOPA) was done internally within individual
expected the number of scenarios going to LOPA companies. However, once a method had been
(after a HAZOP/PHA) would be 1 to 10% (max) developed and refined, several companies published
of those uncovered in a qualitative analysis papers describing the driving forces behind their
(maybe after 100 HAZOP nodes, you would do efforts to develop the method, their experience with
1–10 LOPA). A PHA team would recommend (or LOPA, and examples of its use [1–3].
use) LOPA only if the scenario was too complex In parallel with these efforts, discussions took
for the PHA/HAZOP team. It appears that most place on the requirements for the design of safety
companies are using LOPA for every scenario instrumented systems (SIS) to provide the required
that has a severe consequence; this result in levels of availability. United States and international
doing LOPA on much more than 10% of the standards [4–6] described the architecture and design
scenarios. features of SISs. Informative sections suggested meth-
• Many times, there is weak definition of the con- ods to determine the required safety integrity level
sequence that is being avoided, so an independ- (SIL), but LOPA was not mentioned until the draft of
ent layer of protection does not always match up International Electrotechnical SIS standard [6]. These
well with the consequence. issues were summarized in the CCPS workshop on
• LOPA is also overworked when it is used. the application of ISA S84, held in 2000 [7].
Many of us on the original LOPA book The first LOPA book was developed by a CCPS
authorship considered LOPA a single analyst committee from 1997 through 2000 and was published
job, after a PHA/HAZOP. Instead, the trend in 2001 (William Bridges was one of the principal
appears to be that companies (or perhaps authors of that guideline [8]). LOPA became widely
their consultants) make LOPA part of the PHA used following the publication and most companies
(in situ), therefore involving the whole PHA around the world have used LOPA, with some compa-
team. nies having used LOPA a lot. During roughly 10-years
• LOPA is used in PHA team settings, which dis- of widespread use of LOPA, and especially during the
tracts PHA teams from their primary task of last 5-years, use of LOPA has greatly accelerated. It is
brainstorming to identify the accident scenarios likely that 1 million LOPAs have been performed. Dur-
that can occur. ing this same period, many abuses of LOPA have
been noted and several innovations have occurred.
In 2007, CCPS commissioned a new guideline
book to (1) expand the list of independent protection
Ó 2010 American Institute of Chemical Engineers layers (IPLs) and initiating events (IEs) and (2) to try

Process Safety Progress (Vol.29, No.2) June 2010 103

to remedy some of the major issues noted in the use ‘‘adequately’’ safeguarded by other means. This
of LOPA. The new (future) book is due to be pub- became apparent in the mid-1990s with the early de-
lished in early 2010 [9]. velopment of SIS standards within chemical compa-
nies and by the Instrument Society of Automaton
INTENT OF LOPA (ISA). Some of these early standards would have
LOPA is one of many methods for assessing a imposed a minimum SIL for a given consequence,
given scenario to determine if the risk is tolerable. It without much regard for the number and value of
uses rigid rules to simplify and standardize the defini- other IPLs that already existed or were viable alterna-
tions of independent protection layers (IPLs) and ini- tives to the SISs. Much of these arbitrary requirements
tiating events (IEs). If these rules are followed, then for SIS have disappeared, but some remain.
the simplified risk assessment math of LOPA is valid For the most part today, LOPA is seen as one tool
and the risk assessment should give an order-of-mag- (in many parts of the world, the preferred tool) for
nitude approximation of the risk of a given cause- determining if an SIF is necessary and if it is the cor-
consequence pair (scenario). The rules also cover the rect choice of risk reduction; and LOPA is the pre-
minimum criteria for maintaining features and task ferred method for determining what SIL is necessary,
executions that relate to IEs and IPLs. if an SIF is chosen as the risk reduction method. With
LOPA is only one option for judging risk. The that said, PHA teams are also allowed by IEC 61508
most common and still the best method for judging [5] to make these same determinations.
the risk of most scenarios is the process hazard analy- However, some organizations use LOPA to answer
sis (PHA) team; their judgment is qualitative, but the the question: ‘‘What SIL is needed to lower the risk to
‘‘fuzzy’’ math of the individual team members usually the risk target?’’ without first asking, ‘‘Are we at tolera-
coalesces into excellent judgment of risk for nearly ble risk already?’’ or ‘‘Are there better alternatives for
all accident scenarios. As stated in all books and lowering the risk?’’ This leads to a huge over-specifi-
papers on the topic, LOPA does not find accident sce- cation of SIFs (and the wasting of resources to
narios. Typically only the qualitative hazard evalua- design, implement, and maintain these SIFs) and to
tion methods (such as HAZOP, What-if, and FMEA) many spurious shutdowns of units (which also waste
can find new accident scenarios. money and increase the risk of accidents that can
Figure 1, updated from the original figure contained occur during restart of the process).
in the LOPA book [8], illustrates where LOPA fits into
the spectrum of methods for judging risk.
SUMMARY OF GAINS FROM LOPA
Overall, LOPA has been highly successful in helping
RELATIONSHIP TO SIL DETERMINATION organizations to understand and control risk. Below is
LOPA started with and continues to have a unique
a listing of some of the benefits derived from LOPA:
relationship with SIS and SIL determination. Some of
the originators of LOPA needed LOPA to defend • More consistent definition for protection layers.
against an arbitrary assignment of safety instrumented Information from LOPA helps an organization
functions (SIFs) for systems that were already decide which safeguards to focus on during

104 June 2010 Published on behalf of the AIChE DOI 10.1002/prs Process Safety Progress (Vol.29, No.2)
 operation, maintenance, and related training. One of the Biggest Problems with LOPA Is
Therefore, LOPA is a tool for implementing a That Its Users Do Not Always Follow the
comprehensive process safety management Rules of LOPA
(PSM) mechanical integrity (MI) or risk-based A major problem is that IPL PFD and IE frequency
maintenance system, and it aids in the identifica- values are picked from a list, whereas the specific IEs
tion of ‘‘safety critical’’ features and tasks. and IPLs are not (1) validated to have the stated
• LOPA helps identify operations and practices that value and (2) not maintained to sustain the stated
were previously thought to have sufficient safe- value. Below is a listing of the rules for IPLs (with
guards, but more detailed analysis (facilitated by impact on IEs as well), and descriptions of the prob-
LOPA) indicates there are far more safeguards than lems we have observed:
necessary. Therefore, the company/site can elimi-
• IPLs must meet the independence rule—inde-
nate unnecessary safeguards (eliminate ‘‘extra’’
pendent of the initiating event and other IPLs.
IPLs) or perhaps similarly eliminate the care and
This most important rule is not often violated, at
proof of these safeguards (i.e., run the extra IPLs to
least not intentionally.
failure)—while still maintaining tolerable risk.
• Sometimes, the LOPA scenario will reuse an op-
• Improved evaluation in PHAs of which ‘‘listed’’
erator or use another operator within the same
safeguards are ‘‘valid’’ safeguards. Even though
work team; this usually will not pass the test of
LOPA was not meant for ‘‘live’’ use during a quali-
independence. IPL and IE values used in LOPA
tative, team hazard review (like a PHA/HAZOP)
must be defensible as applicable to the scenario.
because it normally distracts a team from their pri-
This has been a problem. Many organizations
mary job of brainstorming what can go wrong,
choose values from handbooks (or from the
one of the main benefits realized from the first
original LOPA book) and papers/articles or
decade of implementing LOPA within an organiza-
obtain them from calculations based on discrete
tion is that the qualitative hazard reviews (such as
component failure rates from databases, and
PHAs or HAZOPs) have improved. Today, those
then assume those values apply to their situa-
in a qualitative hazard review are not likely to list
tion.
a protective feature or action as a safeguard in a
• IPLs and IEs must be maintained such that they
HAZOP or What-if analysis, unless that safeguard
produce the IE or IPL values stated. This has
appears to meet (or is intended to meet) the
been a huge problem in the past 8-years of
requirements of an IPL (discussed later). This has
LOPA implementation and is one of the prob-
improved the qualitative risk judgment of such
lems we hope to address with the new CCPS
teams because the safeguards they list and discuss
book on IPLs and IEs [9]. An IPL cannot be
are more likely to be independent, capable, vali-
assigned any risk reduction value if it is not
dated, and audited. So, in essence, the qualitative
maintained well enough to produce the risk
aspects of LOPA have been moved into PHAs.
reduction value.
• Justifying when SIS is not needed. (Proper SIL
• IPLs and IEs must be validated and records must
determination can usually show no SIL is
be kept and audited. This has been a huge
needed.) LOPA helps provide the basis for a
problem in the past 8-years of LOPA implemen-
clear, functional specification for an IPL [4–6],
tation and is one of the problems we hope to
and also facilitates assigning of the SIL needed.
address with the new CCPS book on IPLs and
• Faster quantification of severe risk scenarios.
IEs [9]. Currently, even if we follow industry
LOPA requires less time than quantitative risk
advice, we would not get the desired risk reduc-
analysis (QRA). This benefit applies particularly
tion if our own test data (or alternative valida-
to scenarios that are too complex for qualitative
tion record) show the IPL or IE value is worse
assessment of risk. A full QRA of a scenario can
than what we wanted.
take hours or days, whereas a LOPA for the
same scenario will likely take about 1–2 h. Part of the problem is that the industry is still
• Common language among risk reviewers around weak on reporting near misses. For many of us, any
the world. LOPA helps resolve conflicts in decision time we have challenged the last IPL or two, and
making by providing a consistent, simplified anytime we find an IPL in a failed state, we have a
framework for estimating the risk of a scenario and near miss. Yet are these being reported and investi-
provides a common language for discussing risk. gated? In most cases, they are not. There should be
• LOPA offers a rational basis for managing layers 20–100 near misses reported for each loss event, yet
of protection that may be taken out of service the ratio in the industry is currently 1–2 [10]. The or-
(such as bypass of a shutdown interlock). LOPA ganization that gets many near misses reported (and
also provides clarity on what to pay attention to a large percentage of these also get investigated), will
when an IPL is out of service for testing or repair. have tremendous gains in loss prevention and will
also have a much better idea of their reliability factors
supporting the PFD values for IPLs and IEs failure
SUMMARY OF ISSUES WITH THE CURRENT IMPLEMENTATION OF LOPA rates.
While LOPA has been a great benefit to industry,
we have observed many issues with the implementa- • Many times there is weak definition of the con-
tion of LOPA over the past 10-years of use. sequence that is being avoided, so an IPL does

Process Safety Progress (Vol.29, No.2) Published on behalf of the AIChE DOI 10.1002/prs June 2010 105
 not always match-up well with the consequence. of operation. It is difficult to bring the team
This can cause both overestimates and underes- back into brainstorm mode (PHAs) after
timates of the risk. switching to analyzing mode (LOPAs), it is
best for an organization to limit the amount
One issue that we have come across is that the
of brain-power expended by PHA teams on
worst case consequences are being assumed for fail-
LOPAs.
ure of a control system, which sounds wise, but for
– Takes time away from what is critical for the
some cases, it is overly pessimistic. For instance, a
PHA team to do: Identify scenarios for ALL
full bore pipe work rupture is assumed due to brittle
modes of operation. LOPA within the PHA is
failure if the pipe work is subjected to temperatures taking time away from proper identification
lower than its design temperature. While catastrophic
of risky scenarios. The industry is still miss-
brittle failure is remotely possible (this may only
ing many of the largest and least protected
occur in 1 in 50 or 1 in 100 cases), we would get a scenarios in favor of over-analyzing the sce-
much better indication of the risk if operators
narios they know about. Chapter 9 of the
recorded each occasion and the consequences of
HEP Guideline, 3rd edition [12] explains how
exceeding design parameters, even if nothing hap-
to analyze nonroutine modes of operation.
pened. Otherwise, we believe that we are being too
pessimistic. LOPA does help discover ‘‘some’’ new or related
There are cases where the risks have been under- scenarios, but overall, we believe LOPA will cause
estimated, caused by predicting the consequences to a PHA/HAZOP team to find less scenarios, if used
be less severe than they would be. One illustrative in situ during a PHA/HAZOP team meeting.
example of this issue, is the Buncefield UK Incident
• Use for every Medium and High Risk Scenario.
[11], in which overfilling of one of the petrol tanks
resulted in a series of explosions, which caused a
This issue is likely covered adequately in the
huge fire, engulfing 20 large storage tanks (the largest
discussion above, but increasing the number of
fire in the UK since World-War II). The fire burned scenarios that must go through LOPA, reduces
for 5 days. No one was killed, but there were 43
the resources available to find (in a PHA/
minor injuries. The incident happened early on a
HAZOP/What-if) the undiscovered scenarios,
Sunday morning, but had it occurred during a and to manage existing layers of protection
normal working day there could have been a signifi-
(both issues are listed above).
• Use in studies that are redundant to PHAs, such
cant number of fatalities. The economic impact
added to around £1 billion ($1.5 billion USD),
as ‘‘separate SIL determination.’’ IEC 61511
which accounted for the emergency response, com-
allows a qualitative PHA team to determine if a
pensation for loss, costs to the aviation sector, and
SIF is needed for a scenario and to specify a SIL
the investigation.
1 or 2, if one is needed. Yet, most folks believe
that only LOPA or RiskGraph or QRA is valid for
determining if a SIF is needed and then use the
Overuse of LOPA same methods to determine what SIL is needed.
Although we love LOPA, many of the originators As a result, many people do LOPA on almost ev-
thought LOPA would be used a lot less frequently ery scenario of moderate consequence or
than it is now. As shown in Figure 1, it was antici- higher.
pated that LOPA would be used on 1–5% of the sce-
narios uncovered in PHAs. Further, though a couple
of companies at the time were using LOPA within the Too Many Resources Dedicated to LOPA Studies
PHA setting, it was anticipated that LOPA would
• Typically, one LOPA analyst is sufficient (if he/
eventually be used ‘‘after’’ a PHA team meeting. Vari-
ous examples of overuse are discussed below:
she has easy access to PHA team members and
other experts within the organization). No brain-
• Use within PHAs. Many of us on the original storming is necessary for LOPA, so there is no
LOPA book authorship considered LOPA a single inherent need for a team. It is a good practice to
analyst job, after a PHA/HAZOP, for just a few review the LOPA recommendations and conclu-
scenarios (maybe after 100 HAZOP nodes, you sions with the technical and operations folks
would do 1–10 LOPA). Instead, the trend that were represented in the PHA.
appears to be that companies (or perhaps their • Once a LOPA is completed for a scenario, the
consultants) make LOPA part of the PHA (in results can be relayed to management or to a
situ). If the PHA/HAZOP team is properly disci- PHA team, or similar decision makers.
plined on what qualifies as a safeguard (a quali- • Why use a LOPA team (with a LOPA leader and
tative definition of an IPL from LOPA), then per- LOPA scribe)? There is almost No brainstorming
forming LOPA in situ is usually overkill. Prob- occurring during a true LOPA analysis, so there
lems with using LOPA in PHAs include: is no need for a team. On the other hand, if the
• Distracts PHA team from brainstorming LOPA team (or PHA team) recommends a SIF,
– The PHA teams have an awesome responsi- then a small team (two to three experts) will be
bility which is to find ALL scenarios that can needed to ‘‘specify the SIF design and function-
lead to adverse risk and do this for all modes ality issues (such as sequence and delays) for

106 June 2010 Published on behalf of the AIChE DOI 10.1002/prs Process Safety Progress (Vol.29, No.2)
 the SIF.’’ Also, later someone else (usually one International Conference and Workshop on Risk
person) will be needed to validate the SIF Analysis in Process Safety, CCPS/AIChE, Atlanta,
design will produce the SIL determined by the GA, October 1997.
PHA or LOPA team. 3. R.M. Ewbank and G.S. York, ‘‘Rhône-Poulenc Inc.
Process hazard analysis and risk assessment meth-
odology,’’ International Conference and Work-
Too Much Emphasis on Software shop on Risk Analysis in Process Safety, CCPS/
• You do not need software for a 1 1 1 1 2 5 4 AIChE, Atlanta, GA, October 1997.
calculation (i.e., ‘‘Why use a sledgehammer to 4. ISA, Application or Safety Instrumentation Sys-
crack a nut?’’). Most of the commercial packages tems for the Process Industry, International Soci-
for documenting PHAs (using HAZOP, What-If, ety for Measurement and Control, ISA S84.01,
or whatever methods) have options for sending 1996.
scenarios to LOPA worksheets. These tools can 5. IEC, Functional Safety of Electrical/Electronic/Pro-
ease the completion of LOPA and ease the grammable Electronic Safety-related Systems,
exporting of some data from PHA records into a Parts 1–7, Geneva, International Electrotechnical
LOPA form; in fact, one of the authors of this Commission, IEC 61508, 1998.
paper designed one of the first such applications 6. IEC, Functional Safety Instrumented Systems for
for HazardReview LEADER software. On the the Process Industry Sector, Parts 1–3, Geneva,
other hand, these PHA software options do not International Electrotechnical Commission, IEC
make it easier to document ‘‘why an IPL is 61511, 2001.
valid.’’ Many analysts and most operating com- 7. W.G. Bridges, ‘‘Get near misses reported,’’ Interna-
panies have implemented their own spreadsheet tional Conference and Workshop on Process
applications. Industry Incidents, CCPS/AICHE, Orlando, FL,
October 2000.
The most important needs of LOPA documentation 8. CCPS/AIChE, Layer of Protection Analysis (LOPA):
are to enter/record the scenario description in detail, Simplified Process Risk Analysis, CCPS/AIChE,
document the basis for the initiating cause frequency, New York, NY, 2001.
explain clearly why an IPL is given credit, and most 9. CCPS/AIChE, Initiating Events and Independent
importantly, describe how each IPL is maintained to Protection Layers for LOPA, CCPS/AIChE, New
sustain the credit given. This can all be done free- York, NY, 2010 [pending].
hand, and PHA (or LOPA) software does not help 10. W.G. Bridges, ‘‘Gains in getting near misses
shortcut this necessary chore. reported—Revisited,’’ 8th ASSE-Middle East Chap-
CLOSING ter Conference and Workshop, Bahrain, February
Introduction of the streamlined quantitative risk 2008.
assessment method, LOPA, has had a tremendous 11. The Buncefield Incident, 11 December 2005, The
impact on the chemical and related industries. Ninety Final Report of the Major Incident Investigation
percent of the quantitative risk assessments that may Board, Vol. 1, 2008.
be necessary can now be performed in 1/10th the 12. CCPS/AIChE, Guidelines for Hazard Evaluation
time of a QRA. Many benefits have been reaped, Procedures,Third Edition with Worked Examples,
including a continual improvement on the identifica- CCPS/AIChE, New York, NY, 2008.
tion and control of critical features and actions. How- 13. W. Bridges and T. Clark, ‘‘Key issues with imple-
ever, the initial rollout of LOPA has led to a few prob- menting LOPA (layer of protection analysis)—Per-
lems, as discussed in this article. The problems are spective from one of the originators of LOPA,’’
easily remedied by judicious use of LOPA and by Process Plant Safety Symposium Proceedings,
carefully adhering to the rules of LOPA. Tampa, Fl (2009), pp. 3–18.
An example to illustrate when LOPA is not neces- 14. K. Study and J. Champion, ‘‘LOPA misapplied:
sary in addition to more details concerning the teach- Common errors can lead to incorrect conclusions,’’
ings of this article are published in a PPS Proceedings Global Congress on Process Safety, San Antonio,
[13]. There are other articles in PSP that emphasize TX, USA, March 22, 2010.
this important LOPA topic [14–17]. 15. R. Wasileski and F. Henselwood, ‘‘LOPA—Going
Down the Wrong Path?’’ Global Congress on Pro-
LITERATURE CITED cess Safety, San Antonio, TX, USA, March 22, 2010.
1. W.G. Bridges and T.R. Williams, ‘‘Risk acceptance 16. W. Bridges, ‘‘LOPA and Human Reliability—Human
criteria and risk judgment tools applied worldwide Errors and Human IPLs,’’ Global Congress on Pro-
within a chemical company,’’ International Confer- cess Safety, San Antonio, TX, USA, March 22, 2010.
ence and Workshop on Risk Analysis in Process 17. A. III Dowell and T. Williams, ‘‘Layer of protec-
Safety, CCPS/AICHE, Atlanta, GA, October 1997. tion analysis: Generating scenarios automatically
2. A.M. III Dowell, ‘‘Layer of protection analysis: A from HAZOP data,’’ Process Safety Progress, Vol.
new PHA tool, after HAZOP, before fault tree,’’ 24, 2005, pp. 38–44.

Process Safety Progress (Vol.29, No.2) Published on behalf of the AIChE DOI 10.1002/prs June 2010 107