The Principles of IEC 61508 and IEC 61511 Day 3

The Principles of
IEC 61508 and IEC 61511

Day 3
C. Timms
Tel: +44 (0) 1339 886618
c.timms@ifb.co.uk
© C & C Technical Support Services 2008 1 Part 3 of IEC 61508/61511 Training

Contents
Topic Page
Software Requirements 5
Relationship between Hardware and Software Architecture 11
Application Software Safety Requirements Specification 13
Application Software validation Planning 16
Requirements for Application Software Architecture 17
Requirements for Support Tools, User Manual and Application 18
Language
Requirements for Application Software Development 22
Requirements for Application Software Module Testing 25
Integration of Application Software with SIS Subsystems 26
FPL and LVL Software Modification Procedures 27
Application Software Verification 28

Contents Cont’d
Topic Page
SIF Interaction With Other Technologies 32
Multiple Functions 41
Primary Functions 49
Intermediate Trips 60
Risk Graph Calibration 64
SIL Determination for Fire and Gas 73
Further Operational Lifecycle Considerations 108
Methods for Solving Complex functions 117

Day 3 Objectives
1. To provide details of the requirements for safety application
software design, development, integration and validation.
2. To equip students with methods that will enable them to undertake

complex SIL determination exercises and understand factors, from
other protection levels, that influence the SIL determination, the
implementation and maintenance N.B. Some of the topics covered in
(2) are not dealt with in the standard. You will be given methods which have
evolved from the experience of a number of practitioners.
3. To undertake SIL determination of mitigating systems such as fire and gas

systems.
4. To be able to use tools to model and solve the PFD of complex Safety
Instrumented Systems

Software Requirements
Three types of software:
application software;
utility software, i.e., the software tools used to develop and verify the
application software;
embedded software, i.e., the software supplied as part of the PE.
Three types of software development language:
fixed program languages (FPL);
limited variability languages (LVL);
full variability languages (FVL).
N.B. The standard is limited to application software developed using
FPL or LVL.
The requirements are suitable for the development and modification
of application software up to SIL 3.
The standard does not differentiate between SIL 1, 2 and 3.

Manage- Safety Verifica-
Hazard & Risk Analysis
ment of Lifecycle
Structure
Clause 8
tion SIS safety lifecycle
Functional 1
Safety and
Planning
phases and functional
and
Functional
Allocation of Safety
Functions to
safety assessment
Safety Protection Layers
Assess-
2 Clause 9 stages
ment and
auditing
Safety Requirements
Specification for the Safety
Instrumented System
3 Clauses 10 & 12
Stage 1
Design and
Design and Engineering of Development of Other
Safety Instrumented System Means of
Clauses 11 & 12 Risk Reduction
4 Clause 9
Stage 2
Installation, Commissioning
and Validation
Clauses 14 & 15
5
Stage 3
Operation and Maintenance

6 Clause 16
Stage 4
Modification
7 Clause 17
Clause 5 Clause 6.2 Stage 5 Clauses 7,

12.4, &
Decommissioning 12.7
10 11
8 Clause 18 9
Legend:
Typical direction of information flow. No detailed requirements given in this standard.
Requirements given in this standard.
NOTES:
1. Stages 1 through 5 inclusive are defined in clause 5.2.6.1.3.
2. All references are for Part 1 unless otherwise noted.

Software Requirements
A safety lifecycle for the development of application software shall
be specified during safety planning.
Verification activities such as quality and safety assurance
procedures shall be integrated into the safety lifecycle.
Each phase of the application software safety lifecycle shall be
divided into activities with:
Objectives
Inputs and outputs of each phase.
Appropriate techniques and measures must be used for each phase.
Each phase with results and activities shall be documented.
If changes are made to any phase then preceding phases and
following phases shall be repeated.

Software Requirements - Fig A
Application software safety lifecycle (realisation)
12.2 -
Design and Software safety requirements specification
development Safety functions Safety integrity
requirements requirements
of SIS specification specification
12.3 - Software safety 12.4 - Software design

validation planning configuration and planning
12.5 - PE integration 12.6 - Software operation &

(hardware/software) modification procedures
Software safety
validation
Validation SIS operation and

maintenance

Software development lifecycle
(the V-model)
SIS Safety
Requirements SIS Safety
Validated
Specification Validation
SIS
Application
Sub-system Software Safety
architecture Requirements
Specification PES
Application
software
Integration
testing
Application Software
Architecture design
Application Application
software software
development Testing
Application Application
module module
development testing
Output Code development &

Verification test - FVL only –
see IEC 61508-3

Application software safety lifecycle: overview
Require-
Objectives ments Information Required Required Results
Safety lifecycle phase clause
Figure A Title
box number
•12.2 •Application •To specify the requirements for the software •12.2.2 •SIS safety requirements •SIS application software safety
Software safety instrumented functions for each SIS specification requirements specification;
safety function necessary to implement the required •Safety manuals of the •Verification information.
requirements safety instrumented functions. selected SIS
specification •To specify the requirements for software •SIS architecture.
safety integrity for each safety instrumented
function allocated to that SIS.
•12.3 •Application •To develop a plan for validating the •14.3.2 •SIS application Software •SIS application Software safety
Software application software. safety requirements validation plan;
safety specification. •Verification information.
validation
planning
•Application •Architecture: •12.4.3 •SIS application Software •Description of the architecture

12.4 Software •To create a software architecture that fulfils safety requirements design;
design, and the specified requirements for software specification; •e.g., segregation of application S/W
development safety. •SIS hardware architecture into related process subsystem and
•To review and evaluate the requirements design manuals. SIL(s).
placed on the software by the hardware •E.g., recognition of common
architecture of the SIS. application S/W modules such as
pump or valve sequences.
•Application Software architecture
and sub-system integration test
specification;
•Verification information.
•12.4 cont’d •Application •Support tools and programming languages: •12.4.4 •SIS application Software •List of procedures for use of utility
Software •To identify a suitable set of configuration, safety requirements software.
design, and library, management, and simulation and test specification; •Verification information.
development. tools, over the whole safety lifecycle of the •Description of the
software (utility software); architecture design;
• •Manuals of the SIS.
•To specify the procedures for development •Safety Manual of the
of the application software. Selected SIS Logic Solver.
Relationship between the hardware
and software architectures of SIS
Programmable SIS Subsystem Architecture

software architecture (s/w architecture consists
hardware architecture of embedded s/w and applications s/w)
Generic and application embedded software application software
specific features in hardware.
Examples include: Examples include: Examples include:
− diagnostic tests; − communications − input/output functions;
− redundant processors; drivers; − derived functions (for
− dual I/O cards. − fault handling; example sensor checking if
− executive software. not provided as a service of
the embedded software).

Objectives Require-
Safety lifecycle phase ments Information Required Required Results
Figure A box Title
clause
number
Application Software • Application software development and • 12.4. • Description of the • 1) Application software
12.4 design, and application module development 5 architecture program (e.g., function block
cont’d deveopment. • To implement the application software • design. diagrams, ladder logic);
that fulfils the specified requirements • List of manuals and
for application safety. proceedures of the
selected PES for use of • 2) Application program
utility software. simulation and integration test
• 3) Special purpose application

safety requirements
specification.
•
4) Verification information.
• 12.4 • Application • Program Development and Test – FVL • 12.4. • Special purpose • Refer to IEC 61508-3
cont’d program only: 6& application software
development • To implement full variability language 12.4. safety specification
using full that fulfil the specified requirements for 7 requirements.
variability software safety.
languages
• 12.4 • Application • Software and Application testing: • 12.4. • Application program • 1) Software test results.
cont’d Software • 1) To verify that the requirements for 6, simulation and • 2) Verified and tested software
• design and software safety have been achieved; 12.4. integration test system.
development • 2) To show that all application program 7, specification (structure • 3) Verification information.
subsystems and system interact 12.7 based testing);
correctly to perform their intended • Software architecture
functions and do not perform integration test
unintended functions. specification.
• Can be merged with the next phase
(12.5) subject to satisfactory test
coverage.
• 12.5 • Programmabl • To integrate the software onto the • 12.5. • Software and hardware • Software and hardware
e electronics target programmable electronic 2 integration test integration test results;
integration hardware. specification. • Verified software and
• (hardware hardware.
and software)
• 14.3 • SIS safety • Validate that the SIS, including the • 14.3 • Software and SIS safety • Software and SIS validation
validation safety application software, meets the validation plans. results.
safety requirements.

