Академический Документы
Профессиональный Документы
Культура Документы
Whereas the Parliament of India has set out to provide a practical regime of right to
information for citizens to secure access to information under the control of public authorities,
in order to promote transparency and accountability in the working of every public authority,
and whereas the attached publication of the Bureau of Indian Standards is of particular interest
to the public, particularly disadvantaged communities and those engaged in the pursuit of
education and knowledge, the attached public safety standard is made available to promote the
timely dissemination of this information in an accurate manner to the public.
1 +, 1 +
01 ' 5
Jawaharlal Nehru
! $ ' +-
Satyanarayan Gangaram Pitroda
! > 0 B
BharthariNtiatakam
lS/lEC
ml
immb,-,+
61511-1:2003
m&md??+i-eRR&hid@
Indian Standard
u,
PART
FRAMEWORK,
DEFINITIONS,
SYSTEM,
HARDWARE
AND
$OFTWARE
REQUIREMENTS
ICS 25.040.01:13.110
.4
BUREAU
MANAK
Jmmy
2009
OF
INDIAN
STANDARDS
E3HAVAN, 9 BAHADUR
SHAH
NEW DELHI 110002
ZAFAR
MARG
Price Group
16
lS/lEC
61511-1:2003
CONTENTS
lNTRODUCTION
... ............. .... .......... .................................. .. ..... ... .. ........... ........... ...... ........... vi
Scope ...... ... ..... ....... .... ................... .. ......... .... ..................... ... ..... .......... .............. .............
Normative
Abbreviations
references
and definitions
3.1
Abbreviations
3.2
Definitions
.. ..... ............... .......... ... ................... .... .... ........ ............................. ...... 7
Conformance
to this International
Management
of functional
5.1
Objective
5,2
Requirements
Safety
Objective
6.2
Requirements
10
11
.. ... ... ............ ................................... .... ..... ..... ...... .............. ...............22
........ ......... .................... ....... ... .... ........................ .......... ....27
... ................. ............ .. ................ ... ..... .... .. ... ................... ..................27
hazard
8.1
Objectives
8.2
Requirements
Allocation
of safety
functions
to protection
9,1
Objective
9.2
Requirements
9.3
Additional
9.4
Requirements
9.5
Requirements
for preventing
common cause, common mode and dependent
failures ..... ........ ..... ............. ...................................... .. .... ............................ ..........34
S1S safety
........ ..... ................ ............................ ... ...... .... ..... ........ .............. ..............3l
of the allocation
requirements
Objective
10.2
General
10,3
S1S safety
process
for safety
requirements
10.1
S1S design
.4
specification
integrity
control
as a protection
layer ...............33
$!
.......... ... ............ ............................ ............ ... .... ............... ............ ............35
requirements
requirements
and engineering
.......... ............ ... ...... ............ ... ... ..... ....... ...........................3b
..... .... ..................................... ... ... ............................ ...........36
11.1
Objective
....... ..... ............... ... ............. ...................... ... ... .... ................................... 36
11.2
General
11.3
Requirements
for system
11.4
Requirements
forhardware
fault tolerance
11.5
Requirements
for selection
of components
11.6
Field devices
11.7
interfaces
11.8
Maintenance
11.9
SIF probability
requirements
......... ................ ........... ......... ... .... ....... ............. ..... .............. 36
behaviour
on detection
. . ..
...... . ........
.... 40
.... ...... ................ .. ...... ............................. .... ....... ...... .............'' ............
ortestlng
design
requirements
44
,!,
*
*
.. .......... ................ ........... .. ......................... ... ... ........... ...... ....... ...............27
Objective
Process
requirements
6.1
7.1
8
Standard
.......... ... ............. ............. ........................... .... ..... ....... .............. ...............22
life-cycle
Verification
....... ......... .......... ............ .. .................... ...... ... ....... ...... ............. .... .......... 8
@
lS/lEC
12
61511-1:2003
Requirements
15
16
17
18
including
Application
software
safety
life-cycle
12.2
Application
software
safety
requirements
123
Application
software
safety
validation
12.4
Application
software
design
12.5
Integration
of the application
12,6
12.7
Application
software
acceptance
13,1
objectives
13.2
Recommendations
Objectives
14.2
Requirements
....47
.. ........................................54
procedures
..... ........................ 61
....................... .. ...........................62
validation
Objective
15.2
Requirements
and maintenance
16.1
Objectives
16.2
Requirements
16.3
Proof testing
............. ......... ................ ....... .. ... ... .... .................................. .. ... ... ... ..... 68
S1S modificatio
17.1
Objective
17.2
Requirements
SISdecommissioning
. ...... ........ ............ ..... ...... ........ ........ ......... .......... ................. ...........72
.... ...... ......... .. ... ............... .... ...... ...... ... .... ....................... ...................... 72
Requirements
Information
software
........ .. ............................. ............ .... ..... .......... .. ... ................ .... ............. 65
15.1
18.2
verification
for utility
specification
planning
software
and commissioning
14.1
S1S operation
requirements
criteria
S1S installation
S1S safety
selection
and development
modification
testing
18. 1 Objectives
19
software,
12.1
Factory
14
for application
and documentation
19.1
Objectives
19.2
Requirements
requirements
Annex
A (informative)
Differences
Figure
1 .Overall
Figure
2 - Relationship
between
IEC 61511
Figure
3-
Relationship
between
IEC 61511
Figure
4 Relationship
between
safety
Figure
5-
between
system,
Figure
6 Programmable
Figure
7-
Example
Figure
8-
S1S safety
Figure
9 -Typical
framework
Relationship
of this standard
electronic
SISarchitecture
life-cycle
risk reduction
instrumented
hardware,
system
(PES):
functions
and software
structure
........... ..
and terminology
phases
and functional
methods
found
safety
in process
assessment
plants
............................ ........... 34
Figure 10 Application
software safety life cycle and its relationship
to the S1S safety
life cycle .... ......................... ........................... .............. ..... ... .................................... .............48
ISIIEC
61511-4:2003
I
Figure
11 Application
software
Figure
12-
Software
Figure
13-
Relationship
safety
development
between
used in lEC6151
1 -Abbreviations
Table
2.
SISsafety
Table
3-
Safety
integrity
levels:
probability
of failure
Table
4-
Safety
integrity
levels:
frequency
of dangerous
Table
5-
Minimum
hardware
and software
Table
architectures
fault tolerance
on demand
failures
of PE logic solvers
Table 6 Minimum hardware fault tolerance of sensors and final elements and non-PE
logic solvers ........ ........ ... .. ................ ............... ..... .......................... .... ..... ........ .. ...........40
Table
7-
Application
software
safety
life cycle:
overview
*r
,..
Ill
IllIllII1...1. .1.,
,..._JJ
lS/lEC
. . -.
. . ...--.
61511-1:2003
NATIONAL
ETD 18
FOREWORD
This Indian Standard (Part 1) which is identical with IEC 61511-1 :2003 Functional safety Safety
instrumented systems for the process industry sector Part 1: Framework, definitions, system,
hardware and software requirements issued by the International Electrotechnical
Commission (lEC)
was adopted by the Bureau of Indian Standards on the recommendation
of the Industrial Process
and approval of the Electrotechnical
Division
Measurement
and Control Sectional Committee
Council.
The text of IEC Standard has been approved as suitable for publication as an Indian Standard without
deviations.
Certain conventions
are, however, not identical to those used in Indian Standards.
Attention is particularly drawn to the following:
a)
b)
Comma (,) has been used as a decimal marker, while in Indian Standards,
practice is to use a point (.) as the decimal marker.
the current
/nterrratior7a/ Standard
Corresponding
Degree of
Equivalence
/ndian Standard
Part 2: Requirements
for electrical/
electronic/programmable
electronic
safety-related systems
LS/lEC 61508-2:2000
Functional safety
of electrical/e lectronic/program
mable
electronic safety-related systems: Part 2
Requirements
for electrical/
electronic/
programmable
electronic
safety-related
systems
IEC 61511-2:2003
Functional safety
Safety instrumented
systems for the
process
industry
sector Part 2:
Guidelines
in the application
of IEC
61511-1
lS/lEC 61511-2:2003
Functional safety
Safety instrumented systems for the
process
industry
Part
2
secto~
Guidelines
in the application
of IEC
61511-1
Standard
safety
Identical
do
Part 3
do
Title
IEC 60654-1:1993
Industrial-process
measurement
and control
conditions Part 1: Climatic conditions
equipment
Operating
IEC 60654-3:1998
Industrial-process
measurement
conditions Part 3: Mechanical
equipment
Operating
iv
and control
influences
lS/lEC
/nfernat;ona/
IEC 61326
Standard
61511-1:2003
Title
Electrical equipment for measurement
requirements
use EMC
For the purpose of deciding whether a particular requirement of this standard is complied with, the
final value, observed or calculated, expressing the result of a test or analysis, shall be rounded off in
accordance with IS 2 : 1960 Rules for rounding off numerical values (revised). The number of
significant places retained in the rounded off value should be same as that of the specified value in
this standard.
INTRODUCTION
Safety instrumented
systems have been used for many years to perform safety instrumented
functions
in the process
industries.
If instrumentation
is to be effectively
used for safety
instrumented
functions,
it is essential
that this instrumentation
achieves
certain minimum
standards
and performance
levels.
This international
standard
addresses
the application
of safety instrumented
systems for the
Process Industries.
It also requires a process hazard and risk assessment
to be carried out to
enable the specification
for safety instrumented
systems to be derived. Other safety systems
are only considered
so that their contribution
can be taken into account when considering
the
performance
requirements
for the safety instrumented
systems.
The safety instrumented
system
includes
all components
and subsystems
necessary
to carry
out the safety
instrumented
function from sensor(s) to final element(s).
This international
standard
has two concepts
Iifecycle and safety integrity levels.
which
are fundamental
to its application;
safety
This standard
addresses
safety
instrumented
systems
which are based on the use of
electrical/electron
ic/programmable
electronic
technology.
Where other technologies
are used
for logic solvers, the basic principles
of this standard should be applied. This standard also
addresses
the safety instrumented
system sensors
and final elements
regardless
of the
technology
used. This international
Standard is process industry specific within the framework
of IEC 61508 (see Annex A).
This International
Standard
sets out an approach
for safety life-cycle
activities
to achieve
these minimum
standards.
This approach
has been adopted
in order that a rational and
consistent
technical policy is used.
!n most situations,
safety is best achieved by an inherently
this may be combined
with a protective
system or systems
r{sk. Protective
systems can rely on different technologies
pn~umatic,
electrical,
electronic,
programmable
electronic)
standard
requires that
requirements;
a hazard
and
risk
assessment
This International
Standard
addresses
operation
enables existing
this standard.
of the safety
is carried
which
on safety
requirements
is applicable
instrumented
specific
process
out to identify
to the safety
management,
systems
industry
the
overall
instrumented
to all instrumented
all safety
life-cycle
phases
from initial
and maintenance
through to decommissioning;
or new country
methods
which
design,
safety
system(s)
of achieving
may be applicable
industry
implementation,
to be harmonized
with
This International
Standard is intended to lead to a high Ievelof
consistency
(for example, of
underlying
principles,
terminology,
information)
within the process
industries.
This should
have both safety and economic benefits.
In jurisdictions
where the governing
authorities
(for example, national, federal, state,
county, city) have established
process safety design, process safety management,
requir-ements,
these take precedence
over the requi~ements
defined in this standard.
vi
province,
or other
,.,
fWEC
I1
61511-1:2003
Definitions and
abbreviations
Clause 3
PART 1
Clauses 9 and 10
Management of
functional safety
Clause 5
J%E?PTL
I
I
PART 7
f
Operation and maintenance,
mocfificatirm and retrofit,
decommissioning
or disposal of
safety instrumented systems
Clauses ?6, f 7, and 18
w
w
information
reauirementa
C/ause 19
[,
I
Guidance for the
determination of the
required safety
integrity levels
Figure
1-
Overall
framework
vii
of this standard
lS/lEC 61511-1:2003
Indian Standard
FUNCTIONAL SAFETY SAFETY INSTRUMENTED
SYSTEMS FOR THE PROCESS INDUSTRY SECTOR
PART
FRAMEWORK,
DEFINITIONS,
SYSTEM,
HARDWARE
AND SOFIWARE
REQUIREMENTS
Scope
This International
Standard
gives requirements
for the specification,
design,
installation,
operation
and maintenance
of a safety instrumented
system, so that it can be confidently
entrusted
to place and/or maintain
the process
in a safe state. This standard
has been
developed
as a process sector implementation
of IEC 61508.
In particular,
this standard
a)
specifies
the requirements
for achieving
functional
safety but does not specify who is
responsible
for implementing
the requirements
(for example,
designers,
suppliers,
owner/operating
company,
contractor);
this responsibility
will be assigned
to different
parties according to safety planning and national regulations;
b)
applies
when equipment
that meets the requirements
of IEC 61508,
or of 11.5 of
IEC 61511-1,
is integrated
into an overall system that is to be used for a process sector
application
but does not apply to manufacturers
wishing to claim that devices are suitable
for use in safety instrumented
systems
for the process sector (see IEC 61508-2
and
IEC 61508-3);
c)
defines
d)
e)
the relationship
between
IEC 61511
(Figures
2 and 3);
f)
outlines
the
(Figure 4);
relationship
9)
h)
specifies
software,
i)
specifies
requirements
instrumented
systems
specified:
some
between
applications,
safety
example, off-shore),
(for
instrumented
functions
and
other
of the functional
requirements
and safety integrity
function(s)
taking into account the risk reduction
requirements
for system
and system integration;
architecture
for application
(clause
12). In
and
software
particular,
hardware
oil
configuration,
functions
requirements
achieved
by
application
for users
and integrators
of safety
requirements
for the following
are
safety life-cycle
phases and activities
that are to be applied during the design and
development
of the application
software (the software safety life-cycle
model). These
requirements
include the application
of measures and techniques,
which are intended
to avoid faults in the software and to control failures which may occur;
information
relating to the software
carrying out the SIS integration;
safety
validation
to be passed
to the organization
EMEG
61511 -I :2003
preparation
of information
and procedures
concerning
the operation
and maintenance
of the SiS;
procedures
and specifications
to safety software;
software
needed
carrying
out modifications
j)
applies
when functional
safety
is achieved
using one or more safety
instrumented
functions
for the protection
of personnel,
protection
of the general public or protection
of
the environment;
k)
may be applied
1)
defines
requirements
overall arrangements
in non-safety
applications
such as asset
protection;
for implementing
safety instrumented
for achieving functional
safeiy;
functions
as a part
of the
n)
See Figure
9 for an overview
of risk reduction
methods.
o)
establishes
numerical
of dangerous
failures
p)
specifies
minimum
q)
specifies
techniques/measures
r)
cleflnes a maximum
instrumented
function
s)
defines
t)
provides a framework
for establishing
safety integrity levels but does not specify
integrity
levels required for specific applications
(which should be established
knowledge
of the particular application);
u)
specifies requirements
element(s);
v)
defines
that is needed
w)
requires
factors;
a minimum
requirements
the
for hardware
required
of failure
levels;
on demand
for achieving
the specified
design
of a safety
requirements
during
instrumented
the safety
instrumented
integrity
levels;
be achieved
this standard
system
for
a safety
from sensor
to final
life cycle;
function
on the individual
and frequency
fault tolerance;
level of performance
(S!L 4) which can
implemented
according to this standard;
level of performance
the information
that
takes
operator
into
account
or maintenance
human
person.
....-...
-.
~
ISIIEC
Yf
Y
\
SAFETY
INSTRUMENTED
SYSTEM
STANDARDS
(
\\
\
61511-1:2003
i.
~.+ Y.
Manufacturers and
suppliers of
devices
Safety
instrumented
systems designers,
integrators and
users
IEC 61508
IEC 61511
Figure
2-
Relationship
between
IEC 61511
lS/!EC
61511-1:2003
-\
!2
~
in
E
ii
of
..
.........
;.., . ...........
lS/lEC
61511-1:2003
i,
KUIEC 6151$-1:2003
output
Logic
Input
fFunction)
(Function)
(Function)
1
Software
r ~
Safety instrumented
Software reqwrernents
L..
Figure 5-
Relationship
Normative
references
systems
(clause 12)
...
...
The following
referenced dorxments
are indispensable for the application of this document.
For dated references, only the edition cited app!ies. For undated references, the latest edition
of the referenced docwmenf (including any amendments) applies.
IEC fi0654-1: 1993, /ndustrial-pmc&%s
conditions Part f: C/irnatic conditions
measurement
equipment
for
measurefnefff,
and
control
equipmwi
@crating
and
control
equipment
Operating
control
and
laboratory
use
EMC
IEC 61508,
sys~~[~s re/ated
IEC 61508-3,
Fuoetional
safety of @/ectrical/electronic/programmable
systems Part 5: Software requirements
6
e~ectronic
safety-related
lS/lEC 61511-1:2003
systems
IEC 61511-2: Functional
safety - Safety instrumented
Part 2: Guidelines
in the application
of IEC 61511-11
3
Abbreviations
3.1
and
industry
sector
definitions
Abbreviations
Abbreviations
used throughout
Table
IEC 61511
1-
are given
Abbreviations
in Table
1.
Abbreviation
~----1 Alterriatlng
Acl@c
current/ciirect
ALARP
As low as reasonably
ANSI
American
BPCS
Basic process
DC
Diagnostic
National
current
practicable
Standaras
control
i.
lnstit~te
system
coverage
E/EIPE
Electrical/electro
E/E/PES
Electrical/electronic/programmable
nic/programmable
electronic
EMC
Electro-rmagnetic
FAT
Factory
FPL
Fixed program
FTA
FVL
Full variability
H FT
Hardware
HMI
Human
machine
H&RA
Hazard
H RA
Human
reliability
H/W
Hardware
IEC
International
Electrotechnical
Commission
IEV
International
Electrotechnical
Vocabulary
electronic
system
compatibility
acceptance
testing
language
ianguage
fault tolerance
interface
analysis
4
ISA
Instrumentation,
IGO
International
Systems
LVL
Limited
MOON
NP
Non-programmable
PE
Programmable
electronics
PES
Programmable
electronic
PFD
Probability
PFD.vq
Average
PLC
Programmable
SAT
Site acceptance
SFF
Safe failure
SIF
Safety
instrumented
SIL
Safety
integrity
Sls
Safety
instrumented
SRS
Safety
requirement
Slw
Software
Organization
variability
and Automation
Society
for Standardization
language
of failure
probability
0$
system
on demand
of failure
on demand
Ioglc controller
test
fraction
function
level
system
specification
1 To be oublished.
lS/IEC 61511-1:2003
3.2
Definitions
3.2.1
architecture
arrangement
of hardware
(1) arrangement
of safety
and/or
software
instrumented
elements
system
apply.
in a system,
for example,
(S1S) subsystems;
\
(2) internal
structure
(3) arrangement
NOTE
This term
of an S1S subsystem;
of software
differs
3.2.2
asset protection
function allocated
programs
in IEC 61508-4
to reflect
differences
in the process
sector
terminology,
*
i*
to system
design
of preventing
loss to assets
3.2.3
basic process
control
system (BPCS)
system which responds
to input signals from the process,
its associated
equipment,
other
programmable
systems and/or an operqtor and generates
output signals causing the process
and its associated
equipment
to operate in the desired manner but which does not perform
any safety instrumented
functions with a claimed SIL > 1
NOTE
3.2.4
channel
element
See Clause
A.2,
,
or
group
of elements
final
within
that independently
a channel
could
a function
perform(s)
include
input/output
(1/0)
elements.
configuration
a complete
is one with
system
two channels
or a portion
that independently
of a system
(for example,
perform
;:.
sensors
or
3.2.5
coding
see programming
3.2.6
3.2.6.1
common
cause failure
failure, which is the result of one or more events, causing failures
channels in a multiple channel system, leading to system failure
3.2.6.2
common
mode failure
failure of two or more channels
3.2.7
component
one of the parts of a system,
subsystem,
or device
of two or more
performing
a specific
separate
result
function
3.2.8
configuration
see architecture
/
;/
.>
lS/lEC
3.2.9
configuration
management
discipline
of identifying
the components
purposes
of controlling
changes
to
traceability
throughout
the life cycle
3.2.10
control
system
system
which responds
generates
output signals
NOTE
The control system
a combination
of the two.
to input signals
from the process
and/or
causing the process to operate in the desired
includes
3.2.11
dangerous
failure
failure which has the potential
to-function
state
NOTE
Whether or not the potential
with multiple
channels
to improve
hazardous
or fail-to-function
state,
input
devices
and final
elements
NOTE
1
2
Iwo
NOTE
Dependent
instrumented
3.2.13
detected
revealed
overt
in relation to hardware
normal operation
failures
be either
operator
a BPCS
and
or an S1S or
common
failure
cause
consideration
in a hazardous
or fail-
architecture
of the svstem: in svstems
is less likely to lead to the overall
simple
bf dependent
includes
from an
manner
system
failure
and may
3.2.12
dependent
failure
faiiure whose probability
cannot be expressed
as the
probabilities
of the individual events which caused it
NOTE
61511-1:2003
product
of the
unconditional
between
layers
of protection,
(see 3.2.6).
and software
faults,
detected
by the diagnostic
tests or through
3.2.14
device
functional
unit of hardware or software, or both, capable of accomplishing
a specified purpose
(for example, field devices;
equipment
connected
to the field side of the S1S 1/0 terminals;
final elements,
logic solvers,
and those
such equipment
includes
field wiring,
sensors,
operator interface devices hard-wired to S1S 1/0 terminals)
3.2.15
diagnostic
coverage
(DC)
ratio of the detected failure rate to the total failure rate of the component
or subsystem
detected
by diagnostic
tests. Diagnostic
coverage
does not include any faults detected
proof tests.
as
by
z
g
$Q
m
e
I
NOTE 2
example.
;.,.,,,,,,
Diagnostic
coverage
is applied
to components
or subsystems
of a safety instrumented
the diagnostic
coverage is typically determined
for a sensor, final element or a logic solver.
system.
For
rate,
!SJIEC
61511-4:2003
3.2.16
diversity
existence
NOTE
of different
Dlverslty
means
performing
may be achieved
by different
a required
physical
function
methods
or different
design
approaches.
3.2.17
eiectricalie!ectrorl
iclprogrammable
based
(E) and/or
on electrical
(E/E/PE)
electronic
(E) and/or
programmable
or systems
electronic
operating
(PE) technology
on electrical
principles
and would
include
eleciro-mechanical
solid-state
electronic
devices
(electrical);
non-programmable
dewces
based
electronic
on computer
devices
?electronic);
technology
(programmable
electronic)
3.2.18
error
discrepancy
between
a computed,
observed
or measured
specified or theoretically
correct value or condition
NOTE
Adapted
from
IEV 191-05-24
by excluding
Examples
NOTE 2 This
terminology
3.2.20
failure
termination
include
term
a drain system,
devia!es
from
of the ability
NOTE
This definition
NOTE
For further
the
(excluding
definition
these
are separate
lwnd
and distinct
NOTE 4
Failures
random
in IEC
matches
61508-4
ISCI!IEC
to
reflect
differences
a required
function
[lSO/lEC
The definition
in the
process
sector
2382-14-01-09:1997,
(see
3.2,62
a reduction
in IEV 191-15-05
refers
to perform
only to sub-item
2382-14-04-06]
10
may be
of a functional
unit to continue
functions
and 3.2.85),
3.2.22
fault avoidance
use of techniques
and procedures
which aim to avoid the introduction
phase of the safety life cycle of the safety instrumented
system
NOTE
the true,
necessarily
excludes
certain behaviour,
and some
The occurrence
of such behaviour
is a failure.
or systematic
3.2.21
fault
abnormal condition that may cause
to perfcrm a required function
3.2.23
fault tolerance
ability of a functional
or errors
and
..
(dike).
unit to perform
notes)
Performance
of required functions
in terms of behaviour to be avoided.
NOTE
IEV 191-05-01
defines
excluding
the inability
during
resources.
[l SO/l EC 2382-14-01
or condition
NOTE 3
specified
are either
which
fire wall,
of a functional
information,
value
the notes.
3.2.19
external
risk reduction
facilities
measures to reduce or mitigate the risks,
NCTE
(see 3.2,55).
a required
faults.
function
unit
a required
function,
to lack of external
of faults
during
in the presence
any
of faults
in 3.2.21.
lS/lEC 61511-1:2003
3.2.24
final element
part of a safety instrumented
achieve a safe state
system
which
implements
NOTE
Examples
are valves, switch gear, motors including
and actuator if involved in the safety instrumented
function.
their
the
auxiliary
physical
elements,
3.2.26
functional
safety assessment
investigation,
based on evidence,
protection
layers
to judge
to reflect
to reflect
depends
differences
In process
safety
achieved
differences
in process
the functional
necessary
for example,
3.2.25
functional
safety
part of the overall safety relating to the process and the BPCS which
fonctionlng
of the S1S and other protection layers
NOTE This term deviates from the definition in IEC 61508-4
action
a soietloid
to
valve
on the correct
sector
terminology.
by one
sector
or more
terminology
safety audit
and independent
examination
to determine
whether the procedures
specific to the
safety requirements
comply with the planned
arrangements,
are implemented
and are suitable to achieve the specified objectives
NOTE A functional safety-audit ma# be carried out as part of a functional safety assessment.
3.2.28
functional
unit
entity of hardware
or software,
or both, capable
term item
of accomplishing
is LIsrxl In place
a specified
of functional
purpose
3.2.29
hardware
safety integrity
part of the safety integrity of the safety
faiiures in a dangerous
mode of failure
instrumented
function
relating
to random
hardware
NOTE 1 The term relates to failures in a dangerous mode. That is, those failures of a safety instrumented function
that would impai: Its safe!y integrity. The two parameters that are relevant in this context are the overall dangerous
failure
NOTE
See 3286
NOTE
3.2.30
harm
physical
damage
of failure
to operate
on demand.
in IEC. 61508-4
of people,
to reflect
either
differences
directly
in process
or indirectly,
sector
terminology.
as a result
of
source
of harm
This definition
(without
notes)
matches
3.4 of ISCMEC
Guide
51
11
lS/lEC
64511-1:2003
3.2.32
human error
mistake
human action
or inaction
that produces
an unintended
result
NOTE This is the definition found in lSO/l EC 2382-14-02-03 and differs from that given in IEV 191-05-25
addition
by the
of or inaction.
3.2.33
impact analysis
activity of determining
the effect that a change to a function or component
functions
or components
in that system as well as to other systems
3.2.34
independent
department
department
which is separate and distinct from the departments
which take place during the specific
phase of the safety life
functional
safety assessment
or validation
responsible
cycle that
3.2.35
independent
organization
organization
which is separate
and distinct,
by management
and other resources,
from the
organizations
responsible
for the activities
which take place during the specific phase of the
safety life cycle that is subject to the functional
safety assessment
or validation
3.2.36
independent
person
person who is separate
and distinct from the activities
which take
phase of the safety life cycle that is subject to the functional
safety
and does not have direct responsibility
for those activities
3.2.37
input function
function which monitors the process
information
for the logic solver
NOTE
An in~ut function
3.2.38
instrument
apparatus
could
be a manual
used in performing
equipment
in order
to provide
input
function
an action
(typically
found
in instrumented
systems)
NOTE
instrumented
systems
in the process
sector are typically
composed
of sensors (for example,
pressure,
flow,
temperature
transmitters),
logic
solvers
or control
systems
(for example,
programmable
controllers,
cfistributed
control
systems),
and final elements
(for example,
control
valves).
In special cases, instrumented
systems can be safety instrumented
systems (see 3.2.72).
3.2.39
logic function
function which performs
the transformations
between input information
(provided
by one or
more input functions)
and output information
(used by one or more output functions);
logic
functions
provide the transformation
from one or more input functions
to one or more output
functions
NOTE
For further
guidance,
12
lS/lEC 61511-1:2003
3.2.40
logic solver
that portion of either
logic systems
electronic
PE logic system
NOTE 2
systems,
for electro-mechanical
logic systems
for electronic
for programmable
technology;
technology;
electronic
systems.
Examples
are: electrical
systems,
electronic
hydraulic systems. Sensors and final elements
systems,
programmable
electronic
are not part of the logic solver.
3.2.40.1
safety configured
logic solver
general
purpose industrial
grade PE logic solver
safety applications
in accordance
with 11.5
which
is specifically
systems,
pneumatic
configured
for use
in
3.2.41
maintenance/engineering
interface
maintenance/engineering
interface is that hardware and software provided to allow proper S1S
maintenance
or modification.
It can include instructions
and diagnostics
which may be found
in software,
programming
terminals
with appropriate
communication
protocols,
diagnostic
tools, indicators,
bypass devices, test devices, and calibration
devices
3.2.42
mitigation
action that reduces
NOTE
Examples
the consequence(s)
include
emergency
3.2.43
mode of operation
way in which a safety
of a hazardous
depressurizatlon
instrumented
event
on detection
function
of confirmed
operates
3.2.43.1
demand
mode safety instrumented
function
where a specified
action (for example,
closing of a valve) is taken in response to process
conditions
or other demands.
In the event of a dangerous
failure of the safety instrumented
function a potential hazard only occurs in the event of a failure in the process or the BPCS
3.2.43.2
continuous
mode safety instrumented
function
where in the event of a dangerous
failure of the safety instrumented
hazard will occur without further failure unless action is taken to prevent
NOTE 1 Continuous
mode
maintain functional
safety.
covers
those
safety
Instrumented
functions
which
measures
3 and 4.
for safety
instrumented
in IEC 61508-4
13
functions
to reflect
operating
differences
function
a potential
it
implement
continuous
control
to
terminology
3.2.44
module
seif-contained
assembly
of hardware
components
that performs a specific hardware function
(i. e., digital input module, analogue
output modu!e), or reusable application
program (can be
internal
to a program or a set of programs)
that support a specific function,
for example,
portion of a computer program that carries out a specific function
NOTE
In the context
NOTE
of IEC 61131-3,
a software
module
is a function
in IEC 61508-4
or function
to reflect
block.
differences
in the process
sector.
3.2.45
MOON
safety instrumented
system, or part thereof, made up of N independent
channels,
which
so connected,
that M channels are sufficient to perform, the safety instrumented
function
3.2.46
necessary
risk reduction
risk reduction required to ensure
3.2.47
non-programmable
(NP) system
system
~ased on non-com-puter
electronics
[PE] or software)
NOTE
Examples
systems.
would
include
technologies
hard-wired
electrical
to a tolerable
not
systems,
are
level
based
mechanical,
on
programmable
hydraulic,
or pneumatic
3.2.48
operator
interface
means by which information
is communicated
between a human operator(s)
and the S!S (for
example.
CRTs, indicating
lights,
push-buttons,
horns, alarms);
the operator
interface
is
sometimes
referred to as the human-machine
interface (t-lMl)
3.2.49
other technology
safety related
safety related systems that are
programmable
electronic
NOTE
include
systems
based on a technology
technology
systems.
3.2.50
output
function
function which controls the process
information
from the logic function
3.2.51
phase
period
within
the safety
life cycle
3.2.52
prevention
action that reduces
the frequency
3.2.53
prior use
see proven-in-use
(see 3.2.60)
safety
related
system,
where
activities
of occurrence
14
other
Other
than
technology
equipment
described
electrical,
safety
according
in this standard
of a hazardous
event
electronic,
related
systems
to final
take place
or
may
actuator
lS/lEC
3.2.54
process
risk
risk arising
from
malfunction)
the
process
conditions
caused
by
abnormal
events
NOTE
Assessment
NOTE
include
associated
human
factor
:2003
61511-1
BPCS
(including
in which
of determining
layers.
risk is to
issues.
3.2.55
programmable
electronics
(PE)
electronic
component
or device forming part of a PES and based on computer
The term encompasses
both hardware and software and input and output units
technology.
NOTE 1 This term covers micro-electronic devices based on one or more central processing units (CPU) together
with
associated
smart
memories
sensors
programmable
Examples
and final
electronic
of process
sector
programmable
electronics
include
elements;
logic solvers
including
programmable
controllers;
programmable
logic controllers,
loop controllers.
NOTE
from
the definition
in IEC 61508-4
to reflect
differences
in process
sector
terminology.
3.2.56
programmable
electronic
system (PES)
system for control. protection
or monitoring
based on one or more programmable
electronic
devices, including all elements of the system such as power supplies, sensors and other input
devices, data highways
and other communication
paths, actuators
and other output devices
(see Figure 6). -
........... ...........
Extent of PES
!,,
,,
.,,,,.
.,.
~ input intefiaces
: (for exampie, A-D
: converters)
...
$.,,.
.,.,.,...
Communications
. .
,,
.,,.,,,,,
Output interfaces
(for example, A-D
conve~rs)
~
.
,$
?i=F*,
k;
R
:
:
s
input devices
(for example, sensors)
,, ...,,,..,
Output devicen/final
elements
(for example, actuators)
. . . . . . . . . . . . . . . . . . . . , <,.,..,,..
. . . . . . . . . . . . . . . . . . . . . . . ...>....!
1
:
, .,,,,.,,,.
Figure
electronics are shown centrally located but cou!d exist at several places in the PES.
6 Programmable
electronic
system
Is
(PES):
structure
and terminology
ISIIEC
61511-1:2003
3.2.57
programming
process
of designing,
processing
data
NCTE
In this standard,
writing
and
programming
testing
is typ{cally
3.2.58
proof test
test performed
to reveal
undetected
necessary,
the system can be restored
3.2.59
protection
layer
any independent
mechanism
a set
associated
of
instructions
for
solving
or
with PE.
faults
in a safety
instrumented
to its designed functionality
that reduces
a problem
risk by control,
prevention
system
so
that,
if
or mitigation
NOTE
It could be a process engineering
mechanism
such as the size of vessels containing
hazardous
chemicals,
a mechanical
engineering
mechanism
such as a rellef valve, a safety instrumented
system or an administrative
procedure
such as an emergency
plan against
an Imminent
hazard.
These responses
may be automated
or
initiated by human actions (see Figure 9).
3.2.60
proven-in-use
when a documented
assessment
has shown that there is appropriate
evidence,
based on the
previous
use of the component,
that the component
is suitable
for use in a safety
instrumented
system (see prior use in 11 .5)
NOTE This term deviates
from
IEC 61508
3.2.61
quality
totality
of characteristics
NOTE
to reflect
of an entity
3.2.62
random
hardware
failure
failure, occurring at a random
the hardware
differences
in process
time, which
results
sector
technology.
to satisfy
from a variety
stated
and implied
of degradation
needs
mechanisms
in
3.2.63
redundancy
use of multiple
elements
implemented
by identical
redundancy)
NOTE
Examples
NOTE 2
Redundancy
NOTE
The definition
NOTE
This term
3.2.64
risk
combination
NOTE
or systems
to perform
the same function;
redundancy
elements
(identical
redundancy)
or by diverse elements
is used primarily
in IEV 191-15-01
deviates
to improve
components
reliability
is less complete
of the frequency
functional
on this concept,
16
bits.
to reflect
1].
differences
see Clause
of parity
or availability.
[lSO/l EC 2382 -14-01-1
in IEC 61508-4
of occurrence
can be
(diverse
in process
sector
of that harm
terminology.
lS/lEC
3.2.65
safe failure
failure which does not have the potential
or fail-to-function
state
NOTE
Whether
NOTE 2 Other
to-safe failure.
used
for safe
3.2.65.1
safe failure fraction
fraction of the overall random
failure or a detected dangerous
3.2.66
safe state
state of the process
is realized
failure
may depend
are
hardware
failure
when safety
nuisance
failure
instrumented
on the channel
failure,
spurious
system
architecture
trip
rate of a device
61511-1:2003
failure,
in a hazardous
of the system.
false
trip
that results
failure
in either
or fail-
a safe
is achieved
NOTE 1 In going from a potentially hazardous concfition to the final safe state, the process may have to go
through a number of intermediate safe-states. For some situations, a safe state exists only so long as the process
is continuously controlled. Such continuous control may be for a short or an indefinite period of time.
NOTE
3.2.67
safety
freedom
from unacceptable
in IEC 61508-4
to reflect
differences
in process
sector
terminology,
risk
in IEC 61508-4
to reflect
differences
3.2.69
safety instrumented
safety instrumented
necessary to prevent
control
function
function
with a specified
SIL operating
a hazardous
condition from arising and/or
3.2.70
safety instrumented
instrumented
system
control
system
used to implement
in process
sector
risk,
with
terminology.
in continuous
mode which
to mitigate its consequences
instrumented
control
NOTE
Safety instrumented
control
systems
are rare within the process
industries.
Where
identified,
they will need to be treated as a special case and designed
on an individual
basis
within this standard
should apply but further detailed
analysis
may be required to demonstrate
capable of achieving
the safety requirements.
3.2.71
safety instrumented
function
safety function with a specified
safety and which can be either
instrumented
control function
is
functions
such systems
are
The requirements
that the system is
(SIF)
safety integrity level which is necessary to achieve functional
a safety instrumented
protection function or a safety
3.2.72
safety instrumented
system (S1S)
instrumented
system used to implement one or more safety instrumented
functions.
An S1S is
composed
of any combination
of sensor
(s), logic solver (s), and final elements(s)
(for
example, see Figure 7)
NOTE 1
or both.
either
safety
instrumented
control
17
functions
or safety
instrumented
protection
functions
Manufacturers
NCrE 3
and suppliers
of S1S devices
NOTE 4
See Clause
should
refer to C!ause
1 a) through
d) inclusive.
software.
A..2
S1S
and
archdecture
=fetv
mstrtimented
funcbon
e~arnplewrn different
Sensors
and reliability
of the operator
for the S1S. See IEC 61511-2
Logic solver
action must
for guidance
be
on
Final elements
dewce +
shown
B!$%jfl
L.Figure
3.2.7-3
safety integrity
a~erage probability
safety instrumented
There
7 Example
L...-.-...-----
of S1S architecture
of a safety instrumented
system satisfactorily
performing
the required
functions under all the stated conditions
within a stated period of time
integrity
of safety
level,
integrity
the
higtrer
for safety
the
probability
instrumented
that
the required
safety
instrumented
functions
NOTE 3 In de!erminlrlg
safety integrity,
all causes of failures
(both random
hardware
failures
and systematic
failures)
which lead to an unsafe state should be included;
for example,
hardware
failures,
software
induced
faiiures and failure?, due to electrical
interference.
Some of these types of failure, in particular
random
hardware
allures,
may be quantified
using such measures
as the failure
rate in the dangerous
mode of failure
or the
:rcbability
of a safety instrumented
function
failng
to operate on demand.
However, the safety integrity
of an SIF
IISO depends on many factors, which cannot be accurately
quantified
but can only be considered
qualitatively.
NOTE 4
Safety
integrity
comprises
hardware
safety
in?egrify
and systematic
safety
integrity
3.2:74
safety integrity
level (SIL)
discrete level (one out of four) for specifying
the safety integrity
requirements
of the safety
instrumented
functions
to be allocated
to the safety instrumented
systems.
Safety integrity
level 4 has the highest level of safety integrity; safety integrity level 1 has the lowest
NOTE
The target
failure
measures
integrity
levels
are specified
in Tables
3 and 4.
NOTE 2 It is possible
to use several lower safety integrity
level systems to satisfy the need for a higher
function (for example,
using a SIL 2 and a SIL 1 system together to satisfy the need for a SIL 3 function).
NOTE 3
in IEC 61508-4
to reflect
differences
3.2,75
safety integrity
requirements
specification
specification
that contains
the safety
in?egrity
requirements
functions &at have to be performed
by the safety instrumented
NOTE 1 This
(see 3.2.78).
NOTE 2
specification
is
one
part
(the
safety
integrity
in IEC 61508-4
-part)
to reflect
of
in process
of the
system(s)
the
safety
differences
sector
safety
terminology
instrumented
requirements
in process
level
specification
sector
terminology.
...
3.2.76
safety life cycle
necessary
activities
involved
in the implementation
of safety
occurring
during a period of time that starts at the concept phase
when all of the safety instrumented
functions are no longer available
NOTE 1 The term functional
safety life cycle is strictly more accurate,
considered
necessary
in this case within the context of this standard.
NOTE 2
The safety
life-cycle
model
is shown
18
in Figure
instrumented
of a project
for use
but the
8.
adjective
function(s)
and finishes
functional
is not
KMEC 61541-1:2003
3.2.2?
safety manual
manual which
defines
subsystem
or system
can be safe!y
3.2.78
safety requirements
specification
spt?ci~ication that conta_ins al! the requirements
of the safety
to be performed
by the safety instrumented
systems
3.2.79
safety software
software
in a safety
functionality
instrumented
3.280
sensor
device
or combination
transmitters,
transducers,
system
of devices,
which
process switches,
with
a prograrnrnmg
instrumented
application,
embedded
measure
the process
position switches)
Software
is independent
3.2.8f.l
software
without
data.
languages
of the medium
rmte 1 differs
on which
from
a standaw
manual,
that have
functions
or
utility
software
condition
(for
example,
3.2.81
software
Inte!iectua!
creation
comprising
the programs.
procedures,
data, rules
documentation
pertaining to the operaticm of a data processing
system
NOTE
applied
and
any
associated
it is recorded.
ISO 2382-1,
definitiori
differs
from
ISO 9000-3
by
in S!S subsystems
3.2.8 f.~.l
fixed program
ianguage
(FPL)
in this type of language,
the user is limited to adjustment
of a few parameters
range of the pressure transmitter,
alarm levels, network addresses),
(for example,
NOTE Typical examples of devices with FPL a!e: smart sensor (for example, pressure transmitter), smart valve,
sequence of events controller, dedicated smart alarm tmx, small data Icgging systems,
3.2.81 .1.2
limited variability
language
(LVL)
this type of language is designed to be comprehensible
to process sector users, and provides
Me capability
to combine predefine,
application
specific, library functions
to implement
the
safety requirements
specifications.
An LVL provides a close functional
correspondence
with
the functions required to achieve the application.
NOTE 1 Typical examples
of LVL are given
and sequential
function chart.
in IEC 61131-3.
LVL.
of systems
using
standard
They
PLC
include
ladder
(for example,
diagram,
function
programmable
block
logic
controller
3.2.81 .f.3
fu!l variability
language
(IWL)
this type of language
is designed
provides the capability to implement
to be comprehensible
to computer
programmers
a wide variety of functions and applications
NOTE
Typical
NOTE
In the process
sector,
NOTE
FVL examp!es
include:
example
of systems
using
FVL is found
in embedded
Ada, C, Pascal,
Instruction
purpose
software
computers.
and rarely
List, assembler
in application
language-s,
software.
C++, Java,
diagram
SQL.
for
and
KMEC
6151d-1
3.2.81.2
software
:2003
program
type
3.2,81 .2.1
application
software
software specific to the user application.
In general, it contains logic sequences,
permissive,
limits and expressions
that control
the appropriate
input, output,
calculations,
decisions
necessary
to meet the safety instrumented
functional
requirements.
See fixed and limited
variability
language
3.2.81 .2.2
embedded
software
software
that is part of the system supplied
by the manufacturer
modification
by the end-user,
Embedded
software is also referred
software, See 3.2.81.1.3,
full variability
language
3.2.81 .2.3
utility
software
software
tools
These software
3.2.82
software
life cycle
activities
occurring
during a period of time that
when the software is permanently
disused
starts
Software
cannot
bemaintained;
rather,
when
phase,
of application
software
development
is conceived
phase,
test phase,
programs,
and ends
integration
it is modified
3.2.83
subsystem
see system
3.2.84
system
set of elements,
which interact according
to a design; an element
system, called a subsystem,
which may be a controlling
system
may include hardware, software and human interaction
NOTE
A person
NOTE
This definition
NOTE 3
belonglng
3.2.85
systematic
failure
failure related in a deterministic
way to a certain cause,
modification
of the design
or of the manufacturing
documentation
or other relevant factors
NOTE
Corrective
NOTE
A systematic
NOTE
This definition
NOTE
Examples
the safety
the design,
the design
maintenance
failure
modification
can be induced
of systematic
manufacture,
failure
would
by simulating
requirements
and/or
without
causes
usually
communication
and ancillary
equipment
the failure
the failure
cause.
cause,
IEV 191-04-19.
including
human
error in
specification;
installation
implementation
and operation
of the hardware;
of the software.
20
ISIIEC 61511-1:2003
J,2.86
systematic
safety integrity
that part of the safety integrity of safety instrumented
(see note 3 of 3.2.73) in a dangerous
mode of failure
NOTE
Systematic
safety
NOTE
integrity
cannot
usually
be quantified
function
(as distinct
relating
to systematic
from hardware
safety
failures
integrity).
3.2.87
target failure
measure
intended
probability
of dangerous
mode failures
to be achieved
in respect
of the safety
integrity requirements,
specified in terms of either the average probability
of failure to perform
the design function
on demand (for a demand
mode of operation)
or the frequency
of a
dangerous
failure to perform the SIF per hour (for a continuous
mode of operation)
NOTE
The numerical
values
failure
measures
are given
in Tables
3 and 4
3.2.88
template
software
template
structured
non-specific
piece of application
software
that can be easily altered to support
specific
functions
while retaining
the original
structure;
for example,
an interactive
screen
template
controls the process flow of the application
screens,
but is not specific to the data
being presented;
a programmer
may take the generic template
and make function-specific
revisions to produce a new screen for the users
NOTE
The related term software template
is sometimes
used. Typically,
it refers to an algorithm
or collection
of
algorithms
that have been programmed
to perform a desired function
or set of functions
and is constructed
so it
can be used in many different instances.
In the context of IEC 61131-3, it is a program that can be selected for use
in many applications.
3.2.89
tolerable
risk
risk which is accepted
in a given context
based
on the current
values
of society
and software
faults
not found
by the diagnostic
tests or during
normal
NOTE This term deviates from the definition in IEC 61508-4 to reflect differences in process sector terminology.
3.2.91
validation
activity of demonstrating
that
system(s)
under consideration
specification
instrumented
requirements
3.2.92
verification
activity of demonstrating
for each phase of the relevant safety life cycle by analysis
and/or
the outputs
meet in all respects
the objectives
and
tests,
that,
for specific
inputs,
requirements
set for the specific phase
NOTE
Example
verification
activities
include
reviews on outputs (documents from all phases of the safety life cycle) to ensure compliance with the objectives
and requirements of the phase taking into account the specific inputs to that phase;
-
design reviews;
21
tesis
perfcrmed
on the designed
integmiion
tes!s
ihe performance
products
to ensure
confirms
that
(for example, hardware
N ~;~ ~
de$e,oted
The watchdog
can
in ~,der to p~J\ tile
coverage
of
according
to their
Conformance
the software
system is operating
correctly
by the regular
resetting
of an
electronic
watchdog
timer) by an output device coniro!led
by the software.
be !~se~ to de-energize
pr~~~s~
into
safe
a group
s~ate
The
of safety
vfa~chdog
iS
outputs
used
to
when dangerous
failures
are
increase
the on-line diagnostic
to this
5.t
Management
!rtternational
Standard
NOTE
This
;ns!wmen!ed
~.,:h; evement
5.2.1
of functional
safety
Objective
The objective
are necessary
5.2
manner and by
manner.
specification;
3.2.93
~vatcbdog
eomb!nation
of diagnostics
and an output
ope!-ation of the programmable
electronic
i(~~orrect operation
s~:te~l-fa! aevice
of the requirements
of this c!ause is to identify the management
to ensure the functional
safety objectives
are met,
clause
,s s~iely aimed
at the achievemeili
systems and IS separate
and ciis:, nct from
of safety irl the workplace.
afid maintenance
genera! heal!h and
of the functional
safety measures
activities
that
safety of safety
necessary
for the
Requirements
General
5.2. f.1
The policy
means for evaluating
and strategy
for achieving
safety shall be identified
together
with
its achievement
and shall be communicated
within the organization.
the
5.2.1.2
.A safety management
system shall be in place so as to ensure that where safety
!ns!iumented
systems are used, they have the ability to place and/or maintain the process in a
ssfe state.
5.2.2
Organization
and resources
organizations
5.2.2. !
Persons,
departments,
carrying
out and reviewing
each of the safety
lnforrned
of the responsibilities
assigned
to
authorities
or safety regulatory
bodies).
or other
units which
are responsible
for
life-cycle
phases shall be identified
and be
them (including
where
relevant,
licensing
5.2.2.2
Persons, departments
or organizations
involved in safety
competent
to carry out the activities for which they are accountable.
life-cycle
NOTE
As a minimum,
the following
items should be addressed
when considering
departments,
organizations
or other units involved in safety life-cycle activities:
a)
engineering
knowledge,
b)
engineering
knowledge,
training and experience
electrical,
electronic
or programmable
electronic);
c)
engineering
knowledge,
training
training
and experience
and experience
appropriate
appropriate
appropriate
22
to the process
the competence
shall
be
of persons,
application;
to the applicable
to the sensors
activities
technology
and final
used
elements;
(for example,
ISIIEC
a)
safety
~)
knowiedge
~)
adequate
engineering
management
g)
understanding
h)
the safety
~)
the novelty
5.2.3
knowledge
consequerice
risks
to consider
analysls).
Iife-cyc!e
actwlt!r?s,
of an even?
instrumented
and risk
ai~pr.~prlaie
of the application
evaluation
safety
requirements
skills
and complexity
process
regulatory
and leadership
of the potential
integrity
Risk
NOTE
(for example.
61511-4:2003
functions:
management
evaluated
a!so potential
capital
iosses,
risk reduction
for economical
determined
as
reascns.
Planning
5,2.4
Safety planning
shall take place to define the activities
that are required to be carried out
along with the persons, department,
organization
or other units responsible
to carry out these
activities,
This planning shall be updated as necessary
throughout
the entire safety life cycle
(see Clause 6).
NOTE
l-he safety
a section
planning
in the quality
a separate
document
several documents
5.2.5
may be incorporated
plan entitled
entitled
which
Implementing
safety
safety
plan:
may include
in
plan,
or
c?r
company
procedures
or working
practices.
and monitoring
5.2.5. ? Procedures
shall be implemented
to ensure
prompt
follow-up
reso!uhon of recommendations
pertaining to the safety instrumented
system
a)
hazard
b)
assessment
c)
verification
d)
validation
e)
post-incident
analysis
and satisfactory
arising from
and auditing
activities;
g
activities;
activities;
and post-accident
activities
5.2.5.2
Any supplier,
providing
products
or services
to an organization,
having
overall
responsibility
for one or more phases of the safety life cycle, shaii deliver products or services
as specified
by that organization
and shall haJe a quality management
system. Procedures
shall be in piace to establish the adequacy of the quality management
system.
5.2.5.3
Procedures
instrumented
system
identification
assessing
accordance
NOTE 1
demand.
shall
be implemented
to evaltiate
the performance
against its safety requirements
inc!uding procedures
for
and prevention
of systematic
whether
dangerous
with those assumed
Dangerous
failures
are
failure
during
revealed
failures
which
rates of the
the.design;
by means
of proof
could jeopardize
safety
testing,
NOTE 2 Procedures
should be considered
that define the necessary
failure rates are greater than what was assumed during des!gn.
corrective
2.3
system
or failure
action
the
safety
safety;
instrumented
diagnostics
of
are
in
to operate
to be taken
cm
if the
.
actual operation to
level requirements
iS/i EC
61511-1
:2003
5.2.6
Assessment,
5.2,6.1
Functional
auditing
safety
and revisions
assessment
5.2.6.1.1
A procedure
shall be defined and executed
for a functional
safety assessment
in
sIJch a way that a judgement
can be made as to the functional
safety and safety integrity
achieved
by the safety instrumented
system. The procedure
shall require that an assessment
team is appointed
which includes the technical,
application
and operations
expertise
needed
for the particular
installation,
5.2.6.1.2
competent
The membership
of the assessment
team shall
person not involved in the project design team.
include
NOTE 1
competent
NOTE
The following
the scope
should
of the functional
who is to participate
the skIlk,
safety
the identity
and authorities
of any other
required
safety
NOTE 1
identified,
by which
a functional
safety
to having
of the functional
involved
safety
safety
assessment
of the functional
safety
safety
team;
assessment
assessment
activity;
activity;
will be revalidated
after
modifications.
be given
activities
may need
during operation.
to carrying
out functional
to
safety
be
instrumented
system
safety
introduced
assessment
senior
team;
assessment
Additional
functional
safety assessment
after modification
and at periodic intervals
2- After
one
in the assessment;
the functional
of the assessment
the functional
should
than
senior
assessment:
The stages
in the safety life cycle at which the functional
are to be carried out shall be identified during safety planning.
NOTE 2 Consideration
stages (see Figure 8).
Stage
more
one
assessment;
as a result
bodies
to complete
safety
the resources
when planning
least
assessment;
in the functional
responsibilities
the information
5.2.6.1.3
activities
be considered
at
as
activities
protection
assessment
new
hazards
are
at the following
layers
have
been
3 - After
the installation,
pre-commissioning
The factors
in this decision
are likely
safety assessment
to include
size of project;
degree
safety
of complexity;
integrity
duration
of project;
consequence
degree
safety
previous
level;
in the event
of standardization
regulatory
of failure;
of design
features;
requirements;
experience
with a similar
design.
24
activities
should
depend
upon
the specific
ISIIEC
61511-1:2003
. ........
Ihfazard and risk
Safety
life-cycle
structure
and
planning
Management of
functional
safety
and
functional
safety
assessment and
auditing
Verification
141
1!
Clause 9
;........+..
Stage 2
...............
+
Installation,
1I
commissionii?g
and validation
Clauses 14 and 15
sta9e3~
eration and maintenance
kl
Clause 16
Sag-=--%
Clause 5
stage,=
+
Clause 6.
Z1
Decommissioning
Clall<e IFI
Clauses 7
12.4, and
12.7
7
Key:
~
; Nodetailed
:,,..........,....;
requirements
Requirements
c1
flow
gkrenin
this standard
NOTE1
Stages lthrough
NOTE2
Allreferences
5inclusive
areto
Partl
aredefined
in 5.2.6,1.3
.
Figure
8-
S1S safety
life-cycle
phases
and functional
25
safety
assessment
stages
1%!EC 61514-1:2003
5.2.6.1.4
At least one functional
safety assessment
shall be undertaken.
This functional
safety assessment
shall be carried out to make sure the hazards arising from a process and
Its associated
equipment
are properly
controlled.
As a minimum,
one assessment
shall be
carried out prior to the identified
hazards being present (i. e., stage 3). The assessment
team
shall confirm, prior to the identified
hazards being present, that
*
th~ hazard
the recommendations
instrumented
system
project
design
change
procedures
the recommendations
resolved;
arising
the safety
the safety
system is designed,
constructed
and installed in accordance
with
specification,
any differences
having been identified and resolved;
the safety
instrumented
system
activities
have been completed;
the employee
instrumented
instrumented
requirement
the previous
and emergency
validation
for implementing
further
to which
such tools
LNOTE 2 Examples
of development
equipment,
test equipment,
equipment
NOTE 3
operating
planning
should
to the
and
the
includes,
shall
be
made
assessments
validation
will depend
upon their
are in place.
life-cycle
impact
to, traceability
activity,
on the safety
shall be available
available
to
the
measuring
tools.
to calibration
standards,
together
with any
functional
shall
be defined
of the auditing
and executed
for auditing
compliance
with
safety
and follow-up
require-
activities;
safety
information
about the safety
and operating personnel;
safety
been
and revision
5.2.6.2.1
Procedures
ments including
the frequency
is appropriate
need to be addressed
of tools
5.2.6.1.7
All
relevant
information
assessment
team upon their request.
pertaining
have
and production
tools include
simulation
and modelling
tools,
used during maintenance
activities
and configuration
management
Functional
safety assessment
history and defect list.
Auditing
assessment
5.2.6.1.6
The results of the functional
safety assessment
recommendation
coming from this assessment,
5.2.6.2
safety
procedures
functional
5.2.6.1.5
Where development
and production
they shall themselves
be subject to a functional
NOTE 1 The degree
!J De achieved,
functional
training
has been completed
and appropriate
system has been provided to the maintenance
plans or strategies
from
implemented;
or other
activities.
5.2.6.2.2
Management
of modification
procedures
review,
implement
and approve
changes
to the
replacement
in kind (i.e. like for like).
26
document,
other than
iS/lEC 61511-1:2003
5.2.7
S1S configuration
5.2.7.1
Requirements
management
5.2.7.1.1
Procedures
for configuration
management
of the S1S during the S1S and software
safety life-cycle
phases shall be available;
in particular,
the following should be specified:
*
the stage
the procedures
to be used
(hardware
and software);
for
the procedures
unauthorized
Safety
6.1
at which
formal
configuration
for preventing
life-cycle
control
uniquely
is to be implemented;
identifying
all
constituent
parts
of
an
item
service.
requirements
Objectives
The objectives
of this clause
to define
to organize
to
and establish
the technical
the requirements
activities
into a safety
of the safety
life-cycle
that adequate
planning
exists (or is developed)
that
instrumented
system shall meet the safety requirements.
The overall
approach
approach
IS for illustration
through decommissioning.
of this
standard
6.2
Requirements
6.2.1
during
A safety life-cycle
safety planning.
is shown
to Indicate
incorporating
the
6.2.2
Each phase of the safety life cycle
verification
activities (see Table 2).
In Figures
the typical
8, 10, and
safety
requirements
shall
27
activities;
life cycle;
ensure
safety
NOTE
the phases
are:
be defined
11
life-cycle
of this
in terms
makes
It should
activities
standard
certain
be stressed
from
initial
shall
of its inputs,
that
that
the
this
conception
be defined
outputs
and
I!MEC
61511-1:2003
Table
2SIS
safety
Iife-cycie
overview
..
Safety
!gure 8
box
,umber
1
life-cycle
or activity
phase
Objectives
Requirements
Aitocatlon
of
safety functions
to protection
layers
S1S safety
~requirements
~specrflcatlon
S1S design
engineering
outputs
Clause or
subclause
Title
To determine
the hazards
and hazardous
events of
the process and associated
equipment,
the sequence
of events leading to the
hazardous
event, the
process risks associated
with the hazardous
event,
the requirements
for risk
reduction
and the safety
functions
required to
achieve the necessary
r;sk
reduction
Allocation
of safety
functions to protection
layers and for each safety
Instrumented
function, the
associated
safety integrity
level
To specify the
requirements
for each S1S,
In terms of the required
safety Instrumented
functions
and their
associated
safety Integrity
In order to achieve the
required functional
safety
10
Process design,
layout, manning
arrangements,
safety targets
and
A description
of the
hazards, of the
required safety
function(s)
and of
the associated
risk
reduction
Inputs
A description
of the
required safety
instrumented
, function(s)
and
I associated
safety
integrity
requirements
Description
of
allocation
of safety
requirements
(see
clause 9)
S1S installation
commlsstoning
and validation
To Integrate
S1S safety
requirements:
software safety
requirements
Desi9noftheSS
in conformance
with the S1S safety
requirements;
planning for the
S1S integration
test
SSsafety
requtremenls
Software safety
requirements
.
5L
Description
of
allocation
of safety
requirements
(see
Clause 9)
123,
Sls
14, 15
S1S design
S1S Integration
plan
test
SIS safety
requirements
Plan for the safety
validation
of the
Sls
Fully functioning
S1S in conformance
with the S1S design
results of S1S
integrtition
tests
Results of the
installation,
com missioning
and
validation
activities
SIS operation
and maintenance
28
16
S1S requirements
SIS design
Plan for S1S
operation
and
maintenance
Results of the
operation
and
maintenance
activities
lS/lEC 61511-1:2003
Table
Safety life-cycle
2 (continued)
phase
Requiremen%
or activity
Objectives
Title
igure 8
box
timber
Inputs
outputs
Clause or
subclause
S1S modification
To make corrections,
enhancements
or
adaptations
to the S1S,
ensuring that (he requ!red
safety integrity level IS
achieved and maintained
17
Results of S1S
modification
Decommlssioning
18
As built safety
requirements
and
process information
SIF placed
service
out of
SIS verifica!l~n
7, 127
Results of the
verification
of the
S1S for each phase
10
S1S functional
safety
assessment
To Investigate
and arrive at
a judgement
on the
functional
safety achieved
by the S1S
Results of S1S
functional
safety
assessment
S1S safety
requirement
6.2.3
For all safety life-cycle
phases, safety
techniques,
measures and procedures
to
*
planning
shall
take
place
to define
ensure
that the S1S safety requirements
are achieved
for all relevant
process; this includes both function and safety integrity requirements:
ensure
proper
ensure
the safety
maintain
the
manage
system.
the
installation
integrity
safety
and commissioning
of the safety
integrity
process
during
hazards
of the safety
instrumented
operation
during
functions
(for example,
maintenance
instrumented
modes
of the
*
system;
after installation:
proof
activities
the criteria,
testing,
on
the
failure
safety
analysis);
instrumented
Verification
7.1
Objective
The objective
of this clause is to demonstrate
by review, analysis
required outputs satisfy the defined requirements
for the appropriate
safety life cycle identified by the verification
planning
7.1.1
Verification
the safety
and/or
phases
testing
(Figure
that the
8) of the
Requirements
planning
life cycle.
the verification
procedures,
the
implementation
(Figure
8) of
activities:
measures
and resolution
and
!eCt7nlq
of resulting
UeS
to be used
recommendations:
29
for
verification
includlng
lS/[iZC
61511-1:2003
when these
activities
the persons,
departments
levels of independence:
identification
of items to be verified;
identif~cation
of the information
how to handle
and
organizations
against
responsible
which
for
the verification
these
activities,
is carried
including
out;
non-conformances;
analysis
7.1.1.1
Verification
shall
be performed
7.1.1.2
The results
of the verification
according
process
to the verification
planning,
shall be available
NOTE 1 Selection
of techniques
and measures
for the verification
process
and the degree of independence
depends
upon a number of factors
including
degree of complexity.
novelty of design, novelty of technology
and
safety Integrity level required.
NOTE 2 Examples
software verification
Process
8.1
of some verification
tools and CAD tools.
hazard
and
risk
activities
include
design
reviews,
use of tools
and techniques
including
assessment
Objectives
The objectives
of the requirements
to determine
the hazards
to determine
the sequence
to determine
the process
to determine
any requirements
to determine
the safety
to determine
Clause 9).
if
any
of this clause
and hazardous
of events
the
of the process
and associated
to the hazardous
equipment;
event;
event;
functions
of
events
leading
risks associated
are:
required
safety
to achieve
functions
are
the necessary
safety
risk reduction;
instrumented
NOTE 1 Clause
8 of this standard
IS addressed
to process
engineers,
hazard
and risk
managers
as well as Instrument
engineers.
The purpose
is to recognize
the multl-disciplinary
required for the determination
of safety instrumented
functions,
functions
(see
specialists,
approach
safety
typically
8.2
Typical
risk reduction
methods
found
In process
plants
are indicated
in Figure
9 (no hierarchy
Implied).
Requirements
8.2.1
A hazard and risk assessment
shall be carried
equipment
(for example, BPCS). It shall result in
a description
of each identified
(including
human errors);
hazardous
a description
consideration
of conditions
such as normal
process upset, emergency
shutdown:
the determination
required safety;
a description
of. or references
hazards and risk:
of the consequences
of requirements
event
and likelihood
30
and
the
factors
that
contribute
to it
of the event:
operation,
for additional
to information
start-up,
risk reduction
shutdown,
necessary
taken
maintenance,
to achieve
to reduce
the
or remove
iS/lEC
61511-1:2003
a detailed description
of the assumptions
made during the analysis of the risks including
probable demand rates and equipment
failure rates, and of any credit taken for operational
constraints
or human intervention;
allocation
of the safety functions
to layers of protection
(see Clause 9) taking account of
potential reduction
in effective protection
due to common cause failure between the safety
layers and between the safety layers and the BPCS (see note 1);
identification
Clause 9).
of those
safety
function(s)
applied
as safety
instrumented
function(s)
(see
NOTE 1 In determining
the safety integrity
requirements,
account will need to be taken of the effects cf common
cause between
systems that create demands
and the protection
systems that are designed
to respond
to those
demands,
An example of this would be where demands can arise through control system failure and the equipment
used within the protection
systems is similar or identical
to the equipment
used within the control system. In such
cases, a demand caused by a failure of equipment
In the control system may not be responded
to effectively
if a
common cause has rendered similar equipment
in the protection
system to be ineffective.
It may not be possible
to
recognize
common
cause problems
during the initlai hazard Ident!ftcation
and risk analysis
because
at such an
early stage the design of the protection
system will not necessarily
have been completed.
In such cases, it will be
necessary
to reconsider
the requirements
for safety integrity
and safety instrumented
function
once the design of
the safety instrumented
system and other layers of protection
has been completed.
In determining
whether
the
overall
design
of process
and protection
layers meets requirements,
common
cause failures
will need to be
considered.
NOTE 2 Examples
of techniques
are illustrated
in IEC 61511-3.
8.2.2
places
to establish
the required
The dangerous
failure rate of a BPCS (which does
a demand on a protection
layer shall not be assumed
8.2.3
The hazard and risk assessment
shall be recorded
between the above items is clear and traceable.
NOTE 1
numer}cal
SIL of safety
instrumented
functions
targets
have
to be assigned
as
Allocation
9.1
of safety
functions
to protection
layers
Objectives
The objectives
allocate
determine
determine
NOTE
of the requirements
safety
Account
functions
the required
to protection
safety
9.2
Requirements
9.2.1
The allocation
be taken,
of this clause
instrumented
shall result
the allocation
of safety
functions
prevention,
control
or mitigation
equipment;
the allocation
NOTE
Legislative
of risk reduction
requirements
or other
targets
industry
functions;
function,
the process
of the allocation
process
layers;
instrumented
during
are to
the associated
of allocation,
of other
Industry
safety
integrity
standards
level.
or codes,
process
in
to specific
of hazards
to safety
codes
protection
from the
instrumented
may determine
31
layers
process
priorities
functions.
in the allocation
process.
LsilEc 61511-1:2003
9.2.2
taking
by
3 Safety
..
..
.
integrity
operating
with Table
levels:
in continuous
4,
probability
of failure
mode
of operation,
on demand
DEMAND
MODE
probability
Target average
of failure
on demand
the
OF OPERATION
L.-
!
t
Safety integrity
level (S IL)
I
I
----~
<--;:;:j~
reduction
>1000 to =10,000
\ -----=-
>Iooto S1OOO
I,
.- .
,.10
:-
l--.._-__._.:___t_
Table
4-
Safety
2to
integrity
levels:
,.-...
frequency
CONTINUOUS
--
Safety integrity
level (SIL)
MODE
failures
of the SIF
<10-9 to <10-8
i. -....
1
I
zl o@ to <10-7
210-7 to <10-s
-+
1
See 3243
OF OPERATION
of dangerous
Target frequency
of
dangerous
failures
to perform
the safety
instrumented
function
(per hour)
L--.. -- - .--
TE 2
aiterna!lve
systematic
>lotosloo
<lo-,
NO
risk
>10,000 to <100,000
L---._.__:----
NOIE
Target
for further
explanation
so as to prov!de
an objective
target
to compare
that, given the current
state of knowledge,
many
failures
per hour for a continuous
mode safety
instrumented
terms of hazard rate) caused by failure of the safety Instrumented
the failure rate of other equipment
that leads to the same risk,
protection
layers
NOTE 4 It IS possible
10 use several
lower safety Integrity
level systems
to satisfy the need for a higher
function (for example,
using a SIL 2 and a SIL 1 system together to satisfy the need for a SIL 3 function).
9.3
Additional
requirements
for safety
integrity
level
level
9.3.1
No safety instrumented
function with a safety integrity level higher than that associated
with SIL 4 shall be allocated
to a safety instrumented
system. Applications
which require the
use of a single safety instrumented
function of safety integrity level 4 are rare in the process
industry.
Such applications
shall be avoided where reasonably
practicable
because
of the
difficulty
of achieving
and maintaining
such high levels of performance
throughout
the safety
Ilfe cycle. Where such systems are specified they will require high levels of competence
from
all those Involved throughout
the safety life cycle.
32
,,,,
?,14.
,-,
w.,,
m,-
. .
..,. ._..
lS/lEC
If the
analysls
results
function
consideration
becomes
more
could
perhaps
function
9.3.2
crlterla
In a safety
shall
Inherently
then
A safety
In either
be
Integrity
given
level
to
safe or adding
reduce
safety
of 4 being
changing
the
additional
integrity
level
assigned
to
a safety
design
of protection.
layers
Instrumented
function of safety Integrity
a). or both b) and c) below are met
for
the
level 4 shall
instrumented
process
requirements
61511-1:2003
safety
instrumented
be permitted
only if the
a)
b)
There
safety
NOTE
should
c)
There
e,-perience
Such experience
should have been gained in a .sImilar enwronment
have been used in a system of comparable
complexity
level
is
sufficient
hardware
failure
data,
obtained
safety Instrumented
function, to allow sufficient
target failure measure that is to be claimed.
NOTE
of the components
9.4
Requirements
9.4.1
Figure
The basic
9.
be relevant
to the proposed
on the basic
process
control
process
system
from
confidence
environment,
control
may be identified
as part of the
as a minimum,
components
used
in the hardware
application
system
and,
used
and complexity
as a protection
as a protection
as
components
part
safety
of
the
integrity
level
layer
layer as shown
in
33
ISIIEC
61511-1:2003
Emergency
broadcasting
/
\
PLANT EMERGENCY RESPONSE
Evacuation
procedut-es
\
Mechanical mltlgatlon systems
Safety instrumented control systems
Safety Instrumented mit!gatlon systems
Operator supewlslon
,H
Figure
9.4.2
The
IEC 61508)
9-
Typical
risk
reduction
methods
found
risk reduction
factor for a BPCS (which does
used as a protection
layer shall be below 10.
in process
not
NOTE
When considering
how much risk reduction credit to be given to a BPCS,
the fact that a part of the BPCS may also be an Init!atlng source for an event
9.4.3
If a risk reduction
factor of greater than 10 is claimed
designed to the requirements
within this standard.
9.5
Requirements
failures
for preventing
common
cause,
common
plants
conform
to
consideration
mode
IEC
should
then
61511
be given
it shall
or
to
be
and dependent
9.5.1
The design of the protection
layers shall be assessed
to ensure that the likelihood
of
common
cause,
common
mode and dependent
failures
between
protection
layers
and
between
protection
layers and the BPCS are sufficiently
low in comparison
to the overall
safety integrity requirements
of the protection
layers. The assessment
may be qualitative
or
quantitative,
NOTE
For a definition
of dependent
failure
see 3.2.12.
34
lS/lEC 61511-1:2003
9.5.2
The assessment
independency
dlverslty
between
physical
separation
shall consider
between
protection
protection
layers:
layers:
between
different
common
cause failures
between
BPCS (for example,
can plugging
sensors in a S1S?)
10
S1S safety
the following:
requirements
protection
layers;
protection
layers and between
protection
layers and
of relief valves cause the same problems as plugging of
specification
Objective
10.1
The objective
function(s)
10.2
of
General
this
clause
is to
specify
the
requirements
for
the
safety
instrumented
requirements
10.2.1
The safety requirements
shall be derived from the allocation
of safety
functions and from those requirements
identified during safety planning.
NOTE
10!3
S1S safety
10.3.1
These
following:
requirements
requirements
shall
to identify
a definition
function:
requirements
a description
of all the safety
functional
safety:
instrumented
of the
sufficient
instrumented
safe
state
of the
a definition
of any individually
create a separate
hazard (for
to flare system);
the assumed
requirement
response
sources
be
of demand
for proof-test
to
design
functions
of common
process
for
the
necessary
cause
failures;
each
identified
include
to achieve
shall
the required
safety
occurring
storage,
the
instrumented
concurrently,
multiple
relief
instrumented
function;
intervals;
time requirements
a description
a description
of S1S process output actions and the criteria
example, requirements
for tight shut-off valves;
the functional
relationship
between
mathematical
functions
and any required
requirements
for manual
requirements
relating
requirements
for resetting
maximum
of SIS process
mode
of operation
to a safe state;
allowable
S1S and
measurements
(demand/continuous)
process
inputs
permisslves;
or de-energize
to trip;
spurious
each
safety
shutdown;
to energize
for
trip rate
35
and
for successful
outputs,
operation,
including
for
lo9ic,
lS/lEC
61514-1:2003
failure
down):
modes
and
desired
any specific
all interfaces
between
a description
instrumented
the application
requirements
the specification
of any action necessary
to achieve or maintain a safe state in the event
of fault(s) being detected
in the S1S, A~y such action shall be determined
taking account
of all relevant human factors;
identification
avoided;
the extremes
of all environmental
conditions
that are likely to be encountered
by the S1S
shall be identified,
This may require consideration
of the following:
temperature.
humidity,
contaminants,
grounding,
interference/rad
infrequency
interference
electromagnetic
(EM1/RFl),
shock/vibration,
electrostatic
discharge,
electrical
area classification,
flooding,
lightning, and other related factors;
identification
to normal and abnormal
modes for both the plant as a whole (for example,
plant start-up)
and individual
plant operational
procedures
(for example,
equipment
maintenance,
sensor calibration
and/or repair). Additional
safety instrumented
functions
may be required to support these modes of operation;
definition
of the requirements
for any safety instrumented
function
necessary
to survive
a major accident
event, for example:
time required
for a valve to remain operational
in
the event of a fire.
requirements
response
related
of the
to the procedures
software
safety
for overrides/in
S1S (for
system
hibits/bypasses
including
11
11.1
software
safety
requirements
specification
and the chosen
S1S design
and
the BPCS
shut-
the S1S:
and operators):
identification
of the
safety
in 12.2.2:
of output
NOTE
Non-safety
instrumented
functions
may be earned out
start-up. These should be separated
from the safety instrumented
10.3.2
The
requirements
(including
combinations
automatic
up and restarting
of the dangerous
alarms,
for starting
requirements
which is feasible
service contracts,
example,
states
the travel
specification
shall be
architecture
of the SIS.
orderly
derived
need
shutdown
from
time.
to be
or faster
the
safety
engineering
Objective
General
11.2.1
The
specifications,
the
requirements
design
of the SIS shall be in accordance
with the S1S safety
taking into account all the requirements
of this clause.
requirements
11.2.2
Where the S1S is to implement
both safety and non-safety
Instrumented
function(s)
then all the hardware
and software
that can negatively
affect any SIF under normal and
fault conditions
shall be treated
as part of the S1S and comply with the requirements
for
the highest SIL.
NOTE 1 Wherever
practicable,
instrumented
functions.
the
safety
Instrumented
36
functions
should
be
separated
from
the
non-safety
... . .
_.._
h
lS/lEC 61511-1:2003
NOTE 2 Adequate
Independence
access to the non-safety
software
functions
11.2.3
Where the S1S is to implement
safety instrumented
functions
of different
safety
integrity
levels, then the shared or common
hardware
and software
shall conform
to the
highest safety integrity level unless it can be shown that the safety instrumented
functions
of
lower safety integrity
level can not negatively
affect the safety instrumented
functions
of
higher safety integrity levels.
11.2.4
If it is intended not to qualify the basic process control system to this standard,
then
the basic process control system shall be designed
to be separate
and independent
to the
extent that the functional
integrity of the safety instrumented
system is not compromised.
NOTE
Operating
Information
may be exchanged
but should
not compromise
11.2.5
the functional
safety
of the S1S
if it can be shown
functions
of the
Requirements
for operability,
maintainability
and testability
shall be addressed
during
of the SIS in order to facilitate
implementation
of human factor requirements
in the
(for example, by-pass facilities to allow on-line testing and alarm when in bypass).
the design
design
NOTE
The maintenance
dangerous
failures arlslng
should
be designed
to minlmlze
as far as practicable
the likelihood
of
11.2.6
The design of the S1S shall take into account human capabilities
and limitations
and
be suitable
for the task assigned
to operators
and maintenance
staff. The design
of all
human-machine
interfaces
shall follow good human factors practice and shall accommodate
the likely level of training or awareness
that operators
should receive.
11.2.7
The S1S shall be designed in such a way that once it has placed the process
state, it shall remain in the safe state until a reset has been initiated unless otherwise
by the safety requirement
specifications,
.4
in a safe
directed
*
11.2.8
Manual means (for example,
emergency
stop push button), independent
of the logic
solver, shall be prowded to actuate the SIS final elements
unless otherwise
directed
by the
safety requirement
specifications.
11.2.9
The design of the S1S shall take into consideration
all aspects of independence
dependence
between the SIS and BPCS, and the S1S and other protection
layers.
and
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.
NOTE
When a part of the S1S IS also used for control purposes and a dangerous failure of the common equipment
WOUld cause a demand for the function
performed
by the S1S, then a new risk is Introduced.
The additional
risk IS
dependent
on the dangerous
failure rate of the shared component
because if the shared component
fails. a demand
WIII be created Imrnedlately
to which the S1S may not be capable of responding
For that reason, additional
analysis
WIII be necessary In these cases to ensure that the dangerous failure rate of the shared equipment
is sufficiently
low.
Sensors and valves are examples where sharing of equipment with the BPCS is often considered.
11.2.11
For subsystems
that on loss of power do not fail to the safe state,
requirements
shall be met and action taken according to 11,3:
.
loss of circuit
integrity
is detected
(for example,
is ensured using
power supplies);
end-of-line
supplemental
is detected,
37
monitoring);
power
supply
(for example,
battery
lS/lEC
61511-1:2003
11.3
Requirements
11.3.1
means)
for system
behaviour
The detection
of a dangerous
fault
in any subsystem
which can tolerate
action
to achieve
or maintain
on detection
of a fault
(by diagnostic
tests, proof tests or by any other
a single hardware fault shall result in either
a)
a specified
or
b)
continued
safe operation
of the process whilst the faulty part is repaired.
If the repair of
the faulty part is not completed
within the mean time to restoration
(MTTR) assumed in the
calculation
of the probability
of random hardware failure, then a specified
action shall take
place to achieve or maintain a safe state (see note).
11.3.2
The detection
of a dangerous
fault (by diagnostic
test, proof
means)
in any subsystem
having
no redundancy
and on which a safety
is entirely
dependent
(see note 1) shall, in the case that the subsystem
instrumented
function(s)
action
operation
to achieve
in the demand
or maintain
mode,
a safe state;
result
in the
part of
in either
a)
a specified
or
b)
38
lS/lEC
61511-1:2003
11.3.3
The detection
of a dangerous
fault (by diagnostic
test, proof tests or by any other
means) in any subsystem
having no redundancy
and on which a safety instrumented
function
is entirely dependent
(see note 1) shall, in the case of a subsystem
which is implementing
any
safety instrumented
function(s)
operating
in the continuous
mode (see note 2), result in a
specified action to achieve or maintain a safe state.
The specified
action (fault reaction)
required
to achieve or maintain
specified
in the safety requirements
specification.
It may consist,
for
shutdown
of the process, or that part of the process which relies, for
faulty subsystem,
or other specified
mitigation
planning, The total time
to perform the action shall be less than the time for the hazardous
event
11.4
Requirements
for hardware
fault
tolerance
11.4.1
For safety instrumented
functions,
have a minimum hardware fault tolerance.
NOTE 1 Hardware
the required safety
fault tolerance
of 1
failure of one of the
of the
under
the sensors,
logic
solvers
shall
fault tolerance
is the ability of a component
or subsystem
to continue to be able to undertake
instrumented
function in the presence of one or more dangerous
faults in hardware.
A hardware
means that there are. for example,
two devices and the architecture
is such that the dangerous
two components
or subsystems
does not prevent the safety action from occurring.
shortcomings
in SIF design
with uncertainty
in the
NOTE 3 It is important
to note that the hardware fault tolerance
requirements
represent the minimum component
or subsystem
redundancy.
Depending
on the application.
component
failure rate and proof-testing
interval.
additional
redundancy
may be required to satisfy the SIL of the SIF according
to 11.9.
11.4.2
For
Table 5.
PE logic
Table
solvers,
5 Minimum
the
minimum
hardware
hardware
fault
fault
tolerance
Minimum
tolerance
shall
of PE logic
hardware
fault
be as shown
solvers
tolerance
SIL
SFF <60
1
2
3
SFF 60 % to 90
~0
SFF >9010
+----+-
3
Special
39
requirements
apply
in
lS/lEC
61511-1:2003
11.4.3
For all subsystems
(for example,
sensors,
final elements
and non-PE logic solvers)
except PE logic solvers the minimum
hardware
fault tolerance
shall be as shown in Table 6
provided that the dominant failure mode is to the safe state or dangerous
failures are detected
(see 11 ,3), otherwise the fault tolerance
shall be increased
by one.
NOTE To establish whether the dominant failure mode is to the safe state it ts necessary to consider each of the
foliowing
the process connection of the device;
use of diagnostic information of the device to validate the process signal:
use of inherent fail safe behaviour of the device (for example,
Ilve zero
signal,
loss
of power
results
in a safe
state)
11.4.4
For all subsystems
(for example,
sensor, final elements
excluding
PE logic solvers the minimum fault tolerance
specified
by one if the devices used comply with all of the following:
the hardware
of the device
the adjustment
of the
jumper, password;
the function
1
I
I
11.4.5
Alternative
made in accordance
11.5.1
of process-related
failure direction;
process-related
11.5
is selected
parameters
parameters
of the device
is protected,
measuring
for example,
of less than 4.
6 Minimum
hardware
fault tolerance
of sensors
and final elements
and non-PE logic solvers
Minimum hardware fault tolerance
(see 11.4.3 and 11.4.4)
SIL
1
1
Special
tolerance
fault
requirements
apply
requirements
may be used providing
of IEC 61508-2, Tables 2 and 3,
an assessment
is
to the requirements
Requirements
for selection
of components
and subsystems
Objectives
11.5.1.1
The first objective
of the requirements
for the selection
of components
or subsystems
instrumented
system
The
second
11.5.1.2
requirements
to enable
Sls
objective
of
a component
the requirements
of this clause
is to specify
or subsystem
to be integrated
in the architecture
the
of a
11.5.1.3
The third objective
of the requirements
of this clause is to specify
acceptance
crlterla for components
and subsystems
in terms of associated
safety ~nstrumented
functions
and safety integrity.
40
lS/lEC
14.5.2
General
61511-1:2003
requirements
selected
for use as part of a safety
instrumented
11.5.2.1
Components
and subsystems
system for S!L 1 to SIL 3 applications
shall either be in accordance
with IEC 61508-2 and IEC
61508-3, as appropriate,
or else they shall be in accordance
with
11.4 and 11.5.3 to 11.5.6,
as appropriate,
11.5.2.2
Components
and subsystems
selected
for use as part of a safety instrumented
system for SIL 4 applications
shall be in accordance
with IEC 61508-2 and IEC 61508-3,
as
appropriate.
11.5.2.3
The suitability
of the selected
through consideration
of
manufacturer
hardware
if applicable,
and
appropriate
NOTE
For the
selectlon
embedded
application
11 .5.2.4
The components
ments specifications.
aPPIY. lncludin9
software
software
language
and subsystems
of components
architectural
components
and
constraints
Integrity
11.5.3
Requirements
for the selection
based on prior use
11.5.3.1
suitable
Appropriate
evidence
shall be available
for use in the safety instrumented
system.
11.5.3.2
The evidence
consideration
systems;
adequate
of suitability
of components
that
identification
include
quality,
and specification
demonstration
of the performance
profiles and physical environments;
with
aspects
on detection
of this
of a fault
require-
standard
and
still
application
and subsystems
the components
operating
experience
and subsystems
either
rn safety
are
or non-safety
should be !n accordance
with the complexity
of the considered
of failure necessary
{o achieve the required safety integrity
level
shall
of the manufacturers
be demonstrated
(see 12.4.4)
applicable
behavlour
shall
documentation;
shall
subsystems,
hardware
and subsystems
the following:
management
and configuration
of the components
of the components
management
or subsystems;
or subsystems
in similar
operating
NOTE
In the case of field dewces (for example,
sensors and final elements)
fulfilling
a given function,
Ihls
which
means that the device
will be
functton
is usually
identical
in safety and non-safety
applications,
performing
In a similar way in both type of applications.
Therefore,
consideration
of the performance
of such
devices In non-safety
applications
should also be deemed to satisfy this requirement.
the volume
of the operating
experience.
NOTE
For field devices, information
relating to operating
experience
is mainly recorded
in the users list of
equipment
approved
for use in their facilities,
based on an extenswe
history of successful
performance
in
safety and non-safety
applications,
and on the elirnlnatlon
of equipment
not performing
in a satwfactory
manner. The list of field devices may be used to support clalms of experience
in operation,
provided that
the Ilst IS updated
and monitored
field devices
field devices
are removed
the process
application
regularly,
when sufficient
operating
is included
41
experience
of not performing
relevant
in a satisfactory
manner;
lS/lEC
11.5.4
61511-1:2003
Requirements
(for example,
11.5.4.1
for selection
field devices)
The requirements
of FPL programmable
based on prior use
of 11,5,2
and 11.5.3
characteristics
modes
functions
previous
configuration
shall consider
of input
and output
and subsystems
apply
11.5.4.2
Unused features
of the components
and
evidence
of suitability,
and it shall be established
the required safety instrumented
functions.
11 .5.4.3
For the specific
the evidence of suitability
components
subsystems
that they
and operational
profile
shall be identified
in the
are unlikely
to jeopardize
of the hardware
and software,
signals;
of use;
and
configurations
use in similar
used;
applications
and physical
11.5.4.4
For SIL 3 applications,
a formal
device shall be carried out to show that
environments.
assessment
(in accordance,
with 5,2,6.1)
of the FPL
the
appropriate
standards
for hardware
used
and
software
or tested
in configurations
representative
of the intended
11.5.4.5
For SIL 3 applications,
a safety manual including constraints
for operation,
maintenance and fault detection
shall be available
covering
the typical configurations
of the FPL
device and the intended operational
profiles.
11.5.5
Requirements
systerps
(for
components
use
and sub-
11.5.5.1
The following
requirements
may only be applied to PE logic solvers used
Instrumented
systems which implement
SIL 1 or SIL 2 safety instrumented
functions.
11.5.5.2
The requirements
of 11,5.4
in safety
apply
11.5.5.3
Where
there is any difference
between
the operational
profiles
and physical
environments
of a component
or subsystem
as experienced
previously,
and the operational
profile and physical environment
of the comoonent
or subsystem
when used within the safety
Instrumented
system.
then any such differences
shall be identified
and there shall be an
assessment
based on analysis
and testing,
as appropriate,
to show that the likelihood
of
systematic
faults when used in the safety instrumented
system is sufficiently
low,
11.5.5.4
The operating
experience
determined
taking into account
SIL of the safety
the
the complexity
NOTE
Instrumented
and functionality
for further
considered
neGessary
to justify
function;
of the component
guidance
42
or subsystem.
the
suitability
shall
be
!S/lEC
11 .5.5.5
provided
For
that
SIL
1 or 2 applications,
understanding
use of techniques
the embedded
protection
of unsafe
failure
for safety
software
against
a safety
additional
configured
provisions
11 .5.5.6
A formal
has a good
unauthorized
assessment
it IS both able
a low enough
to perform
probability
that
history
address
the identified
or unintended
measures
appropriate
purpose
program
sequence
protection
failure
range
modular
check
(in accordance
with 5.2.6.1)
out to show that
modes;
grade
PE
logic
solver
which
used
is
in a
previous
use has shown
there
is
could
lead to a hazardous
event
due
to either
random
to detect
faults
during
program
execution
measures
shall comprise
all of the following:
against
modifications
or diverse
of variables
coding
hardware
and
initiate
or failure
detection
by on-line
monitoring;
programming;
or plausibility
standards
it has been
tested
intended
operational
trusted
failure
check
of values;
approach;
appropriate
used
monitoring;
of code
assertion
be
applications;
industrial
the required
functions
and that
that it will fail in a way which
are
implemented
reaction;
these
may
modifications,
solver
modes:
configuration
shall be carried
logic
are met:
NOTE
A safety configured
PE Ioglc solver
IS a general
specifically
configured
for use In safety applications
SIL 2 application
PE
61511-1:2003
verified
have
in typical
profiles;
software
the system
has undergone
the system
does
documented
used
configurations,
modules
dynamic
fault-insertion
been
testing
and
with
components
analysis
intelligence
test
have
cases
been
and
utility
software;
representative
of
the
used;
and testing;
nor dynamic
*I
reconfiguration;
11.5.5.7
For SIL 2 applications,
a safety
manual
including
constraints
for operation,
maintenance
and fault detection
shall be available
coverina the tv~ical
configurations
of the
.,
PE logic solver and the intended operational
profiles.
11.5.6
Requirements
subsystems
11.5.6,1
When the applications
are programmed
accordance
with IEC 61508-2 and IEC 6;508-3.
11.6
Field
components
and
shall
be in
devices
11.6.1
Field devices shall be selected and installed to minimize failures that could result in
inaccurate
information
due to conditions
arising
from the process
and environmental
conditions.
Conditions
that should be considered
include corrosion,
freezing
of materials
in
pipes,
suspended
solids,
polymerization,
cooking,
temperature
and pressure
extremes,
condensation
in dry-leg impulse lines, and insufficient
condensation
in wet-leg impulse lines.
43
iS/lEC
61511-1:2003
11.6.2
Energize
and power supply
NOTE
ensure
to trip discrete
integrity.
input/output
circuits
shall
a method
to ensure
circuit
11.6.3
Each individual
field device
shall
input/output,
except in the following
cases.
.
Multiple
monitor
discrete
the same
Multiple
final
sensors
process
elements
have
its
own
dedicated
wiring
to
and
the
are connected
in series
to a single
input
condition
(for example,
motor overloads).
are connected
to a single
A digital
bus communication
with
requirements
of the SIF it services.
overall
the
to
system
sensors
all
output.
NOTE
For two valves connected
to one output. both valves
all the safety instrumented
functions
that use the two valves
apply
are required
safety
to change
performance
state
that
at the same
meets
the
time for
integrity
11 .6.4
remote
should
Smart sensors
shall be write-protected
to prevent
inadvertent
modification
from a
location,
unless appropriate
safety review allows the use of read/write.
The rewew
take into account human factors such as failure to follow procedures.
11.7
Interfaces
Human
machine
and communication
operator
maintenance/engineering
communication
interfaces
to
interface(s):
interface(s):
interface(s),
11.7.1
Operator
11 .~.l.1
be taken
interface
requirements
account
shall
11.7.1.2
The design of the S!S shall minimize the need for operator selection of options and
the need to bypass the system while the unit is running.
If the design does require the use of
operator actions, the design should include facilities
for protection
against operator error.
NOTE
If the operator
has to select
a part~cular
11.7.1.3
Bypass
switches
unauthorized
use.
shall
option,
be
there
should
protected
by
be a repeat
key
locks
confirmation
or
11.7.1.4
The S1S status information
that +s critical to maintaining
as part of the operator interface.
This information
may include
where
indication
that
indication
that a protective
indication
occurred;
that automatic
status
the process
failure
passwords
to
prevent
be available
in its sequence:
S1S protective
of sensors
the results
IS
step
action
has occurred:
function
action(s)
is bypassed;
such as degradation
of voting
and/or
fault
handling
has
that energy
loss impacts
safety:
of diagnostics;
of environmental
conditioning
equipment
44
which
is necessary
to support
the SI. S
lS/lEC
61511-1:2003
11,7.4.5
The S1S operator
interface
design shall be such as to prevent changes
to S1S
application
software. Where safety information
needs to be transmitted
from the BPCS to the
S1S. then systems
should be used which can selectively
allow writing from the BPCS to
specific S1S variables,
Equipment
or procedures
should be applied to confirm that the proper
selection
has been transmitted
and received by the SIS and does not compromise
the safety
functionality
of the SIS
NOTE 1 If tk, e options
or bypasses
are
selected
in the
BPCS and downloaded to the S1S then failures in the BPCS
may interfere with the ab!llty of the S1S to operate on demand If this can occur then the BPCS will become safety
related
NOTE 2 In batch processes an S1S may be used to select different set points or logic functions depending
recipe be~ng used In these cases the operator interface may be used to make the required selection.
NOTE 3
11.7.2
Maintenance/engineering
interface
on the
requirements
11 .7.2.1
The design of PE SIS maintenance/engineering
interface
shall ensure that any
failure of this interface shall not adversely affect the ability of the SIS to bring the process to a
safe state. This may require disconnecting
of maintenance/engineering
interfaces,
such as
programming
panels, during normal SIS operation.
11.7.2.2
The maintenance/engineering
access security protection to each
S1S operating
mode,
bypass, maintenance:
S1S diagnostic,
add, delete,
data necessary
voting
or modify
program,
interface
data,
to troubleshoot
of
provide
disabling
the
following
alarm
functions
with
communication,
test,
services;
software:
the S1S,
where bypasses
are required
they
shutdown facilities are not disabled,
NOTE
means
shall
should
be installed
such
that
alarms
and
manual
11.7.2.3
The maintenance/engineering
interface
11.7.2.4
Enabling
and disabling
the read-write
access
shall be carried
configuration
or programming
process
using the maintenance/engineering
appropriate
documentation
and security measures.
11.7.3
Communication
interface
interface.
out only
interface
by a
with
requirements
11.7.3.1
The design of the S1S 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.
11.7.3.2
The S1S shall
Impact on the SIF
11.7.3.3
magnetic
be able
The communication
interference
including
to communicate
An alternate
rnedlum
the
BPCS
and
peripherals
with
no
interface
shall be sufficiently
robust to withstand
electropower surges without causing a dangerous
failure of the SIF.
11 ,7.3.4
The communication
interface
referenced
to different electrical
ground
NOTE
with
(for example,
shall be suitable
potentials.
fibre optIcs
may be required)
45
for communication
between
devices
Maintenance
51 .8.1
or testing
The design
shall
allow
design
requirements
interval
between
scheduled
process
facilities
are required
$ine testing
The term end-to-end
NOTE
11.8.2
When
on-line
proof testing
IS required,
design to test for undetected
failures
SIS
11 .8.3
When
the following.
.
test
and/or
bypass
facl:lties
are
test
11.8.4
Forcing
of inputs
and outputs
application
software;
operating
procedure(s);
maintenance,
except
as noted
SIF probability
to the bypass
pr~cess
facilities
inciudr?d
@ The operator
shall be alerted
operating
procedure.
i~
flwd
shall
In the
el?d
be an integral
S1S.
maintenance
of any portion
at actuatlor?
they
and
shall
test!ng
the
on-
part
conform
of the
with
req!ulrements
and/or
below.
unless
or set
of failure
function
shall be
11.9.1
The probability
of failure on demand of each safety instrumented
equa! to, or less than, the target failure measbre
as spec!fied
in the safety requirement
specifications.
This shall be verified by calculation.
NOTE 1 In the case of safety Instrumented
functions
operating
In the demand mode of operation,
the target failure
measure
should be expressed
in terms of the average
pro bahllrty of failure
to perform
Its design function
on
demand, as determined
by the safety lntegrlty level of the safety lnSlrUmented
function (see Table 3)
NOTE 2 In the case of a safety Instrumented function operating In the continuous mode of operation the target
:ailure measure should be expressed [n terms of the frequency of a dangerous iallure per hour as determined by
the safety Integrity level of the safety Instrumented function {we Table 41
NOTE 3 It IS necessary to quantify the probability of failure separately for each safety Instrumented function
because different component failure modes could apply and tlIe architecture of the S1S (in ternis of redundancy]
may als~ vary.
11.9.2
The calculated
probability
of failure
hardware failures shall take into account
of the
SIS
as
It relates
value of avelage
probability
of failure
on demand
or
or :t, e spemfled
range associated
with the SIL If It has
of
each
a)
the architecture
consideration;
to
b)
the estimated
rate of failure of each subsystem
modes which would cause a dangerous
failure
d~agnostic tests:
each
safety
safety
instrumented
Instrumented
function
function
due
to
under
in any
by the
NOTE
The estimated
rates of failure of a subsystem
can be de!errnlned
by a quantified
failure-mode
analysis
of the design using component
or subsystem
failure data from a recognized
industry source or from experience
of the prewous use of the subsystem
in the same environment
as far the intended application,
and In which the
experience
IS sufficient
to demonstrate
the clalmect mean time to failure on a statistical
basis to a single-sidecl
lower corifldence
Ilrmf of a! leas: 70 A
the
susceptibility
tr~e
dtagnosilc
iEC
G151
of the
S1S, to common
coverage
1-2),
the
of
any
associated
cause
periodic
diagnostic
failures,
diagnostic
test
interval
tests
and
(determined
the
reliability
according
for
the
to
diagnostic
faciiiiles,
the
intervals
at which
the
repair
the
estimated
times
for
tests
detected
rate
would cause
tests):
proof
are
undertaken:
failures;
of dangerous
a dangerous
failure
failure
of any
communication
detected
the estimated
rate of dangerous
failure of any human response
In any modes which would
cause a dangerous
failure of the S1S (both detected and undetected
by diagnostic
tests)
the susceptibility
to EMC disturbances
the susceptibility
to climatic
IEC 60654-1
and !EC 60654-3)
and
(for example,
mechanical
NOTE 1 Modell\ng
me!kocls are available
and the mo:t
dcnend on the clrcu; nst:~nces Available
methods include
according
conditions
to IEC 61326-1).
(for
example,
appropriate
method IS a matter
(see IFC 61508-6, Annex B)
according
to
and should
slrr7ulation
cause
consequence
fau!t-!ree
analysls
ana!ysis,
F,la!kov models
rellablllty
NOTF, 2
restolatlon
12
t>lock cflagrants
The diagnostic
test Interval and the subsequent
(see IEV 191-i 3-{)8) which should be considered
Requirements
for
for utility
software
This clause
software,
including
together
model
constitute
selection
the
mean
time
for
:
criteria
recognizes
three types
of software
application
utility software,
software;
application
software,
embedded
three types
i e., the
software,
of software
fixed
program
limited
full variability
tools
languages
variability
software
supplied
to develop
and
verify
the
application
language.
(FPL):
languages
languages
used
(LVL);
(FVL).
This standard
is limited to application
software developed
using FPL or LVL. The following
requirements
are suitable for the development
and modification
of application
software
up to
SIL 3 Therefore,
this standard does not differentiate
between SIL 1, 2 and 3.
47
ISKC
61511-1:2003
The development
comply with this
shall comply with
FVL shall comply
and modification
of application
software using
standard.
The development
and modification
IEC 61508. The development
and modification
with IEC 61508.
Utility software
(together
with the manufacturer
safety manual which defines
how the PE
system
can be safely
applied)
shall be selected
and applied
in conformance
with the
requirements
of 12.4.4. The selection of embedded
software shall comply with 11.5,
t2.1
Application
12.1.1
software
safety
life-cycle
requirements
Objectives
12.1 .1.1
The objectives
of this clause
are:
to define
application
required
how to select,
software;
to develop
control,
and
the application
apply
the
so that
utility
software
for each
programmed
software
used
develop
the functional
safety
to
objectives
allocated
NOTE Figure 10 illustrates the scope of clause 12 within the application safety life cycle
S1S safety
requirements
specification
0 S1Ssubsystem*
architecture
I
Hardwaresafetyrequirements
Programmable Non-programmable
hardware
electronichardware
*
Non-programmable
T
hardwaredesign
Programmable anddevelopment
electronicsaelectior
Scope of
clause 12
software
I
+ + +
r ApplicationSIW ,
safety
requirements
12.2
L
ApplicationSAN
designand
configuration
12.4
Programmable
electronics
integration
12.5
Figure
10-
Application
S1Sinstallation
and validation
48
the
~
lS/lEC
12.1.2
61511-1:2003
Requirements
12.1 .2.1
A safety life cycle for the development
of application
software
which satisfies
requirements
of this clause shall be specified
during safety planning and integrated
with
S1S safety life cycle.
12.1 .2.2
Each phase of the application
software safety life cycle shall be defined
its elementary
activities,
objectives,
required input information
and output results,
requirements
(see 12.7) and responsibilities
(see Table 7 and Figure 1 1).
the
the
in terms of
verification
NOTE 1 Provided
that the application
software
safety
life cycle satisfies
the requirements
of Table 7. It is
acceptable
to tailor the depth, number and size of the phases of the V-model (see Figure 12) to take account of the
safety Integrity and the complexity
of the project
NOTE 2 The type
aPPljcatlon
func!lons
of software
may Impact
language
the scope
software
safety
NOTE 4
validation
software
validation
The application
plan
12.1.2.3
The
safety integrity
techniques
minimize
reveal
ensure
ensure
demonstrate
safety
and remove
may
may
be Included
as part
faults
tools
faults
that already
remaining
shall
be selected
of the
as part
of the overall
and
language
shall
to the
be suitable
applied
for
each
for the
life-cycle
software:
throughout
results:
of the S1S:
quality.
depend
upon
the specific
circumstances,
The factors
In
of complexity.
integrity
of stand ard!zatlon
of failure
of design
in the software
and techmques
be included
software
can be maintained
closeness
of software:
consequence
degree
and
NOTE
The selectlon
of methods
this declslon are likely to Include
degree
plan
the
specifications
12.1.2.4
Methods,
phase so as to
amount
requirements
and
elements
12.1.2.5
Each phase of the application
software safety
and the results shall be available (see Clause 19).
life cycle
shall
be verified
(see
12.7)
12.1.2.6
If at any stage of the application
software
safety life cycle, a change is required
pertaining
to an earner life-cycle
phase. then that earlier safety life-cycle
phase and the
followlng phases shall be re-examined
and. if changes are required, repeated and re-verified
12.1.2.7
Application
software, the S1S hardware and embedded
(tools) shall be subject to configuration
management
(see 52.7)
49
software
and utlllty
software
W!EC 61511-1:2003
fi2.1 .2.8
Test planning
the policy
test cases
types
test environment
test criteria
physical
dependence
appropriate
nonconformances.
shall be carried
for integration
of software
issues
should
be addressed:
and hardware;
of tests
to be performed;
including
on which
location(s)
tools,
support
the completion
(for example,
on external
software
and configuration
description;
factory
or site);
functionality;
personnel;
Software
safety
life-cycle
Box 4
in figure 8
1---1
Design and
engineering
of the safety
instrumented
system
Softwaredeeign,configurationandsimulation
t
To box 6 and 7
To
Figure
11 Application
software
i
box 5 in Figure 8
safety
50
in Figure 8
phase)
ISIIEC
S1S safety
requirements
~~pecification
/-
* [AH&%&
[EE!!l
Val:;ted
I__
{
requirements
specification
l
_--___.
___ -----
_------
_._.
>
iApplication software
I arctlitecture design I
12.4.3, 12.4.4
./
(~cat!on
=
software
development
--~
12-
Software
PES
Application
software
integration
testing
12.5
L-_
1
-- --
*--------
+-d
~Apphcadon
module
deve10pnlcnt12 45,,1---I\__
...-. :
Figure
,*
-JJ
.-
++
>
S IS safety
validation
14.3
-)
61511-1:2003
~
7
Application
module
~
-.s6
A
Application
software
Testing 12.4.7
~:s~::L~ny;et
a=
+1 (see IEC r31508.3, 12.4.2.1)
+
._. __
development
life cycle
(the
V-model)
51
IWEC
61511-1:2003
Table
Safety
life-cycle
Figure
box
numbe
2.2
phase
Title
{application
;oftware
;afety
equirements
specification
7-
Application
software
safety
life cycle:
overview
I
Requirements
clause
Objectives
2.2.2
Information
required
Required
results
31S safety
equirements
specification
31S application
software
;afety requirements
specification
Safety manuals of
he selected SIS
/edification
information
t
51S architecture
23
application
;oftwa re
;afety
ralldation
IIanning
2.3.2
24
application
;oftware
Ieslgn and
~evelopment
Wchitecture
2.4.3
SIS application
;oftware safety
equirements
specification
>1S application
;afety validation
Verification
To create a software
~rchitecture
that fulfils
specified requirements
software safety
the
for
S1S application
joftware safety
equirements
;r)ecification
51S hardware
~rchitecture
design
nanuals
software
plan
information
description
of the
architecture
design, for
?xample, segregation
of
implication
S/W into
elated process subiystem and SIL(S), for
?xample, recognition
of
;ommon application
HW modules such as
Jump or valve
;eauences
Application
software
architecture
and subsystem integration
test
.sDecification
Application
software
design, and
~evelopment.
..
12.4.4
Verification
S1S application
software safety
requirements
specification
Verification
Description
architecture
information
List of procedures
for
use of utility software
information
of the
design
Safety manual of
the selected SIS
logic solver
52
.,
lS/lEC
Safety
life-cycle
igure
11
box
number
24
phase
Title
Appljcatlon
software
design. and
development
Requirements
clause
Objectives
124.5
Appllcatlon
software
development
and
application
module
development
10 implement
the
application
software
fulflls the speclfled
req Lllrement S for
application
safety
Information
required
Description
architecture
of the
design
that
61511-1:2003
Required
results
1) Application
software
program (for example,
function block diagrams,
ladder logic)
2) Application
program
simulation
and integration
test
3) Special purpose
application
software
safety requirements
specification
4) Verification
24
24
Appllcatlon
program
development
using full
varlablllty
languages
Appllcatlon
software
design and
development
Program development
test FVL only
and
To Implement
full varlablllty
language
that fulflls the
speclfled
requirements
for
software safety
Application
software
testing
1246
and
1247
Special purpose
application
software safety
requirements
speclflcatlon
Refer
12.4.6,
12.47,
127
Application
program simulation
and integration
test
specification
(structure
based
testing)
1) Software
information
to IEC 61508-3
test results
information
Software
architecture
integration
test
specification
123
Programmable electronlcs
integration
(hardware
and software)
To integrate
the software
onto the target
programmable
electronic
hardware
S1S safety
validation
Validate
that the SIS
including
the safety
application
software
meets
the safety requirements
125.2
Software and
hardware
integration
test
specification
Verified software
hardware
123
53
Software
validation
and SIS
results
and
lS/lEC
61511-1:2003
12.2
Application
software
safety
requirements
specification
11
Objective
12.2. I.1
The objective
of this clause is to provide requirements
for the specification
of the
application
software
safety requirements
for each programmable
S1S subsystem
necessary
to impiement
the required
safety instrumented
function(s)
consistent
with the architecture
of the S1S.
NOTE
See Figure
13 for hardware
and softwa~e
Programmable
Embedded
Examples
include
diagnostic
tests
redundant
processors
12.2.2
Relationship
An application
between
include
inputioutput
functions
~ -- fault handling
software
the hardware
and software
software
safety
requirernents
specification
architectures
of S1S
sensors
A software
functionality
may place
that
have
additional
already
safety requirements
specification
is required
to identify
and aiso to constrain
the selection
of any functionality
12.2.2.2
The input to the
subsystem
shaii include
safety
specification
a)
the specified
b)
the requirements
resuiting
c)
any requirements
of safety
This information
shaii be deveioped.
consists
of three architectural
subsystems:
sensors,
logic solver
could have redundant
devices to achieve the required integrity level.
2 An S1S hardware
architecture
with redundant
(for example,
implementation
of 1002 logic).
NOTE
Examples
software
Requirements
12.2.2.1
NOTE
solver
Application
software
include
executive
13-
architecture
- communications
drivers
Figure
relationship.
S1S subsystem
architectural
requirements
should
of the
software
safety
been
and
requirements
specified
final
elements.
the minimum
capabilities
of the PE
which would result in an unsafe
requirements
for
each
S1S
of the SiF;
(see Clause
be made available
and
5)
to the application
software
developer.
54
IS/lEC
61511-1:2003
12.2.2.3
The specification
of the requirements
for application
software
safety
shall be
suffi~!ently
detailed
to allow the design and implementation
to achieve the required
safety
Integrity and to allow an assessment
of functional
safety to be carried out. The following
shall
be cons~dered
e
the functions
supported
by the application
capac!ty
equipment
proof tests
elements)
software
se! f-mor?ltoring
range validation):
monitoring
enabling
references
architecture
and response
time performance,
and operator
and
interfaces
of operation
diagnostic
(for
testing
tests
of other devices
periodic
software:
variable
within
such
of external
example,
as specified
as sensor
devices
includes
(for
application
of safety
instrumented
value
driven
detected
sensors
and
final
watch-dogs
and
data
specification
requirements
requirement
out of range,
example,
sensors
functions
is operational;
or
in the specification
12.2.2.4
The application
software developer
shall review the information
to ensure that the requirements
are unambiguous,
consistent
and understandable.
Any
deficiencies
in the specified
safety requirements
shall be identified
to the S1S subsystem
developer.
12.2.2.5
The specified
In such a way that they
requirements
for software
safety
should
be expressed
and structured
are verifiable,
testable,
are traceable
12.2.2.6
allowlng
modifiable:
The application
proper equipment
functions
that enable
of the safety
requirements
of the S1S.
to achieve
or maintain
to the detection,
functions
related
to the periodic
testing
of safety
instrumented
functions
on-line;
functions
related
to the periodic
testing
of safety
instrumented
functions
off-line;
functions
Interfaces
capacity
the safety
to non-safety
and response
integrity
NOTE I Dependent
systen) software
NOTE 2
Interfaces
related
and management
of faults
in subsystems
modified,
functions,
time performance
levels
on the properties
)Ilclucie
information
a safe state;
functions
related
of the S1S.
annunciation
provide
both of f-llne
of the selected
and omllne
S1S subsystem
modification
55
some
facilities,
of these
functions
61511-1:2003
lS/lEC
Application
12.3
This phase
NOTE
software
safety
validation
planning
11.
Objective
12.3.1
12.3.1.1
application
The objective
of the requirements
of this
software validation
planning is carried out.
clause
is
to
ensure
that
suitable
f
I
12.3.2
Requirements
12.3.2.1
Application
Clause 15.
12.4
Application
NOTE
This phase
12.4.1
12.4.1.1
software
specified
software
validation
planning
shall
be carried
out
in accordance
with
I
software
design
and development
11.
Objectives
The first objective
of the requirements
of this clause is to create
architecture
that is consistent
with the hardware
architecture
and
requirements
for software safety (see 12,2).
an application
that fulfils the
12.4.1.2
The second objective
of the requirements
of this clause is to review and evaluate
the requirements
placed
on the software
by the hardware
and embedded
software
architecture
of the S1S. These include side-effects
of the SIS hardware/software
behaviour,
the application
specific configuration
of S1S hardware,
the inherent fault tolerance
of the SIS
and the interaction
of the S1S hardware
and embedded
software
architecture
with the
application
software for safety.
12.4.1.3
The third objective
of the requirements
of this clause is to select
tools (including
utility software) to develop the application
software,
a suitable
set of
12.4.1.4
The fourth objective
of the requirements
of this clause is to design and implement
or select application
software that fulfils the specified
requirements
for software
safety (see
12.2) that is analyzable,
verifiable
and capable of being safely modified.
12.4,1.5
The fifth
objective
of
requirements
for software
safety
functions)
have been achieved.
12.4.2
General
the
(in
requirements
terms of the
of this
required
clause
is to verify
that the
software
safety
instrumented
requirements
12.4.2.1
The development,
test, verification
and validation
application
program shall be in accordance
with IEC 61508-3.
12.4.2.2
The design method shall be consistent
given for the applied SIS subsystem,
NOTE
Restrictions on the application of the S1S subsystem
should be defined in the equipment safety manual.
12.4.2.3
features
a)
The selected
that facilitate
design
method
of the full
and application
necessary
to ensure
language
variability
tools
language
and restrictions
compliance
with
IEC
61511
possess
abstraction,
modularity
and other features
which control complexity;
wherever
possible,
the software
should be based on well-proven
software
modules that may include
user
Ii,brary functions
and well-defined
rules for linking the software modules;
56
lS/lEC 61511-1:2003
D)
expression
-
01
functionality,
ideally
as a logical
description
flow between
sequencing
requirements;
assurance
constraints;
freedom
assurance
that internal data items are not erroneously
duplicated,
all used
are defined and appropriate
action occurs when data is out of range or bad;
design
safety
instrumented
from indeterminate
assumptions
elements
operate
within
the defined
time
data types
d)
verification
and validation,
including coverage
coverage
of the integrated
application,
the
specific hardware configuration;
e)
application
software
documentation.
by developers
and others who need to understand
the design, both from
functional
understanding
and from a knowledge
of the constraints
of the
The design
include
always
functions;
behaviour;
comprehension
an application
technology;
12.4.2.4
of the application
functions
c)
a)
functions;
information
that
modular
or as algorithmic
modification.
achieved
data integrity
checks
Such
of the application
software code, functional
interface
with the S1S and its application
features
include
modularity,
traceability
and
shall
and reasonableness
checks;
NOTE For example, end-to-end checks in communications links, bounds checking on sensor inputs, bounds
checking on data parameters and diverse execu!ion of application functions.
b)
be traceable
c)
be testable;
d)
e)
to requirements;
software
to a minimum.
*
12.4.2.5
Where the application
software
is to implement
safety instrumented
functions
of
different safety integrity levels or non-safety
functions,
then all of the software shall be treated
as belonging
to the highest safety integrity
level, unless independence
between the safety
instrumented
functions of the different safety integrity levels can be shown in the design. The
justification
for independence
shall be documented.
Whether independence
is claimed or not,
the intended SIL of each SIF shall be identified.
NOTE 1 IEC 61511-2 provides guidance
on how to design and develop the application
and non-safety
instrumented
functions
are to be implemented
in the S1S.
NOTE 2 IEC 61511-2
provides
guidance
on how to design
different SIL are to be implemented
in the SIS.
and
develop
the
software
application
when
software
both safety
when
SIF of
12.4.2.6
If previously
developed
application
software library functions
are to be used as part
of the design, their suitability
in satisfying
the specification
of requirements
for application
software safety (see 12.2) shall be justified.
Suitability
shall be based upon
compliance
to IEC 61508-3
compliance
to
evidence of satisfactory
operation
in a similar application
which has been demonstrated
and validation
have similar functionality
or having been subject to the same verification
software
(see 11.5.4 and
procedures
as would be expected
for any newly developed
11.5,5).
NOTE
The Justification
when
may be developed
using
using
during
FVL; or
FPL or LVL; or
safety
planning
57
(see Clause
6).
IWEC
61511-1:2003
12.4.2.7
program
As a minimum,
the following
information
documentation
or related documentation:
aj
legal entity
b)
description;
c)
traceability
d)
logic conventions
e)
standard
f)
inputs
g)
configuration
12.4.3
(for example
company,
to application
functional
shall
be contained
in the
application
author(s));
requirements;
used;
library
functions
and outputs;
used;
and
management
Requirements
including
a history
for application
of changes
software
architecture
f12.4.3.l
The design of the application
software
architecture
shall be based on the required
S1S safety specification
within the constraints
of the system architecture
of the S1S. [t shail
comply
with the requirements
of the selected
subsystem
design,
its tool set and safety
manual,
NOTE 1
software,
Examples
Examp\es
The software
architecture
defines
the major components
and subsystems
of system
and application
how they are interconnected,
and how the required
attributes,
particularly
safety integrity,
are achieved.
of system
software
modules
include
operating
systems,
databases,
communication
subsystems.
of application
software modules Include application
functions which are replicated
throughout
the plant.
12.4.3.2
The description
should
of the application
a)
provide a comprehensive
description
S1S subsystem
and of its components;
b)
c)
identify
d)
describe
systems
e)
identify
the software
architecture
of the internal
design
structure
all non-SIF
methods
the predictability
the fault tolerance
modules
included
and ensure
importance
and techniques
of the behaviour
(consistent
architecture
and techniques
for their choice
should
the proper
documentation
of the S1S
shall
of all identified
components,
and the description
identified components
(software and hardware);
12.4.3.3
The set of methods
be identified and the rationale
These
software
by the underlying
of the
of connections
NOTE
It is of particular
to the S1S subsystem.
NOTE
also be determined
to the input/output
subimposed by scan times;
operation
is up to date
of any SIF.
and complete
with
software
respect
should
aim at ensuring
and fault
avoidance,
including
redundancy
and diversity,
12.4.3.4
The methods and techniques
used in the design of the application
software
be consistent with any constraints
identified
in the S1S subsystem safety manual.
12.4.3.5
The features used for maintaining
the safety
and justified.
Such data may include plant input-output
data, maintenance
data and internal database data.
NOTE
There will be iteration
between
the hardware
therefore
a need to discuss with the hardware developer
the programmable
electronics
hardware and the software
58
should
and software
architecture
(see Figure
11) and there
such issues as the test specification
for the integration
(see 12.5).
is
of
Requirements
12.4,4.1
language,
automatic
for support
tools,
A suitable
set of tools,
configuration
management,
test coverage measurement
12.4.4.2
The availability
of suitable
development)
to supply the relevant
considered.
user
manual
and application
languages
including
a sub-set
of the application
programming
simulation,
test harness tooIs, and, when applicable,
tools, shall be selected.
tools (not necessarily
those used during initial system
services
over the whole lifetime of the SIS should be
NOTE
The selection
of development
tools should depend
activities,
embedded
software and the software architecture
on the nature
(see 12.4.3).
of the application
software
development
12.4.4.3
A suitable
set of procedures
for use of the tools should be identified,
taking into
account
safety
manual constraints,
known yveaknesses
likely to introduce
faults
into the
application
software and any limitations
on the coverage of earlier verification
and validation.
12.4.4.4
The application
language
selected
be implemented
for purpose;
be completely
contain
features
that facilitate
support
features
shall
using a translator/compiler
and unambiguously
defined
or restricted
to establish
to unambiguously
defined
its fitness
features;
of the application;
the detection
of programming
mistakes;
and
method.
12.4.4.5
When 12.4.4,4 cannot be satisfied,
then a justification
be documented
during application
software
architecture
design
justification
shall detail the fitness for purpose of the language,
which address any identified shortcomings
of the language.
12.4.4.6
The
procedures
for use of the application
language
should specify
good
programming
practice,
proscribe
unsafe generic software
features
(for example,
undefined
language features,
unstructured
designs),
identify checks to detect faults in the configuration
and specify procedures
for documentation
of the application
program.
12.4.4.7
The safety
manual
a)
use of diagnostics
b)
list of certified/verified
c)
mandatory
d)
use of watchdogs;
e)
requirements
f)
safety
12.4.4.8
shall address
to perform
safety
libraries;
shutdown
The suitability
of the tools
the device
shall
Requirements
for application
12.4.5.1
software
The following
design:
information
the specification
of software
logic;
12.4.5
a)
items as appropriate:
safe functions;
integrity
the following
is suitable
be verified.
software
shall
safety
or system
languages;
development
be available
requirements
59
(see 12.2);
application
lS/lEC 61511-1:2003
b)
the description
of the application
software
architecture
design
(see 12.4.3)
including
identification
of the application
logic and fault tolerant
functionality,
a list of input and
output
data, the generic
software
modules
and support
tools to be used and the
procedures
for programming
the application
software.
12.4.5.2
The application
modularity
testability
the capacity
traceability
NOTE
software
should
be produced
in a structured
way to achieve
of functionality;
of functionality
(including
fault tolerant
features)
and of internal
structure;
of, application
functions
and associated
constraints.
12.4.5.3
The design
plausibility
input data;
of each application
checks
of each
full definition
system
configuration
hardware and software
input
module
variable
The application
checks
including
modules,
software
be readable,
understandable
satisfy
the relevant
design
satisfy
the relevant
requirements
including
any
robustness
global
including
variables
used
to provide
interfaces;
shall address
the
existence
software
module
shall be specified.
and
accessibility
and
the
of
structural
expected
tests
to
be
should
and testable;
principles;
specified
during
safety
planning
12.4.5.6
The application
software shall be reviewed to ensure conformance
to the specified
design, the design principles,
and the requirements
of safety validation
planning.
NOTE
Application
software
review includes
such techniques
as software
inspections,
walk-throughs,
and formal
analysis.
It should be used in conjunction
with simulation
and testing to provide assurance
that the application
software
satisfies its associated
specification.
Requirements
12.4.6
for application
software
module
testing
NOTE
Testing that the applicatio,~
software
module correctly
satisfies
its specification
is a verification
activity
(see also 12.7). It is the combination
of review and structural
testing that provides
assurance
that an application
software
module satisfies its associated
specification,
i.e., it is verified.
12.4.6.1
point
The
shall
be
configuration
checked
of
through
each
input
review,
to the correct
point
through
simulation
application
and
the
testing
processing
techniques
logic
to
be suitable
for the
specific
exercising
exercising
data boundaries;
the
output
that
the
logic.
12.4.6.2
Each application
software module shall be checked through review,
testing
techniques
to determine
that the intended
function
is correctly
unintended
functions are not executed.
The tests shall
considered:
to
confirm
module
model;
60
being
tested
simulation
executed
shall
and
and
be
lS/lEC 61511-1:2003
timing
proper
12.4.6.3
effects
sequence
implementation.
The results
12.4.7
of the application
Requirements
NOTE
Testing
of execution;
software
for application
is correctly
module
software
integrated
testing
integration
is a verification
shall
be available.
testing
activity
(see also
12.7).
12.4.7.1
The application
software tests shall show that all application
software modules and
components/subsystems
interact correctly with each other and with the underlying
embedded
software to perform their intended function,
NOTE
Tests should also be carried
jeopardize
its safety requirements.
12.4.7.2
out to confirm
b)
whether
If there
software
integration
testing
and criteria
all software
b)
the necessary
12.5
the reasons
modules
impacted;
re-design
Integration
NOTE
unintended
shall be available
functions
that
modification
to the
software
shall
be
and
and re-verification
of the application
be reported
12.4.7.3
During application
software
integration,
any
subject to a safety impact analysis that shall determine:
a)
not perform
and
the objectives
is a failure,
does
a)
activities
software
(see
12.6).
11.
Objective
12.5.1
12.5.1.1
The objective
of this clause is to demonstrate
that the application
its software
safety requirements
specification
when running on the hardware
software used in the S1S subsystem.
NOTE
Depending
12.5.2
these activities
may be combined
software
meets
and embedded
with 12.4.7
Requirements
12.5.2.1
Integration tests shall be specified as early in the software safety life cycle as
possible to ensure the compatibility
of the application
software with the hardware
and
embedded
software platform such that the functional and performance
safety requirements
can be met,
NOTE
NOTE
software
based on previous
into manageable
experience.
integration
tools, configuration
for corrective
and programs;
of the test will be judged;
61
and
sets;
lS/lEC 61511-1:2003
12.5.2.2
During testing,
any
which shall determine
analysis
a)
ail software
b)
the necessary
t2.5.2.3
modules
modification
impacted;
re-verification
The following
or change
activities
test information
under
b)
~onfiguration
items
supporting
c)
personnel
involved;
d)
test cases
e)
f)
whether
9)
test;
functionality);
the objective
and criteria
applies
primarily
of the tests
modification
procedures
The objective
of the requirements
of this clause is to ensure that the
to meet the software safety requirements
specification
after modifications.
12.6.2
Modification
a)
Prior to modification
process
and
on the
the modification
b)
Safety
c)
Modifications
and
d)
The
for conditions
e)
All documentation
f)
Details
planning
planning
for the
be carried
Application
out in accordance
with
5.2.6.2.2,
5.2.7
and Clause
requirements,
an analysis
of the effects
of the modification
on the safety
of the
software
design
status
shall
be carried
out and used
to direct
modification
re-verifications
affected
software
and re-verification
shall
required
by the
be carried
during
shall
be available.
out in accordance
modification
modification
activities
shall
shall
and testing
with
the planning.
shall
be considered.
be updated.
be available
(for
example,
a log).
verification
Objectives
12.7.1.1
The
satisfactory.
first
objective
of
this
clause
is
to
demonstrate
that
the
information
12.7.1.2
The second objective
of this clause is to demonstrate
that the output results
the defined requirements
at each phase of the application
software safety life cycle.
12.7.2
software
requirements
12.6.2.1
Modifications
shall
17 with the following
additional
12.7.1
and external
Objective
12.6.1,1
continues
12.7
test (tools
12.6.1
impact
shall be available:
items
Modiftcatlon
to a safety
(see 12.7).
configuration
NOTE
be subject
and
a)
42.6
shall
satisfy
Requirements
12.7.2.1
Verification
planning shall be carried out for each
life cycle in accordance
with Clause 7.
62
phase
of the application
is
software
lS/lEC 61511-1:2003
fi2.7.2.2
The results
of each phase
a)
the adequacy
of the outputs
for that phase;
b)
the adequacy
c)
compatibility
d)
correctness
12.7.2.3
testability;
b)
readability;
c)
traceability.
1
between
outputs
and/or
generated
for
life-cycle
testing
at different
phase
coverage
against
the requirements
of the outputs;
life-cycle
phases;
of the data.
Verification
a)
NOTE
of the review,
shall be verified
Data format
should
also address
in the application
program
should
be verified
for
completeness;
self-consistency;
protection
against
consistency
NOTE 2
unauthorized
alteration;
Application
consistency
requirements.
data should
be verified
for
completeness;
compatibility
correct
within
a known
3 Modifiable
invalid
system
software
(for example,
sequence
of execution,
run-time);
data values;
operation
NOTE
parameters
of undefined
erroneous
safe boundary.
initial
should
be verified
for protection
against
values;
values;
unauthorized
changes;
data corruption.
NOTE 4 Communications,
-
failure
process
interfaces
and associated
software
should
be verified
for
detection;
protection
against
message
corruption,
and
data validation.
12.7.2.4 Non-safety
and functions should
non-interference
protection
non-safety
13
Factory
functions
be verified
and process
for
against interference
functions.
acceptance
NOTE
This clause
13.1
Objectives
testing
interfaces
integrated
with
safety
related
signals
functions;
with the safety
functions
in the case
of malfunction
of the
(FAT)
is informative.
13.1.1
The objective
of a factory
acceptance
test (FAT) is to test the logic solver and
associated
software
together
to ensure it satisfies
the requirements
defined
in the safety
requirement
specification.
By testing
the logic solver
and associated
software
prior to
installing in a plant, errors can be readily identified and corrected.
63
61511-1:2003
lS/lEC
NOTE
The
validation
factory
acceptance
13.2
Recommendations
13.2.1
The
test
need
between
follow
NOTE
are applicable
is sometimes
The activities
referred
be specified
the design
during
supplier
and development
an
integration
the design
and design
phases
to the subsystems
test
phase
contractor
and precede
and
can
13.2.2
The planning
specify
environment
prior
be
part
of the
in order
to
of a project.
may be required
the installation
and
NOTE 4
the plant.
to as
to Installation
electronics.
and commissioning
in
the following
Test cases,
test description
NOTE
It is very important to make clear who is responsible for developing
be responsible for carrying out the test and witnessing the test.
Dependence
on other
Test environment
Logic solver
configuration.
Test criteria
on which
Procedures
for corrective
Test personnel
Physical
systems/interfaces.
and tools.
the completion
action
on failure
of test.
competence.
location.
NOTE
For tests that cannot be physically demonstrated,
these are normally
why the S1S achieves the requirement, target or constraint.
13.2.3
13.2.4
should
13.2.5
FAT should
place on a defined
the version
the safety
the detailed
a chronological
the tools,
a)
take
version
function
test procedures
record
equipment
The results
should
with
by a formal argument
the
FAT
planning.
!
be addressed:
being used;
and performance
characteristic
of FAT should
resolved
used.
be documented,
64
as to
13.2.6
stating
being tested;
These
tests
lS/lEC 61511-1:2003
b)
c)
whether
and
the objectives
and criteria
If there is a failure during test, the reasons for the failure should
and the appropriate
corrective
action should be implemented.
13.2.7
During
determine
FAT,
any modification
or change
a)
the extent
of impact
on each safety
b)
the extent
of re-test
which
NOTE
Commissioning
should
may commence
should
instrumented
be defined
whilst
corrective
be documented
be subject
and analysed
to a safety
analysis
and
function;
and implemented.
action
is undertaken,
I
depending
on the results
of the FAT.
14
S1S installation
14.1
and
commissioning
Objectives
44.1.1
The objectives
install
commission
14.2
the safety
of the requirements
instrumented
the safety
system
instrumented
of this clause
according
system
are to
to the specifications
and drawings;
validation.
Requirements
14.2.1
Installation
and commissioning
planning
shall
installation
and commissioning.
The planning shall-provide
the installation
and commissioning
the procedures,
when these
the persons,
measures
activities
define
all activities
the following:
required
for
activities;
and techniques
and commissioning;
departments
and organizations
Installation
and commissioning
where appropriate.
planning
responsible
may
be integrated
14.2.2
All safety instrumented
system components
the design and installation
plan(s) (see 14.2.1).
shall
for these
in the
be properly
activities.
overall
project
installed
planning
according
to
14.2.3
The safety instrumented
system shall be commissioned
in accordance
with @arming
in preparation
for the final system validation.
Commissioning
activities
shall include, but not
be limited to, confirmation
of the following:
earthing
(grounding)
energy
transportation
no physical
all instruments
logic solver
the interfaces
sources
damage
connected;
connected
materials
is present;
calibrated;
are operational;
and input/outputs
to other systems
are operational;
and peripherals
65
are operational.
ISIIEC
61511-1:2003
14.2.4
Appropriate
records of the commissioning
of the S1S shall be produced,
test results and whether the objectives
and criteria identified
during the design
been met. If there is a failure, the reasons for the failure shall be recorded.
stating the
phase have
14.2.5
Where it has been established
that the actual installation
does not conform
to the
design information
then the difference
shall be evaluated
by a competent
person and the
likely impact on safety determined.
If it is established
that the difference
has no impact on
safety, then the design information
shall be updated to as-built
status. If the difference
has a
negative
impact
on safety,
then the installation
shall be modified
to meet the design
requirements.
15
S1S safety
15.1
validation
Objective
This is sometimes
15.2
Requirements
15.2.1
Validation
following
referred
to as a site acceptance
The validation
activities
including
respect
to the safety
requirements
resulting
recommendations,
Validation
including
of ail relevant
preparation
start-up,
re-setting,
reasonably
foreseeable
risk analysis phase;
manual,
shutdown,
the procedures,
when these
the persons,
independence
reference to information
and effect chart).
Examples
of operation
automatic,
setting
15.2.2
Additional
following.
semi-automatic,
steady
abnormal
conditions,
and techniques
against
activities
validation
equipment
state of operation;
for example,
which
include
planning
validation
loop
for
responsible
testing,
the
safety
Information
on the technical
and automated
and dynamic
those
identified
through
the
b)
static
system(s)
with
and resolution
of
Identification
of the safety software which needs
operation
before commissioning
commences.
The
and adjustment;
a)
manua!
for validation.
the safety
instrumented
including
implementation
of the process
departments
and organizations
for validation
activities;
of validation
of
required
maintenance;
measures
activities
all activities
validation
specification
modes
NOTE
software.
test (SAT)
strategy
shall
techniques;
66
be carried
calibration
activities
to be validated
including
and levels
procedures,
application
techniques;
for these
simulation
software
for each
shall
of
cause
of application
include
the
mode of process
WEC
analytical
and statistical
61511-1:2003
techniques,
c)
In accordance
with b), the measures
(techniques)
and procedures
that shall be used for
the
specified
confirming
that
each
safety
instrumented
function
conforms
with
requirements
for the software safety instrumented
functions
(see 12.2) and the specified
requirements
for software safety integrity (see 12,2).
d)
The required
for
e)
tests
The
environment
would include
pass/falI
criteria
I the required
the anticipated
other
the validation
calibrated
and
output
acceptance
policies
in which
tools
for accomplishing
process
The
f)
this
criteria,
and
with
procedures
for
validation
input
signals
their
sequences
for example,
(for example,
equipment).
software
operator
signals
activities
and
memory
evaluation
the
with
including:
their
and
usage,
sequences
their
values;
timing
results
and
the
values;
and
and value
of
their
tolerances.
validation,
particularly
failures.
NOTE
These
15.2.3
requirements
Where
are based
measurement
on the general
accuracy
is
requirements
required
as
of 12.2.
part
of
the
validation
then
instruments
a specification
traceable
to a standard
If such a calibration
is not feasible,
an
15.2.4
The validation
of the safety
instrumented
system
and
its associated
safety
instrumented
functions
shall be carried out in accordance
with the safety instrumented
system
validation
planning. Validation
activities
shall include, but not be limited to, the following:
confirmation
that adverse
interaction
of the basic
connected
systems do not affect the proper operation
logic
solver,
sensors,
requirement
specification,
(where
elements
perform
in
all redundant channels;
NOTE
If a factory acceptance
test (FAT) was performed
on the logic
may be taken for validation
of the Ioglc solver by the FAT.
safety
instrumented
confirmation
system
that
variable
values
the
(for
documentation
safety
instrumented
example,
the
proper
shutdown
the
safety
instrumented
is consistent
out
sequence
function
accordance
solver
with
performs
required)
as described
the
as
specified
the
the
in Clause
iristalled
and other
system;
with
with
(for
basic
safety
13, credit
system;
on
invalid
process
of range);
is activated;
system
provides
the
proper
annunciation
and
proper
operation
display;
8
computations
the
safety
requirement
that
are
included
instrumented
in the
system
safety
reset
instrumented
functions
system
perform
are
as
defined
specification;
bypass
functions
start-up
overrides
operate
correctly;
manual
shutdown
systems
operate
the
diagnostic
proof-test
operate
intervals
alarm
functions
correctly;
are
correctly;
documented
perform
in the
as
required;
67
maintenance
correct;
procedures;
in
the
safety
ISIIEC
61511-1:2003
confirmation
that the safety instrumented
system performs as required
on loss of utilities
(for example, electrical
power, air, hydraulics)
and confirmation
that, when the utilities are
restored. the safety instrumented
system returns to the desired state;
confirmation
that the EMC immunity,
(see 10.3), has been achieved.
as specified
in the safety
requirements
specification
15.2.5
The software
validation
shall
show
that all of the specified
software
safety
requirements
(see 12.2) are correctly
performed,
and the software
does not jeopardize
the
safety requirements
under S1S fault conditions
and in degraded
modes of operation
or by
executing
software
functionality
not defined
in the specification.
The information
of the
validation
activities
shall be available.
15.2.6
Appropriate
provides
information
of the results
the version
tools
the results
the version
the criteria
for acceptance
the version
any discrepancy
the analysis
made and the decisions
taken on whether
change request, in the case where discrepancies
occur.
and equipment
used,
planning
along
being
shall
be produced
which
used,
with calibration
reference
data:
of each test:
used;
of the integration
between
tests,
and software
expected
being tested:
and actual
results;
to continue
the
test
or
ssue
15.2.7
When discrepancies
occur between expected
and actual results, the analysi i made
and the decisions
taken on whether
to continue the validation
or to issue a change request
and return to an earlier part of the development
life cycle, shall be available
as part of the
results of the safety validation.
15.2.8
After the safety instrumented
being present, the following
activities
.
system validation
and
shall be carried out.
All forces
16
shall
shall
(for example,
be removed
S1S operation
16.1
valves
and
to the
and PE sensor
be set according
fluids)
prior
to the
identified
forces,
process
disabled
start-up
hazards
alarms)
requirements
shall be removed.
and if applicable
shall be removed.
maintenance
Objectives
16.1.1
The objectives
to ensure
operation
to operate
of the requirements
SIL of each
of this clause
safety
instrumented
68
are:
functional
function
safety
is maintained
is maintained.
during
lS/lEC 61511-1:2003
16.2
Requirements
16.2.1
Operation and maintenance
planning
carried out. It shall provide the following:
routine
and abnormal
operation
proof testing,
the procedures,
II
verification
of adherence
when these
activities
the persons,
preventive
maintenance
and techniques
to operations
shall take
departments
instrumented
shall
be
activities;
and maintenance
and maintenance;
procedures;
place;
and organizations
responsible
for these
activities.
16.2.2
Operation and maintenance
procedures shall be developed
relevant safety planning and shall provide the following:
the routine actions which need to be carried
safety of the S1S, for example,
adhering
determination;
system
activities;
and breakdown
measures
in accordance
with the
.
.
the information
Sls;
which
needs
to be maintained
the information
Sls;
which
needs
to be maintained
procedures
to be followed
procedures
procedures
for revalidation;
maintenance
procedures
requirements;
for tracking
maintenance
for reporting
procedures
for analysing
systematic
they understand
the S1S);
the hazard
on the
and tests
on the
when
faults
or failures
occur
in the
S1S,
performance
failures;
and
failures.
used
maintenance
16.2.4
Operators shall be trained
training shall ensure the following:
of audits
rates
include
procedures
16.2.3
Operation
procedures.
results
and demand
and repair;
reporting
Considerations
ensuring
calibrated
showing
failure
the maintenance
including
NOTE
on system
during
shall
proceed
maintenance
in
(trip points
activities
accordance
normal
with
is
properly
the
relevant
action
that is taken
these
bypasses
by
against;
the operation
be used;
of all bypass
switches
and under
the operation
these manual
what circumstances
and manual
start-up
activity
are to
and when
This
may include
expectation
when
on
system
activation
reset
of any
restart
diagnostic
is activated
16.2.5
Maintenance
personnel
performance of the S1S (hardware
and system
alarms
indicating
there
16.2.6
Discrepancies
between expected behaviour and actual
modifications
made such
analysed
and, where necessary,
maintained,
This shall include monitoring
the following:
the actions
the failures
of equipment
actual demand;
the cause
of the demands;
the cause
of false trips
NOTE
taken
1: is very
following
Important
analysed
This should
16.2.7
The
a demand
forming
operation
and
be taken
full
functional
on the system:
part
of the
not be confused
behaviour
that the
shall
between
expected
demands encountered
with monttorlng
maintenance
S1S established
procedures
may
during
routine
testing
behaviour
and actual
behavlour
during normal operation
require
revision,
if
or
are
necessary,
following
.
functional
tests
safety
on the
audits:
S1S.
16.2.8
Written proof-test
procedures
shall be developed
for every SIF to reveal
failures undetected
by diagnostics,
These written test procedures
shall describe
that is to be performed
and shall include
the correct
correct
logic action:
correct
alarms
NOTE
operation
The followlng
examination
failure
16.3
16.3.1
16.3.4.3
NOTE
different
and final
element;
and indications.
methods
and effect
centred
the undetected
failures
Proof
Proof
analysis:
maintenance.
testing
and inspection
testing
16.3.1.1
Periodic
proof
reveal undetected
faults
requirement
specification.
16.3.1.2
element
sensor
of fault trees.
mode
reliability
of each
dangerous
every step
shali be as decided
Different
parts of the S1S may require different
test Interval than the sensors or final elements
tesl
70
Intervals
the logic
(see 16.2.8) to
with the safety
solver
for example,
the logic
solver
may require
lS/lEC 61511-1:2003
16.3.1.4
Any
timely manner.
deficiencies
found
during
the
proof
testing
shall
be repaired
16.3.1.5
At some periodic interval (determined by the user), the frequency
re-evaluated
based on various factors including historical
test data,
hardware degradation, and software reliability.
in a safe
and
of testing shall be
plant experience,
16.3.1.6
allowed
changes
16.3.2
Inspection
Documentation
of proof tests
a)
description
b)
c)
d)
e)
results
17
who performed
performed;
the tests
and inspections;
unique identifier
of the system
number, and SIF number);
(for example,
tested
as-found
(for example,
and as-left
loop
number,
conditions),
Objectives
17.1.1
and inspections
completed
S1S modification
17.1
of the tests
and inspection
The objectives
of the requirements
of this clause
that modifications
to any safety instrumented
approved prior to making the change; and
to ensure that the required
made to the S1S.
safety
integrity
system
are:
are properly
planned,
despite
reviewed
and
of any changes
NOTE
Modifications
to the BPCS,
other equipment,
process
or operating
conditions
should
be reviewed
to
determine
whether they are such that the nature or frequency
of demands on the S1S will be affected.
Those having
an adverse
effect should
be considered
further
to determine
whether
the level of risk reduction
will still be
sufficient.
17.2
Requirements
17.2.1
Prior to carrying out any modification
to a safety
authorizing
and controlling
changes shall be in place.
17.2.2
The procedures
shall include a clear method
be done and the hazards which may be affected.
instrumented
of identifying
system,
procedures
and requesting
for
the work to
17.2.3
An analysis
shall be carried out to determine
the impact on functional
safety as a
result of the proposed modification.
When the analysis shows that the proposed
modification
will impact safety then there shall be a return to the first phase of the safety life cycle affected
by the modification.
71
i,
61511-1:2003
lS/lEC
Modification
17.2.4
activity
17.2.5
Appropriate
information
Information
shall include
a description
the reason
identified
an analysis
all approvals
tests used
required;
appropriate
17. 2.6
trained.
of the modification
be
maintained
authorization.
for
all
changes
to
the
S1S.
The
or change;
which
of the impact
required
to verify
of the modification
configuration
Modification
All affected
may be affected;
activity
on the S1S;
that
was properly
regard
18
S1S decommissioning
implemented
as
I
i
history;
the change
shall be performed
with
and appropriate
personnel
with
18.1
shall
proper
impacted
qualified
personnel
should be notified
parts
of the
S1S which
to the change.
Objectives
18.1.1
The objectives
of the requirements
active
to ensure
that
decommissioning
during
the required
activities.
safety
instrumented
functions
remain
operational
*?
18.2
Requirements
18.2.1
Prior to carrying
procedures
for authorizing
18.2.2
The procedures
be done and identifying
instrumented
and requesting
system,
the work to
18.2.3
An analysis shall be carried out on the impact on functional
safety as a result of the
proposed
decommissioning
activity. The assessment
shall include an update of the hazard
and risk assessment
sufficient to determine
the breadth and depth that subsequent
safety lifecycle phases shall need to be re-taken. The assessment
stlall also consider
functional
the impact
and facility
safety
during
the execution
of decommissioning
services.
of the decommissioning
a safety
instrumented
system
activities;
and
on adjacent
operating
units
18.2.4
The results of the impact analysis shall be used during safety planning to re-activate
the relevant requirements of this standard including re-verification and re-validation.
18.2.5
Decommissioning
72
lS/lEC 61511-1:2003
19
Information
19.1
and
documentation
requirements
Objectives
19.1.1
The objectives
of the requirements
to ensure
verification,
performed.
NOTE
in order
For examples
of documentation
structure,
could be available
or displays).
in different
forms
Annex
in order that
be effectively
(for example,
on paper,
that all
IEC 61506.
medium
i,
19.2
Requirements
19.2.1
The documentation
required
19.2.2
The documentation
should
describe
the installation,
be accurate:
be easy to understand;
be available
system
for which
by this standard
in an accessible
and
and maintainable
unique
shall
19.2.4
The documentation
19.2.5
The documentation
shall
be traceable
form.
19.2.3
The documentation
the different parts.
19.2.6
The documentation
to identify different versions
have
be available.
or equipment
it is intended;
shall
identities
so it shall
indicating
index
(version
of this standard.
numbers)
19.2.7
The documentation
shall be structured
to make it possible
information.
It shall be possible to identify the latest revision (version)
NOTE
The physical structure of the documentation
should vary depending
size of the system, Its complexity
and the organizational
requirements.
19.2.8
All relevant documentation
under the control of an appropriate
19.2,9
Current
documentation
a)
the results
of the hazard
b)
the equipment
requirements;
c)
the organization
d)
the procedures
e)
the modification
used
shall be revised,
information
control
pertaining
responsible
necessary
information
safety
to achieve
as defined
functions
functional
and maintain
in 17.2.5;
73
to make
it possible
to search for
of a document.
relevant
reviewed,
approved
and
be
shall be maintained:
instrumented
for maintaining
upon
amended,
scheme.
to the following
to reference
to the requirements
be possible
assumptions;
together
with
safety;
functional
safety
of the SIS;
its
safety
lS/lEC
f)
61511-1:2003
design,
NOTE
implementation
test
and validation
for Infornlatlon
14 af}ri 15
i*
74
lS/lEC 61511-1:2003
Annex A
(informative)
Differences
NOTE
This annex
It illustrates
between
IEC 61511
1
IEC 61511 has some differences
from IEC 61508, These differences
are discussed
in Clauses
A 1 and A.2 and are based on the comparison
of this version of IEC 61511 to IEC 61508.
A.1
Organizational
IEC 61508
differences
b
*
Comment
IEC 61511
Part 1
Part 1
Part 2
Part 1
Included
in IEC 61511-1
Part 3
Part 1
Included
in IEC 61511-1
Part 4
Part 1
Included
in IEC 61511-1
Part 5
Part 3
Included
in IEC 61511-3
Part 6
Part 7
IEC 61508-1,
Part 2
Guidelines
All parts
Informative
been combined
references
included
in each part as
annexes (where required)
I
4
Terminology
A.2
IEC 61508-4
E/E/PE
safety
related
system
Process
control
system
EUC
Safety
Comment
Sis
Sls
PES
function
Basic
IEC 61511-1
process control
system
Process
under
control)
Safety instrumented
function (SIF)
75
ISIIEC 61511-1:2003
Bibliography
IEC 60050(191):
1990, /nfermafiona/
ability and qua/ity of service
IEC 60050(351):
1998, /nfernationa/
IEC 60617-12:1997,
IEC 61131-3:1993,
IEC 61506:1997,
software
E/ectrotechnica/
Graphical
/3/ectrotechnica/
symbols
Programmable
Vocabulary
for diagrams
confro//ers
/ndustria/-process
Vocabulary
Chapter
- Part 3: Programming
measurement
and control
191: Depend-
contro/
logic elements
language
Documentation
of application
IEC 61508-1:1998,
Functions/
safety of e/ectrica/\e/ectronic/programmab/e
related systems - Part 1: General requirements
electronic
safety
I EC 61508-4:1998,
Functions/
safety of e/ectrica/le/ectronic/programmab/e
related systems Part 4. Definitions
and abbreviations
electronic
safety
IEC 61508-6:2000,
Functions/
safety of e/ectrica//e/ectronic@ogrammab/e
related systems - Part 6: Guidelines
on the application
of lEC 61508-2
IEC 61511-3, Functions/
safety - Safety
Part 3: Guidance for the determination
lEC/l SO 2382 (all parts),
lEC/lSO
2382-1:1993,
lEC/l SO Guide
51:1999,
ISO 9000:2000,
Quality
/formation
/formation
ISO 9000-3:1997,
Quality
for the application
of /S0
of computer software
Safety
instrumented
systems
of the required safety
technology
technology
aspects
management
sector
Vocabulary
Vocabulary
- Guidelines
systems
electronic
safety
and IEC 61508-3
Part 1: Fundamental/
-- Fundamentals
terms
in standards
and vocabulary
management
and quality assurance standards
- Part 3: Guidelines
9001:1994
to the development,
supply, installation
and maintenance
2 To be published
GMGIPN163
76
131Slf4D/2006-300
Copies
to connected
matters
of /ndian
marking
Standards
and quality
certification
of goods
in the country.
Copyrigh
61S has the copyright
form without
implementing
designations.
the standard,
of necessary details, such as symbols and sizes, type or grade
Enquiries relating to copyright be addressed to the Director (Publications), 61S.
Review
of hdian
Amendments
Standards
are issued
to standards
on the basis
of comments.
Standards
are
Amendments
Amendment
No.
Text Affected
.
BUREAU
OF INDIAN
STANDARDS
Headquarters:
Manak Bhavan, 9 13ahadur Shah Zafar Marg, New Delhi 110002
Telephones: 23230131, 23233375, 23239402
Website: www.bis.org.
in
Regionai Offices:
Telephones
Central :
23237617
{ 23233841
Eastern :
160022
23378499,
{ 23378626,
23378561
23379120
2603843
{ 2609285
22541216,
{ 22542519,
22541442
22542315
28329295, 28327858
{ 28327891,28327892
..
PRINTED
BY THE GENERAL
MANAGER,
NASHiK-422
006