ISA Safety Instrumented Systems for the

Process Industries Conference Paper

ISA Safety Instrumented Systems for the Process

Industries Conference
14-16 May 2002
Baltimore, MD

Copyright 2002 by ISA The Instrumentation, Systems, and Automation Society. All rights
reserved. Not for resale. Produced in the United States of America.
ISA
67 Alexander Drive
P.O. Box 12277
Research Triangle Park, North Carolina 27709
Phone: (919) 549-8411
Fax: (919) 549-8288
Email: info@isa.org
ISANetwork: http://www.isa.org

LAYER OF PROTECTION ANALYSIS: LESSONS

LEARNED
Arthur M. (Art) Dowell, III, P.E.
Senior Technical Fellow
Hazard Analysis
Rohm and Haas Company
Deer Park, TX 77536

KEYWORDS
Alarm Systems, Documentation, Emergency Shutdown System, Fault Tree Analysis, Final Element,
Instrumentation, Interlocks, Modeling, Probability of Failure on Demand, Qualitative, Quantitative,
Safety, Sensors, Systems Design, Unavailability.

ABSTRACT
During the 1990s, several companies and industry groups developed and applied LOPA (Layer of
Protection Analysis) to determine if sufficient IPLs (Independent Protection Layers) were present to
reduce the risk and to assign SILs (Safety Integrity Levels) to SIFs (Safety Instrumented Functions).
LOPA offers a consistent approach and enhanced documentation with cost-effective resource input
for these tasks. Drawing from the experience of several companies and organizations, this paper
presents lessons learned from the application of LOPA over the past decade. Examples are given to
avoid potential pitfalls and traps.

INTRODUCTION
As companies and industry groups developed standards to design, build, and maintain Safety
Instrumented Systems (SIS) in the 1990s (1, 2, 3), it became clear that a key input to this process
was the required PFD (Probability of Failure on Demand) for each SIF. PHA (Process Hazard
Analysis) and project teams struggled to determine the required SIL for the SIFs (interlocks) (4).
The concept of layers of protection and an approach to analyze the number of layers needed were
shown in the CCPS (Center for Chemical Process Safety) Safe Automation book (1). Building on
those concepts, several companies developed internal procedures for LOPA (Layer of Protection
Analysis) (5). As LOPA was practiced, adjustments, improvements, and refinements were made.
CCPS documented LOPA practices in 2001 (6). This paper highlights lessons learned from ten
years practice of LOPA.

59

WHAT IS LOPA?
LOPA is a semi-quantitative analysis that is applied after a qualitative hazard identification step like
HAZOP. LOPA starts with an undesired consequence usually, a consequence with environmental,
health, and safety impact, although LOPA can be used for business or economic consequences. The
general format of a LOPA table is shown in Table 1 (the orientation can be horizontal or vertical).
Table 1: General Format of LOPA Table
Consequence
& Severity

Initiating
Event
(Cause)

Initiating
Event
Challenge
Frequency
/yr.

Preventive Independent Protection Layers

Probability of Failure on Demand (PFD)
Process
Design

BPCS
(DCS)

Operator
Response
to Alarms

SIF
(PLC
relay)

Mitigation
Independent
Protection
Layers

Mitigated
Consequence
Frequency

(PFD)

/yr.

The severity of the consequence is estimated (usually from look-up tables). One or more initiating
events (causes) may lead to the consequence; each cause-consequence pair is called a scenario.
LOPA focuses on one scenario at time. The frequency of the initiating event is estimated (usually
from look-up tables). Each available safeguard is assessed to determine if it can be effective in
preventing the scenario from reaching the consequence AND to determine if it is independent of the
initiating event and the other IPLs (Independent Protection Layers). If the safeguard meets these two
tests, it is an IPL. LOPA multiplies the frequency of the initiating event by the product of the PFDs
for the applicable IPLs to calculate the frequency of the consequence using Equation 1 (6).
J

f i = f i PFDij
C

(1)

j =1

= f i I PFDi1 PFDi 2 K PFDiJ

Where f i C = frequency for consequence C for initiating event i

f i I = initiating event frequency for initiating event i
PFDij = probability of failure on demand of the jth IPL that protects against consequence C
for initiating event i.

