Safety instrumented systems: Tips from the trenches: Part I

The two-part installment introduces safety instrumented systems (SIS) and

outlines specific tips on designing, developing, and verifying SIS applications.
Todays article focuses on the purpose and application of the SIS as well as
safety integrity layer (SIL) calculations. The second installment will finish up with
exploring tips for SIS hardwarde and the control system interface.
What is this SIS thing? Ive been asked that.
It makes your hair fall out. Ive answered that.
In all seriousness, a safety instrumented system (SIS) is commonly referred to as
a control system, but it is actually a critical shutdown system. It is composed of
sensing devices, logic solvers, and final elements. An SIS contains interlocks
known as safety instrumented functions (SIFs) that put the process in a safe
state in order to mitigate the risk of a hazardous situation. The sole function of
an SIS is to protect life and limb, not mechanical equipment.
The SIS is the last line of defense in automation. This is opposed to the basic
process control system (BPCS) that sits on the front lines. The BPCS performs
the basic regulatory control functions in the plant, and is the workhorse of
automation.
ANSI/ISA 84.00.01-2004 (IEC 61511 Mod) is the SIS standard for the process
industry. It is a performance-based (rather than prescriptive) standard meaning
that all components of the SIS have to meet certain performance criteria. And,
it is the burden of the SIS developer to determine how to meet these criteria.
Designing, developing, and verifying an SIS can be an onerous task. Here are
some tips based on real-world experience that may be helpful:
General
Nothing should be placed in an SIS unless it is required by a process hazard
analysis (PHA). Furthermore, if a PHA has not been performed on the process,
there is no justification for even having an SIS. This is the most important item in
the list. Read it again.

An SIS can be expensive and has a considerable lifecycle commitment. For

this reason, if the PHA
for a plant only has single-credit deficits in a few scenarios, installing an SIS
would not be the most cost effective option. Adding hard-wired interlocks as a
separate layer of protection (this could even involve programmable stand-alone
controller) may be the best method to take care of the PHA credit deficit.
A BPCS is used for control while an SIS is used for safety. Control functions
should not be placed in
the SIS. Likewise, critical safety functions should not be placed in the BPCS.
SIS logic should be simple and straight-forward. For instance, a high level on a
tank closes a block
valve and stops a pump. Period. The SIS is not the place for long sequences or
complex operations. Those belong in the BPCS.
When choosing an SIS, select a system that has been certified as SIL 3 (this
should cover any safety
function ever required by the process). Certain processors are SIL capable and
this should not be confused with SIL certified. SIL certifiedmeans that the
system has been vetted by a qualified third party for the specified SIL and is
good to go out of the box. SILcapable means the system is able to attain the
given SIL only if an extra set of safety guidelines are followed by the user. These
guidelines can be extensive and complicated. They also put an extra burden
and expense on the person designing, configuring and maintaining the SIS.
Even if a SIL-capable system is designed and installed following all of the
required safety guidelines, there is always the possibility that a modification
could be made in the future that would invalidate the systems SIL capability.
SIL and SIL Calculations
Each SIF is required to have a calculated safety integrity level (SIL) that
defines the amount of risk
reduction it can provide. A SIF is the only item that can truly carry a SIL rating.
Some devices are certified as SIL 2 or SIL 3, but that only means they have been
proven as acceptable for use in a SIL 2 or SIL 3 safety function (with possible
redundancy requirements). Using one of these instruments does not
automatically guarantee a SIL 2 or 3 interlock. A SIL calculation still has to be
performed incorporating all devices and factors in the SIF.
While a safety functions SIL is based primarily on the probability of failure on
demand (PFD)
determined from a calculation, there is also an accompanying SIL that is based
on the architectural requirements of the function. This requirement deals with
the redundancy of each device in the SIF and depends on the hardware fault

