When is an Independent Protection Layer (IPL) Not a Safeguard

We are going to continue discussing the results from exidas recently published industry
benchmark survey on the practices for the use of alarms as safeguards and IPLs. Over
200 safety practitioners from around the world provided responses. This entry will
discuss the relationship between alarms identified as safeguards and those that
become IPLs. One industry reference defines a safeguard as a potential protection
layer that has yet to be evaluated in a LOPA to determine effectiveness and
independence [1]
Respondents provided feedback to the following question: What percentage of the
alarms that are considered during a Layer of Protection Analysis (LOPA) were identified
during a Process Hazard Analysis (PHA)?
Ideally 100% of the alarms that are considered in a LOPA would have first been
identified as a safeguard/recommendation in the PHA. Figure 2 shows that in practice,
this is far from the case. Only 12.4% of the respondents indicated that all (100%) of the
alarms in the LOPA had come from the PHA. 51% of the respondents appear to
frequently identify new alarms during LOPA that were missed during the PHA. This
would seem to indicate poor PHA practices. Failing to identify alarms during a PHA could
signal various issues, such as a lack of thoroughness, lack of documenting all
safeguards in order to save time, or a lack of understanding of the process. This blogger
wonders whether this pattern is unique to the treatment of alarms or is present for
other safeguards as well.

SIS Should Only Be Used as an IPL Once

Another mistake that I commonly run into when reviewing HAZOP/LOPA studies (i.e.,
studies where the SIS is included as a protection as opposed to LOPA/SIL where the SIS
is not considered an IPL so that its performance target can be determined) is the
unrealistic use of the SIS in multiple protection layers. This is a clear violation of the
separation criteria of a protection layer that often gets neglected due to
inexperienced analysts focus on sensors instead of entire SIF. The best rule of thumb
for including a SIS as an IPL in a LOPA is that the SIS can only be used as a protection
layer once per scenario. Granted, the SIL target may be high (e.g., SIL 2 or SIL 3 with
corresponding failure probability of 1% and 0.1%), but credit can only be taken once.
Let me clarify this rule with an example of an analysis that was done very poorly, and
the correct assessment of the situation. Consider the hazard of overfilling a compressor
knockout drum with liquid which subsequently could be carried over into the machine
causing damage to the machine and potential loss of containment through damaged
seals. The assessment team, lead by an inexperienced facilitator with little
understanding of how SIS worked listed the following IPL.
1. High Level Shutoff
2. High Vibration Shutoff

3. High/Low Motor Current Shutoff

