Disclosure to Promote the Right To Information

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

The Right to Information, The Right to Live

Step Out From the Old to the New

Mazdoor Kisan Shakti Sangathan

Jawaharlal Nehru

IS/IEC 61511-1 (2003): Functional safety - Safety

instrumented systems for the process industry sector, Part
1: Frameworks, definitions, system, hardware and software
requirements [ETD 18: Industrial Process Measurement and
Control]

! $ ' +-
Satyanarayan Gangaram Pitroda

Invent a New India Using Knowledge

! > 0 B

BharthariNtiatakam

Knowledge is such a treasure which cannot be stolen

lS/lEC

ml

immb,-,+

61511-1:2003

m&md??+i-eRR&hid@

Indian Standard

FUNCTIONAL SAFETY SAFETY INSTRUMENTED

SYSTEMS FOR THE PROCESS INDUSTRY SECTOR

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

. ... .................. ............ ................... ....... ...... ......... ........................... 6

and definitions

3.1

Abbreviations

3.2

Definitions

...... ................................ .... ..... ...................................... ..... 7

.. ..... ............... .......... ... ................... .... .... ........ ............................. ...... 7

Conformance

to this International

Management

of functional

5.1

Objective

5,2

Requirements

Safety

Objective

6.2

Requirements

10

11

.. ... ... ............ ................................... .... ..... ..... ...... .............. ...............22
........ ......... .................... ....... ... .... ........................ .......... ....27

... ................. ............ .. ................ ... ..... .... .. ... ................... ..................27

.............. .... ................ ..................................... ... ...... ...................... ...............29

......... ... ................. .................................... ... ...... .................. ........ ...........29

hazard

and risk analysis

8.1

Objectives

8.2

Requirements

Allocation

........... ............................ ... ... .................... ...................3O

......... .............. ... ..................................... .... ...... ....................................3O

... ............... ................................... ...... ... ...... ....... .............................3O

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

on the basic process

requirements

10.1

S1S design

.4

layers ............ .... ... ......................... ................3l

specification

................... .. ... .... .....................................3l

integrity
control

level 4 .. .... ... .. ........... ...........................32

system

as a protection

layer ...............33

$!

............................... ... .... .......................................35

.......... ... ............ ............................ ............ ... .... ............... ............ ............35
requirements

..... ..... ......... ........................... ... .... .......................................35

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

of a fault ........ ........................... 38

....... ..... ...... ... .... ............................ ....... 39

and subsystems

. . ..

...... . ........

.... 40

..... ...................................................... ... ....... ...... .......... ....... ............. 43

.... ...... ................ .. ...... ............................. .... ....... ...... .............'' ............
ortestlng

design

requirements

44

.......... .... ....... .................................... 46

of failure .. .................. ............ ........... .... ....... ..... .......... ................... 46

,!,

*
*

.. .......... ................ ........... .. ......................... ... ... ........... ...... ....... ...............27

Objective

Process

..................... .... .... .......................................22

safety ....... ......... .. ...................... ... ............................... ...........22

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

FPL and LVL software

12.7

Application

software

acceptance

13,1

objectives

13.2

Recommendations

Objectives

14.2

Requirements

....47

.. ........................................54

... ... ... ............................................56

..... .. ........ .............. .......................... 56

with the S1S subsystem

procedures

..... ........................ 61

....................... .. ...........................62

....................... ...................... ................... ............62

(FAT) . ..................... ..... ............ .. ........................................ 63

............. .............. ............... ....... ........ .. .. .... ...... ......................... 64

.

............. ....... ..... ... ........ ............... ...... ......... .............65

..... ............................. .... .......... .. .... ....... .................. ........................ 65

validation

Objective

15.2

Requirements

................................... .............. ..... ....... .................................... ..... 66

............... ...... .................... ............. ...... .................................................. 66

...... ........... ................... ........... .... .................... ................................ 66

and maintenance

16.1

Objectives

16.2

Requirements

16.3

Proof testing

.... ............ ............ ... .... .................... .... ............. ............. 68

............. ......... ................ ....... .. ... ... .... .................................. .. ... ... ... ..... 68

S1S modificatio

.... .............................. ............ .... .. .......... ................................. ... ..... 69

and inspection

............. ......... ...... ... ................................................... 70

n ......... ... .............. ....... ......... .. ......... ..... ................................... ................ 71

17.1

Objective

17.2

Requirements

... ... .... ............ ................ ............... .. ...................... ............................ 71

.. ..... .......... ........... .... ................ .... ....................... ............. .............. 71

SISdecommissioning

. ...... ........ ............ ..... ...... ........ ........ ......... .......... ................. ...........72
.... ...... ......... .. ... ............... .... ...... ...... ... .... ....................... ...................... 72

Requirements

Information

software

........ .. ............................. ............ .... ..... .......... .. ... ................ .... ............. 65

15.1

18.2

verification

for utility

..... .. ........................... ............. 48

specification

planning

software

and commissioning

14.1

S1S operation

requirements

criteria

.............. ......................... ............ ..... ............. ......................... ............. 63

S1S installation

S1S safety

selection

and development

modification

testing

18. 1 Objectives
19

software,

12.1

Factory

14

for application

..... .... ..... .................... ............... .... .................... ...................... ........ 72

and documentation

19.1

Objectives

19.2

Requirements

requirements

......... .... ..... .................................... .. ......... 73

............ .......................... ............... ... .................................................... 73

... ... ............... ........... .. ............ ...... ........... ........................................ 73

Annex

A (informative)

Differences

Figure

1 .Overall

Figure

2 - Relationship

between

IEC 61511

and IEC 61508 ...... ......... .................... .. ............

Figure

3-

Relationship

between

IEC 61511

and IEC 61508

Figure

4 Relationship

between

safety

Figure

5-

between

system,

Figure

6 Programmable

Figure

7-

Example

Figure

8-

S1S safety

Figure

9 -Typical

framework

Relationship

.. ................ .. ............ ....... ..................................... ............75

of this standard

electronic

SISarchitecture
life-cycle

risk reduction

.............. .... .................... ................. ............... vii

instrumented
hardware,

system

(PES):

(see 1.2) ...................... ............

functions

and other functions

and software
structure

........... ..

of IEC 61511 -1 ................ 6

and terminology

..... ........ .. ...... 15

.................. ......... .... ... ....... .... ............................ ........... 18

phases

and functional

methods

found

safety

in process

assessment
plants

stages .. ..... ..... .. .. . 25

............................ ........... 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

life cycle (in realization

life cycle (the V.modeI)

the hardware

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

life. cycle overview

hardware

............ ........ ................ .... .... .... ...5l

and software

Table

phase) .. ...... .. ............... ... .. ...5O

architectures

of SIS ......... ... ....54

l ......... ................... .. ..... .. ... ............. ............. .... .... . 7

............... ............. ......... .. .......... ......................... ... ...28

fault tolerance

on demand
failures

of PE logic solvers

........ ........................ .. ... ....32

of the SIF ...... ............ .. .....32
..,., ... ..... .......... ................ ....39

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

.. ........ ... ........ .......... ................. .. .... 52

*r

,..

Ill

IllIllII1...1. .1.,
,..._JJ

lS/lEC

. . -.
. . ...--.

61511-1:2003

Industrial Process Measurement

NATIONAL

and Control Sectional Committee,

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)

Wherever the words International

be read as Indian Standard.

Standard appear referring to this standard, they should

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

In this adopted standard, reference appears to certain International

Standards for which Indian
The corresponding
Indian Standards, which are to be substituted in their
Standards also exist.
respective places, are listed below along with their degree of equivalence for the editions indicated:

/nterrratior7a/ Standard

Corresponding

Degree of
Equivalence

/ndian Standard