Application software safety
requirements specification
To provide requirements for the specification of the
application software safety requirements for each
programmable SIS subsystem necessary to implement
the required safety instrumented function(s) consistent
with the architecture of the SIS and:
are clear to those who will utilize the document at any stage of
the SIS safety lifecycle; this includes the use of terminology
and descriptions which are unambiguous and understood by
plant operators and maintainers as well as the application
programmers;
are verifiable, testable, modifiable;
are traceable back to the specification of the safety
requirements of the SIS.

Sufficiently detailed to cover:
the functions supported by the application software;
capacity and response time performance;
equipment and operator interfaces and their operability;
all relevant modes of operation of the process as specified in the SIS
safety requirement specification;
action to be taken on bad process variable such as sensor value out of
range, detected loose wire open circuit, detected short circuit, etc.;
proof tests and diagnostic tests of external devices (e.g., sensors and
final elements);
software self-monitoring (e.g., includes application driven watch-dogs
and data range validation);
monitoring of other devices within the SIS (e.g., sensors and final
elements);
enabling periodic testing of safety instrumented functions when the
process is operational;
references to the input documents (e.g., specification of the SIF,
configuration or architecture of the SIS, hardware safety integrity
requirements of the SIS).
The application software safety requirements
specification shall provide information allowing proper
equipment selection. The following shall be considered:
functions that enable the process to achieve or maintain a safe
state;
functions related to the detection, annunciation and management
of faults in all SIS subsystems of the SIS;
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 modified;
interfaces to non safety-related functions;
capacity and response time performance;
the safety integrity levels for each of the above functions.

validation planning
Five main objectives:
1. To create an application software architecture that is consistent with the
hardware architecture fulfilling the specified requirements for software
safety.
2. To review and evaluate the requirements placed on the software by
the hardware and embedded software architecture of the SIS,
including:
side effects of the SIS hardware/software behaviour;
the application specific configuration of SIS hardware;
the inherent fault tolerance of the SIS;
the interaction of the SIS hardware and embedded software
architecture with the application software for safety.
3. To select a suitable set of tools (including utility software), to develop
the application software.
4. To design and implement or select application software that fulfils the
specified requirements for software safety (see clause 12.2) that is
analysable, verifiable and capable of being safely modified.
5. To verify that the requirements for software safety (in terms of the
required software safety instrumented functions) have been achieved.
Requirements for application
software architecture
The description of the application software architecture
design shall:
provide a comprehensive description of the internal structure and
of the operation of the SIS subsystem and of its components;
include the specification of all identified components, and the
description of connections and interactions between identified
components (software and hardware);
identify the software modules included in the SIS subsystem but
not used in any SIF;
describe the order of the logical processing of data with respect
to the input/output sub-systems and the logic solver functionality,
including any limitations imposed by scan times;
identify all non-SIF and ensure they can not affect the proper
operation of any SIF.

Requirements for support tools, user
manual and application languages
The safety manual shall address the following

items as appropriate:
use of diagnostics to perform safe functions;
list of certified/verified safety libraries;
mandatory test and system shutdown logic;
use of watchdogs;
requirements for, and limitations of tools and
programming languages;
safety integrity levels that the device or system is
suitable for.

A suitable set of tools, including:
a sub-set of the application programming language;
configuration management;
simulation;
test harness tools;
when applicable automatic test coverage measurement tools.
A suitable set of procedures for use of the tools should
be identified, taking into account:
safety manual constraints;
known weaknesses likely to introduce faults into the application
software;
any limitations on the coverage of earlier verification and
validation.

The application language selected shall:
be implemented using a translator/compiler that has
been assessed to establish its fitness for purpose;
be completely and unambiguously defined or
restricted to unambiguously defined features;
match the characteristics of the application;
contain features that facilitate the detection of
programming mistakes; and
support features that match the design method.

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, etc.);
identify checks to detect faults in the configuration;
specify procedures for documentation of the
application program.

software development
The following information shall be available prior to the
start of detailed application software design:
1. the specification of software safety requirements;
2. the description of the application software architecture design
including identification of the application logic and fault tolerant
functionality;
3. list of input and output data;
4. the generic software modules and support tools to be used;
5. the procedures for programming the application software.

The application software should be produced in

a structured way to achieve:
modularity of functionality;
testability of functionality (including fault tolerant
features) and of internal structure;
the capacity for safe modification;
traceability to and explanation of application functions
and associated constraints.

The design of each application module shall address
robustness including:
plausibility checks of each input variable including any global
variables used to provide input data;
full definition of input and output interfaces;
system configuration checks including the existence and
accessibility of expected hardware and software modules.
The application software should:
be readable, understandable and testable;
satisfy the relevant design principles;
satisfy the relevant requirements specified during safety planning

software module testing
The configuration of each input point through the processing logic to
the output point shall be checked through review, simulation and
testing techniques to confirm that the I/O data is mapped to the
correct application logic.
Each application software module shall be checked through review,
simulation and testing techniques to determine that the intended
function is correctly executed and unintended functions are not
executed.
The tests shall be suitable for the specific module being tested and
the following shall be considered:
exercising all parts of the application model;
exercising data boundaries;
timing effects due to the sequence of execution;
proper sequence implementation.
The results of the application software module testing shall be
available.
Integration of the application
software with the SIS sub-system
To demonstrate that the application software meets its software
safety requirements specification when running on the hardware and
embedded software used in the SIS sub-system.
Requirements:
Integration tests shall be specified as early in the software safety
lifecycle as possible:
(to ensure the compatibility of the application software with the hardware and
embedded software);
the division of the application software into manageable integration sets;
test cases and test data;
types of tests to be performed;
test environment, tools, configuration and programs;
test criteria on which the completion of the test will be judged; and
procedures for corrective action on failure during test.

FPL and LVL software modification
procedures
Modifications shall be carried out in accordance with
change control procedures with the following additions:
prior to modification an analysis of the effects of the modification
on the safety of the process and on the software design status
shall be carried out and used to direct the modification;
safety planning for the modification and re-verification shall be
available.
modifications and re-verifications shall be carried out in
accordance with the planning;
the planning for conditions required during modification and
testing shall be considered;
all documentation affected by the modification shall be updated;
details of all SIS modification activities shall be available (e.g., a
log).

Application software verification
Two main objectives:

1. To demonstrate that the information is satisfactory.
2. To demonstrate that the output results satisfy the
defined requirements at each phase of the
application software safety lifecycle.

Each phase shall be planned

Requirements:
The results of each phase shall be verified for:
a) the adequacy of the outputs from the particular lifecycle
phase against the requirements for that phase;
b) the adequacy of the review, inspection and/or testing
coverage of the outputs;
c) compatibility between outputs generated at different lifecycle
phases;
d) correctness of the data.

Verification should also address:
testability;
readability;
traceability.
The application program should be verified for:
completeness;
self-consistency;
protection against unauthorised alteration;
consistency with the functional requirements.
Application data should be verified for:
consistency with the data structures;
completeness;
compatibility with the underlying system software (for example
sequence of execution, run-time, etc);
correct data values;
operation within a known safe boundary.

Modifiable parameters should be verified for protection against:
invalid or undefined initial values;
erroneous values;
unauthorised changes;
data corruption.
Communications, process interfaces and associated software
should be verified for:
failure detection;
protection against message corruption; and
data validation.
Non safety functions and process interfaces integrated with safety
related signals and functions should be verified for:
non-interference with the safety functions;
protection against interference with the safety functions in the case of
malfunction of the non-safety functions.

SIF Interaction With Other
Technology

SIF and Relief Valves
But applicable to any form of layered protection
for the same function, e.g.
mechanical over speed protection and SIF,
electric motor overload protection and SIF.

SIF and RV
HH
PZA

SIF and RV - Protection
Relief Valve:
Provides overpressure protection.
Does not stop the event.
SIF:
Provides overpressure protection.
Prevents relief by RV.
Stops the event.

Escalation
Escalation of consequences of failure of overpressure protection:
Initial
Loss of
demand Ignition Escalation
containment
rate
Case 1 Case 2 Case 3
Increasing consequence
Decreasing demand rate

Classification of SIF+RV
(Option 1)
SIL determination of the failure on demand of
the whole pressure protective envelope (i.e.
SIF+RV):
Case 1
Select highest SIF class for total
Case 2 overpressure protection (SIF+RV)
Case 3
SIL determination for SIF failure on demand as
per traditional method:
SIL class for SIF (assuming RV functions properly).

Implementation- Option 1
SIL class for
failure of
protective
envelope
RV
implementation
Distribution of
reliability
requirements
SIF
implementation
SIL class for SIF
Minimum
(assuming RV
implementation
functions
of SIF
properly)

Classification of SIF+RV
(Option 2)
SIL determination of the failure on demand of
the whole pressure protective envelope (i.e.
SIF+RV):
Case 1
Case 2 Select highest SIF class for total
overpressure protection (SIF+RV)
Case 3
Take credit for the RV PFD to reduce overall