Typical initiating event frequencies, and IPL PFDs are given in Dowell (4, 5, 7) and CCPS (6).
Figure 1 shows the concept that each IPL acts as a barrier to reduce the frequency of the
consequence. Figure 1 also compares LOPA with event tree analysis; LOPA analyses the path
through the event tree shown by the heavy line.
The mitigated consequence frequency from Equation 1 is compared to the companys risk tolerance
criteria for that consequence severity. If additional risk reduction is needed, more IPLs must be
added to the design; alternately, the process could be made inherently safer (8, 9). Figure 2 shows
the iterative cycle of a layer of protection analysis.
Frequently, the additional IPLs include SIFs. An outcome of the LOPA analysis is the required PFD
of the SIF, which then defines the SIL for the SIF. With the SIL defined, ANSI/ISA 84.01-1996, IEC

60

61508, and, when it is made final, draft IEC 61511 should be used to design, build, commission,
operate, test, maintain, and decommission the SIF.

LESSONS LEARNED
Here are some of the lessons learned in 10 years experience using LOPA, extending its use, training
users, and sharing techniques across the process industry.
TEAM MAKEUP
Some companies perform LOPA during the PHA, using the PHA team. The team make-up is typical
for a HAZOP with knowledgeable representatives from Operations, Management, Process
Engineering, Control Engineering, Instrument/Electrical, and Risk Analysis. They report that all the
needed skills are present, and the team is familiar with the scenario since they just evaluated it in the
PHA. Decisions from the LOPA are recorded as part of the PHA recommendations. This approach
works best when the risk tolerance criteria are applied to each scenario individually.
Other companies report that it is more efficient to capture a list of scenarios during the PHA for later
evaluation by a smaller LOPA team. Scenarios in the red zone of the companys risk matrix are
flagged for LOPA; an action to do LOPA on the scenarios is included in the PHA recommendations.
Typically, a process engineer and a person skilled in LOPA (perhaps a risk analyst) execute the
LOPA. The LOPA expert gives the process engineer a brief overview of LOPA and provides the
lookup tables for initiating event frequency, PFD for IPLs, and risk tolerance criteria. The two
people work together through two or three scenarios to ensure the process engineer is comfortable
with the technique. The process engineer then prepares a draft LOPA table for all the scenarios. The
process engineer and the LOPA expert go over the LOPA table together, making corrections and
adjustments where needed (typical issues are discussed below). The frequencies of the mitigated
scenarios (after all the IPLs are applied) are compared to the risk tolerance criteria. If required,
additional IPLs are recommended. The LOPA results are reviewed with other members of the PHA
team. It is reported that this approach allows a more relaxed schedule for doing the LOPA, and it
reduces the meeting time for the PHA team. This approach is of particular benefit when the
companys risk tolerance criteria are based on the sum of the scenarios affecting a given area.
Either approach may be used. The important factor is that the process knowledge is incorporated in
the LOPA and that the LOPA methodology is applied correctly and consistently.
ONE CAUSE ONE CONSEQUENCE = ONE SCENARIO
It is critical that each LOPA scenario have only one cause and one consequence. New users
frequently desire to combine causes that lead to the same consequence to save time in the analysis
and documentation. Unfortunately, each IPL may not protect against each initiating event. For
example, a SIF that blocks the feed flow into a reactor protects against high pressure from the feed
streams, but it does not protect against high pressure caused by internal reaction or caused by
backflow from downstream equipment. It is important each candidate IPL be evaluated for its
effectiveness against a single initiating event leading to a single consequence. Likewise each
candidate IPL must be evaluated for its independence of each initiating event and the other IPLs in

61