IEC 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

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 61508-3 : 1998 Functional safety

of electrical/electron
ic/programmable
electronic
safety-related
systems

Part 3: Software requirements

IEC 61508-3 : 1998 Functional

of electrical/electronic/programmable
electronic safety-related systems:
Software requirements

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

The technical committee has reviewed the provisions of the following

in this adopted standard and has decided that they are acceptable
standard:
/nternationa/

Standard

safety

Identical

do

Part 3
do

International Standards referred

for use in conjunction with this

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

control and laboratory

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

requires that an allocation

is carried out;

works within a framework

functional
safety;

details the use of certain activities,

such as safety
to all methods of achieving functional
safety.

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

safe process design If necessary,

to address any residual identified
(chemical,
mechanical,
hydraulic,
To facilitate
this approach,
this

methods
which

for the process

concept,
standards

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

Development of the overall safety

requirements (concept scope definition,
hazard and risk assessment)
Clause 8
I

61511-1:2003

Definitions and
abbreviations
Clause 3

PART 1

Allocation of the safety requirements to

the safety instrumented functions and
development of safety requirements
specification

Clauses 9 and 10

Management of
functional safety
Clause 5

J%E?PTL

Safety life-c ycie

requirements
Clause 6
PART f i

I
I

Factory acceptance testing,

installation and commissioning and
safety validation of safety
instrumented systems
Clauses f3, 14, and 15

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
[,

Guideline for the

application of part 1

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)

applies when application

software
is developed
for systems having limited variability
or
fixed programmed
but does not apply to manufacturers,
safety instrumented
systems
designers,
integrators
and users that develop
embedded
software
(system
software)
o~
use full variability
languages
(see IEC 61508-3);

e)

the relationship

between

IEC 61511

and IEC 61508

(Figures

2 and 3);

applies to a wide variety of industries

within the process sector including
chemicals,
refining, oil and gas production,
pulp and paper, non-nuclear
power generation;
NOTE
Within
the process
sector
requirements
that have to be satisfied.

f)

outlines
the
(Figure 4);

relationship

9)

results in the identification

for the safety instrumented
other means:

h)

specifies
software,

i)

specifies
requirements
instrumented
systems
specified:

some

between

applications,

safety

example, off-shore),

(for

instrumented

functions

may have additional

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

to be met by the organization

needed

carrying

by the user for

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

m) uses a safety life cycle

determine
the functional
instrumented
systems;

(Figure 8) and defines a list of activities

which are necessary
to
requirements
and the safety integrity requirements
for the safety

n)

and risk assessment

is to be carried
and safety integrity levels of each safety

requ~res that a hazard

functional
requirements
NOTE

See Figure

9 for an overview

of risk reduction

out to define the safety

instrumented
function;

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);

for all parts of the safety

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

xi, does not place any direct

of a safety
requirements

(SIL 1) below which

during

instrumented

the safety

instrumented

integrity

levels;

be achieved

this standard

system

for

a safety

does not apply;

the safety
based on

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

targets for average probability

per hour for the safety integrity

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

and IEC 61508

lS/!EC

61511-1:2003

-\

!2
~

in
E

ii

of

..

. .......... ... . . .....

.........

;.., . ...........

lS/lEC

61511-1:2003

i,

KUIEC 6151$-1:2003

Management of functional safety (clause 5)

Oeterrnintition of function and integrity (clause 8)
Verification and vaiiciatkm (clause 7$ ?2.3, 12.7,
clauses 43 and 15)
Iperatkm, maintenance and modification (clauses 16 and 17j
Safety instrumented functions
Continuous mode
Safety instrumented control function
Demand mode control
Safety instrumented protection function
- Safety instrumented preventicm function
- Safety instrumented mitigation function

Safety instrumented systems

System and hardware requirements (clause 6)

output
Logic
Input
fFunction)
(Function)
(Function)

1
Software

r ~

Safety instrumented
Software reqwrernents

L..

Figure 5-

Relationship

Normative

references

systems
(clause 12)

...

...

between system, hatdware, and software of IEC 61511-1

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

i EC (506 S4-3:1998, lndusfrial-process

~neasurement
condifjons
Part 3: M@chanica/ influences
IEC 61326-1 :Elecirical
requirer77t2nts

equipment

for

measurefnefff,

and

control

equipmwi

@crating

and

control

equipment

Operating

control

and

laboratory

use

EMC

IEC 61508,
sys~~[~s re/ated

f~]nctional safety of elecfricaifelecfroniclprogrammable

electronic
safefy-relafed
Part 2: Requirements
for e/ectrica//elecironic/programn?able
electronic
safetysystems

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

for the process

industry

sector

definitions

Abbreviations

Abbreviations

used throughout
Table

IEC 61511
1-

are given

Abbreviations

in Table

1.

used in IEC 61511

Full expression

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

Fault tree analysis

FVL

Full variability

H FT

Hardware

HMI

Human

machine

H&RA

Hazard

and risk assessment

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

M out of N (see 3.2.45)

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

For the purposes of this document, the following 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

from the definition

in IEC 61508-4

to reflect

differences

in the process

sector

terminology,

*
i*
to system

design

for the purpose

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

NOTE 1 The elements

sensors,

final

within

that independently

a channel

could

a function

perform(s)

include

input/output

(1/0)

modules, logic systems (see 3.2.40),

elements.

NOTE 2 A dual channel

the same function.
NOTE 3 The term
final elements).

(i. e., a two-channel)

can be used to describe

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,

in the same way, causing

subsystem,

or device

of two or more

the same erroneous

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.

of an evolving (hardware and software)

those
components
and maintaining

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

See 9.5 as an example

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

where P(z) is the probability

bf dependent

includes

from an
manner

system

is realized may depend on the channel

safety, a dangerous
hardware
failure

events A and B are dependent,

failure

and may

system for the

continuity
and

to put the safety

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

of event z, only if P(A and B) z P(A) x P(B).

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

NOTE 1 The diagnostic coverage is used to compute the detected

from

z
g
$Q
m
e
I

the total failure

NOTE 2
example.

rate (k, O,,l,,,,u,,,,,,) as follows:

;.,.,,,,,,

failure rates (~..decled)

(kde[ected ) and undetected
= DC x }.,,,,, ,,,,U,,,,,, and kun,,C,.d = (1 -DC) x A,Q,a,
,,,,,=,,,,

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

NOTE 3 For safety applications

the diagnostic
coverage is typically applied to the safe and dangerous
failures of
a component
or subsystem.
For example,
the diagnostic
coverage
for the dangerous
failures
of a component
or subsystem
is DC = A.oo/J.DT , where LOD is the dangerous
detected failure rate and AOT is the total dangerous
failure

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

NOTE The term is Intended to cover any and all devices

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, or loss of, the capability

in IEV 191-15-05

refers

to perform
only to sub-item

2382-14-04-06]

10

may be

of a functional

fault as a state characterized

by the inability
to perform
preventive
maintenance
or other planned
actions,
or due
-09]

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,

from the S1S

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

see IEC 61508-4

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

See the note for the term fault

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

NOTE This term deviates from the definition in IEC 61508-4

3.2.27
functional
systematic
functional
effectively

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,

NOTE 1 In IEV 191-01-01

,nclude people
NOTE

or both, capable

the more general

This is the definition

term item

of accomplishing
is LIsrxl In place

a specified

of functional

purpose

unit, An item may somehmes

given in lSO/l EC 2382-14-01-01.

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

rate and the probability

NOTE

See 3286

NOTE

This term deviates

3.2.30
harm
physical
damage

of failure

to operate

from the definition

on demand.

in IEC. 61508-4

injury or damage to the health

to property or to the environment

of people,

to reflect

either

differences

directly

in process

or indirectly,

sector