tolerance (HFT) of each instrument. A devices safety certificate will list the HFT
that is required for each SIL value that the device is certified for. An HFT of 0
means no redundancy is required, while an HFT of 1 means 1oo2 redundancy is
needed. SIL 1 does not require redundancy unless the safe failure fraction
(percentage of total failures that are safe vs. dangerous) of a smart instrument
is less than 60% (and this is rare). In this case, the instrument will have to be
redundant in order to even meet SIL 1. SIL 2 typically requires redundancy in
either the initiating or final devices while SIL 3 will require it for both. After
taking all of this into account, the final achieved SIL of the safety function will be
the lesser of the SIL from the PFD calculation and the SIL from the architectural
requirements.
The main component of the PFD calculation is the dangerous undetected
failure rate (DU) of each
device in the safety function. There are three other types of device failure rates
(safe detected, safe undetected and dangerous detected), but they are not
related to the PFD. DU can be found on the devices safety certificate or its
failure modes effects and diagnostic analysis (FMEDA) report. It is usually
expressed in units of failures in time (FIT) which is failures per billion hours.
SIL 4 interlocks are science fiction in the process industry (however, they are
seen in nuclear
reactors, airplanes and railways). If a process hazard requires a SIL 4 interlock,
it is time to go back to the drawing board. SIL 3 interlocks are difficult and
expensive and should be rare at best.
The test interval (how often a complete SIF validation test is performed) and
mission time (how often
a device is replaced or refurbished to as-new condition) both affect the SIL.
Lowering either one can potentially lower the PFD and raise the SIL. For this
reason, people may play with the test interval or mission time values in order to
force a SIF into a SIL value it normally would not be able to meet. Beware of
this. It is good practice to adopt a standard test interval (typically one year) for
all SIFs and a standard mission time (typically 10 or 15 years) for categories of
SIS devices. It is highly unlikely someone will remember that one particular SIF
that needs to be tested monthly, or that one instrument that needs to be
replaced every year.
Todays article just scratched the surface of SIS basics. Keep in mind the tips
presented, including the fact that the SIS should be used for safety and not basic
control its the last line of defense for the automation system and intended as
a critical shutdown system. There are several nuances to be aware of when
designing, developing and verifying a safety instrumented system. We have
much more to cover in the next article, including SIS hardware and the interface
to the main control system.

The two-part installment introduces safety instrumented systems (SIS) and

outlines specific tips on designing, developing, and verifying SIS applications.
Part one of this article outlined the purpose and application of the safety
instrumentedsystem (SIS) as well as specific nuances with the safety integrity
layer (SIL) calculations and general tips to consider when designing, developing
and verifying a safety instrumented system. Keep in mind that the SIS is used
for safety, not basic control. While the basic process control system (BPCS) is the
workhorse of automation, the SIS is the last line of defense for the process and
intended as a critical shutdown system. This second and final installment of the
article wraps up by exploring tips for SIS hardware and the control system
interface.
SIS I/O If possible, use transmitters instead of switches in the SIS.
Transmitters offer better reliability,
diagnostics and easier maintenance and testing. If multiple transmitters are
used in a safety function, their values can also be compared against one another
providing valuable diagnostic information. These diagnostics can also lower the
probability of failure on demand (PFD) in the safety integrity layer (SIL)
calculation.
If SIS I/O conditioning components (isolators, splitters, barriers, relays, etc.)
are used, the PFD of
each component has to be incorporated into the SIL calculation for the safety
function that uses it.
Only I/O that is used in an SIS safety function should be wired to the SIS. If it
is not used in a safety
function, it has no business being there. For instance, if the SIS closes a block
valve, only the solenoid should be wired to the SIS. The limit switches should be
wired to the BPCS and can be used to indicate position status in the
accompanying BPCS valve module. The limit switches should only be wired to
the SIS if they are used as initiating devices in another safety function.
An analog control valve should never be used as the sole shut-off device in a
safety function. If there
is not a discrete quarter-turn block valve downstream of the control valve, then
one should be installed and wired to the SIS. Then, a solenoid should be
installed on the air line to the analog control valve positioner and wired to the
SIS as well. The SIS safety function will then close the block valve and the
control valve at the same time.

As a benchmark for estimates, approximately 10% of the total I/O in a new

system will belong to the
SIS. However, the true number of SIS I/O cannot be determined until a full
process hazard analysis (PHA) has been performed on the entire process.
BPCS/SIS Interface
All SIS I/O should be repeated to the BPCS (via Modbus or some other
communication link) and
integrated into standard BPCS controls so everything is available to the operator
as a cohesive system. However, SIS-controlled devices should be indicated as
such on the BPCS graphics.
All SIS interlocks should also be repeated to the BPCS and shown in the
interlock faceplate for the
appropriate SIS-controlled device. They should also be identified as SIS
interlocks.
An SIS initiating device that is repeated to the BPCS (even if it is hardwired
between the two systems)
cannot be used for a PHA-credited BPCS interlock. This is because the PHA is
already claiming one or more credits for an SIS interlock using this instrument,
and the single instrument cannot provide credits for two different layers of
protection.
If an SIS analog input is also used for control in the BPCS and the BPCS and SIS
are not an
integrated system (i.e. the two systems communicate via Modbus or a similar
interface), then the signal should be wired to BPCS I/O as well. This can be done
by wiring the instrument to the SIS and then wiring an SIS analog output to a
BPCS analog input and passing the signal through. If this is not possible (some
SIS manufacturers do not provide analog output I/O), use a SIL-rated splitter and
split the incoming 4-20ma signal to both the SIS and BPCS. However, if this is
done, the PFD of the splitter will have to be incorporated into the SIL calculation
of the safety function.
For block valves that are controlled by the operator and the SIS, there are two
approaches: (1) Have