that scenario. An IPL may be independent of one initiating event leading to a consequence, and not
be independent of another initiating event leading to the same consequence.
WHAT IS AN IPL?
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. The effectiveness and independence of an IPL must be
auditable.. The PFD or unavailability of the IPL is a measure of its effectiveness (6). All IPLs are
safeguards, but not all safeguards are IPLs. Each safeguard identified for a scenario must be tested
for conformance with this definition. The thought process invoked by the following keywords may
be helpful in evaluating an IPL. (All IPLs may not fit all aspects of the model.)
The three Ds help determine if a candidate is an IPL:
Detect
Most IPLs detect or sense a condition in the scenario.
Decide
Many IPLs make a decision to take action or not.
Deflect
All IPLs deflect the undesired consequence by preventing it.
The three Enoughs help evaluate the effectiveness of a candidate IPL:
Big Enough?
Fast Enough?
Strong Enough?
The Big I is a reminder that the IPL must be independent of the initiating event and the other
IPLs.
UNDERSTAND INDEPENDENCE
An issue for many new LOPA users is determining whether IPLs are independent from the initiating
event and from each other. The LOPA methodology is based on independence and the results will
show falsely low risk if IPLs are included that are not independent. Exercises to understand
independence are important in LOPA training, and it is important that an experienced LOPA
practitioner review the early work of a new LOPA user. Issues of independence frequently involve
the BPCS (Basic Process Control System).
EXAMPLE 1: BPCS INITIATES, BPCS LOGIC MIGHT PREVENT
Failure of a BPCS control loop may initiate the scenario (flow control loop for reactor feed fails to high flow,
leading to a consequence of overpressure and loss of containment with fire). There is a BPCS high pressure
sensor on the reactor with BPCS logic to close the flow control valve. Can the BPCS high pressure sensor and
shutdown logic be considered an IPL? No, the final element for the candidate IPL is part of the control loop that
is the initiating event. If the flow valve failed and caused the high flow, the flow valve will not be able to
prevent the high flow. As LOPA is typically practiced, the control loop as a whole is considered as the initiating
event, and the combination of sensor, logic, and final element as a whole are considered as the candidate IPL.
One could split the initiating event up into sensor, BPCS controller, and control valve and write three LOPA
scenarios; the high pressure sensor and BPCS logic to close the flow valve would be independent of the flow
sensor, but it would not be independent of the BPCS or the flow valve thus it would not be an IPL for the two
of the three scenarios.
For the scenario above, suppose the BPCS high pressure sensor uses BPCS logic to close a different emergency
shutdown valve. Now the sensor and final element of the candidate IPL are independent of the initiating event,

62

but the BPCS logic solver is common to the initiating event and the candidate IPL. The LOPA rules for many
companies do not allow this candidate IPL to be used. Some companies do allow this candidate IPL under
specific conditions including independence of the input and output cards. They require evaluation of this
arrangement by fault tree analysis. This practice is an advanced topic in LOPA (6) and should done with great
care.
EXAMPLE 2: BPCS INITIATES, OPERATOR RESPONSE TO ALARM
For the scenario of Example 1 in which failure of the reactor feed flow control loop initiates the consequence, a
candidate IPL is the existing high flow alarm and operator response to close a manual valve in the reactor feed
line. The sensor for the operator response is part of the initiating event and the candidate IPL can not used as an
IPL.
Suppose there is a high pressure alarm for the BPCS pressure sensor annunciated on the BPCS HMI (Human
Machine Interface) and the operator is trained to close the manual valve in the reactor feed line. While the
sensor and final element are independent, the logic solver for this candidate IPL is common to the initiating
event and the LOPA rules for many companies do not allow this candidate IPL to be used. Some companies do
allow this candidate IPL under specific conditions including independence of the input and output cards. They
require evaluation of this arrangement by fault tree analysis.
EXAMPLE 3: OTHER INITIATOR, BPCS LOGIC MIGHT PREVENT, OPERATOR RESPONSE TO
ALARM
There are systems in which the initiating event is independent of the BPCS and there is control or logic
functionality in the BPCS to prevent the consequence. There may also be an alarm with operator response to
prevent the consequence. Can both the BPCS functionality and the operator response be counted as IPLs? No,
because the BPCS logic solver is common to both the functionality and the alarm. Additionally, IEC 61511 (10)
limits the PFD of all the IPLs based on the BPCS to more than 0.1. In this system for both the BPCS
functionality and the operator response to be counted as separate IPLs, the sensor(s) for the alarm must be
independent of the sensors for the BPCS functionality, the logic solver must be independent of the BPCS
functionality (could be the SIS logic solver), the alarm annunciation must be independent of the BPCS, and the
final elements manipulated by the operator must be independent of the BPCS functionality. Again, some
companies do allow sharing of the BCPCS logic solver under specific conditions including independence of the
input and output cards. They require evaluation of this arrangement by fault tree analysis. The analysis is much
easier for complete independence.

WHAT ABOUT PROCEDURES AND INSPECTIONS?

A frequently asked question, Can procedures and inspections be counted as an IPL? No, because
procedures and inspections do not have the ability to detect the initiating event leading to a
consequence, they cannot make a decision to take action, and they cannot action to prevent the
consequence. For example, the unit has a mechanical integrity program to inspect the reactor
thickness periodically. While that inspection may detect loss of vessel wall thickness, allowing
replacement before the wall deteriorates below the thickness required for the operating pressure, the
inspection does not detect or prevent the overpressure scenario from high reactor feed flow. The
inspection can be viewed as an IPL for another scenario that is, failure of the reactor under normal
operating conditions. The latter scenario is usually not evaluated in LOPA, but is considered in a risk
based inspection program and in a QRA (Quantitative Risk Assessment), a much more detailed
analysis than LOPA.