4. and strangely, High Pressure Shutoff
Furthermore, the team stated that since the facility used a SIL 3 rated logic solver, all of
these protection layers afforded three orders of magnitude of risk reduction, resulting in
an overall protection level of 12 orders of magnitude of risk reduction.
Incredibly safe? Hardly. This analysis was a comedy of errors that I will now dissect.
The first thing to note is the amateur description of the SIS IPL that only includes the
sensor and not the action taken. This is usually a dead giveaway that the analysis was
put together by a rookie who doesnt understand the SIS IPL. While each one of these
protection layers does indeed use a separate sensors, they all share the same logic
solver (with the possible exception of the over/undercurrent trip) and all share the same
final element, i.e., the compressors motor starter. In reality you dont have four SIFs,
you have one SIF with four sensors (at least that is what the team alleges.
Furthermore, the high pressure SIF blatantly violates the specificity criteria of an
IPL. You cant argue that the high pressure shutdown in the separator vessel was
specifically designed to detect an overfill condition. Even high current and vibration
trips are of dubious credibility with respect to an overfill condition, but are still
somewhat commonly used. In this scenario, the team theorized that if the separator
drum were to overfill it would also result in a high pressure, which would be detected by
the high pressure switch. This is in fact not true, in addition to being not specific and
not separate.
Finally, while a SIL 3 logic solver may be a good thing, that doesnt mean that every
loop that goes through the logic solver is SIL 3. In fact, most of the failure probability is
associated with field equipment, which in this case was blind switches capable of
achieving SIL 1, but not more.
Ultimately, all of the protection layers that were listed by the team fell very much short
of reaching the purported 12 orders of magnitude of risk reduction. The most restrictive
interpretation of an IPL would only allow credit for the high level SIF (the others are not
really specific, and not really separate), which can only provide one order of magnitude
of risk reduction. If you additionally took credit for the vibration and/or
under/overcurrent sensing, these are not additional protection layers, but could be
considered as additional sensors for the single SIF that protects the compressor. If
these multiple sensors are considered as part of the SIF, then the SIF could likely
achieve SIL 2, but no more. The final result not 12 orders of magnitude of risk
reduction, but at most 2.

Acceptable Sharing of BPCS and SIS Field Measurements

Posted November 30, 2014 by Kevin Mitchell
Many users of safety automation equipment employ a practice of using redundant field
devices on safety-critical process measurements (e.g., level transmitters, flow
transmitters, pressures transmitters, etc.). These users, who are often in the petroleum
refining industry, typically use these measurements in a 2oo3 (two-out-of-three) vote to
shutdown using triplicated field instruments, with this logic being implemented in the

Safety Instrumented System (SIS) logic solver. Less commonly, some also use these
same three signals as inputs to the basic process control system (BPCS), usually with a
mid-select function for feedback control of a process variable. This practice involves
splitting each of the three signals with one analog input to the Safety PLC and one
analog input to the BPCS. Signal repeaters are typically powered by the SIS.
ISA and IEC standards for SIS encourage users to separate field devices used in BPCS
from field devices used in the SIS. The intent is to ensure that no device that is used in
BPCS can fail in a way that inhibits or degrades the performance of the SIS. This
position would argue that the shared transmitter practice of shared BPCS and SIS
transmitters in a 2oo3 vote is not compliant with ISA and IEC standards for SIS. The
ANSI/ISA 84.00.01-2004 standard Functional Safety: Safety Instrumented Systems for
the Process Industry Sector (harmonized with the IEC-51511 standard) states:
Clause 11.2.9 The design of the SIS shall take into consideration all aspects of
independence and dependence between the SIS and BPCS, and the SIS and other
protection layers. And
Clause 11.2.10 A device used to perform part of a safety instrumented function shall
not be used for basic process control purposes, where a failure of that device results in
a failure of the basic process control function which causes a demand on the safety
instrumented function, unless an analysis has been carried out to confirm that the
overall risk is acceptable.
Therefore, allowance is made for situations where sharing BPCS / SIS field devices is
suitable from the perspective of risk. In precise terms used in risk analysis, shared
signals for BPCS and SIS only become a problem when there is a potential for a
transmitter failure that inhibits or degrades the performance of the SIS while
simultaneously creating a demand for the SIS to take action by causing the BPCS to
malfunction in a way that initiates a hazardous condition. For example, if loss of liquid
level in a vessel could result in a hazardous gas blow-by event, a single level
transmitter that is used for both control and safety could fail in place above the set
point. This would falsely indicate a high level. In this scenario with a single transmitter
and a 1oo1 vote to trip, the SIS would be unaware of any subsequent low level
conditions. Simultaneously, the BPCS would sense high level and take action to drive
the level in the vessel lower. Because the transmitter has failed in place, the level would
continue to drop until a hazardous low level condition occurred. Clearly, this is not an
acceptable level transmitter configuration for safety-critical applications.
Conversely, shared signals for BPCS and SIS are not an issue in risk analysis terms,
when there is no potential failure mode of the BPCS control loop that would place a
demand on the SIS. One example would be backflow prevention safeguards afforded by
shared flow transmitters. The SIL Selection team identified no failure modes for flow
control loops that could result in a potential hazardous backflow condition occurring.

This hazard would only occur if charge pump fails. No demand would occur for the SIS
to trip even if flow transmitter(s) were in a failed state.
In the refining industry, we see use of three transmitters in a 2oo3 vote to trip in the SIS
and a mid-select function in the BPCS. When 3 transmitters are operational, no single
transmitter failure would simultaneously inhibit the SIS and initiate a hazardous
condition that would place a demand on the SIS. However, not all transmitter modes-offailure, that would traditionally be safeguarded by a typical 2oo3 vote to trip, are being
safeguarded by this practice.
Kenexis has identified the following failure modes that are unprotected by the SIS:
Two transmitters failed in a dangerous undetected mode such as fail-in-place. This
would defeat the protection afforded by the SIS. In this case, the demand for the
hazardous condition would occur simultaneous with the failure of the second
transmitter. Because three transmitters are used to sense the same process variable,
deviation alarms could be used to diagnose a single transmitter being failed-in-place.
A common cause failure mechanism that simultaneously defeats all three transmitters.
Note: this failure mechanism could not be argued to be safeguarded against by
providing additional transmitters that physically separate the BPCS and SIS.
The SIS has degraded to a 1oo1 vote due to diagnosed failures of two out of three
transmitters. Repair to either transmitter has not yet occurred. In this time interval, a
single transmitter is now being used for both control and SIS protection. If this
transmitter were to fail dangerous undetected mode (e.g., fail-in-place) prior to repair of
the remaining two, the SIS would be inhibited and the BPCS would simultaneously
initiate a hazardous condition that would result in a demand on the SIS. Using
administrative procedures that ensure faulted transmitters are repaired within a
relatively short time-frame (e.g., 72 hours) would greatly reduce the likelihood of this
scenario. This would be covered under procedures for defeat of critical safety systems
and temporary operation with Safety Instrumented System in bypass.
Kenexis advises our customers that ISA / IEC standards do not promote use of the
practice of sharing BPCS/SIS transmitters. Further, Kenexis advises our customers on
the potential failure modes which are not protected by the SIS when using this practice,
which are limited to the above four identified interlocks.
Some customers deem these risks to be tolerable given the engineering design and
strong administrative controls that are in place for these systems. Others prefer the
more traditional separation of BPCS and SIS transmitters. ANSI/ISA standards on SIS
allow sharing, but require additional analysis of failure modes, the likelihood of failure,
and an assessment of the risk.

SIS Function Testing

Posted November 6, 2014 by Kevin Mitchell
I recently assisted a customer in testing a newly installed Safety Instrumented System
(SIS) at a Natural Gas Liquids (NGL) processing facility. The activity was a Site

Acceptance Test (SAT) in which Safety Instrumented Function (SIF) is thoroughly tested.
The plan involved exercising each transmitter through its range of normal operation,
alarm points, and trip points. Final elements were reset and observed to change state
during a trip, thereby proving that the SIF logic as well as all field devices were
functioning properly. We encountered a non-conformance when testing for transmitter
fault conditions. The procedure involved driving the transmitter outside the normal 4 to
20 mA range. The expected behavior is for this to be detected by the SIS logic solver,
and the associated process variable to be placed in a vote-to-trip state. In the first,
when we drive the transmitter below the calibrated range resulting in a signal below 4
mA at the PLC. However, no vote-to-trip occurred. The signal was lowered to 3 mA, 2
mA and so forth, but no change in state was observed. We discovered that the
configuration of the logic solver relied upon fault detection at the Analog Input module,
which would set a fault bit and communicate this to the processor. It was noted that this
logic was not properly functioning. The resolution was to program logic in the SIS
application for the processor to detect the out of range condition and properly place the
process variable in a vote-to-trip state.
A thorough examination of the SIS should include defining the saturation current of
each transmitter or type of transmitter being used as input to the SIS. Saturation
current is the lowest current that a transmitter will generate while still functioning
within the calibrated range. For example, a transmitter may be able calibrated to read
100 psig to 1500 psig. 4mA would correspond to 100 psig. The saturation current may
be 3.9 mA for a transmitter. The fault detection is typically set at 0.1 mA below the
saturation current, or other value specified by the vendor. This results in a fault
detection at 3.8 mA or below for this example. Logic was also programmed to detect an
over-range fault as well; however, each transmitter is configured to drive the signal
downscale on a self-diagnosed fault condition. Again, the exact value of the fault
current will vary from vendor to vendor, but it will be significantly lower than the
saturation current. For example, the fault current may be 3.75 mA, which would be
detected by our 3.8 mA or less PLC diagnostic.
The important concept here is to understand the engineering techniques used to verify
that the design of the SIF meets the Safety Integrity Level (SIL) target. This is known as
SIL Verification, which involves a reliability engineering principals and an examination of
possible device failure modes. Each transmitter will have a characteristic failure rate for
failure modes such as Fail High, Fail Low, and Fail in Place. Self-diagnosed fault
conditions are usually configured to result in a Fail Low effect. The SIL verification
calculations typically assume that all over-range (>20mA) or under-range (<4mA)
conditions result in a vote-to-trip, which results in a potentially dangerous failure mode
being converted to a safe outcome. This reduces the SIF probability of failure on
demand (PFD) and increases the achieved Risk Reduction Factor (RRF). It would be a
significant gap if the SIS configuration for fault detection does not match with these
assumptions used in SIL verification.
At Kenexis, we always require function test plans to verify proper handling of
transmitter faults by the SIS Logic Solver. When using a Safety PLC that is certified for
SIS applications, this fault handling is typically the default configuration. However, when
using a general purpose industrial PLC with a safety configuration, this type of fault
handling may require application programming. Please contact Kenexis is youd like
more guidance on SIS function testing, also called proof testing.

Process Safety Milestones

Posted September 22, 2014 by Kevin Mitchell
I recently assisted a customer in conducting risk analysis to develop a Safety
Instrumented System (SIS) design. The chemical process involved storage and handling
of Methyl Isocyanate (MIC), and I was reminded that this coming December will be the
30th anniversary of the Bhopal tragedy, which involved the same chemical. Bhopal
was one of the major turning points in the movement toward a series of safety
principals that would later become known as Process Safety. My professional opinion
is that the severity of the Bhopal event could not occur in the US due to several
fundamental differences; but, I also advocate that we should never be complacent. My
recent experience prompted some introspection on the progress made in 30 years
toward improving process safety. I started my career as a process engineer in 1992;
coincidentally, this was the same year as the advent of the OSHA Process Safety
Management standard. Throughout 20+ years I have seen many changes for the
better. Some prompted by government regulations, but most from industry initiatives.
Sadly, there have also been numerous serious process accidents since that time. While
each is a tragedy, industry should respond to the learnings from these accidents.
In retrospect, here are just a few important process safety improvements, many of
which didnt exist or were not widely practiced in 1992.
Process Hazards Analysis to identify hazards and qualitatively assess their significance
Change Management to assess the safety impacts of proposed changes before they are
implemented
Mechanical integrity programs and risk based inspection instead of breakdown
maintenance
Layer of Protection Analysis (LOPA) to provide consistent semi-quantitative risk analysis
and use as the design basis for critical instrumentation and control
An independent agency charged with investigating chemical process incidents and
communicating lessons learned
Facility siting analyses resulting in blast resistant control buildings and relocating
personnel out of process areas.
Industry consortia for sharing process safety information such as component failures
and lessons learned
Discipline to define safe operating limits and ensure those limits are not violated, even
if it means downtime and lost production
As we look ahead, some challenges remain. Currently, the US Environmental Protection
Agency (EPA) is considering additional regulatory action under 40 CFR Part 68 Risk
Management Program (RMP). In a request for information, EPA has asked for input on
several aspects of process safety. EPA will review responses received by 29 October
2014, and decide what action, if any, to pursue.
Just some of the topics of interest to regulators, include:
Application of Process Safety regulations to reactive chemicals such as ammonium
nitrate.

Formalizing requirements for considering Inherent Safety in process design and

operation
Automated release detection measures such as gas detection and fire detection
Third Party Compliance Audits of Process Safety Management programs
Integrating Safety & Security practices as part of the Presidents directive on Improving
Chemical Facility Safety and Security
Managing organizational change in addition to managing process change
The Safety Case Model, which is a European requirement for facilities to document
and submit a technical justification for safe design and operation, as a condition of
permit to operate
While I dont advocate more government regulation, I do believe that several of these
concepts would indeed reduce the frequency and severity of process safety incidents.
We should strive for a balance of increasing rigor of existing good practices with
stretching to reach new initiatives with new goals. Im reminded of the philosophy of
DuPont, which was once described to me simply as zero. The goal is zero incidents,
zero harm to people, and zero impact on the environment. Its an ambitious target that
helps keep our eyes looking forward and focusing always on continual improvement.

Bypass of Safety Instrumented Functions

Posted August 25, 2014 by Kevin Mitchell
Kenexis is commonly asked to assist in specifying requirements for bypassing functions
the Safety Instrumented System (SIS). Most SIS share a common Human Machine
Interface (HMI) with the Basic Process Control System (BPCS). The HMI application
software typically runs on a server and communicates with both the BPCS and the SIS
using a digital protocol (e.g., Modbus, Ethernet I/P, etc.). In rare situations the SIS will
have its own, dedicated HMI, but this is not typical.
Operators will bypass a Safety Instrumented Function (SIF) using the HMI, which
communicates bypass information to the SIS controller. For relatively small systems,
bypass is accomplished using physical switches that are hardwired inputs to the SIS, but
this is increasingly uncommon.
For most systems, Kenexis limits the ability to bypass to SIS inputs; we disallow SIS
outputs or overriding the commanded state of a SIF. In doing so, operators are
required to take responsibility for providing alternate protection when bypassing any
process condition that is being monitored by the SIS.
Using any digital protocol to communicate bypass status should be carefully engineered
to avoid an unsafe bypass situation. Good engineering practice is described in ANSI/ISA
84.00.01-2004 (IEC 61511-MOD), Clause 11.7.3.1 The design of the SIS communication
interface shall ensure that any failure of the communication interface shall not
adversely affect the ability of the SIS to bring the process to a safe state.
Failure of the communications link between the HMI server and SIS should not create a
situation where a bypass remains in effect when it shouldnt be. Of course, we could
configure the SIS to monitor the status of the communications link and take some pre-

defined action, which could theoretically include automatic shutdown of the process.
Albeit safe, this would not be desirable in most situations, so other configuration
options should be considered.
Typically, Kenexis recommends the SIS be provided with physical switch that is
hardwired to an SIS digital input channel. This is usually a keyswitch that is designated
Bypass Enable. When the switch is in the NORMAL position, the input channel is
OFF, and the SIS is programmed to ignore any requests to bypass any SIS input from
the HMI. When the switch is in the ENABLE position, the input channel is ON, and the
SIS will permit bypasses to be requested from the HMI.
Failure of the communication link between the HMI and the SIS would be a revealed
condition that would generate a fault alarm; however, the state of bypasses would not
change in the SIS. Even though the comm link is down, operators can remove any
bypasses by switching the Bypass Enable keyswitch to NORMAL.
If a Bypass Enable switch has not been provided in the design, then operators would not
have this ability to remove bypasses that were in effect at the time of the
communications failure. This does not conform to Clause 11.7.3.1. To resolve this
without adding a bypass enable switch, we would require the SIS to be configured to
automatically remove any bypasses that might be in effect at the time of comms
failure. Obviously, this could result in a SIF to activate if an input were not in service or
otherwise outside the safe operating limits at the time of the comms failure. As this
may result in an unwanted shutdown of the process, the bypass enable switch avoids
the need for this configuration of the SIS.

SIL 3 Requirements from LOPA, Should be Challenged Before Implementing Costly

Systems
Posted August 15, 2014 by Kevin Mitchell
Recently Kenexis was asked to develop an SIS design for an NGL processing facility. The
hazards were associated with operation of equipment beyond design temperature and
pressure ratings of equipment including pressure vessels, distillation towers,
condensers, reboilers, and pressurized liquid storage tanks. A third party conducted a
hazard and risk analysis to establish target Safety Integrity Levels (SIL) for various
Safety Instrumented Functions (SIF). Our challenge was to identify requirements for
both field instrumentation and the SIS Logic Solver. During our review of the risk
analysis, which was conducted using Layer of Protection Analysis (LOPA), we discovered
several requirements for SIL 3 shutdown of equipment. Most SIL 3 requirements arose
from postulated risk scenarios in which equipment could be subject to temperature
beyond the Maximum Allowable Working Temperature (MAWT), which was specified by
the mechanical designers of pressure vessels in accordance with the ASME Boiler and
Pressure Vessel Code, Section VIII.
The LOPA team contemplated that failure of temperature control in a distillation column
reboiler could subject equipment to temperatures as high as 500 F, when the design
limit is approximately 300 F. The LOPA identified concerns associated with loss of
vessel tensile strength and a significant release of flammable hydrocarbons to the
atmosphere. However, the scenario also involved no elevated pressure of equipment,
which would be well within the allowances of Maximum Allowable Working Pressure

(MAWP). Instead of implementing a SIL 3 shutdown on high temperature, Kenexis

recommended the end user consult with the mechanical designers of the equipment.
Operating a carbon steel pressure vessel above the MAWT is undesirable, and can result
in damage to the equipment over time. At worst, some flange leakage might be
expected in the long term. However, often there is no potential for acute degradation of
the mechanical performance to contain the process pressure, because the vessel is
operating well below its MAWP, and within the allowable working stress. It requires a
competent mechanical engineer to address this concern, and in this case, the existing
vessels were re-rated to limits that were within the bounds of the scenario the LOPA
team contemplated. This eliminated the need to install several SIL 3 loops, which would
have required significant field instrumentation upgrades as well as a SIL 3 capable logic
solver. The SIS was then designed for hazards that resulted in a maximum SIL of SIL 2,
and saved significant resources in terms of implementation.
The key learning is to ensure that any SIL 3 finding from a LOPA is subjected to proper
scrutiny before accepting that high target as the basis of design. Spending a bit more
time and effort in the risk analysis phase can pay big dividends in terms of simplicity of
the SIS, lower maintenance and testing requirements, and more effective use of scarce
resources to be applied to other, more critical safety issues.