terminology.

as a result

of

NOTS This definition matches lSO/l EC Guide 5?

3.2.31
hazard
potential
NOTE

source

of harm

This definition

(without

notes)

NOTE 2 The term Includes danger

and also those that have a long-term

matches

3.4 of ISCMEC

Guide

51

to persons arising within a short time scale (for example,

effect on a persons health (for example, release of a toxic

11

fire and explosion)

substance).

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

will have to other

for the activities

is subject to the

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

and its associated

equipment

place during the specific

assessment
or validation

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,

see IEC 61131-3

and IEC 60617-12.

12

lS/lEC 61511-1:2003

3.2.40
logic solver
that portion of either

a BPCS or S1S that performs

NOTE 1 In IEC 61511 the following terms for logic systems

electrical

logic systems

electronic

PE logic system
NOTE 2
systems,

for electro-mechanical

logic systems

for electronic

for programmable

one or more logic function(s)

are used:

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

fire or gas leak.

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

NOTE 2 In demand mode applications

where the demand rate is more frequent
rate will not be higher than the dangerous
failure rate of the safety instrumented
normally be appropriate
to use the continuous
mode criteria,
NOTE 3 The target failure
mode are defined in Tables
NOTE

This term dewates

measures
3 and 4.

for safety

from the definition

instrumented
in IEC 61508-4

13

functions
to reflect

operating
differences

function

a potential

it

implement

continuous

control

to

than once per year, the hazard

function.
In such a case, it will
in demand
in process

mode and continuous

sector

terminology

WiiEC+ 6154 q-1:2003

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

This term deviates

of IEC 61131-3,

a software

from the definition

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

that the risk is reduced

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

(i. e., a system

or electronic

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

A ielief valve is another

hydraulic
and pneumatic

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,

and its associated

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 1 The risk in this context is that associated

with the specific hazardous
event
with functional
safety).
to provide the necessary
risk reduction
(i. e , the risk associated
NOTE 2
establ!sh

Process risk analysis is described in IEC 61511-3. The main purpose

a reference
point for the nsk without taking into account the protection

NOTE

Assessment

NOTE

This term equates

of this risk should

include

associated

human

factor

:2003

61511-1

BPCS

(including

in which

of determining
layers.

S1S are to be used

the process

risk is to

issues.

to EUC risk in IEC 61508-4

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

This term differs

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
:

, .,,,,.,,,.

Basic PES structure

NOTE Tne Programmable

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

See ISO 9000 for more details.

to reflect

of an entity

3.2.62
random
hardware
failure
failure, occurring at a random
the hardware

differences

in process

that bear on its ability

time, which

results

sector

technology.

to satisfy

from a variety

stated

and implied

of degradation

needs

mechanisms

in

NOTE 1 There are many degradation

mechanisms
occurring
at different
rates in different
components
and since
manufacturing
tolerances
cause components
to fail due to these mechanisms
after different
times in operation,
failures
of a total equipment
comprising
many components
occur at predictable
rates but at unpredictable
(i. e.,
random) times.
NOTE 2 A major distinguishing
feature between random hardware failures and systematic
failures (see 3.2.85) is
that system failure rates (or other appropriate
measures),
arising from random hardware failures,
can be predicted
but systematic
failures,
by their very nature, cannot be predicted.
That is, system failure rates arising from random
hardware
failures
can be quantified
but those arising from systematic
failures
cannot be statistically
quantified
because the events leading to them cannot easily be predicted.

3.2.63
redundancy
use of multiple
elements
implemented
by identical
redundancy)
NOTE

Examples

are the use of duplicate

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

from the definition

of the frequency

For more discussion

functional

on this concept,

16

bits.

to reflect

1].

differences

of harm and the severity

see Clause

of parity

or availability.
[lSO/l EC 2382 -14-01-1

in IEC 61508-4

of occurrence

and the addition

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.

or not the potential

names

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

to put the safety

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

This term deviates

3.2.67
safety
freedom

from the definition

from unacceptable

in IEC 61508-4

to reflect

differences

in process

sector

terminology,

risk

NOTE This definition is according to ISOIIEC Guide 51.

3.2.68
safety function
function to be implemented
by an S1S, other technology
safety related system or external
reduction facilities,
which is intended to achieve or maintain a safe state for the process,
respect to a specific hazardous
event
NOTE

This term deviates

from the definition

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

one or more safety

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.

This can include

either

safety

instrumented

control

17

functions

or safety

instrumented

protection

functions

WIEC 6f5?l=l :2003

NGTE 2

Manufacturers

NCrE 3

.A S1S may or may not include

and suppliers

of S1S devices

NOTE 4

See Clause

should

refer to C!ause

1 a) through

d) inclusive.

software.

A..2

NOTE 5 When a human action is a part of an S!S, the availability

~pecif:ed in the SRS and included
in the performance
calculations
how to include operator avai!abliiiy
and reliability
in SIL calculations

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

NOTE 1 The higher the safety

furictlor) (S IF) will be carried out.
NOTE Z

are four levels

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

for the safety

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

This term differs

from the definition

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

This term deviates

is

one

part

(the

from the definition

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

used in IEC 61511

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

how the device

subsystem

or system

can be safe!y

a!} !n$~rl$ci~or}al ~anual,

NOTE
This could be a stand-aione
dccurneni,
document,
or included in the user document(s)
definiiig
application
/imitations

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

NOTE 2 This definition

the addition of the woid

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,

and the full

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.

NOTE 2 Typical example

burner management).

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

FVL are genera!

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

for the creation,

modification,
and documentation
tools are not required for the operation of the S1S

3.2.82
software
life cycle
activities
occurring
during a period of time that
when the software is permanently
disused

starts

NOTE 1 A software life cycle typically includes a requirements

phase, Installation
phase and modification
phase.
NOTE

Software

and is not accessible

for
to as firmware
or system

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

can be part of a system.

differs

from IEV 351-01-01.

A system includes the sensors, the logic solvers, final elements,

to S1S (for example, cables, tubing, power supply).

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

of a system can be another

or a controlled
system and

maintenance
failure

modification

can be induced

of systematic

manufacture,

failure

would

by simulating

(up to note 2) matches

requirements

and/or

without

causes

usually

communication

and ancillary

equipment

which can only be eliminated

by a
process,
operational
procedures,
not eliminate

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

See also 3.2.29.

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

for the target

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

NOTE See IEC 61511-3.

[ISOIIEC Guide 51]
3.2.90
undetected
unrevealed
covert
in relation to hardware
operation

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

the safety instrumented

function(s)
and safety
after installation
meets in all respects the safety

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