63

Inspections and tests of the IPLs do not count as another IPL. The inspections and tests do affect the
PFD of the IPL. In general, a longer interval between inspections and tests means a higher PFD. If
the IPL is never inspected or tested, its failure will be discovered when it fails to work when needed.
Procedures do not count as an IPL by themselves. However, procedures used during operations may
reduce the frequency of the initiating event. For example, a start-up checklist that is carefully used
can reduce the frequency of leaving a drain valve open. Likewise, a checklist used during
maintenance can reduce the frequency of leaving a sensor isolated from the process.
MITIGATING IPL
A preventive IPL stops the scenario before it proceeds to any undesired consequence. A mitigating
IPL prevents the identified consequence, but by its success, it may generate another less severe, but
still undesired, consequence. Note that a mitigating IPL does not reduce the severity of the
consequence 100% of the time; every IPL has a non-zero PFD. An example is a relief valve on a
vessel. It prevents the overpressure loss of containment consequence by causing a release from the
relief valve to the atmosphere or to an abatement device (scrubber, flare). In some cases, the relief
valve release is an undesired consequence of significant severity. Another LOPA scenario is written
to determine if the frequency of the relief release consequence meets the risk tolerance criteria. The
second scenario has the same initiating event and the same IPLs as the original scenario with the
exception of the relief device. In some cases, the first scenario may meet the risk tolerance criteria
and the second may not (6, 7).
WHEN TO GO BEYOND LOPA?
There are times when the problem is too complex for LOPA and a more detailed risk assessment tool
is needed, such as event tree analysis, fault tree analysis, or QRA. One trigger is a system where
components are shared between the initiating event and candidate IPLs and there are not any cost
effective means to separate them fully; fault tree analysis may be a better tool. Another trigger is a
system containing two or more mitigating IPLs; splitting such a system up into the appropriate
LOPA scenarios may be difficult and event tree analysis may a better tool. Additionally, if the risk
tolerance criteria are based on the total risk to a population (say, risk to the community, or risk to the
staff onsite), QRA may be a better tool, particularly if the zone affected by each scenario is different
(6).
IMPLEMENTATION TIPS
Implementation of a LOPA system is easier if an organization has defined risk tolerance criteria. It is
very difficult to make risk based decisions without some knowledge of the risk tolerance criteria.
The risk tolerance criteria are used to decide if the frequency of the mitigated consequence (with the
IPLs in place) is low enough. In some organizations, the risk tolerance criteria may be imbedded in
the look-up tables used for LOPA calculations (for example, two IPLs of PFD less than X are
required for a consequence of Y severity and Z initiating event frequency). In other companies, the
risk tolerance criteria are explicitly stated. If the organization has not established risk tolerance
criteria, it may choose to do LOPA on some processes with which it has a lot of experience. It can

64

then benchmark the LOPA results against good engineering practice and industry standards to help
develop risk tolerance criteria.
When an organization implements LOPA, it is good to establish the tools, to develop look-up tables
for consequence severity, initiating event frequency, PFD for standard IPLs, to document the
calculation tools, and then to train the users. It is important that all LOPA practitioners in a company
use the same rules in a consistent way (6).

CONCLUSION
Based on 10 years use of LOPA, risk analysts and SIL assignment teams from many companies
conclude that LOPA is an effective tool for SIL assignment. LOPA requires fewer resources and is
faster than fault tree analysis or quantitative risk assessment. If more detailed analysis is needed, the
LOPA scenarios and candidate IPLs provide an excellent starting point.
LOPA has the following advantages:
Focuses on consequences with high severity,
Considers all the identified initiating causes,
Encourages thinking from a system perspective,
Confirms which IPLs are effective for which initiating causes,
Allocates risk reduction resources efficiently,
Gives clarity in the reasoning process,
Documents everything that was considered,
Improves consistency of SIL assignment
Offers a rational basis for managing IPLs that may be taken out of service, e.g., interlock bypass.

DISCLAIMER
Although it is believed the information contained in this paper is factual, no warranty or
representation, expressed or implied, is made with respect to any or all of the content thereof, and no
legal responsibility is assumed therefore. The examples shown are simply for illustration, and as
such do not necessarily represent any company's guidelines. The readers should use data,
methodology, and guidelines that are appropriate for their situations.