SIL for pressure protection:
SIL for SIF will then be residual risk reduction.

Implementation- Option 2
SIL class for
failure of
protective
envelope RV
implementation
Distribution of
reliability
requirements
SIF
implementation
Take credit for the
PFD of the RV

Multiple Functions

Multiple Functions - Double Jeopardy
Where more than one function is performed by an
initiator:
Analyse each function individually;
Assume all other functions operate;
i.e. there is no double jeopardy;
However, what if the initiator fails?
All final elements will fail (simultaneous failure);
The reliability of the initiator may need to be improved;
This eventuality is not covered by the standards;
But may need special consideration.
Multiple Functions - Initiators
Where an initiator activates more than one final
element:
SIL determination can determine the SIL of each final
element, individually, from a functional perspective;
i.e. the assumption is made that all other functions (including
the initiator) operate properly.
An additional consideration is therefore

recommended to determine the consequences of the
initiator failing:
i.e. none of the final elements would be activated;
the criticality of the initiator may be greater if all functions fail.
this is often known as the synergetic consequences

of failure.
Multiple Functions
Flare
PSV
PCV
HH PICA Gas Compression

PZA1
XZV3
Inlet
XZV1 XZV2
LZA1
HH
LICA
LZA2
LL
Oil out
XZV4 LCV

Multiple Functions - Initiators
Final elements
Function 1 XZV3 – Gas

Compression
Instrumented
Initiator e.g. PZA1 Protective XZV1/2 – Inlet
System
Function 2
Function 3 XZV4 – Oil Outlet

Synergetic Consequences
Effect Overall
Initiator
XZV1 XZV2 XZV3 XZV4 SIL for
Cause Failure
Initiator
Initiator 1 1 N/A 1
Initiator 2 1 2 2 2
Initiator 3 (PZA1) 2 2 1 2 3 3
Initiator 4 1 1 1 1
Initiator 5 0 0 N/A 0
Initiator 6 1 N/A 1
Overall SIF Class

2 2 1 2
Final Element

Multiple Functions – Final Elements
Where a final element is acted upon by more

than one initiator:
i.e. the final element is part of multiple loop
functions;
the final element will take the highest SIL
class;
this needs careful tracking in a good cross
reference database.

Multiple Functions – Final Element
Initiators
PZA1 Function 1
Final element
Function 2
Instrumented
Confirmed Protective XZV1/2
High Level System
Gas
LZA1 Function 3

Primary Functions

Primary Functions
Numerous functions may be driven by the

same initiator.
It is important to identify the ‘primary’
function.
This will save considerable time and effort:
With SIL determination;
With Design.
Can save a lot of money.

Primary Functions
API RP 14C
Section 3.4, para b: “The safety system should provide two levels of
protection to prevent or minimise the effects of an equipment failure
within the process. (...) In general, the two levels should be provided
by functionally different types of safety devices for a wider spectrum
of coverage. (...) ”
Section 4.2.3, para 1: “When an abnormal condition is detected in a
process component by a safety device or by personnel, all input
sources of process fluids, heat, and fuel should be shut off or
diverted to other components where they can be safely handled. If
shut-off is selected, process inputs should be shut off at the primary
source of energy. (...) There may be special cases where shut in by
cascading is acceptable. (...)

Primary Functions
Secondary functions:
Often result of pre-emptive tripping of
functions that could cascade.
Would result in large classification exercise.
SOLUTION:
Identify design intent of hazard detection.
This is the primary function.
Only assess the primary function.
Assume that secondary functions don’t exist.

Exercise – Primary & Secondary Functions
C&E
Close
Close
Close
Close
Open
XZV1
XZV2
XZV3
XZV4
XZV5
EDP Manual
Flare
PZA1 X X X X X PSV
LZA1 X X X X
XZV3
LZA2 X X X
EDP X X X X X
PCV
HH Gas Compression
PZA1 PICA
2oo3 XZV4
Inlet Spec.
HH
break
XZV1 XZV2
LZA1
LICA
Q1. Mark up the Primary function
for each initiator in the C&E box? LZA2
LL
Oil out
Q2. Are there any logic simplification
opportunities? XZV5 LCV
Spec.
Q2A: break

Name:
Primary & Secondary Functions
C&E
Close
Close
Close
Close
Open
XZV1
XZV2
XZV3
XZV4
XZV5
EDP Manual
Flare
PZA1 X X X X X PSV
LZA1 X X X X
XZV3
LZA2 X X X
EDP X X X X X
PCV
HH Gas Compression
PZA1 PICA
2oo3 XZV4
Inlet Spec.
HH
break
XZV1 XZV2
LZA1
LICA
Q1. Mark up the Primary function
for each initiator in the C&E box? LZA2
LL
Oil out
Q2. Are there any logic simplification
opportunities? XZV5 LCV
Spec.
Q2A: break

Solution – Primary & Secondary Functions
C&E Close
Close
Close
Close
Open
XZV1
XZV2
XZV3
XZV4
XZV5
EDP Manual
PZA1 X X X X X
Flare
PSV
LZA1 X X X X
XZV3
LZA2 X X X
EDP X X X X X
PCV
HH Gas Compression
PZA1 PICA
2oo3 XZV4
Inlet Spec.
HH
break
XZV1 XZV2
LZA1
LICA
LZA2
LL
Oil out
A2. Why close XZV5 on LZA1 High High level? XZV5 LCV
Spec.
Why close XZV1 and XZV2 on LZA2 a Low Low level? break

Primary Functions
STEPS:
Cause and Effect review to identify primary functions;
Use HAZOP reports,
Classify primary functions;
If primary identified then secondary will have no impact on
consequences;
Check by doing a simultaneous failure of all final elements.
If simultaneous failure results in higher IL then the primary
has not been identified.
Decide if secondary functions need a full classification at
this stage;
i.e. Final elements may have a number of secondary functional
roles, but they will most probably have a primary purpose in
association with a particular initiator.

Primary Functions
“Caution”
Not always easy to spot the primary function.
Danger of missing something.
All elements should be considered somewhere;
Need to cross check that all elements have been
covered. If it is does not serve a primary purpose
in one function then there will most probably be a
function where it does.

Primary Functions
Audit Trail:
Ensure that the following information is still
recorded for each secondary function along with
the primary function:
Its purpose;
Why it was considered secondary;
References to Hazop findings;
Recommendations for any design changes.

Secondary Functions
Logic Simplification
Identify benefits of removal of secondary
functions;
(e.g. simple logic, less re-classifications,
uptime).
If justification exists, build case for removal.
Experience shows that opportunities for
simplification of Brown Field functions is
often not economic.

Intermediate Trips

Intermediate Trips
Emergency
generator room
2ooN
Smoke
Initiators 1 2 3 XB 1 2 3
INTERTRIP
UZ-A UZ-B
Final
elements Shutdown area
Local area protection ventilation
Firewater pump start Shutdown emergency

generator
Audible and visual alarm Isolate generator fuel
supply

Intermediate Trips
Initiators XA 1 2 3 XB 1 2 3
INTERTRIP
UZ-A UZ-B
Final 1 2 3 1 2 3
YA YB
elements
STEPS:
Determine the SIL for each initiator XA to final elements YA
Determine the SIL for each initiator XB to final elements YB
Determine the SIL for each initiator XA to INTERTRIP (i.e. synergetic failure of YB)
Determine the SIL of the INTERTRIP to each YB (W = sum of XA demands)

Intermediate Trips
Initiators XA 1 2 3 XB 1 2 3
INTERTRIP1
UZ-A INTERTRIP2 UZ-B
Final 1 2 3 1 2 3
YA YB
elements
STEPS:
Determine the SIL for each initiator XA to final elements YA
Determine the SIL for each initiator XB to final elements YB
Determine the SIL for each initiator XA to INTERTRIP1 (Synergetic failure of all YB )
Determine the SIL of the INTERTRIP1 to each YB (W = sum of XA demands)
Determine the SIL for each initiator XB to INTERTRIP2 (Synergetic failure of all YA )
Determine the SIL of the INTERTRIP2 to each YA(W = sum of XB demands)

Risk Graph Calibration

There are problems with a purely qualitative
approach:
Inconsistency with interpretation:
What is a ‘Relatively High’, ‘Low’ or ‘Very Low’
frequency?
How long is an occupancy of ‘Rare’ or ‘Frequent’?
How many people in ‘Multiple’?
How many people make a ‘Catastrophe’?
Difficulty with demonstrating ALARP:
How to set a ‘tolerable’ risk reduction;
How to establish the risk reduction achieved.
Semi quantifying (i.e. calibrating) significantly
improves risk assessment.