N(J-.-E1 The watchdog

confirms
that
(for example, hardware

N ~;~ ~
de$e,oted

The watchdog
can
in ~,der to p~J\ tile

coverage

of

according

to their

the PE logic solver

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

(see 3.2 15 and 3.2.40).

to this

5.t

Management

!rtternational

Standard

NOTE
This
;ns!wmen!ed
~.,:h; evement

5.2.1

of functional

each of the requirements

criteria and therefore
the

safety

Objective

The objective
are necessary

5.2

manner and by
manner.

device (typically a switch) for monitoring

the correct
(PE) device and taking action upon detection
of an

To conform to this International

Standard
, it shall be shown that
outlined
in Clauses 5 through 19 has been satisfied to the defined
c!,~iJse
objective(s)
has(have) been met.

specification;

performed ,where ciifferen$ parts of a system are put together In a step-by-step

of environmental
tests to ensure that all the parts work together in the specified

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

ti~al they pertorlm

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).

lo their roie irr safety

Iife-cyc!e

actwlt!r?s,

of an even?

instrumented

and risk

Hazards shall be identified,

defined in Clause 8,
It may be beneficial

ai~pr.~prlaie

of the application

evaluation

safety

requirements

skills

level of the safety

and complexity

process

regulatory

and leadership

of the potential

integrity

Risk

NOTE

(for example.

of the legal and safety

61511-4:2003

functions:

and the lechnalcgy

management
evaluated

and the necessary

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 risk assessment;

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.

assessing the demand

verify the assumptions
were determined.

corrective

2.3

system

or failure
action

rate on the safety instrumented

functions
during
made during risk assessment
when the integrity

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

When the assessment

team is large, consideration
should be given
individual
on the team who is independent
from the project team.

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

Stage 1 - After the hazard and risk assessment

has been carried out, the required
identified
and the safety requirement
specification
has been developed.
the safety

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

the level of independence

[he means

safety

that will be generated

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

has been designed.

and final validation of the safety instrumented system has

been completed and operation and maintenance procedures have been developed.
Stage

3 - After

the installation,

pre-commissioning

Stage 4- After gaining experience in operating and maintenance.

Stage 5- After modification and prior to decommissioning of a safety instrumented system.
NOTE 3 The number, size and scope of functional
circumstances.

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:
~

Typical direction ofinformation

; Nodetailed
:,,..........,....;

requirements

Requirements

c1

flow

gkrenin

this standard

given in this standard,

NOTE1

Stages lthrough

NOTE2

Allreferences

5inclusive

areto

Partl

aredefined

in 5.2.6,1.3

unless otherwise noted.

.
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

and risk assessment

the recommendations
instrumented
system

project

design

has been carried

out (see 8.1);

arising from the hazard and risk assessment

have been implemented
or resolved;

change

procedures

that apply to the safety

are in place and have been properly

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, operating,

maintenance
instrumented
system are in place;

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;

the degree of independence

between the persons,
departments,
organizations
units carrying out the work and those carrying out the auditing activities;
the recording

safety

information
about the safety
and operating personnel;

safety

but is not limited

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

tools are usedfor

any safety
safety 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

shall be in place to initiate,

safety
instrumented
system

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

items from entering

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

and IS only meant

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

\ Hazard and risk

assessment

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 design the S1S

to meet
~and24
the requirements
for safety
instrumented
functtons and
safety integrity

To Integrate

and test the

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

To valtdate that the SIS

meets In all respects the
requirements
for safety [n
terms of the required safety
instrumented
functions
ano
the required safety Integrity

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

To ensure that the

functional
safety of the S1S
!s maintained
during
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

Revised S1S safety

requirements

Results of S1S
modification

Decommlssioning

To ensure proper review,

sector organization,
and
ensure SIF remain
appropriate

18

As built safety
requirements
and
process information

SIF placed
service

out of

SIS verifica!l~n

To test and evaluate the

outputs of a given phase to
ensure correctness
and
consistency
with respect to
the products and standards
provided as input to that
phase

7, 127

Plan for the

verification
of the
S1S for each phase

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

Plannlng for S1S

functional
safety
assessment

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

shall define all activities

required for the appropriate
phase
It shall conform to this standard by providing the following:

(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

will take place;

the persons,
departments
levels of independence:

identification

of items to be verified;

identif~cation

of the information

how to handle

tools and supporting

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;

with the hazardous

event;

for risk reduction;

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

NOTE 2 Where reasonably

practicable,
processes
should be designed
to be inherently
safe. When this is not
practical.
nsk reduction
methods
such as mechanical
protection
systems
and safety instrumented
systems
may
need to be added to the design. These systems may act alone or In combination
with each other
NOTE

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

and its associated

that

contribute

to it

of the event:

operation,

for additional

to information

out on the process

start-up,

risk reduction

on. the measures

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

that can be used

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

not conform to IEC 6151 1) that

to be better than 105 per hour.
in such

The above requirements

do not mandate
that risk and risk reduction
value. Graphical
approaches
(see IEC 6151 1-3) can also be used

a way that the relationship

targets

have

to be assigned

as

NOTE 2 The extent of risk reduction

necessary
should vary depend(ng
on the application
and national
legal
requirements
An accepted
principle
in many countries
IS that additional
risk reduction
measures
should be applied
until the cost incurred becomes disproportionate
to the iisk reduction achieved.

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

for each safety

should

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

for the purpose

of
and its associated

functions.
in the allocation

process.

LsilEc 61511-1:2003

The required safety integrity level of a safety instrumented

function shall be derived
Into account the required risk reduction that is to be provided by that function,

9.2.2
taking

by

NOTE See IEC 61511-3 for guidance.

9.2.3
For each safety instrumented
function
operating
in demand mode, the required
SIL
shall be specified
in accordance
with either Table 3 or Table 4. If Table 4 is used then neither
the proof-test
interval
nor the demand
rate shall be used in the determination
of safety
integrity level.
9.2.4
For each safety instrumented
function
required SIL shall be specified
in accordance
Table

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

<10-6 to <I O-5

explanation

The safety !ntegrlty

level ts defined
numerically
deslgris
and solutions.
However,
It IS recognized
causes of failure can only be assessed qualitatively.

NOTE 3 The required

frequency
of dangerous
f~]nctlon ts ctetermlned
by considering
the risk (In
functlor
acting In continuous
mode together
with
iaklng Into consideration
contributions
from other

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

in such a way that it

These enhancements

process

requirements

61511-1:2003

safety

instrumented

be permitted

only if the

a)

There has been an explicit demonstration,

by a combination
of appropriate
analytical
methods and testing. of the target safety integrity failure measure having been met.

b)

There
safety
NOTE
should

c)

There

has been extensive

operating
instrumented
function

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

The data should

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

COMMUNITY EMERGENCY RESPONSE

Emergency

broadcasting

/
\
PLANT EMERGENCY RESPONSE

Evacuation

procedut-es

\
Mechanical mltlgatlon systems
Safety instrumented control systems
Safety Instrumented mit!gatlon systems
Operator supewlslon

Mechanical Protection s~stem

Process alarms wlthoperator corrective action

Safety instrumented control systems

Safety Instrumented prevention systems

,H

Figure
9.4.2
The
IEC 61508)

9-

Typical

CONTROL and MONITORING

Basic process control systems
Monkorlng systems (process alarms)
Operator superwsion

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

for the BPCS,

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

The S1S requirements

clear, precise, verlf!able.

should be expressed and structured In such a way that they are

maintainable

written to ald cornprehens!on

10!3

S1S safety

10.3.1
These
following:

and feasible, and

by those who are Ilkely to utilize the Information

requirements

requirements

shall

to identify

a definition
function:

at any phase of the life cycle.

requirements

a description
of all the safety
functional
safety:

instrumented

of the

sufficient

instrumented

and take account

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

rate on the safety

include

to achieve

safe process states which, when

overload
of emergency
example,
and demand

shall

the required

safety
occurring
storage,

the

instrumented
concurrently,
multiple
relief

instrumented

function;

intervals;

time requirements

for the SIS tc bring the process

and

the safety integrity

level
instrumented
function,

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;

the S1S after a shutdown;

spurious

each

safety

and their trip points;

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

of the modes of operation

functions
required to operate

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;

the mean time to repair

location, spares holding,

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

the SIS and any other

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

how they will be cleared;

for the S1S, taking into account

environmental
constraints:

combinations

automatic

up and restarting

of the plant and

within each mode:
as listed

of the dangerous

alarms,

for starting

requirements

which is feasible
service contracts,

example,

states

the travel

of the S1S that

by the S1S to ensure

functions

specification
shall be
architecture
of the SIS.

orderly

derived

need

shutdown

from

time.
to be

or faster

the

safety

engineering

Objective

The objective of the requirements

of this clause is to design one or multiple S1S to provide
safety instrumented
function(s)
and meet the specified safety integrity level(s).
11.2

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

means that neither the fa]lure of any non-safety