REFERENCES
1. Center for Chemical Process Safety (CCPS), Guidelines for Safe Automation of Chemical
Processes, American Institute of Chemical Engineers, New York, NY, 1993.
2. The Instrumentation, Systems, and Automation Society (ISA), ANSI/ISA 84.01-1996,
Application of Safety Instrumented Systems to the Process Industries, The Instrumentation,
Systems, and Automation Society, Research Triangle Park, NC, 1996.

65

3. International Electrotechnical Commission, IEC 61508, Functional Safety of Electrical /

Electronic / Programmable Electronic Safety-related Systems, Parts 1-7, Geneva: International
Electrotechnical Commission, 1998.
4. Dowell, A. M., III, Layer of Protection Analysis for Determining Safety Integrity Level, ISA
Transactions 37 155-165.
5. Dowell, A. M., III, Layer of Protection Analysis: A New PHA Tool, After HAZOP, Before
Fault Tree Analysis, Presented at Center for Chemical Process Safety International Conference
and Workshop on Risk Analysis in Process Safety, Atlanta, GA, October 21, 1997, American
Institute of Chemical Engineers, New York, NY, 1997.
6. Center for Chemical Process Safety (CCPS), Layer of Protection Analysis, Simplified Process
Risk Assessment, American Institute of Chemical Engineers, New York, NY, 2001.
7. Dowell, A. M., III Layer of Protection Analysis A Worked Distillation Example ISA
Tech/1999, Philadelphia PA, The Instrumentation, Systems, and Automation Society, Research
Triangle Park, NC, 1999.
8. Center for Chemical Process Safety (CCPS), Inherently Safer Chemical Processes: A Life Cycle
Approach, American Institute of Chemical Engineers, New York, NY, 1996.
9. Dowell, A. M., III Layer of Protection Analysis and Inherently Safer Processes, Process Safety
Progress, 18, 4, 214-220.
10. International Electrotechnical Commission, IEC 61511, Functional Safety Instrumented Systems
for the Process Industry Sector, Parts 1-3, International Electrotechnical Commission, Geneva,
Draft in Progress.

NOMENCLATURE
BPCS
CCPS
HAZOP
HMI
IEC
IPLs
ISA
LOPA
PFD
PHA
QRA
SIF
SIL
SIS

Basic Process Control System

Center for Chemical Process Safety
Hazard and Operability Analysis
Human Machine Interface
International Electrotechnical Commission
Independent Protection Layer
The Instrumentation, Systems, and Automation Society
Layer of Protection Analysis
Probability of Failure on Demand
Process Hazard Analysis
Quantitative Risk Assessment
Safety Instrumented Function
Safety Integrity Level
Safety Instrumented System

66

IPL1

IPL2

IPL3
Consequence
Occurs

success
Initiating Event

Safe Outcome
Undesired but
tolerable outcome

success

success Undesired but

tolerable outcome

failure
failure

failure
Key:
Thickness of arrow
represents frequency of
the Consequence if later
IPLs are not successful

Impact
Event

Consequences
exceeding criteria

Frequency

FIG. 1 - COMPARISON OF LOPA AND EVENT TREE ANALYSIS [COPYRIGHT 2001

BY THE AMERICAN INSTITUTE OF CHEMICAL ENGINEERS, AND REPRODUCED
BY PERMISSION OF AICHE]

67

68

EVALUATING
F URTHER RISK
REDUCTION
SUGGESTIONS

Chapter 3

ESTIMATING
CONSEQUENCE
AND SEVERITY

Other Chapters
Chapter 1: Introduction
Chapter 2: Overview of LOPA
Chapter 9: Implementing LOPA
Chapter 10: Using LOPA for
Other Applications
Chapter 11: Advanced LOPA
Techniques

Chapter 4

Chapter 8

DEVELOPING
SCENARIOS

MAKING RISK
DECISIONS

IDENTIFYING
INITIATINGEVENT
F REQUENCY

DETERMINING
SCENARIO
FREQUENCY
Chapter 7

Chapter 5

IDENTIFYING
RELATED IPL S
Chapter 6

FIG. 2 - HOW LOPA WORKS [CHAPTERS REFER TO (6), COPYRIGHT 2001 BY THE
AMERICAN INSTITUTE OF CHEMICAL ENGINEERS, AND REPRODUCED BY
PERMISSION OF AICHE]

69