All semi quantified methods require:

A corporate value for ‘Tolerable Risk’ for both
individual and societal risk;
Quantification of the demand frequencies;
Quantification of the Consequence severities;
Quantification of each IPL (as in LOPA);
Quantified risk reduction for each mitigation claimed.

Tolerability of risk and ALARP – HSE (1992)
UK HSE R2P2
Intolerable region guidance:
1 in 1000 per person/yr (Workers)

1 in 10,000 per person/yr (Public)
The ALARP or
tolerability region Tolerable risk
( Risk is undertaken only if a
benefit is desired)
1 in 1 million per person/yr
Broadly acceptable
region
(No need for detailed working to
demonstrate ALARP) 1 in 10 million per person/yr
Negligible risk
Setting the Safety Target
Example of calibration: Parameter Low Value High Value
W3 0.3 3.0
An example Risk Graph W2 0.03 0.3

parameters are assigned the W1 0.003 0.03
following values: CA Minor Minor
CB 0.01 0.1
A ‘typical’ SIL determination
CC 0.1 1.0
results in a risk path with the
highlighted parameters CD >1.0
FA 0.01 0.1
Each parameter has a range of FB 0.1 1.0
values with a: PA 0.1 0.1
‘low’ end value; PB 1.0 1.0
‘high’ end value.
SIL 1 0.01 0.1
SIL 2 0.001 0.01
SIL 3 0.0001 0.001
SIL 4 0.00001 0.0001

Low Range values
Taking parameters W2, CC, FA, PB W3 W2 W1
then: CA X1
a --- ---
If all parameters at ‘low’ end of X2
range, Starting point
PA 1 a ---
for risk reduction
CB FA PB X3
estimation
FB PA 2 1 a
CC PB X4
FA
FB 3 2 1
‘A’ = best case risk CD
PA
PB X5
FA
reduction
Generalized arrangement
(in practical implementations FB PA 4 3 2
the arrangement is specific to PB X6
the applications to be covered
by the risk graph) b 4 3
C = Consequence parameter --- = No safety requirements
F = Exposure time parameter a = No special safety requirements
P = Possibility of failing to avoid hazard parameter b = A single E/E/PES is not sufficient
W = Demand rate assuming no protection 1, 2, 3, 4 = Safety integrity level
A = Low CC * Low FA * PB * Low W2 * Low SIL 2

A = 0.1 * 0.01 * 1 * 0.03 * 0.001 = 3.0E-08
High Range values
Taking parameters W2, CC, FA, PB
W3 W2 W1
then: X1
CA
a --- ---
If all parameters at ‘high’ end of
X2
range, Starting point
PA 1 a ---
for risk reduction
CB FA PB X3
estimation
FB PA 2 1 a
CC PB X4
FA
‘B’ = worst case risk FB PA 3 2 1
PB
reduction Generalized arrangement
(in practical implementations
CD FA
FB PA
X5
4 3 2
the arrangement is specific to PB X6
by the risk graph) b 4 3
B = High CC * High FA * PB * High W2 * High SIL 2

B = 1.0 * 0.1 * 1 * 0.3 * 0.01 = 3.0E-04
Example of Calibration
The risk reduction afforded by the best case:
A = 3.0E-08
The risk reduction afforded by the worst case:
B = 3.0E-04
Average Risk value is the logarithmic average of the