functions
nor the programming
functions
IS capable of causing a dangerous
failure of the safety instrumented

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

NOTE 2 Devices of the S1S may also be used for functions

of the basic
that a failure of the basic process control system does not compromise
safety Instrumented
system

11.2.5

the functional

safety

process control system

the safety instrumented

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

and test facllltles

from their use.

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

power supply integrity

back-up, uninterruptible

integrity

is detected

(for example,

is ensured using
power supplies);

loss of power to the subsystem

end-of-line

supplemental

is detected,
37

all of the following

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

a safe state (see note);

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).

Where the above actions depend on an operator

taking specific actions in response
to an
alarm (for example, opening or closing a valve), then the alarm shall be considered
part of the
safety instrumented
system (i. e., independent
of the BPCS).
Where the above actions
depend on an operator
notifying
maintenance
to repair a faulty
system in response to diagnostic
alarm, this diagnostic
alarm may be a part of the BPCS but
shall be subject to appropriate
proof testing and management
of change along with the rest of
the S1S.
NOTE
The specified
action (fault reaction)
required to achieve or maintain a safe state should be specified
safety requirements
(see 10.3). It may consist, for example,
of the safe shutdown
of the process or of that
the process which relies, for risk reduction,
on the faulty subsystem
or other specified
mitigation
plannlng

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

tests or by any other

instrumented
function
is used only by safety

in either

a)

a specified

or

b)

the repair of the faulty

subsystem
within the mean-time-to-restoration
(MTTR)
period
assumed in the calculation
of the probability
of random hardware failure. During this time
the continuing
safety
of the process
shall
be ensured
by additional
measures
and
constraints,
The risk reduction
provided
by these measures
and constraints
shall be at
least equal to the risk reduction
provided
by the safety instrumented
system
in the
absence
of any faults.
The additional
measures
and constraints
shall be specified
in
the S1S operation
and maintenance
procedures.
If the repair is not undertaken
within the
specified
mean time to restoration
(MTTR)
then a specified
action shall be performed
to achieve or maintain a safe state (see note 2),

Where the above actions depend on an operator

taking specific actions in response
to an
alarm (for example,
opening or closing a valve), then the alarm shall be considered
part of
the safety instrumented
system (i. e., independent
of the BPCS).
Where the above actions
depend on an operator
notifying
maintenance
to repair a faulty
system in response
to a diagnostic
alarm, this diagnostic
alarm may be a part of BPCS but
shall be subject to appropriate
proof testing and management
of change along with the rest of
the SIS
NOTE 1 A safety instrumented
function
IS considered
to be entirely dependent
on a subsystem
(f a failure of this
subsystem
results
In a failure
of the safely
instrumented
function
In the safety instrumented
system
under
conslderatlon,
and the safety Instrumented
function
has not also been allocated
to another
protection
layer (see
Clause 9)
NOTE 2 The speclfled
action (fault reaction)
required
to achieve or tnalntaln
a safe state should be specified
In
the safety requirements
(see 10.3) It may consist. for example,
of the safe shutdown of the process, or that part of
the process which relles, for risk reduction,
on the faulty subsystem
or on other speclfled
mitigation
planning.

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

a safe state shall be

example,
of the safe
risk reduction,
on the
to detect the fault and
to occur.

Where the above actions depend on an operator taking specific

actions in response
to an
alarm (for example, opening or closing a valve), then the alarm shall be considered
part of the
safety instrumented
system (i. e., independent
of the BPCS).
Where the above actions depend on an operator
notifying
maintenance
to repair a faulty
system in response to a diagnostic
alarm, this diagnostic
alarm may be a part of the BPCS but
shall be subject to appropriate
proof testing and management
of change along with the rest of
the S1S.
NOTE 1 A safety instrumented
function is considered
to be entirely dependent
on a subsystem
if a failure
subsystem
causes
a failure
of the safety
instrumented
function
in the safety
instrumented
system
consideration,
and the safety instrumented
function
has not also been allocated
to another protection
layer.
NOTE 2 When there is a possibility
that some combination
of output states of a subsystem
hazardous
event then it should be necessary
to regard the detection
of dangerous
faults
a safety instrumented
function operating
in the continuous
mode.

11.4

Requirements

for hardware

fault

can directly cause a

in the subsystem
as

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

and final elements

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.

NOTE 2 The minimum

hardware fault tolerance
has been defined to alleviate
potential
that may result due to the number of assumptions
made in the design of the SIF, along
failure rate of components
or subsystems
used in various process applications.

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

(see IEC 61508)

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 device allows adjustment

range, upscale or downscale

the adjustment
of the
jumper, password;

the function

1
I
I

11.4.5
Alternative
made in accordance

11.5.1

on the basis of prior use (see 11 5.3);

of process-related
failure direction;

process-related

has an SIL requirement

Table

11.5

is selected

and non-PE logic solvers)

in Table 6 may be reduced

parameters

parameters

only, for example,

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

(see IEC 61508)

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

of this clause is to specify the requirements

which are to be used as part of a safety

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

and tool selection

be consistent

all !he othel

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

the S1S safety

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

NOTE 1 In the case of field elements,

there may be extensive
applications.
This can be used as a basis for the evidence.
NOTE 2 The ievel of details of the evidence
con, ponent or subsystem
and with the probability
of the safety instrumented
function(s)

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

are only added

field devices

are removed

the process

application

regularly,

when sufficient

operating

when they show a history

is included

in the Ilst where

41

experience

has been obtained;

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

FPL device ts both able to perform the required functions

and that the previous
use
has shown there is a low enough probability
that it WIII fail in a way which could lead to a
hazardous
event when used as part of the safety instrumented
system,
due to either
random hardware failures or systematic
faults in hardware or software;

the

appropriate

the FPL device has been

operational
profiles.

standards

for hardware

used

and

have been applied;

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

for the selection

of LVL programmable
example,
logic solvers)
based on prior

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

See IEC 61511-2

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,

all the followlng

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

of use for safety

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

of any 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,

when used as part of the safety instrumented

system,
failures or systematic
faults in hardware or software;

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

for the embedded

configurations,

modules
dynamic

not use artificial

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;

has been performed.

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

for the selection

of FVL programmable
(for example,
logic solvers)

11.5.6,1
When the applications
are programmed
accordance
with IEC 61508-2 and IEC 6;508-3.
11.6

Field

components

and

using a FVL, the PE Ioqic solver

-

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

An example of such a method IS an end-of-llne

monitor
where a ptlo! current IS continuously
monitored
circuit continuity
and where the p!lot current IS not of sufficient
magnitude
to affect proper 1/0 operation

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 the S1S can include,

but are not limited

to

interface(s):
interface(s):

interface(s),

11.7.1

Operator

11 .~.l.1
be taken

Where the SIS operator

Interface is via the BPCS operator interface,
of credible failures that may occur in the BPCS operator interface.

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

the loss of energy

failure

passwords

the SIL shall

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

and final elements;

where

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

Provlslon of incorrect information

from the BPCS to the S1S shall not compromise safety.

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

and fault handling

application

shall

should

be installed

such

that

alarms

and

manual

Software issues apply only to SIS using PE technology

11.7.2.3

The maintenance/engineering

interface

shall not be used as the operator

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

H31!EC 61511 -I :2003

11.8

Maintenance

51 .8.1

or testing

The design

shall

allow

design

requirements

for testing of the S1S either end-to-end

or In parts Where
downtime
is greater than the proof test Interval.
!hen

interval
between
scheduled
process
facilities
are required
$ine testing
The term end-to-end

NOTE

means from process !Iuld a! SenSGFend

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

Forcing of inputs and outputs