two solenoids in series (one for the BPCS and another for the SIS) for each valve.
The SIS solenoid will be energized if there are no SIS interlocks, and the BPCS
solenoid will be controlled by the operator. (2) Have a single solenoid that is
wired to the SIS. When the operator tries to open the valve, the BPCS will send
a request to the SIS (either via a communication bus or hardwired I/O). If the
quality of the BPCS request is good, the SIS will energize the solenoid if all of the
SIS interlocks for the valve are clear.
Individual initiating devices in a safety function can be bypassed in the SIS,
and the bypass method
used must be described in the safety requirement specification (SRS) of each
safety instrumented function (SIF). Some plants allow an SIS bypass to be
performed from an operator graphic if a password is entered or a locked keyswitch (wired to SIS I/O) is unlocked. Other plants will only allow bypasses to be
performed by an engineer from within the SIS configuration. I prefer the latter
method. If an operator needs to bypass an SIS safety function frequently, it
needs to be redesigned.
After a safety function trips and clears, it can either automatically reset itself
or require a manual
operator reset (like bypasses, the reset method must be defined in the SRS).
The two most common methods of manual resets are: (1) Reset each final
device affected by the SIF individually. If a SIF trips multiple devices, the
operator has to call up each faceplate and press a reset button before the plant
can be brought back online. (2) Reset the SIF itself which will release all final
devices interlocked by it (unless they are affected by another active SIF). I
prefer the latter method, and it has been my experience that the majority of
plants do as well.
The SIS should be completely separate and independent from the BPCS. This
means hardware and
software, cabinets, initiating and final devices, wiring and engineering access.
While the BPCS can read information from the SIS to display on operator
graphics, the BPCS must not be able to adversely affect the operation of the SIS.
Any data (setpoints, limits, etc.) passed from the BPCS to the SIS should initially
be placed in a holding area in the SIS. Then, the data should only be used by
the SIS if the BPCS / SIS communications link is healthy, the BPCS process
writing the data is running fault-free, and the BPCS data passes both quality and
limit checks inside the SIS.
In this series, we have presented some basic tips for designing, developing and
verifying a safety instrumented system and have pointed out some crucial tips
learned from real-world experience to ensure your SIS does what it is supposed

to do protect life and limb as that last line of defense separate from the control
system.
Operator Action within a Safety Instrumented Function
Abstract

In many process safety applications, operator action by itself or in combination

with other layers of protection provides the necessary risk reduction for
functional safety. The operator can not provide this safety function in isolation.
There are a number of physical systems and administrative systems that are
required to be available for the operator to adequately perform as part of the
safety function implementation. The operator must have the necessary process
information presented to him/her and a means to take the needed action to
correct the undesirable or unwanted process condition. As such, the operator
must receive an alarm or monitor an indication to determine that a process
parameter has or, in a good design, is nearing the point of exceeding a safety
limit. The operator must then act to affect the process system in a manner to
bring it to a safe state or prevent it from continuing its movement toward its
safety limit.
This paper presents an overview of the factors that should be considered when
crediting operator action for performing a safety function or being a part of the
process of enabling a safety function. Criteria for evaluating operator action,
such as required time response and operator training among others, are
discussed. The paper will address these and other factors that should be
considered when determining the reliability of the operator to respond and
perform his/her part of the safety function. The entire safety function includes
the operator and the reliability of the instrumented system that provides the
alarm or indication, the final control element, and support systems. The
integration of the operator performance with the hardware safety availability,
including the effects of the supporting systems is discussed. The analysis of
these factors will provide the justification for the amount of risk reduction or
safety integrity level that can be credited for the Safety Instrumented Function
(SIF), including operator action.
Introduction
Safety for a process industry sector facility can be achieved by a number of
means. These include (1) the design of a process or facility to eliminate the
safety risk, (2) administrative controls (i.e. inventory control, safety procedures),
(3) the basic process control system, (4) the application of safety prevention and
mitigation systems (i.e. mechanical, safety instrumented system), (5) facility

emergency response systems, and (6) community emergency response systems.

These safety features are graphically depicted in Figure 1.

Figure 1 Typical Process Facility Safety Features/ Protection Layers

These safety features can be used by themselves or in combination with other

safety features to provide the necessary risk reduction to achieve the required
margin of safety. IEC 61511 (draft) identifies these safety features as protection
layers. ISA S84.01 recognizes the application of non-Safety Instrumented
System (SIS) protection layers that would include safety related operator action,
but the methods for accomplishing this is presently identified as outside the
scope of the standard.

The operator of the facility or process is directly involved in one or more aspects
of protection layers 2 through 6 of Figure 1. This paper will focus on the credit, in
terms of risk reduction, that can be taken for operator action to place a process
or facility in its safe state in response to an alarmed or monitored parameter.
Operator Action When Used for Safety Risk Reduction
Risk for a facility is a function of the frequency of a hazardous event, and the
severity or consequence of that event. Each facility will establish a unique set of
risk criteria depending on the facility function (i.e. processing or storage),
location, design, quantity and types of hazardous materials, and the facilitys
tolerance for risk.
The risk that a process or operating facility presents can be reduced to a level
that is acceptable, within the risk criteria established for the facility, by the
application of protection layers. Figure 1 above illustrates a range of features,
sometimes called protection layers, which can be used to reduce the risk to an
acceptable level. The protection layers consist of emergency response systems,
design features, administrative controls and active protection systems. Three of
the active protection systems are often implemented by manual operator action
in response to process parameters that exceed safety limits. The first of these is
when the operator action is part of the Basic Process Control System (BPCS). The
second is when the operator action is an integral part of a Safety Instrumented
System (SIS) that is designed to prevent or mitigate an event. The third is where
the operator activates a facility emergency response system. In either the first
or second case an operator may respond to an alarm/indication in the control
room and initiate an action within the control room, or the operator may be
required to go into the facility to physically place a component in a safe state.
The main distinction in these is that the BPCS, not being a safety system as is
the SIS, does not have the same design, maintenance and operational criteria
imposed upon it as would be imposed on a safety system. As a result, there are
limits to the amount of risk reduction that can be credited for operator action as
a result of BPCS alarms/indication. Credited, as used in this application, is
defined as the numeric value of risk reduction or probability of failure on
demand that can be assigned to the protection layer. The value of risk reduction
determines the Safety Integrity Level (SIL) that can be achieved for the design of
the Safety Instrumented Function (SIF).
There are several industry standards that address the design of safety
instrumented systems for the process industry.
ISA S84.01, Application of Safety Instrumented Systems for the Process
Industries

IEC 61511 (draft), Functional Safety: Safety Instrumented Systems for the
Process Industry Sector
ISA S84.01 covers the design of Safety Instrumented Systems that are
automatic. Operator action, where it is the sole means required to return a
process to a safe state, is outside the scope of the ISA standard (Ref. ISA S84.01,
Section 1.2.14). Thus the ISA standard, at this time, does not provide any
guidance for the design and verification of operator action to accomplish a SIF.
IEC 61511 (draft) is broader in scope in its definition of a protection layer and
SIS. IEC 61511 Part 1, Section 3.2.57, definition of Protection Layer, and 3.2.70,
definition of Safety Instrumented System, discuss operator actions. The IEC
standard recognizes that safety responses may be automated or initiated by
human actions. Both of the standards provide a fairly consistent approach to the
design of automatic Safety Instrumented Systems. The differences that exist
between IEC 61511 (draft) and ISA S84.01 concerning the design and
verification of operator action within a SIS are expected to be addressed in the
process of issuing IEC 61511 and subsequent ISA S84.01 reaffirmation.
To understand the differences in how to design and evaluate an automatic SIS
versus an operator actuated SIS, it is beneficial to look at the architectures of
the two SIS types. Figure 2 provides the basic architecture of an automatic SIS. It
is composed of sensor(s), logic solver(s) and final element(s). It is assumed for
this figure that the system is de-energize to actuate, so there are no supporting
systems required for the system to complete its safety function. If the SIS was
an energize to actuate function, then support systems (e.g. electrical power,
hydraulic, instrument air) would also be required to provide the motive force to
complete the safety instrumented function.

Figure 2 Typical Example of Automatic Actuated SIS Architecture

Figure 3 provides the basic architecture for manual operator action within a SIF.
The SIS is composed of sensor(s), logic solver(s), alarm presentation/operator
action(s) and final element(s). The basic architecture is different than the
automatic SIS in that Alarm Presentation and Operator Action are an additional
block in the architecture. Support Systems will always be required to complete
the safety instrumented function that incorporates manual operator action. An
operator actuated SIS does not fail-safe on total loss of power or motive force.

An alarm or indication must be presented to the operator in order for the

operator to react and take action. The most common support system required
for an operator to satisfactorily implement this safety function is the supply of
electrical power (e.g. normal electrical power, battery power, UPS) to illuminate
an alarm light or actuate an audible alarm, but there may be others.