Best and Worst risk figures
Ln(Average risk) = (Ln A +Ln B)/2
Ln(Average risk) = ((Ln(3.0E-08) +Ln(3.0E-04))/2
Average risk (Safety Target) = 3.0E-06 for any
single Hazard

Typical Risk Graph Calibration
Calibration of Personnel Safety Risk Graphs
For definitions and assumptions see sheet "Definitions B"
General Risk Graph
Alternatives to Avoid
Consequence Severity Range Personnel Exposure the Danger Demand Rate (per year) Safety Integrity Level Individual Risk
Risk SIL
Low High Redn Low High SIL Low High
C Low Value High Value Category Value Value Category Factor Category Value Value SIL Value Value Best Average Worst Remarks
CB 0.01 0.10 Rare 0.01 0.1 Possible 0.1 Rel High 0.3 3 1 0.01 0.1 3.E-08 3.E-06 3.E-04
CB 0.01 0.10 Rare 0.01 0.1 Possible 0.1 Low 0.03 0.3 0 0.1 1 3.E-08 3.E-06 3.E-04
CB 0.01 0.10 Rare 0.01 0.1 Possible 0.1 Very Low 0.003 0.03 0 0.1 1 3.E-09 3.E-07 3.E-05
CB 0.01 0.10 Rare 0.01 0.1 Possible 0.1 Ex Low 0.0003 0.003 0 0.1 1 3.E-10 3.E-08 3.E-06
CB 0.01 0.10 Rare 0.01 0.1 Possible 0.1 Improb 3E-05 0.0003 0 0.1 1 3.E-11 3.E-09 3.E-07
CB 0.01 0.10 Rare 0.01 0.1 Not Likely 1 Rel High 0.3 3 2 0.001 0.01 3.E-08 3.E-06 3.E-04
CB 0.01 0.10 Rare 0.01 0.1 Not Likely 1 Low 0.03 0.3 1 0.01 0.1 3.E-08 3.E-06 3.E-04
CB 0.01 0.10 Rare 0.01 0.1 Not Likely 1 Very Low 0.003 0.03 0 0.1 1 3.E-08 3.E-06 3.E-04
CB 0.01 0.10 Rare 0.01 0.1 Not Likely 1 Ex Low 0.0003 0.003 0 0.1 1 3.E-09 3.E-07 3.E-05
CB 0.01 0.10 Rare 0.01 0.1 Not Likely 1 Improb 3E-05 0.0003 0 0.1 1 3.E-10 3.E-08 3.E-06
CB 0.01 0.10 Frequent 0.1 1 Possible 0.1 Rel High 0.3 3 2 0.001 0.01 3.E-08 3.E-06 3.E-04
CB 0.01 0.10 Frequent 0.1 1 Possible 0.1 Low 0.03 0.3 1 0.01 0.1 3.E-08 3.E-06 3.E-04
CB 0.01 0.10 Frequent 0.1 1 Possible 0.1 Very Low 0.003 0.03 0 0.1 1 3.E-08 3.E-06 3.E-04
CB 0.01 0.10 Frequent 0.1 1 Possible 0.1 Ex Low 0.0003 0.003 0 0.1 1 3.E-09 3.E-07 3.E-05
CB 0.01 0.10 Frequent 0.1 1 Possible 0.1 Improb 3E-05 0.0003 0 0.1 1 3.E-10 3.E-08 3.E-06
CB 0.01 0.10 Frequent 0.1 1 Not Likely 1 Rel High 0.3 3 3 0.0001 0.001 3.E-08 3.E-06 3.E-04
CB 0.01 0.10 Frequent 0.1 1 Not Likely 1 Low 0.03 0.3 2 0.001 0.01 3.E-08 3.E-06 3.E-04
CB 0.01 0.10 Frequent 0.1 1 Not Likely 1 Very Low 0.003 0.03 1 0.01 0.1 3.E-08 3.E-06 3.E-04
CB 0.01 0.10 Frequent 0.1 1 Not Likely 1 Ex Low 0.0003 0.003 0 0.1 1 3.E-08 3.E-06 3.E-04
CB 0.01 0.10 Frequent 0.1 1 Not Likely 1 Improb 3E-05 0.0003 0 0.1 1 3.E-09 3.E-07 3.E-05
CC 0.10 1.00 Rare 0.01 0.1 Possible 0.1 Rel High 0.3 3 2 0.001 0.01 3.E-08 3.E-06 3.E-04
CC 0.10 1.00 Rare 0.01 0.1 Possible 0.1 Low 0.03 0.3 1 0.01 0.1 3.E-08 3.E-06 3.E-04
CC 0.10 1.00 Rare 0.01 0.1 Possible 0.1 Very Low 0.003 0.03 0 0.1 1 3.E-08 3.E-06 3.E-04
CC 0.10 1.00 Rare 0.01 0.1 Possible 0.1 Ex Low 0.0003 0.003 0 0.1 1 3.E-09 3.E-07 3.E-05
CC 0.10 1.00 Rare 0.01 0.1 Possible 0.1 Improb 3E-05 0.0003 0 0.1 1 3.E-10 3.E-08 3.E-06
CC 0.10 1.00 Rare 0.01 0.1 Not Likely 1 Rel High 0.3 3 3 0.0001 0.001 3.E-08 3.E-06 3.E-04
CC 0.10 1.00 Rare 0.01 0.1 Not Likely 1 Low 0.03 0.3 2 0.001 0.01 3.E-08 3.E-06 3.E-04
CC 0.10 1.00 Rare 0.01 0.1 Not Likely 1 Very Low 0.003 0.03 1 0.01 0.1 3.E-08 3.E-06 3.E-04
CC 0.10 1.00 Rare 0.01 0.1 Not Likely 1 Ex Low 0.0003 0.003 0 0.1 1 3.E-08 3.E-06 3.E-04
CC 0.10 1.00 Rare 0.01 0.1 Not Likely 1 Improb 3E-05 0.0003 0 0.1 1 3.E-09 3.E-07 3.E-05
CC 0.10 1.00 Frequent 0.1 1 Possible 0.1 Rel High 0.3 3 3 0.0001 0.001 3.E-08 3.E-06 3.E-04
CC 0.10 1.00 Frequent 0.1 1 Possible 0.1 Low 0.03 0.3 2 0.001 0.01 3.E-08 3.E-06 3.E-04
CC 0.10 1.00 Frequent 0.1 1 Possible 0.1 Very Low 0.003 0.03 1 0.01 0.1 3.E-08 3.E-06 3.E-04
CC 0.10 1.00 Frequent 0.1 1 Possible 0.1 Ex Low 0.0003 0.003 0 0.1 1 3.E-08 3.E-06 3.E-04
CC 0.10 1.00 Frequent 0.1 1 Possible 0.1 Improb 3E-05 0.0003 0 0.1 1 3.E-09 3.E-07 3.E-05
CC 0.10 1.00 Frequent 0.1 1 Not Likely 1 Rel High 0.3 3 4 0.00001 0.0001 3.E-08 3.E-06 3.E-04
CC 0.10 1.00 Frequent 0.1 1 Not Likely 1 Low 0.03 0.3 3 0.0001 0.001 3.E-08 3.E-06 3.E-04
CC 0.10 1.00 Frequent 0.1 1 Not Likely 1 Very Low 0.003 0.03 2 0.001 0.01 3.E-08 3.E-06 3.E-04
CC 0.10 1.00 Frequent 0.1 1 Not Likely 1 Ex Low 0.0003 0.003 1 0.01 0.1 3.E-08 3.E-06 3.E-04
CC 0.10 1.00 Frequent 0.1 1 Not Likely 1 Improb 3E-05 0.0003 0 0.1 1 3.E-08 3.E-06 3.E-04
CD 1.00 10.00 Rare 0.01 0.1 Possible 0.1 Rel High 0.3 3 3 0.0001 0.001 3.E-08 3.E-06 3.E-04
CD 1.00 10.00 Rare 0.01 0.1 Possible 0.1 Low 0.03 0.3 2 0.001 0.01 3.E-08 3.E-06 3.E-04
CD 1.00 10.00 Rare 0.01 0.1 Possible 0.1 Very Low 0.003 0.03 1 0.01 0.1 3.E-08 3.E-06 3.E-04
CD 1.00 10.00 Rare 0.01 0.1 Possible 0.1 Ex Low 0.0003 0.003 0 0.1 1 3.E-08 3.E-06 3.E-04
CD 1.00 10.00 Rare 0.01 0.1 Possible 0.1 Improb 3E-05 0.0003 0 0.1 1 3.E-09 3.E-07 3.E-05
CD 1.00 10.00 Rare 0.01 0.1 Not Likely 1 Rel High 0.3 3 4 0.00001 0.0001 3.E-08 3.E-06 3.E-04
CD 1.00 10.00 Rare 0.01 0.1 Not Likely 1 Low 0.03 0.3 3 0.0001 0.001 3.E-08 3.E-06 3.E-04
CD 1.00 10.00 Rare 0.01 0.1 Not Likely 1 Very Low 0.003 0.03 2 0.001 0.01 3.E-08 3.E-06 3.E-04
CD 1.00 10.00 Rare 0.01 0.1 Not Likely 1 Ex Low 0.0003 0.003 1 0.01 0.1 3.E-08 3.E-06 3.E-04
CD 1.00 10.00 Rare 0.01 0.1 Not Likely 1 Improb 3E-05 0.0003 0 0.1 1 3.E-08 3.E-06 3.E-04
CD 1.00 10.00 Frequent 0.1 1 Possible 0.1 Rel High 0.3 3 4 0.00001 0.0001 3.E-08 3.E-06 3.E-04
CD 1.00 10.00 Frequent 0.1 1 Possible 0.1 Low 0.03 0.3 3 0.0001 0.001 3.E-08 3.E-06 3.E-04
CD 1.00 10.00 Frequent 0.1 1 Possible 0.1 Very Low 0.003 0.03 2 0.001 0.01 3.E-08 3.E-06 3.E-04
CD 1.00 10.00 Frequent 0.1 1 Possible 0.1 Ex Low 0.0003 0.003 1 0.01 0.1 3.E-08 3.E-06 3.E-04
CD 1.00 10.00 Frequent 0.1 1 Possible 0.1 Improb 3E-05 0.0003 0 0.1 1 3.E-08 3.E-06 3.E-04
CD 1.00 10.00 Frequent 0.1 1 Not Likely 1 Rel High 0.3 3 NR * * * * *
CD 1.00 10.00 Frequent 0.1 1 Not Likely 1 Low 0.03 0.3 4 0.00001 0.0001 3.E-08 3.E-06 3.E-04
CD 1.00 10.00 Frequent 0.1 1 Not Likely 1 Very Low 0.003 0.03 3 0.0001 0.001 3.E-08 3.E-06 3.E-04
CD 1.00 10.00 Frequent 0.1 1 Not Likely 1 Ex Low 0.0003 0.003 2 0.001 0.01 3.E-08 3.E-06 3.E-04
CD 1.00 10.00 Frequent 0.1 1 Not Likely 1 Improb 3E-05 0.0003 1 0.01 0.1 3.E-08 3.E-06 3.E-04

SIL Determination
for
Fire & Gas

Risk Reduction Layers
Emergency Response Procedures
Mitigation Systems Layer

e.g. Fire & Gas
Other Preventative Layers

e.g. Mechanical Relief
Instrument-Based Protective Layer
Alarm Layer
Process Control Layer
Process
Design

SIL Determination for Fire & Gas
Something else will have failed before there can
be a a fire event or gas release e.g.:
Design defect;
A mechanical failure;
Loss of containment;
Leak;
Operational error;
Control failure.
In most cases a number of protective layers will
need to fail before there is a demand on the F &
G systems.
F&G are also ‘power on’ to activate.
Thus the demand on Fire and Gas tends to be
low.
This can be a problem for risk assessment
since:
The event frequency is more difficult to establish;
Many scenarios are often out with site experience.
We still need to establish the risk reduction
attributable to Fire and Gas.
The frequency of demand is fundamental to
making any risk assessment.

We know: Risk = Frequency x Consequence.

We require the best possible data to establish
risk and this includes the likelihood or frequency
of a Fire and Gas related event.
One of the ways of obtaining this is to use
Quantitative Risk Assessment (QRA) data to
determine the likelihood.
This is often available where Safety Cases and
top tier COMAH submissions have been made.

QRA Analysis
TR TR TR TR
Ignited Ignited Fire Explosive Explosiv Impairment Impairment Impairment Impairment
Release Release event event Fire event event event e event Explosion Explosion Fire Freq Fire Years
Source of event Freq Years Freq Years Freq Years Freq Years Freq Years
AB01 2.48E-02 40 8.45E-04 1183 7.87E-04 1271 5.73E-05 17452 - - - -
AB01 4.73E-02 21 1.66E-03 602 1.29E-03 775 3.63E-04 2755 4.42E-07 67873 1.58E-06 18987
CELL 1.53E-05 65359 - - - - - - - - - -
DRILL 2.00E-04 5000 6.80E-06 147059 3.40E-06 294118 3.40E-06 294118 6.43E-08 466563 6.43E-08 466563
EXT 2.57E-03 389 8.74E-05 11442 8.18E-05 12225 5.54E-06 180505 - - - -
BB01 3.04E-03 329 1.03E-04 9709 1.00E-04 10000 2.89E-06 346021 4.39E-09 6833713 8.37E-08 358423
BB03 3.19E-02 31 1.08E-03 926 1.08E-03 926 2.37E-06 421941 2.14E-06 14019 6.76E-08 443787
M01N 8.70E-04 1149 2.61E-04 3831 1.31E-04 7634 1.31E-04 7634 7.40E-07 40541 2.47E-06 12146
M01S 1.32E-01 8 4.55E-03 220 3.96E-03 253 5.89E-04 1698 5.74E-08 522648 7.37E-06 4071
M01E 6.30E-02 16 2.14E-03 467 2.14E-03 467 - - - - 1.18E-05 2542
M01W 1.44E-02 69 4.89E-04 2045 4.45E-04 2247 4.37E-05 22883 2.19E-05 1370 3.00E-06 10000
PG 001 2.03E-01 5 2.03E-03 493 2.03E-03 493 - - - - 1.12E-05 2679
PG002 4.78E-01 2 5.74E-03 174 4.61E-03 217 1.13E-03 885 1.03E-04 291 1.67E-06 17964
PG003 1.59E-01 6 2.07E-03 483 1.62E-03 617 4.48E-04 2232 4.08E-05 735 - -
PG004 2.92E-01 3 2.92E-03 342 2.76E-03 362 1.80E-04 5556 1.27E-05 2362 - -
PG005 9.77E-03 102 9.77E-05 10235 9.77E-05 10235 - - - - - -
SEA 1.67E-02 60 - - - - - - - - - -
DRILL 3.84E-01 3 1.11E-02 90 8.66E-03 115 2.47E-03 405 3.97E-07 75567 1.39E-06 21583
Test Sep 1.45E-02 69 1.45E-04 6897 1.45E-04 6897 - - - - 5.44E-07 55147
De-Air 2.47E-02 40 2.47E-04 4049 2.47E-04 4049 - - - - 1.36E-06 22059
TOTAL 1.90E+00 1 3.56E-02 28 3.02E-02 33 5.43E-03 184 1.82E-04 165 4.26E-05 704

Only provides mitigation i.e. after the event
risk reduction.
Two different scenarios:
Case 1, Immediate effect:
relatively small consequence;
relatively high demand rate.
Case 2, Escalation scenario:

very large consequence;
extremely low probability.
Therefore two IL determinations → select

the highest IL.
Escalation (Gas)
Initial
Loss of
demand Ignition Escalation
containment
rate
Case 1 Case 2

Escalation (Fire)
Initial
Local
Fire demand Escalation
impact
rate
Case 1 Case 2

Flammable Gas Case 1 – Immediate effect:
To detect and alert presence of gas;
Remove personnel from danger area.
To isolate electrical sources of ignition;
Failure will result in ignition.
Activate deluge (if available);
Reduces explosive energy.
Many gas releases are visually detected by
operations;
Manual intervention may be possible.
Vulnerability to personnel dependent on size of
release/accumulation and location.

Flammable Gas Case 2- Reducing escalation:

Close all primary isolation valves in area;
Initiate Blow-down;
Limits/reduces inventory;
Reduce impact of any jet fires;
Reduces potential for escalation;
Activate deluge;
Reduces potential for overpressure.

Toxic Gas Case 1 – Immediate effect:
To detect and alert presence of gas;
Prevent others from entering the area;
Failure could result in harm.
Vulnerability to personnel dependent on size of
release/accumulation.
Note.
In the case of H2S associated with flammable gas.
Flammable gas detectors will usually alarm before H2S
detectors.
H2S detectors installed for concentration above 500
ppmv.

Toxic Gas Case 2- Reducing escalation:

Limits inventory;
Reduces potential for escalation.

Fire Case 1 – Immediate effect:
To detect and alert presence of fire;
Prevent people entering the area;
Activate deluge or dispersant release;
Limit local damage.
Fires tend to be visible with smoke and/or flame;
Manual intervention may be possible.
Vulnerability to personnel depends on material,
quantity, location and type of fire (e.g. pool, jet etc.)

Fire Case 2- Reducing escalation:

Limits inventory;
Reduces potential for escalation.
Activation of deluge;
Also reduces potential for escalation;
If fire escalates other area detection will initiate.

Have all the primary elements been assessed?
Having considered issues such as isolation and blow-
down there may be other executive actions of
equal/more importance.
Undertake a SIL determination which considers the
synergetic failure of all executive actions.
If the consequences are no greater then the primary
functions have been revealed.
If the consequences are more severe the primary
function still needs to be determined from the
remaining group of functions.

SIL determination using risk graphs

Risk graphs are more effective when:
A corporate Safety Target has been set.
A set of ‘extended’ graphs may be needed:
With one/two additional columns for low frequency
events;
The extended columns only to be used with
supporting QRA data.

Extended Risk Graphs for Fire & Gas
PERSONAL SAFETY PRODUCTION AND EQUIPMENT LOSS
S0 L0
W3 W2 W1 W0 W3 W2 W1 W0
S1 L1
- - - - - - - -
G1 L2
A1 1 - - - START - - - -
G2 L3
S2 2 1 - - 1 1 - -
G1 L4
A2 2 1 1 - 2 2 1 1
START G2
3 2 1 1
A1
ENVIRONMENT
S3 3 3 2 1 E0
A2 W3 W2 W1 W0
NR 3 3 2
E1
S4 1 - - -
NR NR NR 3
E2
START 2 1 - -
E3
Frequency of demand: 1
3 3 2
W0 Extremely low (demand rate of once between 300 and 3000 years) E4
W1 Very low (demand rate of once between 30 and 300 years) NR NR 3 2
W2 Low (demand rate of once between 3 and 30 years)
W3 Relatively high (demand rate between once in 0.3 and 3 years)
UKOOA Graphs

IEC 61511 Extended Personnel Protection
W3 W2 W1 W0 W00
CA X1
a --- --- --- ---
X2
Starting point
for risk reduction
PA 1 a --- --- ---
CB FA PB
estimation
FB PA
X3
2 1 a --- ---
PB
CC FA
FB PA
X4
3 2 1 a ---
PB X5
CD FA
FB PA 4 3 2 1 a
the arrangement is specific to X6
PB
by the risk graph) b 4 3 2 1
W3

