More Related Content
Similar to LOPA_SIS - in plain English
Similar to LOPA_SIS - in plain English (20)
LOPA_SIS - in plain English
- 1. 1120 Nasa Parkway
Suite 507
Houston, TX 77058
832-861-6011
SAFE | EFFICIENT | QUALITY
www.sandsepc.com 866-404-1845 1 of 8
© S&S Engineering and Construction Inc. 2015
Authors: Sheri Sammons PE, CFSE – S&S Engineering and Construction Inc.
Robert Sammons – S&S Engineering and Construction Inc.
Title: White Paper – LOPA & SIS in plain English
LOPA/SIS - An Introduction
Application of Safety Instrumentation Systems (SIS) is an evolving topic in the process industries. SIS are
employed to reduce risk in an operating facility. Industries and Facilities have varying levels of
implementation of SIS. Some facilities have SIS installed per the newest standards, some have SIS installed
that may not meet the current accepted standards, and some organizations have not installed SIS.
Organizations that have SIS installed can perform Functional Safety Assessments to confirm that their
installation meets the current accepted standards. For organizations that have not installed SIS, a basic
understanding of tool to identify the requirements for SIS and an introduction to the Safety Instrumented
System Safety Lifecycle are an important starting point.
This whitepaper will provide an introduction to one tool used for assessment of SIS requirements - Layer of
Protection Analysis (LOPA) and to the concepts of the Safety Instrumented System Safety Lifecycle outlined
in the globally recognized standards ISA 84.01 2004 and IEC61511. A basic understanding of process hazard
analysis is assume in this paper.
This paper will not provide a specific SIS implementation roadmap for a company or for specific facilities. In
order for a roadmap to be developed, the following components should be addressed
- Availability of Documentation and Data
- Strategy for Risk Mitigation and Tolerance
- Personnel and Competence
- Practical and Effective Tactics to accomplish company goals
LOPA/SIS – The relationship
Many people use the terms LOPA and SIS interchangeably. However, LOPA – Layer of Protection Analysis
and SIS – Safety Instrumented Systems are two distinct functions that may or may not be associated with
one another. A LOPA is a semi-quantitative hazard and risk review tool. It allows for a more quantitative
review of the likelihood of potential causes and safeguards associated with process safety hazards in an
industrial setting than a Process Hazard Analysis. A LOPA looks for Independent Protection Layers that are
safeguards that meet a specific criteria. One type of IPL is a Safety Instrumented Function (SIF) that may
reside as part of a larger Safety Instrumented System (SIS).
A Safety Instrumented System (SIS) is a functional system that directly affects the operation of a process.
Most SIS are interlocks that take an operation to a safe state through the opening or closing of end devices
- 2. 1120 Nasa Parkway
Suite 507
Houston, TX 77058
832-861-6011
SAFE | EFFICIENT | QUALITY
www.sandsepc.com 866-404-1845 2 of 8
© S&S Engineering and Construction Inc. 2015
in the field. Before the adoption of recognized standards for Safety Instrumented Systems – many different
types of interlocks were identified as safeguards in qualitative hazard and risk reviews as acceptable risk
reduction factors. Since the global introduction and acceptance of Safety Instrumented System Standards,
interlocks and other safety instrumented systems are expected to meet more rigorous design and
maintenance requirements than in the past. A LOPA is one tool that allows an organization to determine
how rigorous the interlock requirements should be.
LOPA
Layer of Protection Analysis (LOPA) is a concept introduced by the Center for Chemical Process Safety (CCPS)
in 2001. It is a risk assessment tool that was developed by chemical companies to provide a more
quantitative assessment of the risks that are found in their operating facilities than a Process Hazard
Analysis (PHA) but less quantitative than a Quantitative Risk Assessment (QRA). The LOPA review is
quantitative regarding the likelihood or frequency that an already identified event will occur. Instead of a
team determining likelihood by their collective experience in industry, the team determines potential causes
for catastrophic consequences. The team follows the event from the cause through the consequence using
failure rates of initiating causes and independent protection layers to determine the likelihood that the
consequence will occur.
Likelihood of event = Likelihood of cause occurring * likelihood of IPLs failing
Layer of Protection Analysis differs from a Process Hazard Analysis (PHA) in the following ways:
The PHA team identifies and documents Hazards associated with the operation of the facility and
then determines the cause and potential consequence of the events associated with the Hazard – a
LOPA team uses the already determined consequence from the PHA,
the PHA team identifies safeguards that reduce the risk of an event and assign the risk reduction
based on the collective experience and knowledge, the LOPA team allows risk reduction for only IPL
that meet defined criteria
The PHA is a qualitative review that is based on the experience of the team - one issue with using a
qualitative identification of safeguards is that there may not be consistency in identification of the
quality and reliability of the chosen safeguard. A LOPA relies on the experience and knowledge of
team to determine consequence severity but uses accepted failure rate data for IPL and other
quantitative data to determine likelihood.
Both the PHA and LOPA are based on a company accepted risk profile for the risk of the event
occurring and acceptability of the risk. This is typically depicted in a risk matrix.
- 3. 1120 Nasa Parkway
Suite 507
Houston, TX 77058
832-861-6011
SAFE | EFFICIENT | QUALITY
www.sandsepc.com 866-404-1845 3 of 8
© S&S Engineering and Construction Inc. 2015
LOPA implementation
The following are requirements for completing a LOPA
A completed hazard review of a scenario
Documents to be used during the review
o P&ID, PFD
o Operating procedures
o Relief valve documentation
Risk profile for use by LOPA team (LOPA specific Risk Matrix)
LOPA procedure identifying
o Initiating Causes/Failure Rates,
o Acceptable Independent Protection Layers/Failure rates,
o acceptable enabling conditions and conditional modifiers (if used)
o criteria for when to perform a LOPA – Severity Ranking, Risk Ranking or both
Typical LOPA team composition includes
Operator
SIS and/or Control Systems Engineer
- 4. 1120 Nasa Parkway
Suite 507
Houston, TX 77058
832-861-6011
SAFE | EFFICIENT | QUALITY
www.sandsepc.com 866-404-1845 4 of 8
© S&S Engineering and Construction Inc. 2015
Maintenance representative
Facilitator
Process engineer
Generic Steps to completing a LOPA
The facilitator or LOPA lead will gather required information or confirm that information will be
readily available during the LOPA.
The team will identify the initiating cause of a potential event occurring. Some examples of causes
used in LOPA are control loop (valve) failure, human error, pressure regulator failure.
Each cause should have a defined failure rate per company documentation. This provides the base
likelihood that the consequence associated with the cause could occur. If enabling conditions are
defined within the risk profile of the company, they would be assigned here.
Since the severity of the consequence was typically already determined during the HAZOP/PHA, this
should not change unless there is compelling evidence that the original team missed information. If
conditional modifiers are defined based on the risk profile of the company, they would be assigned
here to reduce the likelihood of the consequence occurring.
The team would the use the company accepted LOPA risk matrix to determine if IPL(s) are required
to reduce risk.
The team would look at previously identified safeguards to determine if they meet IPL criteria
including reviewing the design and maintenance documentation for the safeguard.
If additional IPL(s) are required the team should look for to see if there are existing non-
instrumented IPL (relief valves) and instrumented systems such as alarms with defined operator
actions that are available for the scenario.
If not, the team should make recommendations to add IPL(s) based on the risk reduction required.
Safety Instrumented Systems should only be added if the other IPLs cannot close the risk gap.
Once the LOPA team completes reviewing all of the cause-consequence scenarios, all of the
recommendations should be assigned to personnel and tracked to closure.
A LOPA report should be written and kept with the associated PHA/Hazard Review.
- 5. 1120 Nasa Parkway
Suite 507
Houston, TX 77058
832-861-6011
SAFE | EFFICIENT | QUALITY
www.sandsepc.com 866-404-1845 5 of 8
© S&S Engineering and Construction Inc. 2015
Safeguards as IPLs
A safeguard is an identified item or function that protects or mitigates an operation or facility from an event.
Safeguards are identified during the Process Hazard Analysis. A major benefit of using LOPA is to improve
the consistency of choosing acceptable safeguards for high potential incidents during or after Hazard
Identification and Risk Assessment. In order for a safeguard to be considered an Independent Protection
Layer, Guidelines for Initiating Events and Independent Protection Layers in Layer of Protection Analysis
(CCPS 2015) recommends it have the following attributes - Independence, Functionality, Integrity,
Reliability, Auditability, Access Security and Management of Change.
There are two different types of IPLs – passive and active
Passive IPLS include dikes, insulation, overflow lines
Active IPLs include Safety Controls, Alarms and Interlocks, Relief Systems, Multiple Seals on a pump
Each IPL that is used in an operating facility must be designed, implemented, operated and maintained to
meet the seven attributes above. IPLS and Initiating causes may have failure rates that are different by
orders of magnitude. These can be used for frequency calculations. A commonly used correlation is that 1
IPL is equal to a failure rate 1x10-1
per year. CCPS has published Guidelines for Initiating Events and
Independent Protection Layers in Layer of Protection Analysis with industry based failure rates for different
types of IPLS. Safety Instrumented Systems failure rates are determined using equipment specific
information.
This paper will provide a basic introduction to using Safety Interlocks (Safety Instrumented Systems) as IPLS.
SIS as IPLS
Safety Controls, Alarms and Interlocks are commonly used to reduce operational and safety risk. They are
systems that depend on instrumentation, logic solvers and either an automatic or manual field device. Over
the years facilities have used varying technology levels of these implementations to bring a process to a safe
state. Mechanical relays and pneumatic controllers were used to control and shutdown boilers and this
technology was then introduced to manufacturing facilities. As technology advanced, computer processor
based systems became more prevalent. As control systems became capable of running multiple control
loops, operating facilities moved their controls and interlocks to the microprocessor based systems (Basic
Process Control System).
However, it became apparent through industry experience that relay based systems and Basic Process
Control Systems and their associated field devices may not have the reliability/integrity to shutdown a
system or take the process to a safe state on demand. Also in some cases, the interlocks may have been
designed to protect operations, but not take the process to a safe place. The global organizations of IEC and
ISA developed standards to improve the safety response for safety related controls.
- 6. 1120 Nasa Parkway
Suite 507
Houston, TX 77058
832-861-6011
SAFE | EFFICIENT | QUALITY
www.sandsepc.com 866-404-1845 6 of 8
© S&S Engineering and Construction Inc. 2015
There are three commonly accepted standards for Safety Instrumented Systems – IEC61508, IEC 61511 and
ISA 84.01. IEC 61511 and ISA 84.01 were developed for process industries as an expansion on the hardware
design requirements in IEC 61508. ISA 84.01 is a duplicate of IEC 61511 with an added “Grandfather “clause.
It is the recognized and generally accepted engineering practice for SIS applicable to PSM regulated
companies in the USA. OSHA has cited and fined several companies in the US for not following the
principles outlined in this standard. This paper will be based on implementing safety instrumented systems
using the principles in ISA 84.01/IEC 61511.
The basis for IEC 84.01/IEC 61511 is a safety lifecycle. The safety lifecycle defines the requirements and steps
to implementing a Safety Instrumented System/Safety Instrumented Function. It includes the following
steps:
Safety Lifecycle Step Actions
Hazard and Risk Assessment HAZOP/LOPA or other risk assessment tools
Allocation of safety functions to protection layers LOPA
SIS safety requirement specification (SRS) Definition of SIS requirements
SIS design and engineering Design of SIS to meet SRS,
SIS installation, commissioning, and validation SIS is installed per design requirements, commissioned
and proof tested to show that it meets functional
requirements outlined in SRS
SIS operation and maintenance The SIS is put into operation and is maintained and proof
tested per requirements outlined in SRS
SIS modification If there are changes required to the SIS or changes to the
Hazard and Risk identified, and MOC should be used to
confirm safety requirements of updated system.
Decommissioning If a SIS is removed from service, the reason for removal
should be documented.
SIS verification Throughout the safety lifecycle, there should be
verification that is step is being followed and that the
appropriate documentation is updated.
SIS functional assessment Each Safety Instrumented Function should be evaluated
to confirm that it has been designed, engineered and
installed to meet the integrity level required and that it
will protect against the hazard that it has been designed
for.
- 7. 1120 Nasa Parkway
Suite 507
Houston, TX 77058
832-861-6011
SAFE | EFFICIENT | QUALITY
www.sandsepc.com 866-404-1845 7 of 8
© S&S Engineering and Construction Inc. 2015
When dealing with safety instrumented systems, it is important to remember how they are different from
basic process control systems. Safety Instrumented Systems sit idle until they are required to take action.
Process Control Systems are always updating information to improve the control of the process around
process variable. If there is a problem with the process control system functions, it will be fairly obvious to
the operator. However if the safety instrumented system has a failure that isn’t detected by diagnostics, the
failure won’t be obvious to the operator and could cause the SIF to not take the process to a safe state when
required. In addition, the SIF is there reduce risk catastrophic event. If it does not work, the catastrophic
event could occur. In order to determine the likelihood that the SIF will not work when required, the
probability of failure on demand (PFD) is calculated. This pfd corresponds to a Safety Integrity Level that
determines the Layers of Protection or Risk Reduction that can be attributed to a given SIF.
Safety Integrity Levels and associated Probability of Failure on Demand
SIL PFD
4 >10-5
to < 10-4
3 >10-4
to < 10-3
2 >10-3
to <10-2
1 >10-2
to <10-1
In order to reach the lower probabilities of failure on demand, special equipment, redundant equipment and
more frequent testing is required. This leads to higher installation and maintenance costs.
The use of safety interlocks requires an understanding of the 1) hazard the safety system is protecting the
process from and 2)the IPLs or risk reduction factors required to achieve acceptable risk in order to develop
the functional requirement of the interlock. This is the basis to implementing the safety system lifecycle -
design, engineering, installation, commissioning, operation, maintenance (Inspection and testing
requirements).
Before adding an SIS, it is strongly recommended to use other IPLs to reduce risk in place first.
Summary
A Layer of Protection Analysis is used a as semi quantitative tool to evaluate to the risk of already identified
high potential risks in an operating facility. The outputs of the LOPA include identification of Independent
Protection Layers that protect the facility from the potential consequences of the event. Each Independent
Protection Layer has a failure rate associated with it. This is used to determine if the potential frequency of
the event based on these failures is acceptable based on the consequence severity. If the IPLS available do
not reduce the risk to an acceptable range, additional IPLS should be recommended. Safety Instrumented
Systems should be the last resort for implementation of IPLs based on their cost to install and operating and
maintenance requirements.
- 8. 1120 Nasa Parkway
Suite 507
Houston, TX 77058
832-861-6011
SAFE | EFFICIENT | QUALITY
www.sandsepc.com 866-404-1845 8 of 8
© S&S Engineering and Construction Inc. 2015
If existing Safety Instrumented Systems are given IPL credit or their implementation is recommended from a
LOPA, the Systems should follow the approach outlined in ISA 84.01 2004 in the US or IEC 61511 in Europe
(rest of the world). An organization can develop their own standards to follow for SIS, but in the US for PSM
regulated sites, the standard must be as comprehensive as ISA 84.01 2004.
Implementation of Safety Instrumented Systems requires analysis of existing operations to develop an
understanding of why and where SIS should be implemented and where they should not be implemented.
This paper discussed some basic concepts (LOPA and SIS Safety Lifecycle) associated with SIS to provide
groundwork for development of a practical implementation roadmap for SIS.
Bibliography
Guidelines for Initiating Events and Independent Protection Layers in Layer of Protection Analysis (CCPS,
2015, Wiley)
ANSI/ISA 84.00.01- 2004 Part 1 (IEC 61511-1 Mod) Functional Safety: Safety Instrumented Systems for the
Process Industry Sector – Part 1: Framework, Definitions, System Hardware and Software Requirements.