supplemented
by procedures
off an alarm, as appropriate.
11.9

SIF probability

to the bypass

pr~cess

facilities

inciudr?d

The S1S shall be designed

In accordance
with the
in the safety requirement
specific ailor?s
defined

@ 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

of the S1S via an alarm

and/or

in PE S1S shall not be used as a part of

below.

without taking the S1S out of service shall not be allowed

and access security. An>l such forcing shall be announced

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.

NOTE 4 The target failure measure may be a speclf!ed

dangerous
failure rate derived from a quantitative
analysis
been determined
by qualttatlve
methods

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

due to random hardware

faults
In any
of the S1S but whtch are detected
by

IWIEC 61511-1 :2003

the estimated
rate of falitire of each subsystem,
due to random hardware
faults,
failure
of the S1S which are undetected
modes which would cause a dan~erOliS
diagnostic
tests.

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

in any modes which

process
and undetected
by diagnostic

communication

of the S1S (both

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

for the analyst

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

time for repair

in the reliability

software,

embedded

three types

i e., the

software,
of software

fixed

program

limited

full variability

tools

i.e., the software

development

languages

variability

software

supplied

to develop

and

verify

the

application

as part of the PE;

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.

FPL or LVL up to SIL 3 shall

of SIL4 application
software
of application
software using

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 the activities

S1S subsystem;

to define
application

to ensure that adequate

planning exists
to the application
software are met.

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

software safety life cycle

to the S1S safety life cycle

48

for example, sensor,

logic eolver,
final element

and its relationship

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

used (FPL, LVL or FVL)

of the V-model phases

NOTE 3 The application

requirements
specifications

software

safety

NOTE 4
validation

software

validation

The application
plan

12.1.2.3
The
safety integrity

techniques

minimize

reveal

ensure

that the faults

ensure

that the software

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

of the S1S safety

S1S or S1S subsystem

be suitable

applied

for

each

for the

life-cycle

software:

throughout

has the required

should

will not lead to unacceptable

the lifetime

results:

of the S1S:

quality.

depend

upon

the specific

circumstances,

The factors

In

of complexity.
integrity

level of the S1S,

In the event

of stand ard!zatlon

of failure
of design

exist in the software:

in the software

and techmques

be included

software

into the application

can be maintained

that the software

closeness

of software:

consequence
degree

and

the risk of Introducing

NOTE
The selectlon
of methods
this declslon are likely to Include

degree

plan

the

specifications

PE device that implements

the application
required by each SIF it services.

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

out. The following

issues

should

be addressed:

and hardware;

and test data;

of tests

to be performed;
including

on which

location(s)

tools,

support

the completion
(for example,

on external

software

and configuration

description;

of the test will be judged:

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

life cycle (in realization

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

To specify the requirements

for the software safety
instrumented
functions for
Bach S1S function
~ecessary to implement
the
required safety
Instrumented
functions

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

To specify the requirements

for software safety integrity
for each safety
nstrumented
function
allocated to that S1S

23

application
;oftwa re
;afety
ralldation
IIanning

To develop a plan for

~alidating the application
Soft ware

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

To review and evaluate the

requirements
placed on the
software by the hardware
architecture
of the SIS

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

Support tools and

programming
languages
To identify a suitable set of
configuration,
library,
management,
and
simulation
and test tools,
over the whole safety life
cycle of the software (utility
software)

Verification
S1S application
software safety
requirements
specification

Verification
Description
architecture

information

List of procedures
for
use of utility software

information

of the
design

Manuals of the S1S

To specify the procedures
for development
of the
application
software

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

List of manuals and

procedures
of the
selected PES for
use of utility
software

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

1) To verify that the

requirements
for software
safety have been achieved

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

2) To show that all application program subsystems

and systems Interact
correctly to perform their
Intended functions
and do
not perform unintended
functions

information

to IEC 61508-3

test results

2) Verified and tested

software system
3) Verification

information

Software
architecture
integration
test
specification

Can be merged with the

next phase (12.5) subject
to satisfactory
test
coverage
125

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

Software and hardware

integration
test results

Verified software
hardware

123

53

Software and S1S

safety validation
plans

Software
validation

and SIS
results

and

lS/lEC

61511-1:2003

12.2

Application

software

safety

NOTE This phase is box 12.2 of Figure

12.2.1

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

NOTE 1 An S!S usually

Furthermore,
subsystems

between

include

inputioutput

functions

derived functions (for

example sensor checking if
not provided as a service of
the embedded software)

~ -- fault handling
software

the hardware

and software

software

safety

requirernents

specification

architectures

of S1S

sensors

NOTE 3 The S1S subsystem

software
safety requirements
for the S1S (see Clause 10) need not be repeated.
NOTE 4
software
condition.

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

dual 1/0 cards

Figure

relationship.

S1S subsystem

Generic and application

specific features in hardware
Examples

architectural

requirements

should

of the

software

safety

been

and

requirements
specified

final

elements.

on the S1S logic

in the requirements

the minimum
capabilities
of the PE
which would result in an unsafe

requirements

for

each

S1S

of the SiF;

from the S1S architecture;

pianning

(see Clause

be made available

and

5)

to the application

software

developer.

NOTE 2 This requirement

does not mean that there should be no Iteration
between
the developer
of the S1S
architecture,
the organization
responsible
for configuration
of the devices
and the developer
of the application
software.
As the application
soffware
safety requirements
and the possible
application
software architecture
(see
12.4.3) become more precise, there may be an impact on the SIS hardware
architecture
and, for this reason, close
cooperation
between
the SIS architecture
developer,
the S1S subsystem
supplier
and the application
software
developer
is essential
(see Figure 5).

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

all relevant modes

specification,

action !O be taken on bad process

open circuit, detected short circuit:

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

and their operability;

of the process

tests

of other devices
periodic

software:

variable

within

such

of external

example,

as specified
as sensor

devices

includes

(for

application

the S1S (for example,

of safety

instrumented

value

driven

detected

sensors

and

final

watch-dogs

and

data

and final elements);

when the process

specification
requirements

requirement

out of range,

example,

sensors

functions

to the Input documents

(for example,
of the SIS, hardware safety Integrity

in the S1S safety

is operational;

of the SIF, configuration

of the S1S).

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 clear to those who will utilize the document

at any stage of the S1S safety life cycle:
this Includes
the use of terminology
and descriptions
which
are unambiguous
and
understood
by piant operators
and maintainers
as well as the application
programmers;

are verifiable,

testable,

are traceable

back to the speciflcatton

12.2.2.6
allowlng

modifiable:

The application
proper equipment

functions

that enable

of the safety

requirements

of the S1S.

software safety requirements

specification
shall
selection.
The following shall be considered:
the process

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

that allow the SIS to be safely

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

for each of the above functions.

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

may be part of the

61511-1:2003

lS/lEC

Application

12.3

This phase

NOTE

software

safety

is box 12.3 of Figure

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

is box 12.4 of Figure

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,

with the development

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

(LVL or FPL) should

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

and their dependencies.

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)

have the capacity

e)

keep the complexity

to requirements;

for safe modification;

and size of SIF application

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 IEC 61511 when

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.

NOTE 2 The application

software architecture
subsystem
provided by the supplier.

12.4.3.2

The description

should

of the application

a)

provide a comprehensive
description
S1S subsystem
and of its components;

b)

include the specification

and interactions
between

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

in the S1S subsystem

they can not affect

that the architecture

and techniques
for their choice
should

the proper

documentation

of the S1S

shall

and of the operation

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

but not used in any SIF;

the order of the logical processing

of data with respect
and the logic solver functionality,
including any limitations

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

used to deveiop the application

should be justified.

with

software

respect

should

aim at ensuring

of the S1S subsystem;

with the hardware)

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