Demand rate between 3 and 0.3 per year. (0.3 and 3 years)
Demand rate between 0.3 and 0.03 per year. (3 and 33 years)
For demonstration
W2
W1 Demand rate between 0.03 and 0.003 per year. (33 and 333 years) purposes only
Demand between 0.003 and 0.0003 per year. (333 and 3,333 years)
W0
Demand greater than 0.0003 year. (greater than 3,333 years)
W00

IEC 61511 Extended Asset Loss
W3 W2 W1 W0 W00
C
A
a --- --- --- ---
X2
Starting point
for risk reduction
PA 1 a --- --- ---
CB PB
estimation
FB PA
X3
2 1 a --- ---
PB
CC
FB PA
X4
3 2 1 a ---
PB X5
CD
FB PA 4 3 2 1 a
PB
W3
For demonstration
W2
W0
W00

IEC 61511 Extended Environmental Impact
W3 W2 W1 W0 W00
C
A
a --- --- --- ---
X2
Starting point
for risk reduction
PA 1 a --- --- ---
CB PB
estimation
FB PA
X3
2 1 a --- ---
PB
CC
FB PA
X4
3 2 1 a ---
PB X5
CD
FB PA 4 3 2 1 a
PB
W3
For demonstration
W2
W0
W00

SIL determination using Layers of Protection
Analysis (LOPA).
LOPA can be used when:
A corporate Safety Target has been set;
Event likelihood data is available;
e.g. pipe failure data or QRA data for undesirable
events.
There is risk reduction data available for:
Each layer of protection;
Each layer of additional mitigation.

Example: LOPA for Fire and Gas
Note: Severity Level E = Extensive; S = Severe; M = Minor
Likelihood values are events per year, other numerical data are PFD average
0 1 2 3 4 5 6 7 8 9 10 11
Protection Layers
Impact Severity Initiating Initiating General BPCS Additional Additional Additional Intermediate SIF Mitigated Notes
Event Level Cause Likelihood Process Mitigation Mitigation Mitigation Event Integrity event
Description Design A B C Likelihood Level Likeliho-
od
Gas Pipe 0.001 0.1 0.1 0.5 5E-06 1E-07 SIF to

1 release in
S hole alert
From Restricted Vulnerability Wind
process QRA access direction and
areas isolate
power
The Corporate criteria has been specified as <1E-07, and the Intermediate Event likelihood
does not meet this. The team decide to add a SIF to reduce the risk further.
The PFD required for the SIF is 1E-07/5.0E-06 = 2E-02 ( SIL 1)

Alarm and executive action in one function:
Assess consequences for both purposes.
Multiple F&G detectors located in one area;
Same function → classify on area demand.
Gas detection without Fire detection;
Include Fire events in classification of Gas Detectors
(i.e. implicit fire detection of gas detectors).
Caution with non executive actions;
Consider the limitations of operator actions.

Safety Case or COMAH Data
Use Safety Case or COMAH QRA data:
When using W0 and W00 columns;
For consequences and probabilistic data;
Involve Safety Engineer for interpretation;
N.B. Safety Case QRA usually includes the
contribution to risk reduction made by the
F&G system;
Therefore data must be corrected.