Figure 3 Typical Example of Operator Actuated SIS Architecture

Evaluation of Credited Operator Action
Operator Action Within a BPCS
The normal control and operation of a facility is accomplished through the BPCS.
Although limited credit can be given to the BPCS for safety related risk
reduction, insufficient care in design can and usually does result in having a
negative impact on safety. Operator actions, which are implemented through the
BPCS, in response to process conditions are not part of a safety system, but it is
generally accepted that a degree of risk reduction can be credited for these
actions. IEC 61511 (draft), Part 1, Section 9.4.2 states that a risk reduction factor
for a BPCS used as a protection layer shall be less than 10. A risk reduction
factor of less than 10 is equivalent to an average Probability of Failure on
Demand (PFD) of greater than 10-1. It is not expected that a formal verification
or calculation of the PFD of credited protection layer operator action within the
BPCS will be done, as would be required for a SIS. There are no specific industry
standards or design requirements for BPCS operator action credited as a
protection layer. The design of a BPCS operator interface should incorporate
Human Factors Engineering (HFE) principals to ensure that the operator will
respond adequately to an alarm or process indication. In addition, it is important

that operator response to normal plant operations and facility upsets does not
unduly challenge the safety of the facility by putting the process into an
undesirable mode or condition.
Operator Action Within a SIF
Operator action as part of a Safety Instrumented Function can be credited with a
level of risk reduction greater than 10. Once the decision has been made to
credit an operator actuated protection layer with a risk reduction greater than
10, then the system from the sensor to the final element (Figure 3) should be
designed and evaluated as a SIS per the requirements of IEC 61511 or ISA
S84.01.
The key to designing and evaluating an Operator Action within a SIS (OASIS) is
to recognize the additional factors that affect the probability of failure on
demand. The two main factors that affect the Safety Integrity Level (SIL) of an
OASIS in addition to the factors considered for an automatic SIS are human
errors and support system reliability.
Human error essentially is the failure of the operator to respond correctly within
the required time to the alarm/process indication and to take the actions
necessary to place the process/facility in a safe state. The human response can
be broken down into four functions: (1) Recognize the unsafe condition, (2)
Analyze the condition properly, (3) Perform the required safety action, and (4)
Follow the process/facility response to completion of the safety function (i.e. SIS
action implemented and process returning to safe operating values). There are a
number of methods for evaluating the probability of human error. Two of the
more well known methods are the Technique for Human Error Rate Prediction
(THERP) (Reference NUREG/CR-1278) and the Accident Sequence Evaluation
Program Human Reliability Analysis Procedure (Reference NUREG/CR-4772).
Error rates are usually established on a per demand basis. The nominal human
error rates can be reduced or increased based on operator related
environmental factors (quality of displays, control layout and clarity, control area
environment, procedures, access), personnel factors (training, experience), and
stress factors (personal, shift schedules, response time pressure, severity or
magnitude of safety condition). The best source for determining the human error
rate would be company/facility specific historical data, but in most organizations
this is not available. Therefore, one must use other sources and adjust the
human error rate for safety related operator responses to their application and
circumstances accordingly.

The second deals with the reliability of support systems that are required for the
OASIS to meet its SIF, which includes a specified Safety Integrity Level. Most SIS
systems are designed as de-energize to actuate. As a result, the calculation of
PFD for these SIS systems does not generally have to take into consideration
any system outside of the SIS. An OASIS inherently requires support systems to
complete the SIF. Display/alarms require power to actuate the light and horn for
operator response. Therefore, the reliability of the electrical power system
directly affects the PFD of the OASIS
Examples of SIS and OASIS Evaluations Using Fault Tree Methodology

Figure 4 Automatic SIS Action to Close Valve on High Pressure

Figure 6 SIS Operator Action to Close Valve on High Pressure

Figure 7 Fault Tree of SIS Operator Action to Close Valve on High Pressure
Shown in Figure 6
Conclusion
Operators are an integral part of the control and safety of virtually all facilities.
When operator action is credited as a protection layer within a Safety
Instrumented Function, the verification of the amount of risk reduction achieved
should be handled in the same manner as the verification of an automatic
Safety Instrumented System as defined by ISA S84.01 or IEC 61511. The
verification includes the consideration of human error rates, support system
reliability, administrative controls such as operator training, and the
establishment and control of alarm response procedures. The systematic
evaluation/verification of an operators safety related actions will greatly aid in
assigning the proper credit for the risk reduction provided by this action, and
identify the salient factors that affect the probability of failure on demand of the
operator action within the safety instrumented function.