integrity of all data shall be described

data, communications
data, operation

and software
architecture
(see Figure
11) and there
such issues as the test specification
for the integration
(see 12.5).

is
of

lS/lEC 61511-1 :2003

12.4.4

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

match the characteristics

contain

features

that facilitate

support

features

that match the design

shall

using a translator/compiler
and unambiguously

that has been assessed

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.

for the language

used shall
description
(see 12.4.3). The
and any additional
measures

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

test and system

libraries;
shutdown

levels for which

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;

of, tools and programming

12.4.5

a)

items as appropriate:

safe functions;

for, and limitations

integrity

the following

is suitable

be verified.
software

shall

safety

or system

languages;

development

be available

requirements

59

prior to the start of detailed

(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;

for safe modification;

to, and explanation

of, application

functions

and associated

constraints.

Wherever possible proven software modules should be used,

12.4.5.3

The design

plausibility
input data;

of each application

checks

of each

full definition

system
configuration
hardware and software

input

of input and output

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;

12.4.5.4 The design of each application

applied to each application
software module
12.4.5.5

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

(see 5.2,4 ).,

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

1/0 data is mapped

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

all parts of the application

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

and the following

shall

and
and

be

lS/lEC 61511-1:2003

timing

proper

12.4.6.3

effects

due to the sequence

sequence

implementation.

The results

12.4.7

of the application

Requirements

NOTE

Testing

of execution;

software

for application

that the software

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

the test results;

b)

whether

If there

software

integration

testing

and criteria

all software

b)

the necessary

12.5

the reasons

modules

for the failure

impacted;

re-design

Integration

NOTE

unintended

shall be available

of the test specification

shall

functions

that

and shall state

modification

to the

software

shall

be

and

and re-verification

of the application

This phase is box 12.5 of Figure

have been met.

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

The results of application

a)

that the software

activities

software

(see

12.6).

with the S1S subsystem

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

on the nature of the application,

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

The scope of the tests may be reduced

NOTE

The following should be addressed:

the division of the application

software

based on previous

into manageable

experience.

integration

test cases and test data;

types of tests to be performed;
test environment,

tools, configuration

test criteria on which the completion

procedures

for corrective

and programs;
of the test will be judged;

action on failure during test.

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

and test scripts;

e)

the test results;

f)

whether

9)

if there is a failure, the reasons for the failure,

of correction
including re-test and re-verification

test;
functionality);

the objective

and criteria

applies

primarily

of the tests

modification

have been met; and

the analysis of the failure
(see 12,5.2,2)

and the records

procedures

tochanges occurring during the operational

phase of the software.

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

of all S1S modification

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

FPL and LVL software

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

from the particular

inspection

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;

with the functional

Application

consistency

requirements.

data should

be verified

for

with the data structures;

completeness;
compatibility
correct

within

a known

3 Modifiable

invalid

system

software

(for example,

sequence

of execution,

run-time);

data values;

operation
NOTE

with the underlying

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

with the safety

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

for a FAT should

need

NOTE 1 Close co-operation

develop the integration
tests.

between

NOTE 2 The activities

commissioning.

follow

NOTE

are applicable

is sometimes

The activities

referred

be specified

the logic solver

the design

during

supplier

and development

an

integration

the design

and design

phases

to the subsystems

test

phase

contractor

and precede

and

can

It is usual for the FAT to take place in a factory

13.2.2

The planning

specify

environment

prior

be

part

of the

in order

to

of a project.

may be required

the installation

and

of an S1S with or without programmable

NOTE 4
the plant.

for a FAT should

to as

to Installation

electronics.

and commissioning

in

the following

Types of tests to be performed

including
black-box
system functionality
tests (i. e., test
design method
that treats the system as a black box, so it does not explicitly
use
knowledge
of its internal structure,
Black-box
test design is usually described
as focusing
on testing function
requirements.
Synonyms
for black box include behavioral,
functional,
opaque-box,
and closed-box
testing); performance
tests (timing, reliability
and availability,
integrity,
safety targets
and constraints),
environmental
tests (including
EMC, life- and
stress-testing),
interface testing, testing in degraded and/or fault modes, exception
testing,
application
of the S1S maintenance
and operating
manuals.

Test cases,

test description

and test data.

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

of the test shall be judged.

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

For each test carried

the version

the safety

the detailed

a chronological

the tools,

a)

take

version

out the following

of the test planning

instrumented

function

test procedures
record

equipment

The results

the test cases:

should

with

by a formal argument

the

FAT

planning.

!
be addressed:

being used;
and performance

characteristic

and test descriptions;

of the test activities;

and interfaces

of FAT should

resolved

used.

be documented,
64

as to

of the logic solver.

The FAT should be conducted

in accordance
show that all the logic performs correctly.

13.2.6

the test case and who is going to

stating

being tested;

These

tests

lS/lEC 61511-1:2003
b)

the test results;

c)

whether

and

the objectives

and criteria

of the test criteria

have been met

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;

so that it is ready for final system

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

to be used for installation

and commissioning;

shall take place;

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

all field devices

logic solver

the interfaces

sources

has been properly

have been properly

stops and packing

damage

connected;

connected

materials

and are operational;

have been removed;

is present;

have been properly

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

15.1.1 The objective

of the requirements
of this clause is to validate,
through inspection
and
testing, that the installed
and commissioned
safety Instrumented
system and its associated
safety instrumented
functions
achieve the requirements
as stated in the safety requirement
specification.
NOTE

This is sometimes

15.2

Requirements

15.2.1

Validation
following

referred

to as a site acceptance

planning of the S1S shall define

items shall be included.

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

for use including

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

and its associated

those

identified

through

the

shall take place;

b)

static

system(s)
with
and resolution
of

to be used for validation;

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

out (for example,

procedures,

application

for the validation

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,

are to take place

(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

used for this function

should be calibrated
against
within an uncertainty
appropriate
to the application.
alternative
method shall be used and documented,

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:

the safety instrumented

system performs under normal
example, start-up, shutdown)
as identified in the safety

confirmation
that adverse
interaction
of the basic
connected
systems do not affect the proper operation

the safety instrumented

process control system

logic
solver,
sensors,
requirement
specification,

and abnormal operating

modes
requirement
specification;
process
control
system
of the safety instrumented

system properly communicates

or any other system or network;
and final
including

(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

of the S1S validation

of tne S1S validation

the version

the safety instrumented

function under test (or analysis),
along
to the requirement
identified
during S1S validation
planning:

tools

the results

the version

of the test specification

the criteria

for acceptance

the version

of the S1S hardware

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

with the specific

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 bypass functions

(for example,
PE logic solver
shall be returned to their normal position.
All process isolation
and procedures.

All test materials

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

all force enables

shall be removed.

maintenance

Objectives

16.1.1

The objectives

to ensure
operation

to operate

of the requirements

that the required

and maintenance;
and maintain

SIL of each

of this clause
safety

instrumented

the S1S so that the designed

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;

to be used for operation

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

for the safety

in accordance

with the

out to maintain the as designed

functional
to proof-test
intervals
defined
by the SIL

the actions and constraints

that are necessary
to prevent an unsafe state and/or reduce
the consequences
of a hazardous
event during maintenance
or operation
(for example,
when a system
needs to be bypassed
for testing
or maintenance,
what additional
mitigation steps need to be implemented);

.
.

the information
Sls;

which

needs

to be maintained

the information
Sls;

which

needs

to be maintained

procedures

to be followed

procedures

for fault diagnostics

procedures

for revalidation;

maintenance

procedures

requirements;

for tracking

maintenance

for reporting

procedures

for analysing

systematic

that test equipment

and maintained.

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

on the function and operation

how the S1S functions

the S1S is protecting

normal

with

is

properly

the

relevant

of the S1S in their area. This

and the resulting

action

that is taken

these

bypasses

by

against;

the operation
be used;

of all bypass

switches

and under

the operation
these manual

of any manual shutdown

switches
switches are to be activated;
69

what circumstances
and manual

start-up

activity

are to

and when

lS/lEC 61511-1 :2003

NOTE
0

This

may include

expectation

when

on

system

activation

any S1S alarm

reset

of any

restart

diagnostic

is activated

16.2.5
Maintenance
personnel
performance of the S1S (hardware

and system

alarms

indicating

there

(for example, what action

is a problem with the S1S).

shall be trained as required

to sustain
and software)
to its targeted integrity.

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

of the S1S shall be

required
safety
is

on the system:
part

of the

that ALL discrepancies

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

may be used to determine

the undetected

failures

that need to be tested:

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

tests shall be conducted

using a written procedure
that prevent the S1S from operating
in accordance

The entire S1S shall be tested including the sensor(s),

(s) (for example, shutdown valves and motors).
The frequency

of the proof tests

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

and the final

using the PFDavg calculation

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

Any change to the application

logic requires full proof testing. Exceptions
to this are
if appropriate
review and partial testing of changes
are carried
out to ensure the
were correctly implemented.

16.3.2

Inspection

Each S1S shall be periodically

visually
inspecied
to ensure
there are no unauthorized
modifications
and no observable
deterioration
(for example,
missing
bolts or instrument
covers,
rusted
brackets,
open wires,
broken conduits,
broken
heat tracing,
and missing
insulation).
46.3.3

Documentation

of proof tests

The user shall maintain records

as required. These records shall

that certify that proof tests and inspections

were
include the following information
as a minimum:

a)

description

b)

dates of the tests and inspections;

c)