QRA Data Correction
Suggested Correction:
fTR impairment, excl. F&G = fTR impairment, incl. F&G
1 – RF&G
Where:
fTR impairment = Frequency of TR impairment
RF&G = F&G availability
TR impairment is loss of approximately 50% POB
e.g. If the F&G availability is given as 90% then,

fTR impairment, excl. F&G = fTR impairment, incl. F&G
1 – 0.9

Multiple Detection
Normally multiple Fire & Gas detectors in each area:
In single shot 1ooN;
When voted this is normally 2ooN.
What credit can we take for multiple detectors in the

PFD calculation?
Since not all detectors in an area will experience the same
fire/gas conditions;
Compromise with no more than 1oo3 for single shot;
Or 2oo4 for voted detectors.
e.g. they should not be 1oo12 or 2oo12 when there

are 12 detectors in an area.

Name: Exercise – Fire & Gas
Q 1. One of the main objectives of a fire and gas system is

to alert personnel to the presence of a fire or a
release of gas and get them to muster. Give two other
primary functions/objectives.
A 1:
Q2: Activating deluge is one of the ways to reduce the

potential for escalation of a fire. Give one other
action that can reduce the potential for escalation?
A 2:
Solution: Exercise – Fire & Gas
Q 1. One of the main objectives of a fire and gas system is

to alert personnel to the presence of a fire or a
release of gas and get them to muster. Give two other
primary functions/objectives.
A 1:
Q2: Activating deluge is one of the ways to reduce the

potential for escalation of a fire. Give one other
action that can reduce the potential for escalation?
A 2:
Example 1: Gas detection on the underside of the 1st stage separator V1001.
Operations
Visit the area >1 hour per day
Safety Engineer
Data from the QRA for the facility indicates a total probability of 2.98E-1 gas release events per year for all leak
sizes. This is equivalent to a demand rate on the gas detectors of once every 3 years. The probability of TR
impairment frequency for ignited events escalating from this area is shown to be 375 years.
Instrument Engineer
The gas detectors are IR point and they are voted 2ooN.
ANS Case 1:ANS Case 2:
W: W:
C: C:
F: F:
P: P:
SIL: SIL:
Example 1: Gas detection on the underside of the 1st stage separator V1001.
Operations
Visit the area >1 hour per day
Safety Engineer
Data from the QRA for the facility indicates a total probability of 2.98E-1 gas release events per year for all leak
sizes. This is equivalent to a demand rate on the gas detectors of once every 3 years. The probability of TR
impairment frequency for ignited events escalating from this area is shown to be 375 years.
Instrument Engineer
The gas detectors are IR point and they are voted 2ooN.
ANS Case 1: ANS Case 2:
W: W:
C: C:
F: F:
P: P:
SIL: SIL:
Example 2: Gas Detection at the Accommodation HVAC Intake:
Safety Engineer
Using data from the QRA for escalation, the probability of TR Total Impairment for any reason is 4.98 x E-4.
Equating to a frequency this is equivalent to 1 in 2000 years. This covers all events.
Instrument Engineer
The gas detectors are IR extended point duct mounted devices and are voted 2oo3.
ANS:
W:
C:
F:
P:
SIL:
Example 2: Gas Detection at the Accommodation HVAC Intake:
Safety Engineer
Using data from the QRA for escalation, the probability of TR Total Impairment for any reason is 4.98 x E-4.
Equating to a frequency this is equivalent to 1 in 2000 years. This covers all events.
Instrument Engineer
The gas detectors are IR extended point duct mounted devices and are voted 2oo3.
ANS:
W:
C:
F:
P:
SIL:
Example 3: Fire detection in the Wellhead Area
Operations
Visit the area 2 hours/d.
Safety Engineer
Data from the QRA for the facility indicates a total probability of a fire event is 6.3E-2. This is equivalent to a
demand rate on the fire detectors of once every 16 years.
The probability of TR impairment frequency for a fire event escalating from this area is shown to be 2542 years.
Instrument Engineer
The fire detectors are triple IR devices and are voted 2oo3.
W: W:
C: C:
F: F:
P: P:
SIL: SIL:
Example 3: Fire detection in the Wellhead Area
Operations
Visit the area 2 hours/d.
Safety Engineer
Data from the QRA for the facility indicates a total probability of a fire event is 6.3E-2. This is equivalent to a
demand rate on the fire detectors of once every 16 years.
The probability of TR impairment frequency for a fire event escalating from this area is shown to be 2542 years.
Instrument Engineer
The fire detectors are triple IR devices and are voted 2oo3.
W: W:
C: C:
F: F:
P: P:
SIL: SIL:
Further Operational Lifecycle
Considerations
Safety Life Cycle
Identify
Hazards
Risk
Modify assessment
SIS
Funct’l safety
requirements
assessment
spec
Review and Appropriate

verification design
Install &
Monitor
commission
Record Validation of
requirements
Operate and
Maintain
Overrides
Override of a SIF defeats protection:
the SIS will not be available to work on demand;
it will NOT provide the required protection;
it is actually in the ‘failed’ state;
if a demand occurs the consequences = failure.
SIFs should never be defeated, bypassed, inhibited or
“frigged” in any way
Overrides should be kept to a minimum
Overrides need proper controls and authority
Override Controls
Authority
Permit to Work
Key control
Key safe
Key logged out
CRO agrees to override and records in panel log
CRO agrees removal and records in panel log
Key returned to safe and logged back in
Permit signed off by the ‘authority’
CRO shift handover
Shift supervisor shift handover
Regular override status audit.
Discrepancy Alarms
Where initiators, sensors or transmitters have

discrepancy alarms:
These indicate a possible measurement error
i.e. a calibration error
This impacts on the ability to trip at the required

set point
Reducing the integrity of the protective function
Modifications & Change Control
Any modification:
To a SIF (the elements or design)
OR
The process on which a SIF operates
Could defeat the integrity of the SIF
ALL modifications to SIFs must be controlled via the
change control process
This may require another SIL assessment to be made
Repairs
When elements of a SIF are being repaired:
The SIF may not be available to protect
e.g. if the element is a 1oo1
The PFD of the SIF may increase

e.g. a 1oo2 would become a 1oo1
This could take the PFD out of the required SIL

band
Repairs must be done promptly
Appropriate sparing is important
Keeping Records
Care of a SIF extends over their full life cycle:
Conception –risk analysis - design - implementation –
testing – maintenance – operation – decommissioning
Thus records through all these phases need to
be maintained
A good cross-reference database structure is
essential
Feedback, Review & Modify
Don’t install and walk away
Records of testing, faults, maintenance and
operation must be recorded and maintained
SIF performance should to be reviewed
regularly
Testing and maintenance can then be ‘tuned’
Solving Complex Functions
by the
Event Space Method
Loss Prevention in the Process Industries’:

Frank P. Lees.
Complex Functions
Subsystems are made up of components e.g.:
Transmitter devices and trip amps;
Logic solver circuit boards;
Valve actuators, solenoids and valves.
Systems are made up of subsystems e.g. A SIS:
Initiators;
Logic solvers;
Final elements.
Complex Systems
EXAMPLE:
A system comprising 3 subsystems
Serial Path
Subsystem1 Subsystem 2 Subsystem 3

made up of made up of made up of
components components components
• If all subsystems work then the system operates

• If one subsystem fails then the system fails
• Thus all subsystems are ‘critical’
Component States
Components/subsystems have two states

Where they are either:
OK and will operate;
Failed and will fail to operate.
n
The number of states is 2 ;
Where n is the number of components/subsystems.
Component States
1oo2 Configuration
For two components or subsystems A and B:
Where n = 2 Component
n
The number of states = 2 A
i.e. 4 states:
1. A and B OK Component
2. A failed and B OK B
3. A OK and B failed
4. A failed and B failed
This is a 1oo2 configuration where the system
will work if at least one component is OK
Neither component is critical
State Table – 1oo2
State Number Subsystem A Subsystem B System

status status Operates?
1 OK OK YES
2 FAIL OK YES
3 OK FAIL YES
4 FAIL FAIL No
Exercise - Complex Systems
A system comprising 3 subsystems:
Serial Path
Subsystem B Subsystem C
Subsystem A
• How many states are there?

• Draw the state Table
Name: Exercise - Complex Systems
Solution – Complex Systems
Probability of Failure
Serial Path
Subsystem A Subsystem B Subsystem C

PFD PFD PFD
• The PFD (Function) = PFD of A + PFD of B + PFD of C
PFD of Complex Functions
Serial Path
Subsystem1 Subsystem 2 Subsystem 3

