Summary
The objective of this paper is to demonstrate, through a practical example,
how an end user should deal with functional safety while designing a
safety-instrumented function and implementing it in a safety-instrumented
system. The paper starts with explaining the problems that exist inherently in
safety systems. After understanding these problems, the paper takes the reader
from the verbal description of a safety function through the design of the
architecture, the process for the selection of safety components, and the role
of reliability analysis. After reading this paper, the end user understands the
practical process for implementing the design of safety-instrumented systems
without going into detail of the requirements of the standard.
Introduction
Every day, end users around the world are struggling with the design,
implementation, operation, maintenance, and repair of safety-instrumented
systems. The required functionality and safety integrity of safety-instrumented
systems is in practice determined through a process-hazard analysis. This task
is typically performed by the end users as they are the experts on their own
production processes and understand the hazards of their processes best. The
result of such a process-hazard analysis is among others a verbal description
of each required safety function needed to protect the process. These safety
functions are allocated to one or more safety systems, which can be of
different kinds of technology. Those safety systems that are based on
electronic or programmable electronic technology need as a minimum to comply
with the functional safety standards IEC 61508 and/or 61511.
The end user is typically not involved in the actual design of the safety
system. Normally this is outsourced to a system integrator. The system
integrator determines the design of the safety system architecture and selects
the safety components based on the specification of the end users. No matter
who designs the safety system according to the safety function requirements, in
the end it is the end user who is responsible for the safety integrity of the
safety system. This means that the end user needs assurance that the chosen
safety architecture and the selected safety components meet the requirements of
the applicable standards, and should be able to defend his or her decision to
any third party performing the functional safety assessment.
In reality, end users and system integrators are not experts in hardware and
software design of programmable electronic systems. They know how to run and
automate chemical or oil and gas plants, but most likely they are not experts
on how the operating system of a logic solver works, or whether the
communication ASIC of the transmitter is capable of fault-free safe
communication. Even if they are experts, the suppliers of the safety components
will not give them sufficient information about the internals of the devices to
assure them of the safety integrity of these devices. Yet they are responsible
for the overall design and thus need to assure themselves that functional
safety is achieved. But how can this be accomplished in practice?
The objective of this paper is to demonstrate, through a practical
example, how an end user and/or system integrator should deal with functional
safety while designing a safety-instrumented function and implementing it in a
safety-instrumented system. The paper starts with explaining the problems that
exist inherently in safety systems. After understanding these problems, the
paper takes the reader from the verbal description of a safety function through
the design of the architecture, the process for the selection of safety
components, and the role of reliability analysis. After reading this paper, the
end user understands the practical process for implementing the design of
safety-instrumented systems without going into detail of the requirements of
the standard.
Why Safety Systems Fail
The hardware of a safety-instrumented system can consist of sensors, logic
solvers, actuators, and peripheral devices. With a programmable logic solver
there is also application software that needs to be designed. An end user in
the process industry uses as basis for the design and selection of the safety
devices the IEC 61511 standard. This standard outlines requirements for the
hardware and software, and refers to the IEC 61508 standard if the requirements
of the IEC 61511 cannot be not met. This means that even if the IEC 61511
standard is used as a basis, some of the hardware and software needs to comply
with IEC 61508.
As with any piece of equipment, safety equipment can fail. One of the main
objectives of the IEC 61508 standard is to design a “safe” safety system. A
“safe” safety system means a system that is designed in a way that it can
either tolerate internal failures and still execute the safety function or, if
it cannot carry out the safety function, it at least can notify an operator
through an alarm. If we want to design a safe safety system, we should first
understand how safety systems can fail. According to IEC 61508, equipment can
fail because of three types of failures:
- Random hardware failures.
- Common-cause failures.
- Systematic failures.
© 2007. Society of Petroleum Engineers
View full textPDF
(
969 KB
)
History
- Original manuscript received:
6 September 2006
- Manuscript approved:
1 November 2006
- Version of record:
20 March 2007
View Cart