name of the person(s)

d)

serial number or other

tag number, equipment

e)

results

17

who performed

performed;

the tests

and inspections;

unique identifier
of the system
number, and SIF number);

of the tests and inspection

(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

of the S1S is maintained

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

shall not begin without

17.2.5
Appropriate
information
Information
shall include

a description

the reason

identified

an analysis

all approvals

tests used
required;

appropriate

tests used to verify

were not modified.

17. 2.6
trained.

of the modification

be

maintained

authorization.
for

all

changes

to

the

S1S.

The

or change;

for the change;

hazards

which

of the impact
required
to verify

of the modification

that the change

configuration

Modification
All affected

may be affected;
activity

on the S1S;

for the changes;

that

was properly

regard

18

S1S decommissioning

implemented

and the S1S performs

as

I
i

history;
the change

has not adversely

shall be performed
with
and appropriate
personnel

with

18.1

shall

proper

impacted

qualified
personnel
should be notified

parts

of the

S1S which

who have been properly

of the change and trained

to the change.

Objectives

18.1.1

The objectives

of the requirements

of this clause are:

a

to ensure that prior to decommissioning

any safety instrumented
system from
service, a proper review is conducted
and required authorization
is obtained; and

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

out any decommissioning

of a safety
and controlling
changes shall be in place.

shall include a clear method of identifying

the hazards which may be affected.

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

activities shall not begin without proper authorization.

72

lS/lEC 61511-1:2003
19

Information

19.1

and

documentation

requirements

Objectives

19.1.1

The objectives

of the requirements

of this clause are:

to ensure that the necessary information is available and documented

phases of the safety life cycle can be effectively performed; and

to ensure
verification,
performed.

NOTE

in order

that the necessary

information is available
and documented
validation
and functional
safety
assessment
activities
can

For examples

of documentation

NOTE 2 The documentation

to be presented
on screens

structure,

could be available
or displays).

see IEC 61508-1

in different

forms

Annex

in order that
be effectively

A and, for more details,

(for example,

on paper,

that all

IEC 61506.

film or any data

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;

suit the purpose

be available

system

for which

by this standard

in an accessible

and

and maintainable
unique

shall

19.2.4

The documentation

shall have designations

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.

and the use of it;

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

and risk assessment

for

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

a number of factors such as the

reviewed,

approved

and

be

shall be maintained:

and the related

instrumented

for maintaining

upon

amended,
scheme.

to the following

to reference

the type of information.

to the requirements

shall have a revision

of the information.

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

Further details of the requlrenlents

for Infornlatlon

are Includeci III Cla(l%s

14 af}ri 15

i*

74

lS/lEC 61511-1:2003
Annex A
(informative)

Differences

NOTE

This annex

is part of this standard.

It illustrates

the key differences

between

IEC 61511

and IEC 61508.

t

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

-2, -3, and -4 have

into IEC 61511-1

Informative

been combined

for IEC 61511-1

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

IEC 61508 refers to E/E/PE safety related systems

while I EC 61511 refers to safety instrumented
systems

Sls

PES

function

Basic

IEC 61511-1

IEC 61508 PES includes sensors and final control

elements, while IEC 61511 uses the term SIS.
Basic process control
process sector

process control
system

system is a global term for the

IEC 61508 refers to EUC (equipment

while IEC 61511 refers to process

Process

under

control)

IEC 61508 safety function implemented

by E/E/PES,
other technology
safety related system, or external risk
reduction
facilities.
IEC 61511 SIF is implemented
solely by S1S

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 351: Automatic

Part 12. Binary

- 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

for the process industry

integrity /eve/sp

sector

Vocabulary
Vocabulary

- Guidelines
systems

electronic
safety
and IEC 61508-3

Part 1: Fundamental/

for their inclusion

-- 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

Bureau of Indian Standards

established
under the Bureau
BIS IS a statutory institution
harmonious development of the achvities of standardizatmn,
and attending

to connected

matters

of /ndian
marking

Standards

Act, 1986 to promote

and quality

certification

of goods

in the country.

Copyrigh
61S has the copyright
form without

of all its publications.

No part of these publications
may be reproduced
in any
the prior permission
in writing of 51S. This does not preclude the free use, in course of

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

as the need arises

on the basis

of comments.

Standards

are

aisu reviewed periodically;

a standard along with amendments
is reaffirmed when such review
Indicates that no changes are needed; if the review indicates that changes are needed, it is taken up
for revision.
Users of Indian Standards should ascertain that they are m possession of the latest
amendments or edition by referring to the latest issue of 61S Catalogue and Standards: Monthly
Additions.
This Indian Standard

has been developed

from Dot: No. ETD 18 (5712).

Amendments
Amendment

Issued Since Publication

Date of Issue

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 :

Manak Bhavan, 9 Bahadur Shah Zafar Marg

NEVV DELHI 110002

23237617
{ 23233841

Eastern :

1/14, C.I.T. Scheme WI M, V.i. P. Road, Kankurgac!w

KOLKATA 700054

Northern : S(XI 335-336,

Southern : C. I.-[. Campus,

Sector 34-A, CHANDIGPRH

160022

IV Cross Road, (X--lENNi%I600113

Western : Manakalaya, E9 MlDC, Marol, Andheri (East)

MUMBA! 400093
Branches:

23378499,
{ 23378626,

23378561
23379120
2603843
{ 2609285

22541216,
{ 22542519,

22541442
22542315

28329295, 28327858
{ 28327891,28327892

A!--lMEDABAD. BANGALORE. EWOPAL. BHUBANESHWAR.

COIMBATORE. FARIDABAD.
GHAZIABAD.
GUWAHATI.
HYDERABAD.
JAIPUFf. KANPUR. LUCKNOW.
NAGPUR.
PARWANOO. PATNA. PUNE. RAJKOT. TtilFfUVANANTHAPURAM.
VISAKHAPATNAM.

..
PRINTED

BY THE GENERAL

MANAGER,

GOVT. OF INDIA PRESS,

NASHiK-422

006