made up of made up of made up of
components components components
Subsystem 4
made up of
components
Parallel Path
How can we resolve the PFD ?
Event Space Method
‘Loss Prevention in the Process Industries’:
Frank P. Lees.
Used to model a wide range of complex
configurations where:
A configuration comprises a number of components;
Components also form sub-systems;
There are both serial and parallel paths;
We need to calculate the PFD.
The Probability of Failure and/or
Success on Demand
This depends on the state of each component

λt
If it is OK, the probability is 1−
2
λt
If it has failed, the probability is
2
Where:
t = the test interval
λ = the un-revealed failure rate
The Probability of Failure and/or
Success on Demand
The PFD is then the sum of the
probabilities where the state will not
operate on demand.
The PSD is the sum of the state
probabilities where the system will achieve
success.
PFD+PSD should be equal to 1.
Example -1oo2 system
State number Component 1 status Component 2 status System status
1 OK OK OK
2 OK FAIL OK
3 FAIL OK OK
4 FAIL FAIL FAIL
λt
Component probability of failure (FAIL) is
2
λt
Component probability of success (OK) is 1 −
2
Example -1oo2 system
State number Component 1 Component 2 Overall state probability System
probability probability (probability 1 x probability 2) status
1 1−
λt (OK)
1−
λt (OK) λ2t 2 OK
2 2 1 − λt +
4
λt (OK) λt (FAIL) λt λt2 2
OK
2 1−
2
−
2 2 4
λt (FAIL) λt (OK) λt λ2t 2 OK
3
2 1− −
2 2 4
λt (FAIL) λt (FAIL) λ2t 2 FAIL
4
2 2
4
TOTAL 1
λ2t 2
+ ( λt λ2 t 2
+ ( λt − λ t λ2t 2
2 2
PSD = (1 − λ t + ) − ) )
4 2 4 2 4 PFD = ( )
4
λ2t 2
PSD = 1 − 4 λ2t 2 λ2t 2
PSD + PFD = (1 − )+ ( ) =1
4 4
Common Configurations
Diverse voted transmitters
A complex final element comprising a pump and a valve.
Total pressure protection with an instrumented protective

function in parallel with a relief valve.
Pressure protection to close off multiple flowlines on a

common manifold.
Final Element - Pump & Valve
Both pump and valve are ‘critical’

There are (22) 4 event states
Instrumented Protection and
Relief Valve
Event PZA Logic XZV RV Operates on
demand ? RV
Flare
1 healthy healthy healthy healthy Yes
2 failed healthy healthy healthy No Logic XZV

3 healthy failed healthy healthy No
4 failed failed healthy healthy No

PZA
5 healthy healthy failed healthy No
6 failed healthy failed healthy No
7 healthy failed failed healthy No
8 failed failed failed healthy No
9 healthy healthy healthy failed Yes
10 failed healthy healthy failed No
11 healthy failed healthy failed No
12 failed failed healthy failed No

• RV < 100%
13 healthy healthy failed failed No • All SIF components
14 failed healthy failed failed No critical
15 healthy failed failed failed No
16 failed failed failed failed No
Flowlines and Manifold
RV1 = one flowline only RV1 Flare
Logic Solver PCV

Gas Compression
HH PICA
PZA1 PZA
FLV1
Inlet
Flowlines
XZV1
LICA
FLV2
• There are 64 States Oil out
• If the RV can only handle one flowline: LCV
PZA1 and the Logic Solver are ‘critical’

All other components are non-critical
SILCalc Application
Using SILCalc to solve the PFD for these

examples
How the application is configured
Component data
Assemblies
System configuration
The PFD calculation
Iterative approach to achieve optimal testing

The Principles of IEC 61508 and IEC 61511 Day 3

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

The Principles of IEC 61508 and IEC 61511 Day 3

Uploaded by

Copyright:

Available Formats

The Principles of

IEC 61508 and IEC 61511

© C & C Technical Support Services 2008 1 Part 3 of IEC 61508/61511 Training

© C & C Technical Support Services 2008 2 Part 3 of IEC 61508/61511 Training

© C & C Technical Support Services 2008 3 Part 3 of IEC 61508/61511 Training

2. To equip students with methods that will enable them to undertake

3. To undertake SIL determination of mitigating systems such as fire and gas

© C & C Technical Support Services 2008 4 Part 3 of IEC 61508/61511 Training

© C & C Technical Support Services 2008 5 Part 3 of IEC 61508/61511 Training

Operation and Maintenance

Clause 5 Clause 6.2 Stage 5 Clauses 7,

Requirements given in this standard.

© C & C Technical Support Services 2008 6 Part 3 of IEC 61508/61511 Training

© C & C Technical Support Services 2008 7 Part 3 of IEC 61508/61511 Training

12.3 - Software safety 12.4 - Software design

12.5 - PE integration 12.6 - Software operation &

Validation SIS operation and

© C & C Technical Support Services 2008 8 Part 3 of IEC 61508/61511 Training

Output Code development &

© C & C Technical Support Services 2008 9 Part 3 of IEC 61508/61511 Training

•Application •Architecture: •12.4.3 •SIS application Software •Description of the architecture

Programmable SIS Subsystem Architecture

© C & C Technical Support Services 2008 11 Part 3 of IEC 61508/61511 Training

• 3) Special purpose application

© C & C Technical Support Services 2008 12 Part 3 of IEC 61508/61511 Training

© C & C Technical Support Services 2008 13 Part 3 of IEC 61508/61511 Training

© C & C Technical Support Services 2008 15 Part 3 of IEC 61508/61511 Training

© C & C Technical Support Services 2008 17 Part 3 of IEC 61508/61511 Training

 The safety manual shall address the following

© C & C Technical Support Services 2008 18 Part 3 of IEC 61508/61511 Training

© C & C Technical Support Services 2008 19 Part 3 of IEC 61508/61511 Training

© C & C Technical Support Services 2008 20 Part 3 of IEC 61508/61511 Training

© C & C Technical Support Services 2008 21 Part 3 of IEC 61508/61511 Training

© C & C Technical Support Services 2008 22 Part 3 of IEC 61508/61511 Training

 The application software should be produced in

© C & C Technical Support Services 2008 23 Part 3 of IEC 61508/61511 Training

© C & C Technical Support Services 2008 24 Part 3 of IEC 61508/61511 Training

© C & C Technical Support Services 2008 26 Part 3 of IEC 61508/61511 Training

© C & C Technical Support Services 2008 27 Part 3 of IEC 61508/61511 Training

 Two main objectives:

© C & C Technical Support Services 2008 28 Part 3 of IEC 61508/61511 Training

 Each phase shall be planned

© C & C Technical Support Services 2008 29 Part 3 of IEC 61508/61511 Training

© C & C Technical Support Services 2008 30 Part 3 of IEC 61508/61511 Training

© C & C Technical Support Services 2008 31 Part 3 of IEC 61508/61511 Training

© C & C Technical Support Services 2008 32 Part 3 of IEC 61508/61511 Training

© C & C Technical Support Services 2008 33 Part 3 of IEC 61508/61511 Training

© C & C Technical Support Services 2008 34 Part 3 of IEC 61508/61511 Training

© C & C Technical Support Services 2008 35 Part 3 of IEC 61508/61511 Training

Case 1 Case 2 Case 3

© C & C Technical Support Services 2008 36 Part 3 of IEC 61508/61511 Training

© C & C Technical Support Services 2008 37 Part 3 of IEC 61508/61511 Training

© C & C Technical Support Services 2008 38 Part 3 of IEC 61508/61511 Training

 Take credit for the RV PFD to reduce overall

© C & C Technical Support Services 2008 39 Part 3 of IEC 61508/61511 Training

© C & C Technical Support Services 2008 40 Part 3 of IEC 61508/61511 Training

© C & C Technical Support Services 2008 41 Part 3 of IEC 61508/61511 Training

 An additional consideration is therefore

 this is often known as the synergetic consequences

HH PICA Gas Compression

© C & C Technical Support Services 2008 44 Part 3 of IEC 61508/61511 Training

Function 1 XZV3 – Gas

Function 3 XZV4 – Oil Outlet

The safety manual shall address the following

The application software should be produced in

Two main objectives:

Each phase shall be planned

Take credit for the RV PFD to reduce overall

An additional consideration is therefore

this is often known as the synergetic consequences

Numerous functions may be driven by the

All semi quantified methods require:

Average Risk value is the logarithmic average of the

We know: Risk = Frequency x Consequence.

relatively high demand rate.

extremely low probability.

Therefore two IL determinations → select

Flammable Gas Case 2- Reducing escalation:

Toxic Gas Case 2- Reducing escalation:

Fire Case 2- Reducing escalation: