You are on page 1of 114

(s.e.

2) uJeS;Il
. uC J - 3
KUWAIT OIL COMPANY (K.S.C.)

STANDARDS PUBLICATION-

KOC RECOMMENDED PRACTICE

FOR

IMPLEMENTATION OF

SAFETY INSTRUMENTED FUNCTIONS (SIF)

DOC. NO. KOC-1-017

STANDARDS TEAM
KUWAIT OIL COMPANY (K.S.C.)

STANDARDS PUBLICATION

KOC RECOMMENDED PRACTICE

FOR IMPLEMENTATION OF

SAFETY INSTRUMENTED FUNCTIONS (SIF)

STANDARDS TEAM
KOC RECOMMENDED PRACTICE

FOR

IMPLEMENTATION OF

SAFETY INSTRUMENTED FUNCTIONS (SIF)

DOC.NO. KOC-1-017

ISSUING AUTHORITY:

STANDARDS TEAM
TABLE OF CONTENTS

FOREWORD

APPLICATION
TERMINOLOGY
REFERENCE CODES AND STANDARDS
ENVIRONMENTAL CONDITIONS
INTRODUCTION AND PURPOSE
RISK ANALYSIS REQUIREMENTS
SAFETY INTEGRITY LEVEL (SIL) STUDIES
SAFETY REQUIREMENTS SPECIFICATION
SIS DESIGN AND ENGINEERING
11.0 SIS DESIGN VERIFICATION 43
12.0 FACTORY ACCEPTANCE TEST (FAT) 44
13.0 SIS INSTALLATION, COMlSSlONlNG AND VALIDATION 46
14.0 SIS OPERATION AND MAINTENANCE 51
15.0 AUDITING OF SAFETY INSTRUMENTED SYSTEMS 60
16.0 SIS MODIFICATION 61
17.0 SIS DECOMMISSIONING 61
18.0 DOCUMENTATION 62
APPENDIX A: INDEPENDENT PROTECTION LAYER REQUIRMENTS 64
APPENDIX B: SAFETY INTEGRITY LEVEL 'a' 69
APPENDIX C: MINIMUM REQUIREMENTS FOR SIF IMPLEMENTATION 70
APPENDIX D: TEMPLATE FOR SIF LIST 74
APPENDIX E: GUIDELINES FOR INITIATING CAUSE FREQUENCY 75
APPENDIX F: EXAMPLE OF SIL SELECTION WORKSHEETS 77
APPENDIX G: SAMPLE SRS FOR SINGLE SIF 78
APPENDIX H: TYPICAL ARCHITECTURES TO SATISFY SIL REQUIREMENTS 80
APPENDIX I:CHECKLISTS 82- 103
APPENDIX J: ROLES AND RESPONSIBILITIES MATRIX 104
APPENDIX K: PROVEN IN USE EVALUATION CRITERIA 107

ACKNOWLEDGEMENT 112
FOREWORD

This document "KOC Recommended Practice for Implementation o f Safety


lnstrumented Functions (SIF)" (KOC-1-017) provides the minimum requirements for life
cycle management of Safety lnstrumented Functions from design, development,
implementation, verification, validation, operation, maintenance 1 modification and de-
commissioning at various KOC facilities within Kuwait. Mr. Harry Cheddie, a well
renowned SIS Expert from MIS Exida.com, Canada, has reviewed this Recommended
Practice. This is the first instance where an external expert is involved in developing
KOC Standards /Recommended Practices.

This Recommended Practice (RP) has been approved by the Standards Team in
consultation with the Standards Technical Committee (STC) for consistent use
throughout the corporate engineering and operational functions o f Kuwait Oil Company,

This Recommended Practice sets out t o achieve the following objectives:

a. To provide technical guidance and establish the base document for developing
project documents with a view t o achieve uniformity, safety, quality, reliability and
efficiency in an economical manner;

b. To assist all stakeholders of SIF, like design, operation, maintenance personnel b y


providing technical information and engineering practices for life cycle management
of Safety lnstrumented System;

c. To maintain the KOC requirements of safety and security o f personnel and


environment established by KOC Fire and Safety Regulations, Health, Safety and
Environment Management System (HSE MS) in line w i t h HSE Policy.

Feedback, comments or suggestions, derived from the application o f this Recommended


Practice at any stage of design, purchase, manufacture, installation, operation and
maintenance are encouraged and should be directed to:

The Team Leader Standards


(Chairman, Standards Technical Committee)
Industrial Services Group, KOC
P.O. Box 9758, Ahmadi 6 1 0 0 8
State o f Kuwait
Task Force Res~onsiblefor this Recommended Practice

The Standards Technical Committee (STC) has entrusted the preparation of this
Recommended Practice t o the Task Force No. TF-1/07, consisting o f the following

Mr. Khalaf Hamada Design Team : Task Force Leader Tel. 6 1 8 3 3


Mr. D. Senthil Kumar Design Team : Author / Member Tel. 6 1 6 7 1
Mr. V.S. Kumar Opns. Tech. Svcs.-WK : Member
Mr. Barun Baruah Safety Team : Member
Mr. Ashok D. Thakare Opns. Tech. Svcs (SK) : Member
Mr. Mansour Al-Qabandi Opns. Tech. Svcs (NK) : Member
Mr. S. Chandra Sekhar Opns. Tech. Svcs (EK) : Member
Mr. Adnan Dashti Prodn. Opns. (SK) : Member
Mr. Ali Qasem Hussain Maintenance (EK) : Member
Mr. Myad Hassan Lead Inst. Engr. (AMEC) : Member
1.0 SCOPE

This Recommended Practice (RP) describes the KOC requirements for the
development and implementation of Safety lnstrumented Functions b y addressing
all safety lifecycle phases as per IEC standard IEC 6 1 5 1 1 from initial concept t o
final decommissioning including:

The methodology t o be used t o identify Safety lnstrumented Functions

The methodology t o be used t o determine, allocate and assign the Safety


lntegrity Level (SIL) for each Safety lnstrumented Function (SIF) that is
required t o make the overall risk of the process tolerable;

The format and contents of a Safety Requirements Specification for the


Safety lnstrumented System (SIS) and associated SIFs;

The design, implementation, operation, and maintenance through to


decommissioning of each SIF;

The methodology t o be used t o validate / verify the achieved Safety Integrity


Level for each Safety lnstrumented Function against initial requirements and
objectives;

Checklists to assist in verifying that key activities as per the safety lifecycle
phases have been completed;

Auditing o f the performance o f the SIS o n a periodic basis.

2.0 APPLICATION

2.1. This KOC RP shall be applied for projects within KOC facilities. This RP shall also
be used for reviewing the adequacy of existing Safety lnstrumented Systems
within KOC facilities. (Also refer to clause 6.3 & 6.4). The methodology shall
comply with the relevant requirements specified in this RP and the referred
standards / codes mentioned herein.

2.2. Any exceptions or deviations from the requirements of this RP, along w i t h their
merits and justifications, shall be brought t o the attention o f KOC Controlling Team
for their review, consideration and amendment b y Standards Team (if required).

2.3 Compliance w i t h this KOC RP does not of itself confer immunity from legal or
statutory obligations.
1
3.0 TERMINOLOGY
3.1 For the purposes of this Recommended Practice, wherever IEC 61 51 1 Parts 1 t o 3
are referred, the references shall be inclusive of ANSI / ISA 84.00.01-2004 Parts 1
t o 3 (IEC 6 1 5 1 1 Mod).

3.2 Definitions

For the purposes of this RP, the following definitions shall apply in accordance w i t h
IEC 6 1 5 1 1-1.

3.2.1 Basic Process Control System (BPCS)

System which responds t o input signals from the process, its associated
equipment, other programmable systems and / or an operator and generates output
signals causing the process and its associated equipment t o operate in the desired
manner but which does not perform any Safety Instrumented Functions with a
claimed SIL > 1.

3.2.2 Channel

Element or a group o f elements that independently perform(s) a function.

NOTE 1 - T h e elements within a channel could include input / output (110)modules,


logic systems, sensors, final elements.

NOTE 2 - A dual channel (i.e., a t w o channel) configuration is one w i t h t w o


channels that independently perform the same function.

NOTE 3 - T h e term can be used t o describe a complete system, or a portion of a


system (for example, sensors or final elements).

3.2.3 Common Cause Failure

Failure, which is the result of one or more events, causing failures of t w o or more
separate channels in a multiple channel system, leading t o system failure.

3.2.4 Common Mode Failure

Failure o f t w o or more channels in the same way, causing the same erroneous
result.

3.2.5 Dangerous Failure

Failure which has the potential t o put the Safety Instrumented System in a
hazardous or fail-to-function state.
NOTE - Whether or not the potential is realized may depend o n the channel
architecture of the system; in systems w i t h multiple channels t o improve
safety, a dangerous hardware failure is less likely t o lead t o the overall
hazardous or fail-to-function state.

3.2.6 Dependent Failure

Failure, whose probability can not be expressed as the simple product of the
unconditional probabilities of the individual events, which caused it.

NOTE - T w o events A and B are dependent, where P(z) is the probability of event
z, if only P(A & B) > P(A) * P(B)

3.2.7 Diagnostic Coverage (DC)

The diagnostic coverage of a component or subsystem is the ratio of the detected


failure rate t o the total failure rate of the component or subsystem as detected by
diagnostic tests. Diagnostic coverage does not include any faults detected b y proof
tests.

NOTE 1 - The diagnostic coverage is used t o compute the detected failure rates
(A,) and undetected failure rates (&) from the total failure rate (&) as
follows: h, = DC * h, and 5 = (1-DC) * h,

NOTE 2 - Diagnostic coverage is applied t o components or subsystems of a


Safety Instrumented System. For example, the diagnostic coverage is
typically determined for a sensor, final element or a logic solver.

NOTE 3 - For safety applications the diagnostic coverage is typically applied t o


the safe and dangerous failures o f a component or subsystem. For
example the diagnostic coverage for the dangerous failures of a
component or subsystem is DC = h,, IA,,, where ,A, is the dangerous
detected failure rate and hLDT
is the total dangerous failure rate.

3.2.8 Electrical IElectronic/Programmable Electronic (EIEIPE)

Based on electrical (E) and Ior electronic (E) and Ior programmable electronic (PE)
technology.

NOTE - The term is intended t o cover any and all devices or systems operating on
electrical principles and would include:

electro-mechanical devices (electrical);


solid state non-programmable electronic devices (electronic);
electronic devices based o n computer technology (programmable
electronic)
3.2.9 External Risk Reduction Facilities

Measures t o reduce or mitigate the risks, which are separate and distinct from the

NOTE - Examples include a drain system, firewall, bund (dike), etc

3.2.10 Failure

Termination o f the ability of a functional unit t o perform a required function.

3.2.1 1 Fault

Abnormal condition that may cause a reduction in, or loss of, the capability of a
functional unit t o perform a required function.

3.2.12 Fault Avoidance

Use of techniques and procedures, which aim t o avoid the introduction of faults
during any phase of the safety lifecycle of the Safety lnstrumented System.

3.2.1 3 Fault Tolerance

Ability of a functional unit, t o continue t o perform a required function i n the


presence of faults or errors.

3.2.14 Final Element

Part o f a Safety lnstrumented System, which implements the physical action


necessary t o achieve a safe state.

NOTE - Examples are valves, switchgear, motors including their auxiliary elements,
e.g., a solenoid valve and actuator if involved in the Safety lnstrumented
Function.

3.2.1 5 Functional Safety

Part of the overall safety relating t o the process and the BPCS which depends on
the correct functioning of the SIS and other protection layers.

3.2.16 Functional Safety Assessment

Investigation, based on evidence, t o judge the functional safety achieved by one or


more protection layers.

3.2.17 Functional Safety Audit


Systematic and independent examination t o determine whether the procedures
specific t o the functional safety requirements comply w i t h the planned
arrangements, are implemented effectively and are suitable t o achieve the specified

NOTE - A functional safety audit may be carried out as part of a functional safety
assessment.

3.2.18 Functional Unit

Entity of hardware, or software or both capable o f accomplishing a specified


purpose.

3.2.19 Hardware Safety Integrity

Part of the safety integrity of the Safety lnstrumented Function relating t o random
hardware failures in a dangerous mode of failure.

NOTE - The term relates t o failures i n a dangerous mode. That is, those failures of
a Safety lnstrumented Function that would impair its safety integrity. The
t w o parameters that are relevant in this context are the overall dangerous
failure rate and the probability of failure t o operate o n demand.

3.2.20 Impact Analysis

Activity t o determine the effect that a change t o a function or component will have
t o other functions or components in that system as well as t o other systems.

3.2.2 1 Input Function

Function, which monitors the process and its associated equipment in order t o
provide input information for the logic solver.

NOTE - A n input function could be a manual function.

3.2.22 Logic Function

Function which performs the transformations between input information (provided


b y 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 t o one or more output functions.

3.2.23 Logic Solver

That portion o f either a BPCS or SIS that performs one or more logic function(s1.

NOTE 1 - In IEC 6 1 51 1 the following logic systems are used:


electrical logic systems for electro-mechanical technology;

electronic logic systems for electronic technology;

PE logic systems for programmable electronic systems.

NOTE 2 - Examples are: electrical systems, electronic systems, programmable


electronic systems, pneumatic systems, hydraulic systems, etc. Sensors
and final elements are not part of the logic solver.

3.2.24 Safety Configured Logic Solver

Purpose industrial grade PE logic solver, which is specifically configured for use in
safety applications.

3.2.25 Maintenance / Engineering Interface

Maintenance / engineering interface is that hardware and software provided t o


allow proper SIS 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.26 Mitigation

Action that reduces the consequence(s) of a hazardous event.

NOTE - Examples include emergency depressurization o n detection of confirmed


fire or gas leak.

3.2.27 Mode of Operation

The way in which a Safety lnstrumented Function operates:

Demand Mode Safety lnstrumented Function: where a specified action (e.g.,


closing of a valve) is taken i n response t o process conditions or other demands.
In the event of a dangerous failure of the Safety lnstrumented Function, a
potential hazard only occurs in the event o f a failure in the process or the BPCS.

Continuous Mode Safety lnstrumented Function: where in the event of a


dangerous failure of the Safety lnstrumented Function a potential hazard will
occur without further failure unless action is taken t o prevent it.

NOTE 1 - Continuous mode covers those safety related functions which implement
continuous control t o maintain functional safety.

NOTE 2 - In demand mode applications where the demand rate is more frequent
than once per year, the hazard rate will n o t be higher that the dangerous
failure rate of the function. In such case, it will normally be appropriate
t o use the continuous mode criteria.

3.2.28 Necessary Risk Reduction

The risk reduction required t o ensure that the risk is reduced t o a tolerable level.

3.2.29 Non-Programmable (NP) System

System based on non-computer (e.g., not using software) technologies and / or


hardware devices (i.e., a system not based o n programmable electronics [PE]).

NOTE - Examples would include hardwired electrical or electronic systems,


mechanical, hydraulic, or pneumatic systems, etc.

3.2.30 Other Technology Safety-Related Systems

Safety-related systems that are based on a technology other than electrical 1


electronic / programmable electronic.

NOTE - A relief valve is an "other technology safety-related system". "Other


technology safety-related systems" may include hydraulic and pneumatic
systems.

3.2.31 Output Function

Function which controls the process and its associated equipment according t o
final actuator information from the logic function.

3.2.32 Prevention

Action that reduces the frequency o f occurrence of a hazardous event.

3.2.33 Process Risk

Risk arising from the process conditions caused by abnormal events (including
BPCS malfunction).

NOTE 1 - T h e risk in this context is that associated w i t h the specific hazardous


event in which SIS are t o be used t o provide the necessary risk
reduction, (i.e., the risk associated w i t h functional safety).

NOTE 2 - T h e main purpose of determining the process risk is t o establish a


reference point for the risk without taking into account the protection
layers.

NOTE 3 -Assessment of this risk should include associated human factor issues.
3.2.34 Proof Test

Test performed t o reveal undetected faults i n a Safety lnstrumented System so


that, if necessary, the system can be restored t o its designed functionality.

3.2.35 Independent Protection Layer

Any independent mechanism that reduces risk b y control, prevention 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 relief valve, a Safety lnstrumented System or an administrative
procedure such as an emergency plan against an imminent hazard. These
responses may be automated or initiated b y human actions.

3.2.36 Proven-In-Use

A component may be considered as proven-in-use when a documented assessment


has shown that there is appropriate evidence, based o n the previous use o f the
component, that the component is suitable for use in a Safety lnstrumented
System.

3.2.37 Random Hardware Failure

Failure, occurring at a random time, which results from a variety o f degradation


mechanisms in the hardware.

NOTE 1 -There are many degradation mechanisms occurring at different rates in


different components and since manufacturing tolerances cause
components t o fail due t o these mechanisms after different times i n
operation, failures of a total item of 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, 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 t o them cannot easily
be predicted.

3.2.38 Redundancy

Use o f multiple elements or systems t o perform the same function; redundancy can
be implemented b y identical elements (identical redundancy) or b y diverse elements
(diverse redundancy).
NOTE 1 -Examples are the use of duplicate functional components and the
addition of parity bits.

NOTE 2 - Redundancy is used primarily t o improve reliability or availability.

3.2.39 Safe Failure

Failure, which does not have the potential, t o put the Safety Instrumented System
in a hazardous or fail-to-function state.

NOTE 1 -Whether or not the potential is realized may depend on the channel
architecture of the system.

NOTE 2 -Other names used for safe failure are nuisance failure, spurious trip
failure, false trip failure or fail t o safe failure.

3.2.40 Safe Failure Fraction

The fraction of the overall random hardware failure rate of a device that results in
either a safe failure or a dangerous detected failure

3.2.41 Safe State

State of the process, when safety is achieved.

NOTE 1 - In going from a potentially hazardous condition t o the final safe state the
process may have t o 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 2 -This term deviates from the definition in 6 1 508-4 t o reflect differences in
process sector terminology.

3.2.42 Safety

Freedom from unacceptable risk.

3.2.43 Safety Function

Function t o be implemented by a SIS, other technology safety-related system, or


external risk reduction facilities, which is intended t o achieve or maintain a safe
state for the process, in respect of a specific hazardous event.
3.2.44 Safety lnstrumented Control Function

Safety lnstrumented Function with a specified SIL operating in continuous mode,


which is necessary t o prevent a hazardous condition from arising and / or t o
mitigate the consequences.

3.2.45 Safety lnstrumented Function (SIF)

Safety function w i t h a specified Safety Integrity Level, which is necessary t o


achieve functional safety. A Safety lnstrumented Function can be either a safety
instrumented protection function or a safety instrumented control function.

SlFs are action taken by a SIS t o bring the process equipment under control t o a
pre-determined safe state. Each SIF consists o f set o f actions t o protect against a
single specific hazard. One or more SIF can be implemented in a SIS for a common
purpose.

NOTE - Sometimes the terminology of 'Safety Loop' is used in a very loose sense
t o indicate a SIF.

3.2.46 Safety lnstrumented System (SIS)

lnstrumented system used t o implement one or more Safety lnstrumented


Functions. A SIS is composed of any combination of sensor (s), logic solver (s),
and final elements(s). Safety lnstrumented Systems could include, but not limited
t o ESD, F&G Systems, Burner Management Systems, Compressor Control
Systems, etc.

3.2.47 Safety Integrity

Average probability of a Safety lnstrumented System, satisfactorily performing the


required Safety lnstrumented Functions under all the stated conditions within a
stated period of time.

NOTE 1 - T h e higher the level o f safety integrity o f the Safety lnstrumented


Function (SIF), the lower the probability that the SIF should fail t o carry
out the required Safety lnstrumented Functions.

NOTE 2 -There are four levels o f safety integrity for Safety lnstrumented
Functions.

NOTE 3 - I n determining safety integrity, all causes of failures (both random


hardware failures and systematic failures) which lead t o an unsafe state
should be included; for example, hardware failures, software induced
failures and failures due t o electrical interference. Some of these types o f
failure, in particular random hardware failures, may be quantified using
such measures as the failure rate in the dangerous mode of failure or the
probability of a Safety lnstrumented Function failing t o operate on
demand. However, the safety integrity of a SIF also depends on many
factors, which cannot be accurately quantified but can only be
considered qualitatively.

NOTE 4 -Safety integrity comprises hardware safety integrity and systematic


safety integrity.

3.2.48 Safety lntegrity Level (SIL)

Discrete level (one out of four) for specifying the safety integrity requirements o f
the Safety lnstrumented Functions t o be allocated t o the Safety Instrumented
Systems. Safety lntegrity Level 4 has the highest level o f safety integrity (i.e.
lowest probability of failure); Safety lntegrity Level 1 has the lowest level of safety
integrity (i.e. highest probability of failure).

NOTE -1 A Safety lntegrity Level applies t o an entire SIF. SIL is used when
implementing a SIF t o reduce process risk t o a tolerable risk level.

NOTE -2 It is possible t o use several lower Safety lntegrity Level systems t o


satisfy the need for a higher level function (e.g., using a SIL 2 and a SIL
1 system together t o satisfy the need for a SIL 3 function).

3.2.49 Safety lntegrity Requirements Specification

Specification that contains the safety integrity requirements of the Safety


lnstrumented Functions, t o be performed by the Safety lnstrumented System(S).

3.2.50 Safety Lifecycle

Necessary activities involved in the implementation of Safety lnstrumented


Function(s), occurring during a period of time that starts at the concept phase of a
project and finishes when all of the Safety lnstrumented Functions are no longer
available for use.

3.2.51 Safety Requirements Specification

Specification that contains all the requirements o f the Safety lnstrumented


Functions, t o be performed by the Safety lnstrumented Systems.

3.2.52 Systematic Failure

Failure related in a deterministic way t o a certain cause, which can only be


eliminated b y a modification of the design or of the manufacturing process,
operational procedures, documentation or other relevant factors.

NOTE 1 - Corrective maintenance without modification would usually not eliminate


the failure cause.
NOTE 2 - A systematic failure can be induced b y simulating the failure cause.

NOTE 3 - Example causes of systematic failures include human error in:

the Safety Requirements Specification;


the design, manufacture, installation and operation of the hardware;
the design, implementation, etc. o f the software.

3.2.53 Systematic Safety Integrity

That part o f the safety integrity of Safety lnstrumented Function(s) relating to


systematic failures in a dangerous mode o f failure.

NOTE - Systematic safety integrity cannot usually be quantified (as distinct from
hardware safety integrity).

3.2.54 Target Failure Measure

Intended probability of dangerous mode failures t o be achieved in respect of the


safety integrity requirements, specified in terms of either: the average probability
of failure t o perform the design function on demand (for a demand mode of
operation); or the frequency of a dangerous failure t o perform the SIF per hour (for
a continuous mode of operation).

3.2.55 Tolerable Risk

Risk which is accepted i n a given context based o n the current values of society.

3.2.56 Total Mitigated Event Frequency

The Total Mitigated Event Frequency (TMEF) is obtained b y summing the mitigated
event frequency for each cause of the impact event (SIS process variable).

3.2.57 Validation

The activity of demonstrating that the Safety lnstrumented Function(s) and Safety
lnstrumented System(s) under consideration after installation meets in all respects
the Safety Requirements Specification.

3.2.58 Verification

The activity of demonstrating for each phase of the relevant safety lifecycle b y
analysis and / or tests, that for specific inputs, the outputs meet in all respects the
objectives and requirements set for the specific phase.

NOTE - Verification activities include:


reviews on outputs (documents from all phases of the safety
lifecycle) t o ensure compliance w i t h the objectives and requirements
of the phase taking into account the specific inputs t o that phase;

design reviews;

tests performed on the designed products t o ensure that they perform


according t o their specification;

integration tests performed where different parts of a system are put


together in a step by step manner and by the performance of
environmental tests t o ensure that all the parts work together i n the
specified manner.

3.2.59 MOONSystem

Safety lnstrumented System, or part thereof, made u p o f "N" independent


channels, which are so connected, that "M" channel(s) is (are) sufficient t o
perform the Safety lnstrumented Function.

3.2.60 Layers o f Protection Analysis (LOPA)

Layers of Protection Analysis is semi-quantitative method t o determine the required


SIL for SIF. LOPA evaluates the adequacy and takes credit for other protection
layers t o prevent or mitigate the hazardous event associated w i t h Safety Function.

3.3 "Shall" means a mandatory requirement that has t o be followed.

3.4 Abbreviations

ALARP As Low As Reasonably Practicable


ANSI American National Standards Institute
BDV Blow-down Valve
BP Budget Proposal
BPCS Basic Process Control System
C&E Cause and Effects Diagrams
CFSE Certified Functional Safety Expert (visit www.cfse.org)
CPP Capital Project Proposal
CPU Central Processing Unit
DC Diagnostic Coverage
EIEIPE Electrical1 Electronic IProgrammable Electronic
EIE IPES Electrical 1 Electronic IProgrammable Electronic System
El A Environmental Impact Assessment
EMC Electro-Magnetic Compatibility
ESD Emergency Shutdown
ETA Event Tree Analysis
EUC Equipment under Control
FAT Factory Acceptance Test
Fire and Gas
Functional Design Specification
Front-End Engineering Design
Failure Modes and Effects Analysis
Functional Safety Consultant
Fault Tree Analysis
Hazard Analysis
Hazard Identification
Hazard and Operability Study
Hardware Fault Tolerance
Human Machine Interface
Hazard & Risk Analysis
Human Reliability Analysis
Health, Safety and Environment

International Electro-technical Commission


Independent Protection Layer
Instrumentation, Systems, and Automation Society
IS0 International Organization for Standardization
LOPA Layer of Protection Analysis
MOC Management of Change
MOON M out o f N
MTBF Mean Time between Failures
NP Non-Programmable
PE Programmable Electronics
PES Programmable Electronic System
PFD Probability of Failure on Demand
PFDav, Average Probability of Failure on Demand
PHA Process Hazard Analysis
PHSER Project Health Safety Environment Review
P&ID Piping and Instrumentation Diagram
PLC Programmable Logic Controller
PSD Process Shutdown
PST Partial Stroke Testing
QA Quality Assurance
QRA Quantitative Risk Analysis
RBD Reliability Block Diagram
SAT Site Acceptance Test
SFF Safe Failure Fraction
SIF Safety Instrumented Function
SIL Safety Integrity Level
SIS Safety Instrumented System
SOE Sequence o f Events
SRS Safety Requirements Specification
S/W Software
S/U Start-up
THERP Techniques for Human Error Rate Prediction
Total Mitigated Event Frequency
Uninterrupted Power Supply

4.0 REFERENCE CODES AND STANDARDS

4.1 Conflicts

In the event o f conflicts between this RP and the latest edition of standards /
codes referred herein, or other purchase or contractual requirements, the most
stringent requirements shall apply.

4.2 List o f Standards and Codes

Safety lnstrumented System(s) shall comply during the entire safety life cycle,
except where otherwise specified, with the current issue and amendments o f the
applicable codes, standards, 0 1 5 series o f KOC Specifications and KOC HSE M S
Procedures, of which the following are listed i n this RP:

4.2.1 International / National Standards

ISA S84.00.01 Functional Safety: Safety lnstrumented Systems


Parts 1 t o 3 for the Process Industry Sector, Parts 1-3

IEC 6 1 5 0 8 Functional Safety of Electrical/ Electronic / Programmable Electronic


Safety Related Systems
Part 1 : General Requirements
Part 2: Requirements for E/E/PE Safety Related Systems
Part 3: Software Requirements
Part 4: Definitions and Abbreviations
Part 5: Examples of Methods for Determination of SIL
Part 6: Guidelines on the Application of IEC 6 1 508-2 and 6 1 508-3
Part 7: Overview of Techniques and Measures

IEC 6 1 5 1 1 Functional Safety : Safety lnstrumented Systems for the Process


Industry Sector
Part 1 : Framework, Definitions, System, Hardware and Software
Requirements
Part 2 : Guidelines i n the Application o f IEC6151 1-1
Part 3 : Guidance for the Determination of the Required Safety
Integrity Levels

4.2.2 KOC Standards

KOC-G-002 KOC Standard for Hazardous Area Classification

KOC-G-004 KOC Standard for Packing, Marking and Documentation

KOC-G-007 KOC Standard for Basic Design Data


KOC-G-009 KOC Standard for Spare Parts and Maintenance Data

KOC-1-001 KOC Standard for Instrumentation and Control System Design

KOC-1-002 KOC Standard for Instrument Installation

KOC-1-004 KOC Standard for Shutdown Systems

KOC-1-005 KOC Recommended Practice for Fire and Gas System Panels

KOC-1-010 KOC Standard for Control and Shutdown Valves

KOC-1-011 KOC Standard for Instrument Cables

KOC-L-006 KOC Standard for Fire & Gas Detection Equipment

KOC-L-017 KOC Recommended Practice for HAZOP Study

4.2.3 0 1 5 Series o f KOC Specification

0 15-JH- 19 0 3 General Instruments

0 1 5-JH-1909 Instrumentation for Package Equipment

015-JH-1910 Mechanical Completion of Instrument Systems

0 1 5-JH-1911 Standard Auxiliary Control Room Cabinets

0 1 5-YH-1004 Emergency Shutdown & De-pressurizing System Requirements

4.2.4 KOC HSEMS Procedures

KOC.GE.OO1 Health, Safety, and Environmental Management System


(HSEMS) Manual

KOC.GE.006 Management of Change Procedure

KOC.GE.021 HAZOP Study Procedure

KOC.GE.048 Procedure for the Preparation o f Project HSE Plan

KOC.GE.050 Procedure for Project HSE Review (PHSER)

KOC.SA.018 HSE Procedure for Risk Assessment

KOC.SA.019 Guideline for HSE Procedure for Risk Assessment


KOC.SA.020 Plant Safety Override Registration Procedure

KOC.EV.OO1 Environmental Aspects Identification and Assessment Procedure

KOC.EV.003 Environmental Impact Assessment (EIA) Procedure

KOC Fire & Safety Regulations (Latest)

4.2.5 List o f Acceptable References

A list of suitable and acceptable references for failure rate data is as per the list

a) Safety Equipment Reliability Handbook, Exida, ISBN-1 3:978-0-9727234-1-1;

b) Offshore Reliability Data Handbook 4th Edition, (OREDA 2002) SINTEF


Technology and Society;

c) Layer of Protection Analysis: Simplified Process Risk Assessment - Center


for Chemical Process Safety (CCPS) ISBN: 0-81 69-081 1-7;

d) IEC 6 1 5 0 8 - Functional Safety o f Electrical I Electronic I Programmable


Electronic Safety Related Systems (Parts 1 t o 7)

e) IEC 6 1 5 1 1 - Functional Safety: Safety lnstrumented Systems for the Process


Industry Sector (Parts 1 t o 3)

f) ANSI 1 ISA-84.01-1996 Parts 1 t o 3 - Functional Safety: Safety


lnstrumented Systems for the Process Industry Sector;

g) Guidelines for Safe Automation of Chemical Processes, American Institute of


Chemical Engineers, Center for Chemical Process Safety, ISBN 0-8169-
0554-1, 1993, Phone 800-242-4363;

h) Guidelines for Process Equipment Reliability Data with Data Tables,


American lnstitute of Chemical Engineers, Center for Chemical Process
Safety, 1989, ISBN 0-81 69-0422-7, Phone 800-242-4363;

i Guidelines for Chemical Process Quantitative Risk Analysis, AlCHE CCPS,


1989, ISBN 0-81 69-0402-2, Phone 800-242-4363;

j) Loss Prevention in the Process Industries, 2"d Edition, Lees, F.P., Elsevier
Science Publishers B. V., Amsterdam, (1996).

I
5.0 ENVIRONMENTAL CONDITIONS

Refer t o "KOC Standard for Basic Design Data" (KOC-G-007), which provides the
detailed information regarding the environmental, site and utility supply conditions
prevailing throughout the KOC Facilities.

6.0 INTRODUCTION AND PURPOSE

6.1 Introduction

A Safety lnstrumented System (SIS) is one of several risk reduction measures used
on a hazardous process t o minimize the risk o f fatalities or injury t o personnel,
harm t o the environment, damage t o plant equipment, or loss o f production.

The primary purpose of this RP is t o provide the guidelines and criteria for the
specification, design, implementation, and support o f all SIS.

The guidelines and criteria outlined in this RP are intended t o ensure that SIS are
correctly specified, designed, and installed, and that adequate management
systems are in place so that the required periodic inspections, modifications, and
repairs are completed once the systems are in operation.

6.2 Purpose

6.2.1 This RP provides guidelines t o be used for the development o f Safety lnstrumented
Functions consistent with the safety life cycle phases in accordance with IEC
61511.

6.2.2 It is expected that this RP should be used b y those, w h o are involved i n the
following activities associated w i t h Safety lnstrumented Systems:

Hazard and risk analysis


Safety Integrity Level Selection
Application, specification, design, selection and engineering
Installation, commissioning, and Pre-Startup Acceptance Test
Operation, maintenance, documentation, and testing

6.2.3A typical Safety lnstrumented System Life Cycle is shown in Fig. 1 of this RP.

6.2.4 Typical activities of safety life cycle from initial concept through decommissioning
of a SIS are detailed in Table No. 1 of this RP.

6.2.5 These guidelines for developing Safety lnstrumented Functions shall be applied t o
new as well as t o review 1 modifications 1 additions o f / t o existing Safety
lnstrumented System within KOC facilities.
Typical Safetv Instrumented Svstem Life Cvcle

i
-
START
Establish

I Develop SIS
Concfptual
Operation &
Maintenance
Procedures
=--
Conceptual
t
Process Design
& Release Verify Conceptual Design
meets SRS, SIS ArchlFDS
1
Pre-Startup
Safetv Review
ID lssue I F D ~
Process Hazards
ReviewlRisk
t
Develop SIS SIS Startup. Operation,
Detail Design per Maintenance, Periodic
P&IDs

1 *
Functional Testina

Technical Auditing

1
Confirm Target
SlLs

t
Confirm if SIS
meets SIL SIS

+
Identify SlFs
reauirements Decommissionin

Define Target

t SIS Installation,
Commissioning
Develop Safety END
and Pre-start-uo
Requirements
Soecification

Analysis Design Operations1


Maintenance
+ b4 - b

IFD - lssue for Design


IFC - lssue for Construction
RFQ - Request for Quotation

Figure 1: Tvpical Safetv lnstrumented System Life Cycle


Table No. 1: SIS Safety Life Cycle Overview

Safety Life Cycle Phase or


Objectives

Hazard and Risk To determine the hazards and Process design, layout, A description of the
hazardous events of the process and manning arrangements, hazards, of the
associated equipment, the sequence of safety targets. required safety
events leading t o the hazardous event, function(s1 and of
the process risks associated w i t h the the associated risk
hazardous event the requirements for reduction.
risk reduction and the safety functions
required t o achieve the necessary risk
reduction.
Allocation of Allocation of safety functions t o A description of the Description of
safety functions t o protection layers and for each Safety required Safety allocation of safety
protection layers Instrumented Function, the associated Instrumented Functions requirements.
Safety Integrity Level. and associated safety
integrity requirements.
To specify the requirements for each Description of allocation SIS safety and
Requirements SIS, in terms of the required Safety of safety requirements. Software safety
Specification Instrumented Functions and their requirements.
associated safety integrity, in order t o
achieve the required functional safety.
To design the SIS t o meet the SIS & Software safety Design of the SIS in
engineering requirements for Safety Instrumented requirements. conformance w i t h
Functions and safety integrity. the SIS safety
requirements;
Planning for the SIS
integration test.
5 SIS installation To integrate and test the SIS. SIS design; SIS Fully functioning
commissioning & integration test plan; SIS, conforming t o
validation To validate that the SIS meets, in all SIS safety requirements. the SlS design
respects, the requirements for safety in Plan for the safety results of SIS
terms of the Required Safety validation of the SIS. integration tests.
Instrumented Functions and the Results of the
required safety integrity. installation,
commissioning and
validation activities.
6 SIS operation and To ensure that the functional safety of SIS requirements; SIS Results of the
maintenance the SIS is maintained during operation design. Plan for SIS operation and
and maintenance. operation and maintenance
maintenance. activities.
7 SIS verification To test and evaluate the outputs of a Plan for the verification Results of the
given phase t o ensure correctness and of the SIS for each verification of the
consistency w i t h respect t o the phase. SIS for each phase.
products and standards provided as
input t o that phase.
8 SIS functional T o investigate and arrive at a judgment Planning for SIS Results of SIS
safety assessment on the functional safety achieved by the functional safety functional safety
SIS. assessment. SIS safety assessment.
requirement.
9 Decommissioning To ensure proper review, sector As-built safety SIF placed out-of-
organization, and ensure SIF remain requirements and service.
appropriate. process information
6.3 A~plicability- N e w Facilities

Safety lifecycle activities as described i n IEC 61 51 1 shall be applied t o all new


KOC facilities w i t h reference t o typical KOC project phases as follows:

a) Process Hazard and Risk Analysis and Protection Layer Design

This activity shall start in the concept design phase at CPP & BP stage and
continue during Front-End Engineering Design (FEED stage) and detail
engineering b y Contractor. The activity should conclude with a risk analysis

b) Allocation o f Safety Functions t o Protection Layers

This activity shall start following the risk analysis performed i n the FEED
stage, assuming that the preliminary risk analysis has identified the Safety
lnstrumented Functions. However, it is necessary t o identify major risks at
this stage also, t o allow them t o be considered in the design process and t o
facilitate future SIL studies.

The minimum SlLs for each Safety lnstrumented Functions shall be assigned
and indicated in P&IDs; and all other relevant documents be based o n this
Recommended Practice before finalization of the FEED.

The activity shall continue during the detail engineering by the Contractor.
The Contractor shall prepare a report (specification) in the detail engineering
stage.

C) Safety Requirements Specification for the Safety lnstrumented System

This activity shall start in the FEED stage, continue in the detail engineering
stage and shall be concluded with a report (specification) by Contractor.

d) Design and Engineering of Safety lnstrumented System

This activity starts in the FEED stage and concludes in the detail engineering
stage.

e) Installation, Commissioning and Validation

This activity starts in the construction stage and concludes with the final
commissioning.

f) Operation and Maintenance

This activity occurs throughout the operational stages of the system.


g) Modification

This activity occurs throughout the operational stages o f the system.

h) Decommissioning

This activity occurs during the decommissioning stage.

6.4 Ap~licabilitv- Existinq Facilities

6.4.1 The verification o f SIL o f each existing safety function shall be considered before
implementing any changes t o existing facilities that would affect the safety o f the
existing system i n order t o ensure that the risk is reduced t o an acceptable level.

6.4.2 Modifications involving changes t o process, changes in operation, maintenance and


the associated safety functions shall also be subject t o verification of the Safety
Integrity Level t o ensure that the integrity level is maintained and the system is
operating according t o the specification.

6.4.3 These guidelines shall also be applied t o periodic revalidation of existing


installations and reviews required as a result o f management of change or incident
investigation activities. It should review existing plant Safety Functions, developing
recommendations for further risk reduction and t o identify additional risks
exceeding the threshold criteria for each potential hazard 1 operability problems
which have not already become evident from operating experience.

6.4.4 For existing SIS designed and constructed in accordance w i t h codes, standards, or
practices prior t o the issue of this RP, KOC shall determine that the equipment is
designed, maintained, inspected, tested, and operating in a safe manner.

7.0 RISK ANALYSIS REQUIREMENTS

7.1 HAZOP Data Reauired

7.1 .IProcess hazard analysis t o identify hazards, potential process deviations and their
causes, available engineered systems, initiating events, and potential hazardous
events (accidents) that may occur, shall be performed for the process.

7.1.2 This shall be accomplished using HAZOP techniques which shall be in full
compliance w i t h the latest edition o f API recommended practices and "KOC
Recommended Practice for HAZOP Studies" (KOC-L-017).
7.1.3 HAZOP shall develop the following data required for SIL analysis:

Table No. 2 : HAZOP D e v e l o ~ e dData for SIL Analysis (LOPA method)

SlL ANALYSIS (LOPA) HAZOP DEVELOPED


REQUIRED INFORMATION INFORMATION
Initiating Event Deviation
Impact Event Consequence
Severity Level Consequence Severity
Initiating Cause Cause
Impact event frequency Cause Frequency
Protection Layers Existing safeguards
Required Additional Mitigation Recommended New Safeguards

7.1.4 Facilities QRA Requirements

The following data from Facilities QRA studies shall be used t o obtain information
relating t o likelihood and consequence values for the SIL determination:

Risk Contours
Consequence analysis
Likelihood analysis
Gas dispersion analysis
Event trees

7.2 Identification of SlFs

The Functional Safety Consultant will compile a list o f safety instrumented


functions (SIF) that were determined t o be required for the process under
consideration. The Consultant will perform this task by reviewing the
documentation where required SIF have been identified and then compiling them
into a document whose format will facilitate SIL selection, and will subsequently
become an integral part of the safety requirements specification.

The key documents t o be used b y the Functional Safety Consultant t o complete


this task are:

Hazop report
P&IDs
Cause and Effects diagrams
Instrument Index
7.3 SIF List

The results of the SIF Identification Support will be documented in a SIF list
document, which will become an integral part o f the safety requirements
specification. The Functional Safety Consultant will compile t w o separate SIF lists,
one for personnel safety and another for process/equipment protection.

The SIF list will contain the following information:

A brief description of each SIF


A tag number for each SIF (if available)
A list of inputs and outputs for each SIF
Reference information for each SIF, including drawing numbers where the
SIF functionality is described.
General requirements for all SIF and an explanation for use o f the SIF list
Specific notes for individual SIF, as needed.

After preparation o f the preliminary SIF lists, the Functional Safety Consultant will
submit them t o KOC for review and approval. KOC will review the list t o .
determine if any additions or deletions are required, and also whether any
personnel safety or process/equipment protection functions have been improperly
assigned.

The following items should not be included i n the SIL list:

Any alarm
Hand switches e.g. Start1 Stop/ Duty/ Standby1 Local/ Remote/ ESD (MCRI
Local)
Fire and Gas detector alarms
Fusible plugs
Control valve loops actuated b y SOVs
Motor Control Center loops
Air conditioner damper controls

A template for SIF list is described in Appendix D of this RP.

8.0 SAFETY INTEGRITY LEVEL (SIL) STUDIES

8.1 General

8.1.1 Safety Integrity Level Studies shall be performed for all projects within KOC
facilities. The services of a Third Party Functional Safety Consultant shall be used
t o complete the following activities in accordance w i t h IEC 6 1 5 0 8 & IEC 6 1 5 1 1
and KOC Standards and Specifications listed under clause 4.2 of this RP.

The SIL determination shall be performed b y a multi-disciplinary team


knowledgeable o f the design for evaluation as per IEC 6 1 5 0 8 & IEC 6 1 51 1
standards. The team shall consist of people qualified t o review the chemical
process, identify potential process hazards, and recommend actions t o be taken t o
minimize risks. This team shall have at least one experienced representative from
the Contractor, Project Management Consultant and the KOC project / concerned
teams with the following functions:

Functional Safety Consultant w i t h CFSE certification, trained in LOPA


analysis. The Functional Safety Consultant shall be as designated
Chairperson for SIL Analysis;
Process and lnstrument Engineers from Design 1 Major Projects Teams as the
case may be;

Process and lnstrument Engineers from Operation Technical Services;


Process and lnstrument Engineers from Operations & Maintenance;
Inspection & Corrosion and Q A l QC;
Representative of Package Equipment Manufacturer (e.g. Gas Turbine,
Compressor, Heater etc.);
Designated Secretary t o record the results of the meetings.

8.1.2 The following activities are t o be completed prior t o the start of the SIL review:

a) Review completed PHSER, HAZOP, EIA and QRA reports provided b y other
Safety Services Consultants (if the Functional Safety Consultant does not
conduct PHSER, HAZOP and QRA studies himself). These reports are t o be
used b y the Functional Safety Consultant t o identify Safety functions and
associated hazards including frequency and consequence data required for
the detailed SIL study.

b) The Functional Safety Consultant shall collect the required data from various
sources and conduct detailed technical discussions with all concerned KOC
Departments related t o the project, main Contractor of KOC project and
other relevant parties and prepare a report of the same t o be approved b y
KOC. The data collected t o be used for the SIL study.

C) A detailed preliminary list of Safety functions to be prepared by the


Functional Safety Consultant as per clauses 7.2 & 7.3 of this RP.

8.1.3 The following activities to be completed during and after the SIL review:

a) Determine the SIL number for the required SIS as per clause 8.2 of this RP.

b) Develop Safety Requirements Specification (SRS) for SIS, as per clause 9.0
of this RP.

C) Perform SIS detail design and verify against SRS using vendor data, as per
clauses 10.1.2 & 10.1.3 of this RP.
d) Establish operation and maintenance procedures for SIS systems, as per
clause 14.0 of this RP.

e) Ensure that appropriate SIS components are specified, produced and installed
to meet the SRS, as per clauses 10.0, 11 .Of 12.0 and 13.0 of this RP.

f) After commissioning, verify, validate and provide final certification that


every SIS meets the requirements of the SRS, as per clause 13.0 of this RP.

8.1.4 Minimum qualifications required o f Functional Safety Consultant 1 Expert (this


includes the individual employee - associate of a firm I company): The Functional
Safety Consultant shall be:

A Graduate Engineer w i t h CFSE certification


Having at least fifteen (1 5) years experience i n Instrumentation & Control
Systems Engineering
Including no less than ten (10) years in Safety Systems of Oil & Gas
Industry
In addition, must have performed all of the works himself, independently, as
per clause 8.1.1 of this RP for at least five (5) SIL studies in the past three
(3) years prior t o the date of submitting his resume for KOC approval.

The main Contractor of KOC project or the Functional Safety Consultant himself, i f
undertaking the SIL study project, shall submit his resume for KOC approval prior
t o commencement of SIL studies.

8.1.5 The individual Functional Safety Consultant and I or agency or any o f the
employees -associates of the firm shall in any form, directly or indirectly be not
associated w i t h the Contractor(s), w h o would execute the project Contract.

8.1.6 The SIL study must include all Safety Functions associated with the following as
applicable:

Main process
Fire and Gas systems (F&G)
Burner Management Systems (BMS)
Anti surge systems
Machinery Vibration I Temperature Monitoring System
Package systems

8.1.7 The SIL review must cover the following risk receptors:

People
Environment
Asset
Company reputation
8.1.8 Safety functions are t o be limited t o functions that take automatic action t o
prevent or mitigate hazardous events. As such there is n o requirement for a SIL
review t o be completed for functions that are manually activated unless a special
request is made b y KOC for a SIL review t o be completed for non-automatic
functions. It has t o be recognized that it is very difficult t o meet even SIL 1 for
manually activated functions.

8.2 Methodoloqv to Determine and Allocate SIL for Each SIF

8.2.1 Introduction

a) The purpose of these recommendations is t o provide the methodology for


performing Safety Integrity Level (SIL) determination and allocation for
projects within KOC facilities.

b) SIL studies shall be undertaken only after completion of the following as part
of the Hazard and Risk Analysis:

Process Design Philosophies


Process Descriptions
Process Flow Diagrams
P&IDs
C&E Diagrams
Control Systems Architecture
Instrument Index
Site Layouts
HAZOP
PHSER reports
EIA Study
Facilities QRA or any other risk technique.

C) National and international standards, such as IEC 6 1 508 / IEC 61 51 1


represent a consensus o f best practices for implementing Safety
lnstrumented Systems (SIS). These standards require that all electrical,
electronic and programmable electronic systems used in a SIS shall be
designed, operated, and maintained so that they should achieve a specified
Safety Integrity Level (SIL).

d) A SIL is assigned t o each individual Safety lnstrumented Function (SIF) or


"safety loop" contained in the system. IEC 6 1 5 1 1 will define SIL for a SIF
operating in demand mode, as a range of the Average Probability of Failure
on Demand (PFD avg.). The relationship between the SIL and the required
failure probability is shown i n Table No. 3 o f this RP. The categories are
usually described both i n terms of PFDavg. and also in terms o f Risk
Reduction Factor, which is the inverse of PFDavg.
Table No. 3 : Safetv lnteqritv Levels - Probabilitv of Failure on Demand

' :2 <;" * * ' " * A t

DEMAND*M B O E ~ ~ F ~ ~ ~ R A T I D N -
'-.
% G 7
i / T I

, 4 " -5%

Safety Integrity Target Average ~rotidt(Bity6f.~iailure


on, . Taig&at.;Riikkeduction
Level (SIL) ~dmantl * %

4 to lo4< > 10,000 to


21 00,000
3 2-10" to > 1000 t o 1 1o,ooo

2 210" t o > 100 to 51000

1 2 10-2t o 10-I< > 1 0 to 5100

e) For each Safety Instrumented Function operating in continuous mode of


operation the required SIL shall be specified in compliance with Table No. 4
of this RP as defined in IEC 6 1 51 1.

f) These recommendations have been developed with the goals o f compliance


with applicable regulations, conformance with the recommendations o f
applicable standards, consistency w i t h risk ranking procedures used in
Process Hazard Analysis studies and conformance with KOC Standards and
Specifications.

Table No. 4: Safetv lnteqritv Levels: Frequency of Danqerous Failures of the SIF

8.2.2 SIL Selection Guidelines

a) As a minimum, for all KOC projects, Layer of Protection Analysis (LOPA)


shall be used as SIL determination methodology for KOC facilities.

b) In cases where LOPA is not an adequate method for a particular application,


then the Functional Safety Consultant should propose an adequate and
better alternative method t o select the appropriate SIL for the application.
The Functional Safety Consultant shall document his proposal including a
detailed justification, and shall obtain KOC approval for the alternative
method prior t o implementation.

C) The requirement for more advanced techniques for SIL determination can
also be initiated by KOC on a project-by-project and / or on an application-
by-application basis. This requirement will be indicated t o the Functional
Safety Consultant or the main Contractor during the detailed engineering
stage, at the time of KOC approval o f the SIL methodology or while
performing the SIL study.

d) LOPA analyzes hazards and associated risks t o determine i f SlFs are required
and, if so, the required safety integrity level (SIL) of each SIF t o ensure
tolerable risk levels is achieved.

e) LOPA is a team exercise that includes individuals w i t h experience similar t o


that of a PHA team. This analysis may be performed in conjunction with a
PHA, or as a separate study (a separate study is recommended).

f) The LOPA analysis shall be performed b y a multi-disciplinary team


knowledgeable o f the design being evaluated, and IEC 6 1 508 / IEC 6 1 51 1
standards. The team shall consist of people qualified t o review the chemical
process, identify potential process hazards, and recommend actions be taken
t o minimize risks. This team shall have at least one experienced
representative from the Contractor, Project Management Consultant and the
KOC project / concerned teams w i t h the following functions:

Functional Safety Consultant w i t h CFSE certification, trained in LOPA


analysis. The Functional Safety Consultant shall be as designated
Chairperson for SIL Analysis.
Process and Instrument Engineers from Design / Major Projects Teams
as required.
HSE Engineer.
Process and Instrument Engineers from Operation Technical Services.
Process and Instrument Engineers from Operations & Maintenance.
Inspection & Corrosion and QA / QC.
Rotating equipment specialist.
Secretary t o record the results of the meetings.

g) Other team members may be used as needed. Team members with


experience and training i n equipment reliability, safety, maintenance,
specialty engineering, or project engineering may be useful

8.2.3 SIL Determination Technique

The LOPA technique outlined i n this RP shall only be used. Other techniques, i f
used, shall be used w i t h special approval from KOC.
8.2.4 LOPA Quantitative Technique

a) The LOPA (Full Quantitative Technique) is based on establishing a tolerable


frequency for each consequence resulting from an impact event. The
Functional Safety Consultant shall apply KOC.SA.018 "HSE Procedure for
Risk Assessment" and KOC.SA.019 "Guideline for HSE Procedure for Risk
Assessment" for KOC Tolerable Risk Matrix. (Refer t o Fig 2: Flowchart

r
Start
L
4
Select SIF
+
Define the most credible consequence
t
Categorize the consequence severity
4
Define the causes of initiating events
t
List the frequency of each cause
+
Identify the lPLs associated w i t h
each cause and then calculate the
ThAFl f n r all r a l l c o c

Compare with Tolerable Frequency


+

Yes

f >
TMEF - Total Mitigated Event Frequency
STOP IPL - Independent Protection Layer
\ J

Figure 2: LOPA Flowchart


Once the Tolerable Frequency for an event is established, all causes of the
impact event are listed. For each cause o f the impact event, its frequency is
established (Refer Appendix E - Guidelines for Initiating Cause Frequency).
The layers of protection and associated PFD for each cause are then listed.
The mitigated event frequency for each cause is then determined from the
following equation:

= Fe*PAXPB*PC*PD

Where: F is the mitigated event frequency for each cause


F, is non-mitigated event frequency and
PA/PB/PC/PD is the PFD values for each effective protection

b) After each cause is analyzed the total event frequency due t o all causes for
the impact event is determined by summing the mitigated frequency for all
causes.

c) The SIL is determined by comparing the established tolerable frequency


(goal) with the total mitigated event frequency i.e.:

-
Fgoal
PFDW -
FTMEF
The total mitigated event frequency (TMEF) is obtained by summing the
mitigated event frequency for each cause.

d) The following steps shall be performed t o determine the required SIL for
each SIF identified:

Define the worst consequence (i.e. most credible worst consequence) if


the SIF failed t o operate when a demand occurs.

Categorize the consequence severity and tolerable frequency based on


KOC.SA.018 "HSE Procedure for Risk Assessment" and KOC.SA.019
"Guideline for HSE Procedure for Risk Assessment". The tolerable
frequency will be selected from the reducible frequency band as per
above mentioned KOC HSE Standards.

List all causes and frequency for the impact event

For each cause identify all applicable and effective layers of protection
and assign failure probabilities for each layer
For each cause, calculate the mitigated event frequency considering all
the effective layers i.e. F = F,*PA*PB*PC*PD

Where, F is the mitigated event frequency,


Fe is non-mitigated event frequency and
PA/PB/PC/PD are the PFD values for each protection layer.

Calculate the total event frequency due t o all causes.

Compare the tolerable frequency goal w i t h the total event frequency.

Assign the required SIL based on the additional risk reduction required.

Document the results of each analysis in the SIL selection worksheet


(APPENDIX - F). Include any notes and recommendations in the
worksheet.

e) In case that the calculated SIL level for any loop is SIL 3 or higher, then a
full Quantitative risk assessment t o determine both the consequence and
likelihood quantitatively shall be utilized t o calculate the SIL of the SIF.

8.2.5 110 Safety Case for each SIF

Upon completing the SIL determination, each SIF has t o be reviewed b y the team
t o identify the Inputs and Outputs required b y each safety function t o address the
hazardous event associated w i t h the Safety function.

This I10 assignment will be the basis for the SIL verification calculations to be
completed.

8.2.6 Where the SIS is t o implement SIF of different Safety Integrity levels, then, the
shared or common hardware and software shall be treated as belonging t o the
highest safety integrity level unless it can be shown that SlFs o f lower SIL can not
negatively affect the SlFs of high SILs.

8.2.7 For tolerable risk guidelines for LOPA, refer t o Table No. 5 of this RP.
Table No. 5 : Tolerable Risk Guidelines for LOPA

Negligible Marginal Critical Seve


Consequences Consequences Consequences Conseque
Single fata
Slight Injury or Minor Injury or health Major Injury or
People permanen
health effects effects health effects
disabi
Unacceptable
1 E-2 per year 1 E-3 per year 1 E-3 per year 1 E-3 per y
Frequency

$100K- $Oa5
Less than $1 OK Less than $ 1 0 0 K
$0.5 Million

1 E-2 per year 1 E-3 per year 1 E-4 per year 1 E-5 per
Frequency

Localized effect - Major eff


Slight effect - Local
Minor effect - Limited loss o f Seve
Environment environment
Contamination discharges of environm
damage
k n o w n toxicity dama
Unacceptable
1 E-2 per year 1E-3 per year 1 E-4 per year 1 E-5 pe
Frequency

Reputation Slight impact Limited impact National d


damage
Unacceptable
1 E-2 per year 1 E-3 per year 1 E-4 per year 1E-5 pe
Frequency

Note 1 : Select the category w i t h the highest unacceptable frequency, and the value w
Note 2: As per Table 1 of KOC.SA.019 - Guideline for HSE Procedure for Risk Assess
9.0 SAFETY REQUIREMENTS SPECIFICATION

9.1 The Safety Requirements Specification (SRS) is the main output from the SIL
determination and allocation activities and shall be developed b y the Functional
Safety Consultant. The SRS will become the main reference source of information
for the initial design of the system and t o validate that all o f the requirements have
been satisfied at the completion of the project.

9.2 The SRS shall be divided between Safety lnstrumented System and Non-
lnstrumented Safety Systems in order t o address the correct requirements.

9.3 The SRS shall include the details listed in IEC 6 1 51 1-1 that shall be sufficient t o
design the SIS and shall include the following for each SIF. Individual Functional I
Integrity Safety Requests Sheet shall be provided for each SIF loop:

a) A description of all the safety instrumented functions necessary t o achieve


the required functional safety;

b) Requirements t o identify and take account o f common cause failures;

C) A definition o f the safe state o f the process for each identified Safety
lnstrumented Function;

d) A definition of any individually safe process states which, when occurring


concurrently, create a separate hazard (e.g., overload o f emergency storage,
relief, flare systems);

e) The assumed sources of demand and demand rate on the Safety


lnstrumented Function;

f) Requirement for proof test intervals;

g) Response time requirements for the SIS t o bring the process t o a safe state;

h) The Safety Integrity Level and mode of operation (demand/continuous) for


each Safety lnstrumented Function;

i) A description o f SIS process measurements and their trip points;

j A description o f SIS process output actions and the criteria for successful
operation e.g., requirements for tight shut-off valves;

k) The functional relationship between process inputs and outputs, including


logic, mathematical functions and any required permissive;
Requirements for manual shutdown;

m) Any special diagnostics required t o achieve SIL need t o included in the SRS

n) Requirements relating t o energize or de-energize t o trip. If energize t o trip


systems are proposed, additional considerations shall be implemented,
including KOC1s approval;

o) Requirements for resetting the SIS after a shutdown;

p) Maximum allowable spurious trip rate;

q) Failure modes and desired response of the SIS (e.g., alarms, automatic shut-

r) Any specific requirements related t o the procedures for starting up and


restarting the SIS;

S) All interfaces between the SIS and any other system (including the BPCS
and operators);

t) A description of the modes of operation of the plant and identification of the


Safety Instrumented Function required t o operate within each mode;

U) The application software safety requirements as listed in IEC 6 1 51 1;

V) Requirements for overrides1 inhibits1 bypasses including h o w they will be


cleared;

w) The specification of any action necessary t o achieve or maintain a safe


state i n the event o f fault(s) being detected in the SIS. Any such action
shall be determined taking account of all relevant human factors;

X) The mean time t o repair which is feasible for the SIS, taking into account
the travel time, location, spares holding, service contracts, environmental
constraints, etc;

y) Identification of the dangerous combinations of output states of the SIS


that need t o be avoided;

Z) The extremes of all environment conditions that are likely t o be


encountered b y the SIS shall be identified and shall be as per KOC Standard
for Basic Design Data KOC-G-007. This may require consideration of the
following: temperature, humidity, contaminants, grounding, Electro
Magnetic Interference1 Radio Frequency Interference (EM1 I RFI), shock I
vibration, electrostatic discharge, electrical area classification, flooding,
lightning, and other related factors;

aa) Identification of 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 lnstrumented Functions may be required t o support these
modes of operation;

bb) Definition of the requirements for any safety function necessary t o survive
a major accident event, e.g. time required for a valve t o remain operational
in the event o f a fire.

9.4 A sample of a SRS for a single SIF is provided in Appendix G o f this RP.

10.0 SIS DESIGN AND ENGINEERING

10.1 General

10.1.1 SIS Design & Engineering shall meet the specification o f SIS Safety Requirements;
and shall be designed t o provide the Safety lnstrumented Function(s) in order t o
meet the specified Safety Integrity Level(s).

Note: It should be noted that the SIL requirement applies t o a complete function,
i.e. the field sensor, the logic solver and the final element. It is therefore
incorrect t o refer t o any individual item of equipment having a safety
integrity level. However, a separate component can be certified as being
"fit for use" for a particular SIL application, but the entire Safety Loop shall
meet the specified SIL.

10.1.2 The SIS Design & Engineering shall implement the requirements o f IEC 6 1 5 0 8 /
IEC 6 1 51 1-1, and KOC Standards and Specifications listed under clause 4.2 o f
this RP.

10.1.3 In case of conflict between IEC 6 1 5 0 8 1 IEC 6 1 51 1 and KOC Standards &
Specifications including this Recommended Practice, the most stringent shall
apply.

10.1.4 The Functional Safety Consultant shall review and verify the Functional Design
Specification (FDS) o f the SIS logic solver provided b y the Vendor and / or the
main Contractor o f KOC projects and issue a report t o KOC, whether or not it
meets the SRS and the necessary changes, i f any, required t o fully comply with
the SRS. The FDS shall clearly detail the technical requirements of the SIS's logic
solver and h o w they will be implemented t o achieve the project objectives.
A Safety Manual should be provided b y the manufacturer for all logic solvers
certified as per IEC61508. All requirements of the safety manual have t o be
reviewed by the Functional Safety Consultant for compliance. This shall include
fully detailed specifications, design drawings, calculations and supporting
documentation, but not limited to:

Works and Equipment that the vendor has included in his scope;
Works and Equipment that the vendor has excluded from his scope;
References t o Process Design Basis, Operating & Control philosophy, P & IDS,
Cause & Effect Diagrams, Layout and Location Plans;
Typical Logic Diagrams;
I10 lists;
Man-Machine Interfaces, Alarms & Trip Settings, Loggers;
Fail Safe Conditions;
System Architectures, Report Formats, Loop Drawings;
MTBF calculations;
System Loading (software, hardware, networks, memory) calculations;
Manufacturers' Specifications and Data Sheets of the field instruments, logic
solvers, final control element and all other equipmentsl components that form

Heat and Power Load lists;


Deviations stated explicitly;
Contract Deliverables list;
Criteria for measuring the SIS performance providing evidence that the
performance requirements have been or can be achieved;
Comprehensive details of new andl or upgraded equipment and the details of
all interfaces t o other existing or new ESD, DCS and F&G Systems;
Details of software, versions, licenses;
Fully indexed user manuals.

The FDS shall serve as the basis for the detailed design of the SIS1s logic solver
and development of Testing, Commissioning, FAT, SAT Procedures, Operating,
Installation and Maintenance Manuals.

The manufacture of SIS1s logic solver shall commence only after the review of the
FDS b y the Functional Safety Consultant and the approval o f the same by KOC.
The FDS shall be updated on an on-going basis until Operational Acceptance is
achieved. The Functional Safety Consultant shall conduct the final review and
verify the FDS, while he provides final certification of the SIS as per the
requirements of clause 8.1 . 1 (f) of this RP.

10.2 Certification

10.2.1 Field sensors, logic solver(s) and final elements that form part of a SIF SIL 1 or
higher shall be:
Proven-in-use i n compliance with requirements in IEC 6 1 508-2 clauses 7.4.7.6
to 7.4.7.1 2, and / or
IEC 6 1 5 0 8 1 IEC 6 1 51 1 certified for the application.

10.2.2 The certification shall be performed b y an independent certification body, such as


TUV, Exida, or Risknowlogy or b y other KOC approved body. The certification
should include evidence that the reliability data (MTBF) and failure mode data
(FMEA) have been verified b y the independent certification body. The individuals
or organizations that produce such SIL certifications shall themselves be certified
t o carry out such activity. Copies of all certifications of the certifying bodies and
individuals shall be made available t o KOC.

11.0 SIS DESIGN VERIFICATION

11.1 As part of the SIS detailed design, SIL verification shall be performed. The SIL
verification shall calculate the Probability o f Failure on Demand (PFD) for the
Safety Instrumented Functions.

11.2 The following quantitative techniques are applicable for verifying that the Safety
Integrity Level is achieved:

Fault Tree Analysis;

Markov Modeling.

11.3 For projects within KOC facilities, the SIL shall be verified b y the application of
Fault Tree Analysis or Markov Modeling Techniques. Markov Modeling Technique
is the preferred method considering that these models provide the most accurate
analysis. Internationally reputed software tools shall be used for SIL verification.

11.4 The SIL verification shall be performed b y Functional Safety Consultant with CFSE
certification, trained i n LOPA analysis and Fault Tree Analysis.

11.5 If the SIL target can not be met during the SIL verification, the following should be
addressed and documented b y the team performing SIL verification:

a) Provision o f additional devices or replacement of the existing devices


(especially initiator and/or final element)

b) Review of the test interval of the specific SIS

The typical proof test interval for the various SlFs shall be one year, and i n
specific cases, a proof test interval o f not less than six (6) months may be agreed
by KOC on case t o case basis, only if the additional measures t o meet the target
SIL is unduly excessive or impractical.
11.6 Commercially available SIL verification software shall be used t o complete the SIL
verification calculations. It is mandatory that the software shall be T*V certified
for the highest SIL required. This certification shall cover the processes (algorithm
1 method etc.) t o be completed b y the software.

11.7 The Factory Acceptance Test of Logic Solver shall be conducted only after the SIL
verification confirms that the target SIL has been met b y SIS. (Note that
sometimes Logic Solver may already be certified for SIL 3 applications, but still the
Contractor may have t o add additional physical input sensor or output I final
control elements, in order t o meet SIL targets. To achieve this, Logic Solver would
need additional 110 cards and reprogramming).

12.0 FACTORY ACCEPTANCE TEST (FAT)

12.1 General

12.1.1 Factory Acceptance Testing (FAT) of a SIS shall be performed in accordance with
IEC 61 5 1 1-1 and KOC Standards and Specifications listed under clause 4.2 of this
RP.

12.1.2 In case of conflict between IEC 6 1 5 1 1 and KOC Standards & Specifications
including this Recommended Practice, the most stringent shall apply.

12.2 Objective

The objective of the FAT shall be t o test the logic solver and associated software
together t o ensure that it satisfies the requirements defined in the Safety
Requirement Specification. By testing the logic solver and associated software
prior to installation, errors shall be readily identified and corrected as per IEC
6 1 51 1-1, sub-clause 0.

12.3 Additional Recommendations t o KOC Standards & S ~ e c i f i c a t i o n s

12.3.1 The need for a FAT shall be specified during the design phase of a project. The
planning of FAT shall specify the following, but not limited to:

Types of test t o be performed;

Test cases, test description and test data;

Dependence o n other systems/interfaces;

Test environment and tools;

Logic solver configuration;


Criteria for when the test is considered complete;

Procedures for corrective action in case o f failure of the test;

Test personnel competencies;

Location of test.

SIS Logic description

Trip Values

Instrument Ranges

Testing tolerances

Communications t o occur between SIS & BPCS

Bypass initiation, required

Alarms & Indications

The FAT documents have t o be project specific and approved prior t o the FAT
being carried out.

12.3.2 For each FAT, the following shall be addressed:

The version of the test plan being used;

The safety instrumented function and performance characteristic being tested;

The detailed test procedures and test descriptions

A chronological record of the test activities;

The tools, equipment and interfaces used.

12.3.3 The results of FAT shall be documented, stating:

The test cases,

The test results,

Whether the objectives and criteria of the test criteria have been met.
12.3.4 If there is a failure during the test, the reasons for the failure shall be documented
and analyzed; and the appropriate corrective action should be implemented.

12.3.5 During the FAT, any modification or change shall be subjected t o a safety analysis
t o determine:

The extent of impact on each Safety lnstrumented Function;

The extent of retest, which should be defined and implemented.

13.0 SIS INSTALLATION, COMMISSIONING AND VALIDATION

13.1 Obiectives

The following recommendations shall be followed in addition t o KOC Standards &


Specifications listed in Clause 4.2 of this RP, and are related to:

lnstallation of the SIS according t o the specifications and drawings;

Performing mechanical completion1 commissioning o f the SIS so that it is ready


for final system validation;

Validation, through inspection and testing, that the installed and mechanically
complete SIS and its associated Safety Instrumented Functions, do achieve
the requirements as stated in the Safety Requirement Specification.

13.2 lnstallation and Mechanical C o m ~ l e t i o nCommissioning


l

13.2.1 General

a) lnstallation and mechanical completion I commissioning shall include the


following:

The installation and mechanical completion activities;

The procedures, measures and techniques t o be used for installation


and mechanical completion;

lnstallation and mechanical completion Icommissioning schedule.

b) lnstallation and mechanical completionl commissioning shall verify the


procedures for handling non-conformities where the actual installation does
not conform t o the design information established.
13.2.2 Installation

All Safety lnstrumented System components shall be properly installed per the
design and installation plan(s) which shall include special requirements for Safety
lnstrumented Functions and shall be in accordance w i t h KOC Standards &
Specifications.

13.2.3 Mechanical Completion1 Commissioning

a) Mechanical completion 1 commissioning shall include all activities ensuring


that all fabrication and installation work has been performed according t o
the requirements of the project specifications and the design drawings, and
that the relevant subsystems/ systems or installations are ready for
commissioning.

b) The SIS shall be mechanically completed before the final system validation.
Mechanical completion/ commissioning activities shall include, but not be
limited t o the following:

i. Grounding has been properly connected;


ii. Energy sources have been properly connected and are operational;
...
111. Transportation stops and packing materials have been removed;
iv. No physical damage is present;
v. All instruments have been properly calibrated;
vi. All field devices are operational;
vii. Logic solver and input/outputs are operational;
viii, Interfaces t o other systems and peripherals are operational.

C) Appropriate records of the mechanical completion 1 commissioning of the


SIS shall be produced, stating the test results and whether the objectives
and criteria identified during the design phase have been met.

d) If there is a failure, the reasons for the failure shall be recorded.

e) If it has been revealed that the actual installation does not conform t o the
design information, this non-conformity shall be evaluated b y the Functional
Safety Consultant, and the likely impact o n safety determined.

f) If it is found that the nonconformity has no impact on safety, then the


design information shall be updated t o as built status. Otherwise, the
installation shall be modified t o meet the design requirements.
13.3 SIS Safetv Validation

13.3.1 S1S safety validation as per this RP shall mean all necessary activities t o validate
that the installed and mechanical completed 1 commissioned SIS and its
associated Safety Instrumented Functions meets the requirements as stated in the
Safety Requirement Specification.

13.3.2 Where measurement accuracy is required as part o f the validation, then


instruments used for this function must be calibrated against a specification
traceable t o a national standard or t o the Manufacturer's specification.

13.3.3 Validation activities of the SIS shall include the following items as a minimum:

a) The validation activities, including validation of the SIS with respect t o the
Safety Requirements Specification and implementation and resolution of
resulting recommendations;

b) Validation o f all relevant modes of operation of the process and its


associated equipment including:

i. Preparation for use including setting and adjustment;


-.
11. Start-up, automatic, manual, semi-automatic and steady state of
operation;
...
111. Re-setting, shut down and maintenance;

iv. Reasonably foreseeable abnormal conditions for example those


identified through the risk analysis phase.

C) The procedures, measures and techniques t o be used for validation;

d) Reference t o information against which the validation shall be carried out


(e.g., cause and effect chart, system control diagrams);

e) SIS Safety Validation Schedule;

f) SIS Specialist should be involved i n validation activities.

13.3.4 Additional validation activities for the safety application software shall include the
following as a minimum:

a) Identification o f the safety-related software which needs t o be validated for


each mode o f process operation before mechanical completion commences;

b) Information on the technical strategy for the validation including;


i. Manual and automated techniques;

ii. Static and dynamic techniques;

iii. Analytical and statistical techniques.

C) In accordance with (b), the measures (techniques) and procedures that shall
be used for confirming that each Safety lnstrumented Function shall conform
t o the specified requirements for the software Safety lnstrumented Functions
and the specified requirements for software safety integrity;

d) The required environment in which the validation activities are t o take place
(for example for tests this would include calibrated tools and equipment);

e) The pass I fall criteria for accomplishing software validation including:

i. The required process and operator input signals w i t h their sequences


and their values;

ii. The anticipated output signals with their sequences and their values;

iii. Other acceptance criteria, for example memory usage, timing and value
tolerances.

f) The policies and procedures for evaluating the results of the validation,
particularly failures.

13.3.5 Validation activities shall, as a minimum, confirm that:

a) The Safety lnstrumented System performs under normal and abnormal


operating modes (e.g., start-up, shutdown, etc.) as identified in the Safety
Requirement Specification;

b) Adverse interaction of the Basic Process Control System and other connected
systems do not affect the proper operation o f the Safety lnstrumented
System;

C) The Safety lnstrumented System properly communicates (where required)


w i t h the Basic Process Control System or any other system or network;

d) Sensors, logic solver, and final elements perform in accordance with the
Safety Requirement Specification, including all redundant channels;

e) Safety lnstrumented System documentation reflects the installed system;

-
f) The Safety lnstrumented Function performs as specified on bad (e.g., out of
range) process variables;

g) The proper shutdown sequence is activated;

h) The Safety lnstrumented System provides the proper annunciation and proper
operation display;

i) Computations that are included in the Safety lnstrumented System are


correct;

j) The Safety lnstrumented System reset functions perform as defined i n the


Safety Requirement Specification;

k) Bypass functions operate correctly;

I) Manual shutdown systems operate correctly;

m) The proof test intervals are documented i n the maintenance procedures;

n) Diagnostic alarm functions perform as required;

O) The Safety lnstrumented System performs as required on loss of power or a


failure of a power supply and that when power is restored, the Safety
lnstrumented System returns t o the desired state.

13.3.6 The software validation shall confirm that all of the specified software safety
requirements are correctly performed. Further that the software does not
jeopardize the safety requirements under SIS fault conditions and in degraded
modes of operation or by executing software functionality not defined in this RP.
The information of the validation activities shall be available.

13.3.7 Prior t o using the SIS for its intended purpose and after the validation activity is
complete, the following activities shall be carried out:

a) All bypass functions (e.g., programmable electronic logic solver and sensor
forces, disabled alarms) shall be returned t o their normal position;

b) All process isolation valves shall be set according t o the process start-up
requirements and procedures;

C) All test materials (e.g., fluids) shall be removed;

d) All forces shall be removed and, if applicable, all force enables shall be
removed.
13.3.8 Appropriate documentation of the results o f the SIS validation shall be produced
which shall include:

a) The Safety lnstrumented Function under test (or analysis), along with the
specific reference t o the requirements identified during SIS validation;

b) Tools and equipment used, along with calibration data;

c) The results o f each test;

d) The test specification used;

e) The criteria for acceptance of the integration tests;

f) Any discrepancy between expected and actual results;

g) The analyses made and the decisions taken on whether t o continue the test
or issue a modification request, in the case when discrepancies occur.

13.3.9 When discrepancies occur between expected and actual results, the analyses
made and the decisions taken should be available as part o f the results o f the
software safety validation. It shall be stated whether it was decided t o continue
the validation, or t o issue a modification request and return t o an earlier part of
the development lifecycle of the SIS.

14.0 SIS OPERATION AND MAINTENANCE

14.1 General

14.1.1 The Safety lnstrumented Systems (SIS) shall be operated and maintained t o
ensure that it functions in accordance w i t h the Safety Requirements Specification
throughout the SIS operational life and the SIS functional safety is maintained.

14.1.2 The required SIL o f each Safety lnstrumented Function, as specified in Safety
Requirements Specification, shall be maintained during operation and
maintenance.

14.1.3 Maintenance as per this RP is concerned w i t h ensuring that the SIS does not
deteriorate below the specified Safety Integrity Level. It details requirements for
repairs of defective components and replacements w i t h identical units having
exactly the same specification. In addition, recommendations for functional proof
testing and handling o f non-conformities and demands are included.
14.2 Requirements

The operation and maintenance program shall consider as a minimum the


following factors:

a) Routine and abnormal operational activities;

b) Functional proof testing;

C) Preventative and breakdown maintenance activities;

d) The application and control o f overrides t o SIS;

e) The procedures, measures and techniques t o be used for operation and


maintenance;

f) Verification of adherence t o operation and maintenance procedures;

g) Activities schedule;

h) Equipment and tools needed for carrying out the activities;

i) The training for staff carrying out the activities relating t o operation and
maintenance of SIS;

j) Consideration for differentiation of operations and maintenance practices t o


reflect the various SIL levels;

k) Specification of which reliability data should be collected and analyzed during


the operational phase.

14.3 O ~ e r a t i o nand Maintenance Procedures

14.3.1 Operation and maintenance procedures shall be developed b y Functional Safety


Consultant as per requirements o f Clause 8.1.I. Operation and maintenance
procedures shall take account of the above factors t o ensure that the SIS performs
throughout the life of the installation in accordance with the Safety Requirements
Specifications and the required SIL of each SIF is maintained.

14.3.2These procedures shall include but not be limited t o the following:

a) The routine actions which need t o be carried out t o maintain the required
functional safety of the SIS;

b) Limits o f safe operation (i.e. trip points) and the safety implications of
exceeding them;
C) H o w the SIS takes the process t o a safe state;

d) Timing requirements for SIS functions including output devices;

e) The correct use of operational or maintenance overrides, bypasses, inhibit/


permissive, system resets, etc. t o prevent an unsafe state and/or reduce the
consequences of a hazardous event (e.g. when a system needs t o be
bypassed for testing or maintenance, which compensating measures must be
implemented);

f) The correct response t o SIS alarms and trips;

g) The information which needs t o be maintained on system failure and demand


rates on the SIS;

h) The information which needs t o be maintained showing results o f audits and


tests on the SIS;

i) The maintenance procedures t o be followed when faults or failures occur i n


the SIS;

j) Procedures for tracking maintenance performance;

k) Procedures for tracking of activation and failures of the SIS;

I) Procedures for ensuring that test equipment used during normal maintenance
activities are properly calibrated and maintained;

m) Documentation o f the above.

14.4 Operation

14.4.1 General

a) All activities concerning the operation of the SIS shall be performed by


operators w h o have been previously trained in this field.

b) Some considerations that shall be considered when operating the SIS are
detailed below:

14.4.2 Training

a) Operations and Maintenance personnel shall be trained t o sustain full


functional performance of the SIS t o its targeted Safety Integrity.
b) Relevant Engineers & Supervisors from Production Operation and Operation
Technical Services shall obtain full training on the functions and operation of
the system.

C) Operators shall be periodically trained o n the function and operation of the


SIS in their area of responsibility. Training should be through HR where
Contractor t o include or refer in his overall training as per the contract
requirements t o particular equipment with SIL function.

d) Training requirements for operations personnel are as follows and training


shall address the following as a minimum:

Understanding of h o w the SIS functions (trip points and the resulting


action that is taken b y the SIS);

Understanding o f the hazards which the SIS is protecting against

The operation and consequences of operation o f all bypass switches,


overrides, inhibits, etc and under what circumstances these bypasses are
t o be used and recorded;

The operation of any manual shutdown switches and when these manual
shutdown switches are t o be activated;

Behavior upon activation of any diagnostic alarms (e.g., what action


shall be taken when any SIS alarm is activated indicating there is a
problem w i t h the SIS itself).

Experienceltraining w i t h SIS lifecycle and understands personal role and


responsibility

Awareness of the significance o f integrity levels and the importance o f


following specified procedures

Early diagnosis of process and SIS faults and failures, requirements for
actions t o be taken, and required reporting.

Understanding o f all bypass and override procedures

Knowledgeable in operating procedures including response t o diagnostic


and critical alarms

Experienceltraining on process hazards


Experienceltraining on the impact of alarm response on safe operation

Experienceltraining on the impact of operational activities on safe operation

Experienceltraining on the impact of operational activities on safe operation

Experienceltraining on the impact of testing on SIS performance

e) Training requirements for maintenance personnel are as follows and training


shall address the following as a minimum:

Experienceltraining w i t h SIS lifecycle and understands personal role and


responsibility

Awareness of the significance of integrity levels and the importance of


following specified procedures

Able t o read and understand all documentation and records

Knowledgeable in maintenance and testing practices and procedures


including proof testing and inspection

Knowledgeable concerning equipment (including fixed equipment and


instrumentation) failure history and causes

Experience1 training on process hazards

Experienceltraining on integrity1 reliability data

Experienceltraining on the impact of testing on SIS performance

Experienceltraining on the impact of maintenance activities on plant


operation

14.4.3 Overrides

a) Override switches requirements are detailed in KOC Standard for Shutdown


System KOC-1-004.

b) In order t o maintain the safety integrity during activation of overrides, KOC


HSEMS Procedure KOC.SA.020 Plant Safety Override Registration Procedure
shall be followed for controlling, approving and recording the application of
overrides t o SIS.

C) The procedure shall be developed by Functional Safety Consultant and shall


consider differentiating between SIL classes in order t o reflect the greater
safety impact of overriding a SIL 3 system than, for example, a SIL 1
system. This could imply imposing different requirements t o implementation
of compensating measures and t o define different upper limits for allowed
override time, depending on the integrity level of the SIS under consideration.

d) If manual intervention is considered as the compensating measure during SIS


overrides, the available operator response time must be assessed, taking into
consideration the foreseen time for revealing the abnormal situation as well
as taking correct action.

14.4.4 Non-Conformities and Demands

a) In order t o ensure that the SIS is performing in accordance w i t h the design


intent as per Safety Requirements Specification and hence the required
Safety Integrity Level, it is necessary t o record non-conformities between
expected behavior and actual behavior o f the SIS.

b) All such discrepancies shall be recorded and analyzed and where necessary,
modifications made such that the required SIL is maintained.

C) The following shall as a minimum be monitored and recorded:

Actions taken following a demand o n the system;

Failures of equipment forming part of the SIS t o act on demand;

Failure of equipment forming part of the SIS during routine testing;

Cause of the demands;

Cause of false trip

That the frequency of the demands is in accordance with the


assumptions made in the original SIL assessment.

d) Preference shall be given t o systems that provide automatic recording and


reporting of non-conformities during normal demands o n the SIS.

14.5 Maintenance

14.5.1 General

a) A maintenance program shall be established b y the Functional Safety


Consultant as per the requirements of Clause 8.1.1, which includes written
procedures for maintaining, testing, and repairing the SIS t o maintain the
required Safety Integrity Level as specified in Safety Requirements
Specification.
b) This program shall be designed t o reveal faults that are not automatically
detected b y the SIS. Non-availability during routine testing and the effect of
mean time t o repair on the overall availability of the system shall be included.

C) SIS maintenance shall include, but not be limited to, the following:

Regularly scheduled functional testing of the SIS;

Regular inspection of field equipment to ensure that there is no observable


deterioration, for example: corrosion or mechanical damage, damaged
cabling or terminations, blockage of fire and gas detectors etc.;

Regularly scheduled preventative maintenance, as required (e.g.,


replacement of ventilation filters, lubrication, battery replacement,
calibration, etc.);

Repair of detected faults, with appropriate testing after repair.

d) Replacement of a component in a SIS with another with different


characteristics shall be treated as a modification.

14.5.2 Testing, Inspection, and Maintenance

a) Manufacturer1 Vendor manuals that describe the SIS maintenance and testing
requirements shall be included in the maintenance procedures.

b) If a SIS function needs t o be bypassed while the process is in a hazardous


state, written procedures shall be provided b y the Functional Safety
t o maintain the safety o f
Consultant as per the requirements of Clause 8.1 .l,
the process. The procedure shall include details related t o resetting any
inhibits or overrides that may be necessary during testing, inspection and
maintenance of the SIS.

14.5.3 Functional Testing

a) Periodical functional tests shall be conducted using a documented procedure


developed b y Functional Safety Consultant, t o reveal the undetected faults
that prevent the SIS from operating according t o the Safety Requirement
Specifications.

b) The entire SIS shall be tested including the sensor(s), the logic solver, and
the final element(s) (e.g., shutdown valves, motors).

C) Activation o f SIS functions shall be recorded and analyzed and included as


part of the functional testing. If proper operation and documentation thereof
exist for a period, the manual proof test for that period may be omitted.
14.5.4 Frequency of Functional Testing

a) The SIS shall be tested at specific intervals based on the frequency specified
in the Safety Requirement Specifications and related t o PFD,, calculation.
Different parts o f the SIS may require different periodic test intervals (e.g.
logic solver or sensors, final elements).

b) A t a periodic interval defined in SRS, the frequency(s) o f testing for the SIS
or parts of the SIS shall be re-evaluated based on historical data, installation
experience, hardware degradation, software reliability, etc. Change of the
interval shall be handled as a modification.

C) Any change t o the application logic shall be full functional tested, and treated
as a modification.

14.5.5 Functional Testing Procedure

A documented functional test procedure, describing each step t o be performed,


shall be provided for each SIS by the Functional Safety Consultant. The functional
testing procedure shall include, as a minimum, verifying the following:

Operation of all input devices including primary sensors and SIS input
modules;

Logic associated with each input device;

Logic associated with combined inputs;

Trip initiating values (set-points) o f all inputs;

Alarm functions;

Speed o f response of the SIS when necessary;

Operating sequence of the logic program;

Function of all final control elements and SIS output modules;

Computational functions performed by the SIS;

Timing and speed of output devices;

Function o f the manual trip t o bring the system t o its safe state;
Function o f user diagnostics;

Complete system functionality;

The SIS is operational after testing.

14.5.6 On-Line Functional Testing

Procedures t o allow on-line functional testing shall be developed b y the Functional


Safety Consultant, where required and shall be available o n site. For those
applications where activating the final trip element may not be practical, the
procedure shall include:

Testing the final element during unit shut down; and

Executing the output(s) as far as practical (e.g., output trip relay, shut down
solenoid or partial valve stroke) during on-line testing. Although partial valve
stroking reduces the need t o fully test the valve, the entire loop still should be
fully tested at certain intervals.

14.5.7 Documentation of Functional Testing

a) The description of all tests performed shall be documented b y the person


performing the required actions, shall be signed b y KOC supervisors and must
be sent t o KOC concerned Production Operation Group for records. Accurate
data related t o SIS testing shall be recorded. Records t o certify that tests and
inspections have been performed shall be maintained b y Maintenance Team.

b) Documentation, which may be recorded in an electronic maintenance


database, shall include the following information as a minimum:

Date of inspection;

Name of the person who performed the test or inspection;

Serial number or other unique identifier o f equipment (loop number, tag


number, equipment number, user approved number, etc.);

Results o f inspection/test ("as-found" and "as-left" condition);

Details of any faults found and the corrective action taken.


15.0 AUDITING OF SAFETY INSTRUMENTED SYSTEMS

15.1 Purpose

The audit is required t o verify that the SIS fulfills the Safety Requirements
Specification and that all operational and maintenance procedures are being
followed.

15.2 Audit Frequency

No specific audit frequency has been defined in the standards. It is recommended


that 3 year intervals be used and the interval of audits may need t o be changed
based on audit history.

15.3 Audit Participants

The individuals conducting the audit should be independent of the plant personnel
where the audit is being carried out. They could be either from a central
engineering facility or from another plant location.

15.4 Specific Items to Be Reviewed Durinq Audit

Record of training of the Production and Maintenance Engineer(s)


Record of training of process operators and instrument maintenance staff
with responsibility for the maintenance and functional testing of SIS
Review of SRS and compare with current settings
Operating instructions relating t o SIS
Up t o date Process and Instrumentation Diagrams (P&IDs) showing the SIS
Proof Test and Maintenance Documents
Existence of maintenance instructions
Up t o date loop diagrams or circuit diagrams needed for the maintenance of
systems.
Cable, junction boxes, and marshalling cabinet
Test procedures/schedules.
Results of tests (test sheets).
Records and results of audits carried out.
Records of repairs and corrective measures taken after testing
Records of any modification carried out t o the SIS, their purpose, the results
o f hazard studies, or other formal investigations, and the design
documentation relating t o the modifications.
Is the equipment being kept t o the design standard?
Is the equipment correctly labeled and does this agree with the
documentation?
Is the equipment in a satisfactory mechanical condition?
Bypassing and possible excessive use of Bypassing
Management of Change (MOC)
Operators disabling alarms but not logging in as required.

16.0 SIS MODIFICATION

16.1 Any modification t o the Safety lnstrumented System shall be performed in


accordance with KOC Management of Change Procedure, KOC.GE.006. The
required Safety Integrity Level of the SIS shall be maintained despite any
modifications made t o the SIS.

16.2 Modifications to the BPCS, other equipment, process or operating conditions shall
be reviewed t o determine whether they are such that the nature or frequency o f
demands on the SIS will be affected. Those having an adverse effect shall be
considered further t o determine whether the level of risk reduction will still be
sufficient.

16.3 A safety analysis shall be carried out t o determine the impact on functional safety
as a result of the proposed modification.

16.4 All modifications t o the SIS shall initiate a return t o the appropriate phase (first
phase affected by the modification) of the Safety Life Cycle. All subsequent
Safety Life Cycle phases shall then be carried out, including appropriate
verification that the modification has been carried out correctly and documented.

16.5 In case of modifications t o the KOC1s existing SIS designed and constructed in
accordance with codes, standards or practices prior t o the issue o f IEC 6 1 5081
6 1 51 1 standards, the Safety Requirements Specification shall be developed and
the modification shall pass through all safety life cycle phases, e.g. for:

Major replacements or upgrades of the SIS

Major units or modules replacement or installation

Major changes in the process characteristics of the fluids handled b y the


plant may create a need for increasing the safety integrity o f the existing SIS,
etc.

17.0 SIS DECOMMISSIONING

17.1 Decommissioning of the Safety lnstrumented System shall be performed in


accordance w i t h KOC Management o f Change Procedure, KOC.GE.006. The
required Safety lnstrumented Functions shall remain operational during
decommissioning activities
17.2 The impact of SIS decommissioning on adjacent operating units and facilities shall
be evaluated prior t o decommissioning activity.

18.0 DOCUMENTATION

18.1 Complete set of documentation shall be available t o ensure that the necessary
information is documented and available in order that all phases of the safety life
cycle can be effectively performed including verification, validation and functional
safety analyses activities.

18.2 All documentation and any other written information shall be i n English language.

18.3 The documentation shall include, but not limited t o the following:

Safety Requirement Specifications

Application logic (e.g. Cause & Effect Diagrams, Logic Narrative, Logic
Table, Boolean Diagrams or Ladder Logic Diagrams)

Process & Control Narratives (SIS Specialist t o advise)

Functional Design Specification of logic solver (SIS Specialist t o advise)

Design documentation, As-built documentation

Factory Acceptance Test Procedures

Factory Acceptance Tests records

Commissioning Pre-Startup Acceptance Test Procedure(s)

Commissioning records

SIS validation documents and records

SIS Operating Procedure(s)

Records of SIS operating events

SIS Maintenance Procedure(s)

SIS maintenance records

Functional test procedure(s)


Functional testing records

SIS modification documentation

Records and complete documentation of verifications that the required SIL of


each safety function implemented in the SIS has been met.

All the calculation and their resultant outputs, the supportive input1 reference
data, etc. (i.e. the entire database of the SIL assessment and the final report)
shall be submitted t o KOC in editable electronic format on DVDI CD. The
programs used t o develop the SIL assessment final report shall be agreed with
KOC prior t o start of SIL assessment and final report preparation.
DOC. NO. KOC-1-017 I Page M o f 113 I REV. 1

APPENDIX A : INDEPENDENT PROTECTION LAYER REQUIREMENTS

A 1.0 Introduction

A n lndependent Protection Layer (IPL) is a specific category of safeguard.


Protection layers shall meet the following criteria t o be qualified as lndependent
Protection Layer:

Specificity - A n independent protection layer shall be specifically designed t o


prevent the consequences o f one potentially hazardous event.

Independence - The operation of the protection layer shall be completely


independent from all other protection layers, no common equipment can be shared
with other protection layers.

Dependability -The device shall be able t o dependably prevent the consequence


from occurring. Both systematic and random faults need t o be considered in its
design. The probability of failure of an independent protection layer shall be
demonstrated t o be less than 10%.

Auditability - The device shall be proof tested and maintained. These audits of
operation are necessary t o ensure that the specified level o f risk reduction is being
achieved.

The following safeguards are commonly used in the process industries as


independent layers o f protection, and could be considered for each LOPA. This list
shown below is not intended t o be a complete and exhaustive list. The team
should work t o identify all safeguard for each scenario under study, even if it is
not shown below.

A 2.0 Basic Process Control Svstem

A Basic Process Control System (BPCS) is a control loop or automated shutdown


with software and/or I10 residing in the unit Distributed Control System (DCS) or a
Programmable Logic Controller (PLC) used for normal process control. In many
cases, the basic process control system is designed t o automatically move the
process t o a safe state under abnormal conditions. The BPCS is also often
designed t o mimic actions taking place in the SIS.

To determine whether a BPCS function can be used as an IPL, the team shall
verify that the BPCS function is independent of the initiating cause and
independent o f the functionality of other IPLs. If the initiating cause is a BPCS
control loop failure, another control loop within the BPCS shall not be designated
as an IPL, unless a detailed study of the BPCS is performed t o ensure sufficient
independence and redundancy i n order t o address common cause failure.
The BPCS IPL shall completely mitigate the scenario without assistance from
other systems. The team should verify that the BPCS runs in automatic mode
during all operational phases where the accident scenario exists.

Note: The team shall be aware that designation o f a BPCS control loop as an IPL
t o protect against failure of another BPCS control loop often has a
significant potential for common cause failure. The analysis shall document
h o w the possibility of common cause failures was addressed b y the IPL
analysis team. Consequently, only one BPCS function could be used as an
IPL t o prevent the possibility o f common cause failure making more than
one IPL ineffective.

The BPCS shall not be considered as Independent Protection Layer for all KOC
projects if its failure is the cause of the initiating event associated with the SIF.

A 3.0 Operator Intervention usinq Operatinq Procedures

A common safeguard involves operator intervention t o manually shutdown a


process when abnormal conditions are detected. In order for this safeguard to
meet the level required of an IPL, an operator shall always be present, be alerted
t o the abnormal situation (typically b y a well-rationalized alarm system), be trained
in the specific actions t o the abnormal situation, and have ample time t o consider
the alarm and respond.

Only one alarm with operator response could be used as an IPL, unless the alarms
occur at distinctly separate times (e.g. an hour or more apart) and utilize separate
field instrumentation.

The alarm and field devices used t o respond shall be independent of the initiating
cause. For example, i f the initiating cause for the scenario is a BPCS malfunction
(e.g. control loop), alarms generated b y the BPCS shall use independent
instrumentation from the failed control loop and shall be processed through an
independent channel i n the BPCS. If an alarm in the BPCS is relied upon for an
operator intervention IPL, any other BPCS functions, including BPCS control loops,
shall not be used for additional risk reduction t o reduce the potential of common
cause failure.

Note I : The purpose for limiting the amount o f risk reduction assigned t o any
single IPL is that multiple systems that reside within the same layer of
protection are vulnerable t o the failure of those components, procedures,
or personnel that they have in common. For example, i f an operator alarm
with response is listed as an IPL, another operator alarm w i t h response
shall not be claimed as additional risk reduction even though the alarm
may be generated b y a separate sensor and may even involve a different
process variable. This is because a correct operator response is required
for both alarms. The failure of the operator t o correctly diagnose and
respond is considered as a common mode failure.

Note 2: In order for a system t o be credited as an IPL, it shall be independent of


the initiating event and enabling event or conditions AND any other BPCS,
alarm with operator response, Safety Instrumented System, or protective
device already listed as an IPL for the same accident scenario.

The Operator Intervention using Operator Procedures shall not be considered as


an Independent Protection Layer.

A 4.0 Local Devices

Local devices such as check valves, excess f l o w valves, pressure regulator valves,
etc. are independent of the BPCS and often can fully mitigate the potential
accident scenario. Often these devices are local controls or shutdowns. Because
these devices are independent of the BPCS, they can be used when the initiating
cause of the scenario is a failure of a BPCS function, including alarms or control

A 5.0 Mechanical lntearitv of E a u i ~ m e n t

In many cases, a pressure vessel will be designed t o withstand the highest


temperatures and pressures generated as the result of abnormal conditions. In
these cases, the mechanical integrity of the vessel is an IPL.

A 6.0 Consequence Mitiaation Systems

Consequence Mitigation Systems (CMS) include rupture disks, pressure relief


valves, thermal fusible plugs, fire and gas systems, etc. To be considered an IPL,
the documentation shall show that the CMS is designed t o mitigate the accident
scenario. For example, it shall be verified that the pressure safety valve or pressure
relief valve is sized for the specific relief case generated b y the accident scenario.

To determine whether a CMS can be used as an IPL, the team shall verify that the
CMS is independent of the initiating cause and other IPLrs. For a manually initiated
CMS, the initiating cause and other IPL1s shall be examined t o ensure that the
same operator or operator response that resulted i n the other failures can not also
cause the CMS t o fail.

A CMS can reduce the frequency and/ or consequence o f the accident scenario.
Depending on the type of CMS, the consequence due t o CMS functioning may
still be undesirable. For example, a pressure relief valve may prevent a vessel
rupture from occurring, but discharge o f process materials t o the atmosphere may
be undesirable from an environmental permit standpoint. Consequently, the team
shall analyze the consequence due t o the CMS functioning.
Note: If the action of a consequence mitigation system does not COMPLETELY
prevent any harm from occurring as a result o f the incident, then Advanced
Analysis will be required. This advanced analysis will typically take the form
of consequence analysis and consequence analysis event trees. For
instance, a fire deluge system may mitigate the consequence of a fire from
a "catastrophic" consequence t o a "Marginal" consequence. Whether or not
the deluge successfully operates, there is a significant consequence that
must be considered.

Fire & Gas Systems shall not be considered as Independent Protection Layer for
all KOC projects.

A 7.0 External Risk Reduction Facilities (ERRFL

Some hazards are mitigated by external actions that will completely eliminate the
consequence, but are initiated by active mechanical means. ERRF may include
items such as water spray curtains that prevent dispersion of toxic liquids.

A 8.0 Intermittent Use Factor

In some cases, a hazard that should be prevented b y the SIF is not continually
present. Some hazards are only present during periodic or maintenance operations.
In these situations, if the hazard is present less than 1 0 % of the time, the risk is
one order of magnitude lower than it would be if the hazard were continually
present. Therefore, i f presence o f the hazard is less than 1 0 % of the time,
intermittent use can be considered a protection layer.

Use Factor = time at risk / total time

Occupancy Factor

To qualify as a safety related scenario, a person must be in the area where the
hazard may occur. Credit should be taken for time not in the hazard zone.

Occupancy factor = time present t o hazard 1 total time

A 9.0 lqnition Probability

The following probabilities are suggested t o be used as probability of ignition given


release:

Pi = 1 for material released above auto-ignition temperature and for


pyrophoric material
Pi = 0.1 for releases of heavy liquids
Pi = 0.2 for volatile liquids

Pi = 0.3 for flammable liquidslgas

Reference: Lees, F.P. (1996). Loss Prevention in the Process Industries. 2nd
Edition. Elsevier.
APPENDIX B : SAFETY INTEGRITY LEVEL 'a'

In some cases, the team may desire t o assign a higher priority t o a SIF that has been
determined as having no safety requirements, through the LOPA procedure (i.e., Integrity
Level equal t o zero). In these cases the team may use their judgment t o assign a SIL of
"a", increasing the priority of that function. SIL "a" means n o special safety
requirements. When a SIF is assigned a SIL of "a", it shall have the following attributes
employed i n its design.

All "qualitative" requirements for conceptual and detailed design given in IEC
6 1 5081 6 1 5 1 1 shall be employed.

The Safety Instrumented System design should employ simplex (single, or 1001
voting) field devices, unless nuisance trip prevention requirements dictate the use of
more advanced voting schemes. The use of advanced voting will be added at the
discretion o f the project team.

The SIL "a" system shall be implemented using the same logic solver hardware as
the SIF that have been rated SIL 1 or higher.

The system shall be tested at an interval deemed appropriate b y the project team,
typically the turn-around frequency of the plant.
APPENDIX C : M I N I M U M REQUIREMENTS FOR SIF IMPLEMENTATION

C1.O General

C 1 . l Components and subsystems selected for use as part of a Safety lnstrumented


System for SIL 1 t o SIL 3 applications shall either be in accordance with IEC
61508-2 and IEC 61 508-3, as appropriate, or else they shall be in accordance
with IEC 6 1 51 1 and shall implement the requirements of KOC1s Standards and
Specifications listed under Clause 4.2. They shall be proven in use or evaluated
and certified b y an independent body (e.g. ~ 1 1for
~ use
) in SIL applications.

C1.2 Response time requirements for the SIS t o bring the process t o a safe state shall
be an important factor in field devices, logic solver and final element selection and
installation. The response time for each SIF has t o be clearly documented in the

C1.3 All Safety lnstrumented Systems with the exception of Fire and Gas systems shall
be De-energize t o trip (DTT).

C2.0 Field Devices

C2.1 Field devices shall be selected and installed t o minimize failures that could result in
inaccurate information due to conditions arising from the process and
environmental conditions. Conditions that should be considered t o include
corrosion (including considering soil condition in this part of Gulf region), freezing
of materials in pipes, suspended solids, polymerization, cooking, temperature and
pressure extremes, condensation in dry-leg impulse lines, and insufficient
condensation i n wet-leg impulse lines.

C2.2 SIL 1 and higher SIF field devices shall have their o w n process tappings, impulse
lines, sensors, utilities (power fuses, air supply branch-offs), etc independent of
control measurements. Only elements such as orifice plates and bluff bodies o f
vortex meters may be shared with control measurements.

C2.3 Intelligent sensors w i t h 4-20 rnA output signals are preferred t o discrete, direct
mounted, field switches due t o the lower failure rates, better accuracy and better
stability, and allow sensor signal analysis and measurement comparison.

C2.4 Digital communication protocols for sensors are not acceptable as these are not
yet proven in use or certified t o be used in SIS.

C2.5 Use o f hand-held communicators on intelligent sensors shall, for reasons of


integrity, be restricted (read-only) and may only be applied if tests have proven
that their use will not cause adverse consequences regarding safe or dangerous
failures. Additional line resistors may be required t o permit communication with the
sensor.

C2.6 These sensors shall communicate with the SIS i n 4 - 2 0 m A signal mode. Separate
trip amplifiers should not be applied. Analogue sensor signals shall be connected
directly t o input cards integrally available in the SIS.

C2.7 The logic solver shall differentiate between sensor signal out of range (saturation),
test modes i f available and transmitter failure.

C2.8 SIF field devices, except high liquid level SIF field devices, should have the same
range and accuracy as neighboring process sensors in order t o facilitate
measurement comparison.

C2.9 High liquid level displacer and dP cell SIF field devices should have vessel
connections at 8 0 % and 1 0 0 % t o ensure proper functioning under varying
density conditions compared to design. However, i f comparison is required with
neighboring process sensors, then range correction has t o be done via software in
the logic solver for high liquid level SIF field devices.

C2.1 OManual switches shall be normally closed.

C2.11 Manual resets shall be provided with a 'pulse timer' (in the logic solver) that
provides a pulse on the rising flank of the reset command.

NOTE: This requirement is intended t o prevent a dangerous failure o f the reset


switch (or DCS interface) that would result in a permanent reset signal,
producing an auto-reset logic. This may be dangerous in cases where the
reset switch confirms that the process is safe and ready t o restart.

A n example is a furnace with a burner trip on l o w fuel gas pressure without flame-
eye. When the fuel gas valve opens again (upon return o f pressure) without reset,
delayed ignition and an internal furnace explosion may follow.

C2.121f intrinsically safe electrical equipment is applied in hazardous areas, isolation


barriers are required. To minimize the number of components in the SIF loop, Ex n,
Ex e or Ex d type sensors should be applied i n zone 2 or in zone 1 (except Ex n)
hazardous areas.

C2.131f the SIS has line monitoring facilities and alarms, analogue sensors shall have
"direct" output signals only. If this is not the case, high trip sensors shall have
"reverse" outputs.

C2.14When available, the burnout feature of the transmitter shall be set so that, upon
transmitter failure, the trip action is initiated.
C2.151f diverse initiators are required t o reduce common mode failures, diverse
measuring technologies shall be applied. These diverse measuring technologies
should, where possible, include different types of process sensors. An example of
a diversity is ultrasonic and dP cell level measurements.

NOTE: In considering diversity, the following aspects need t o be assessed:

The impact of the lower common mode failure rate on the PFD of a
dangerous failure robust initiator. For example, the 1002 combination
of a smart transmitter and a pressure switch may well have a better
PFD than t w o smart transmitters (at the same test intervals).

The difference between the diagnostics possibilities o f one measuring


technology and another, for example, the 1002 combination of a
smart transmitter and a pressure switch may well have a worse PFD
than t w o smart transmitters (at the same test intervals) when
measurement validation and comparison is applied t o each transmitter
signal comparing it w i t h a 3rd (diverse) signal.

C3.0 Loqic Solver

C3.1 If the logic solver of the SIS is PLC based, then the complete system, including
system software versions and releases, shall be evaluated and certified by an
independent body (e.g. TUV, Exida, Risknowlogy or any other KOC approved
body).

C3.2 To avoid unexpected failures of software and/ or hardware, only proven releases
of software and hardware shall be used. The release o f the system should not be
upgraded after order placement. for functionality enhancements. Upgrades t o fix
bugs that jeopardize safety or plant availability shall be implemented but only after
certification by an independent body (e.g. TUV, Exida, and Risknowlogy or any
other KOC approved body).).

C3.3 When determining the required response time of the SIS the most important
consideration is the speed at which the process can move from a detectable
unsafe state t o an unwanted accident. The goal of defining the required response
time is setting a target that will allow the unsafe state t o be detected and action
t o be taken prior t o an accident occurring.

The process safety time is the amount of time that elapses between a process
parameter moves t o a dangerous range, and the actual occurrence of the
unwanted event.

The SIS response time requirements, which include the amount of time required t o
measure, execute application logic, and actuate a final element needs t o be set so
that action can always be taken b y the SIS within the process safety time for the
fastest safety instrumented function serviced by an SIS. In order t o account for
when an unwanted event occurs in relation t o the scan cycle of an SIS, the
response time of the SIS should be less than % o f the process smallest safety
time o f the SIF serviced b y an SIS.

C3.4 For rotating equipment, it shall be confirmed that the cycle time is sufficient t o
protect the equipment, i.e. that the process safety time of the equipment exceeds
twice the cycle time plus response times o f initiator and final element and process.

C4.0 Final Element

C4.1 If diverse dangerous failure robust valves are required t o reduce common mode
failures, the valves shall be of a different make and/or type (model).

C4.2 SIF valves classified as SIL 1 or higher shall not be provided w i t h a hand wheel or
a bypass as these increases the dangerous failure rate of the final element. This
requirement shall also apply if the SIF valve is a control valve, either as a l o o 1
valve or as the second valve o f a 1002 configuration.

C4.3 SIL 1 or higher SIF valves should be air operated and spring return. Hydraulically
operated valves are less suitable due t o the complexity of the hydraulic system.
Electric motor operated valves without spring return shall not be used for SIL 1 or
higher SIF applications.

C4.4 For SIL 1 or higher SIF valves, partial operation with feedback o n movement can
be applied t o reduce manual testing activities. Partial Stroke Testing shall normally
be treated as an on-line functional test which covers only a fraction of the possible
failures, and not as self test with diagnostic coverage.

C4.5 For normally de-energized SIF final elements, automatic wiring tests such as line
monitoring and earth fault and automatic test o f the availability of instrument air
shall be implemented on each loop.

Power and air supply for normally de-energized final elements shall be such that
the impact of supply failure on the SIF PFD is negligible, e.g. b y means o f an alarm
in case the supply fails.
- -

Requi
Aux Hazardous Unmi
SIF Output red
outputs event being tigate
SIF to prevent Tolerable Risk
SIF ID SIF Input that are mitigated or d
Description Hazardous Risk/Goal Redu R
part of prevented Frequ
event* ction
overall logic by SIF ency
RR

On low
pass flow if
heater is
Heater not shut,
22F1 A then there
NoILow ALARM is potential
flow in pass for tube
#1 rupture
leading t o
fire in the
unit.
DOC. NO. KOC-1-017 I Page 75 of 113 I REV. 1

APPENDIX E : GUIDELINES FOR INITIATING CAUSE FREQUENCY

The table below represents typical quantitative estimate of the frequency of the initiating
event using site-specific failure data or data from industry sources that can be used in
LOPA technique.

Guidelines for lnitiatinq Event Frequency

Frequency of Failure
Initiating Cause (IC)
(Events per Year)
BPCS instrument loop failure
Note: IEC 61 51 1 limits the frequency o f BPCS failure t o 10 - I
n o less than 8.76 x 10-*/yr(IEC, 2 0 0 1 )
Regulator failure 10 - I

Fixed Equipment Failure (E.g. exchanger tube failure) 1o - ~

Pumps and other Rotating Equipment


Cooling Water Failure(redundant C W pumps, diverse
10.'
drivers)
Loss of Power (redundant power supplies) 10 - I

Human Error - (Routine Task, Once-per-Day Opportunity) 1o0


Human Error - (Routine Task, Once-per-Month
10.'
Opportunity)
Human Error - (Non-Routine Task, Low Stress) 10 - I

Human Error - (Non-Routine Task, High Stress) 1o0

Pressure Vessel Failure 1o - ~

Piping Failure - (100 meter section - Full Breach ) 1o - ~

Piping Leak - 1 0 0 m

Atmospheric Tank Failure 10"

Gasket / Packing Blowout 1o - ~

Turbine / Diesel Engine Over speed w i t h Casing Breach 1o - ~


Frequency of Failure
Initiating Cause (IC)
(Events per Year)
Third party Intervention (external impact by backhoe,
vehicle, etc.)
Safety Valve Opens Spuriously

Pump Seal Failure

Unloading / Loading Hose Failure

Small External Fire (all causes)

Large External Fire (all causes)


LOT0 (Lock-Out Tag-Out) Procedure Failure - (overall
per opportunity
failure o f a multiple-element process)
Operator Failure (to execute routine procedure, assuming
lo-* per opportunity
well trained, unstressed, not fatigued)
Develop using experience
Other Initiating Events
of personnel
DOC. NO. KOC-1-017 I Page 77 of 113 I REV. 1

APPENDIX F : EXAMPLE OF SIL SELECTION WORKSHEETS


-
LOPA WORKSHEET
PROJECT TITLE:

SIF ID 1 ITEM No.: Sheet No.:

Ref: Drawing No.:

Impact Event:
SIF Process Variable
Worst Consequence:

Consequence rating
and Tolerable 'goal =

frequency goal:

Independent Independent Independent Independent Mitigated


Cause(s1 of
Impact event
(Initiators)
Frequency
of each
cause (Iyr)
Protection
Layer #I and
' Protection
Layer #2and
Protection
Layer #3 and
Protection
Layer #4and
Event
Frequenc
PFD PFD PFD PFD Y (lyr)

(F,,a,,itigafed 1

1 SIL CALCULATION :
Fgoar
PFDsrF =
Ftotal mitigated frequency

I Notes: 1

Recommendations:

Signature: Date:
APPENDIX G : SAMPLE SAFETY REQUIREMENTS SPECIFICATION (SRS)
FOR SINGLE SIF

ITEM # I :

SIF ID: SIF-91 F702-1 Service:


TAG #: FIT-0096 Heater 9 1 F702 Low feed flow t o
I
I

Required SIL: I 1 heater passes.


I Demand rste o n SIF 1 Low demand I Low pass flow, potential for tube
rupture leading t o fire in the box and II
I Test Interval: I 1 year I complete shutdown of the unit. Could

I Response Time:
Method:
I
Refer t o General Reql~irements
cause major damage t o furnace and
loss of FCCU oroduction.

Reset Type: Refer t o General Requirements Safe State:


Nuisance Trip Req's: Closing of a fuel gas supply valve.
Special Diagnostics:
I Transmitter - Comparison diag i n
PLC I
Manual Shutdown: Existing
Regulatory Req's: Refer t o General

Cause-and-Effect Diaqram :

9147'02-1 Heater F7OIZ lcnnr pass flw FIT- ?? X X A


Conceptual Desiqn and Architecture for Safety Function

Safety PLC

s as per MTTFS
AS requirements
2002 Sensor
Voting

SDV1 SDV2
1002 main valve voting

NOTES:

In addition t o the above, all the elements of Clause 9.3 shall be suitably included here
APPENDIX H : TYPICAL ARCHITECTURES TO SATISFY SIL REQUIREMENTS

SIL 1

Switch or -
transmitter

Sensor Single switch or transmitter


Logic Solver : Relay or Conventional PLC
Final Element: Single Solenoid ancl valve

SIL 2

Safety
Transmitter

Logic Solver
(Safety PLC) -

1001
VOTING Smart
Positioner

Sensor Single safety transmitter


SDV
I
Logic Solver : Safety PLC certified
Final Element: Single valve with partial stroke testing via smart positioner
Transmitters

Positioner Positioner

VOTING

SDVl SDV2

Sensor 3 safety transmitters (2003 voting)


Logic Solver : Safety PLC
Final Element: Dual valves (1002 voting) with partial stroke testing via digital
valve controller

Notes:

1. For all three SIL values, the final design has t o be verified via SIL verification
calculations.

2. It shall be noted that architectures alone can not ensure meeting all the requirements
of IEC6151 1. Other design requirements like Hardware Fault Tolerance, Diversity,
Proof Test Frequency, IEC6 1508 / 6 1 5 1 1 certification, Proven-In-Use, etc. also
determine whether a particular architecture meets a particular Target SIL. The
architectures shown i n this Appendix are for information purpose only and shall not
be taken as sufficient t o meet any particular SIL.
APPENDIX I : CHECKLISTS

The following checklists are provided t o assist i n the verification of the relevant phases
of the safety lifecycle:

Checklist 1 : Hazard & Risk Analysis


Checklist 2: Safety requirements specifications
Checklist 3: Equipment specification and design
Checklist 4: FAT
Checklist 5: Installation
Checklist 6: Validation
Checklist 7: Operations
Checklist 8: Maintenance and modification
I DOC. NO. KOC-1-017 I Page 85 of 113 I REV. 1

Checklist No. 2: Safety requirements specification

Comments

(i) Are the SIF de-energize t o trip? C30C1


(ii) Are the SIF energize t o trip? 000
(iii)If energize t o trip, have provisions been nun
made t o ensure integrity of the power at
the required integrity?
(iv) If energize to trip, have provisions been
made t o allow safe shutdown i n the
absence of power?
(i)Are any other utilities required for the SIF
operation?
(ii)Have these utilities been evaluated t o
determine whether they provide the required
performance?
Have the extremes of all environmental
conditions been identified?
Have any special requirements been set based
on survivability of major event?
(i) Has any special SIS logic solver features,
such as sequencing, speed, and accuracy?
(ii) Is it consistent w i t h the defined inputs and
OU~DU~S?
Have the requirements for the operator i n
maintaining safety been defined?

For example:
(i) manual initiation of SIF?
(ii) manual shutdown on SIF fault or faults
during various operational states of the SIF?
(iii)use of overrides/inhibits/bypasses?
(iv) resetting the SIF after shutdown?
(v) starting u p the plant?
In the event of BPCS failure, is sufficient
information given t o the operator t o allow
manual shutdown, if required?
Have the provisions been specified for
maintaining safe operation during maintenance
and modification of:
(i) the SIS?
(ii)the process?
Checklist No. 2: Safety requirements specification

Item Item Y N NA Comments

2.23 Does the specification avoid the need for the


SlFs t o be bypassed under certain conditions?

have adequate grounds for bypassing the SlFs flnm


been established?
have facilities been specified to contrc~l
bypasses, t o ensure that the bypassed state is
clearly indicated, and t o ensure the removal of rim
bypasses after maintenance?
have procedures for the safe use of bypasses
been developed covering the actions t o be
taken before, during and after their application? lloa
2.24 Have provisions been specified for the function ring
testing of SIF devices with a minimumi of
physical bypasses, such as jumpers?

For example, have provisions been specified


which avoid the need for disconnections at
terminals or other undesirable means for:
the injection of test signals? 000
the monitoring of the result of a test? 000
2.25 Do the SlFs as described meet the following:

fault tolerance requirements? 000


functional requirements? 000
integrity requirements? on0
maximum spurious trip rate? 000
Checklist No. 3: Equipment specification and design

Item Item Y N NA Comments

Hardware
3.1 Is there an engineering process for conducting
a design review aimed at:

(i) ensuring that all the requirements of the


SRS are met?
(ii) eliminating errors in design?
(iii) ensuring that the performance
requirements, such as integrity and
spurious trip rate, are met?
(iv) ensuring that the devices are selected
according t o IEC 61 508 and/or proven-in- mna
(v) ensuring that aspects relevant t o
construction, installation, operation,
maintenance and modification are
considered?
(vi) ensuring that assumptions made in the
hazards & risk analysis remain true?
For example:
Independence of BPCS and SIS? 000
lndependence of initiating cause and SIS? mr1-Il
lndependence of SIS and other protection mnn
layers?
3.2 Does the engineering process incorporate CIOO
procedures for the consideration of new
information or management of changes t o the
requirements as the design proceeds?
3.3 Is there an effective system for ensuring Can
coordination between different parties
involved in the project (e.g. ownerloperator,
design contractors, field construction
company, and manufacturers)?
3.4 Is there liaison between the designers and the
operational administration in order t o ensure
that:

(i) the principles of operation, maintenance Clou


and test assumed in the design are correct?
(ii)adequate facilities are provided for
operational requirements?
IIlo
Checklist No. 3: Equipment specification and design

Item Item Y N NA Comments


No.
3.5 Has a philosophy been adopted in the design 8flrl
of the SIS hardware so that a large proportion
of failures tend t o put the plant into a safe
state?
000
(i) loss of power supply? Imn
(ii) cabling faults (open or short circuit or 000
earth faults)? 000
(iii)loss of instrument air?
(iv) loss of hydraulic supply?
3.6 Have measures been taken t o detect those 000
failures that do not automatically result i n a
safe state?

For example, has a dynamic rather than a


static mode of operation been adopted so that
failures resulting i n a stuck SIS outpul: state
can be detected, e.g., by watchdog timer?
3.7 Has the physical operating environment of the
SIS been defined and has the hardware
properly specified w i t h regard to:

(i) temperature range? ooo


(ii) humidity? CEIn
(iii) vibration and shock? 0 ~ 0
(iv) ingress of water and dust? Cnn
(v) contaminating gases? CKIo
(vi) hazardous atmospheres? CKlo
(vii) power supply voltage tolerance? on0
(viii) ionizing radiations? 000
3.8 Have adequate precautions been specified t o
protect against electrical interference in the
environment of the SIS w i t h regard to:

(i) inherent design of the SIS? ~ 0 0


(ii)installation practices (e.g. separation of CEIn
power and signal cables?
(iii)Are all inputs and outputs protected from
damage f r o m voltage spikes that m a y be 000
induced on input cables?
(iv) EMC test program, including conducted
interference o n power supplies, electro- 000
static discharges and radiated
interference?
(v) Are all outputs that s w i t c h inductive loads 0n8
protected from damage from switching
spikes?
(i) Are there specifications and procedures
for the quality of materials, workmanship
and inspection?
(ii) Are they appropriate t o the expected
operating conditions?
(iii) Is there supervision t o ensure the

during manufacture?
(iv) Does the manufacturer perform
management of change reviews t o
determine whether manufacturing changes

of hardware, have they been used?


(ii) If a proven design is used, has it been
critically examined for suitability t o the
n e w environment?

features that are fully specified by the


manufacturer?

and final elements and the logic solver been


Checklist No. 3: Equipment specification and design

Item Item Y N NA Comments

3.49 (i) Has a means been defined of testing the


program prior to installation and
commissioning?
(ii)Is the test method designed to simulate
process conditions as well as normal
conditions, thereby finding faults as well as
proving correct operation?
Checklist No. 4: Factory Acceptance Test (FAT)

Item Item Y N NA Comments

4.1 Factory acceptance test should be specified


during SIS design phase.
4.2 FAT planning should include type of tests t o Ron
be performed, including black-box tests,
performance tests, environmental tests,
interface testing, fault and degraded mode
tests; applicability and verification of system
operations and maintenance procedures;
description of each test, including its passlfail
criteria, and responsible test development and
witness individuallorganization; dependence on
other systems; test environment and tools;
logic solver configuration; test personnel
competences; and physical location.
4.3 Version of the logic solver hardware and
software should be well defined and not
changed during FAT.
4.4 FAT should be developed in accordance with r i m
its planning, t o verify proper logic
performance.
4.5 Each performed test should record the test 000
planning version under use, safety
instrumented function under test, detailed test
procedures and descriptions, chronology of
test activities, and tools, equipment and
interfaces used.
4.6 FAT documentation should include test cases 1
700
and results. Whenever a test fails, failure
reasons and corrective actions implemented
should be documented. Corrective actions
should be subjected t o a detailed impact
analysis t o determine the extend of impact
over the safety function and the extend of re-
testing required.
Checklist No. 5: Installation

Item Item Y N NA Comments


No.
5.1 (i)Are there specifications and procedures for e78i-l
quality of materials, workmanship, inspection
and testing?
(ii) Are they appropriate t o the expected no0
operating conditions?
(iii)Is there supervision t o ensure the correct an0
application of the specifications and procedures
during installation?
5.2 Have personnel been trained on the procedures 8nil
t o the level appropriate for the task that they
are assigned to?
5.3 Are the people carrying out the installation ~ 0 0
aware of the meaning and importance of CCF?
5.4 Are installation procedures designed, managed [70r1
and supervised t o minimize the introduction of
CCF?
5.5 Is there sufficient independence between those m1li-l
carrying out the work and those inspecting it?
5.6 Are the SIS installation activities included in the
overall plant construction program i n such a
way that:

(i)there is no interference by other construction nrln


activities? or 000
(ii)is SIS protected against them?
5.7 (i)Are the standards that have been specified
for the operational phase adequate for the
installation phase when the environment may
be relatively severe?
(ii)If not, have adequate precautions been OOcI
taken, e.g. storage areas for use during
installation?
5.8 (i)Is the SIS inspected i n order t o reveal 000
damage cause by installation activities?
(ii) Is the inspection program coordinated with film
construction activities t o ensure that completed
and inspected work is not violated by
subsequent activities? 000
(iii)Are the necessary records maintained?
5.9 Are installation and inspection procedures 000
sufficiently explicit in their detail so that they
do not leave important decisions or
interpretations t o be made by installation
personnel?
Checklist No. 5: Installation

Item Item Y N NA Comments


No.
5.10 Are items as junction boxes, equipment and
cables protected from the following:
(i)steam leaks? 000
(ii)water leaks? 000
(iii) oil leaks? 000
(iv) heat sources? 000
(v) mechanical damage? Crln
(vi) corrosive vapors? 000
(vii) flammable atmospheres? 000
5.1 1 Have possible external causes of CCF been 000
identified (e.g., fire, flood, vehicle impact, etc)
and is the degree of segregation between each
part of the redundancy systems adequate?
5.1 2 Are protection, segregation or other special 000
requirements of the design strictly observed?
5.1 3 Are all SlSs and associated cables identified i n ilng
such a way as t o minimize inadvertent
interference?
5.1 4 Is there sufficient independence in the 000
installation of equipment (e.g. separate process
connections)?
5.1 5 Is the SIS functionally separate from the basic
process control systems so that there is a l o w
probability of an external influence causing
failure of both?
5.1 6 Is the installation consistent w i t h the SRS? 000
Checklist No. 6: Validation

Item Item Y N NA Comments

Part A SIF Validation

6.1 (i)Are there specifications and procedures for


the validation of each SIF?
(ii) Are they appropriate t o the expected
operating conditions?
(iii) Is there supervision t o ensure the
application of specifications and procedures
during validation test?
6.2 (i) Are there procedures for the function testing llfla
of SIF devices as defined in the safety
requirements specification?
(ii)Are they sufficiently explicit in their detail
not t o leave important aspects t o decisions or
interpretations by the persons involved?
(iii)Is the calibration or performance of test
equipment verified before and after proof

(iv) Are test records maintained?


(v) DO the tests cover as much of the SIS as is sflrl
necessary as assumed in the safety
requirements specification?
(vi) When it is necessary for testing, have nou
means for communication between persons at
different locations been well planned t o reduce
communication mistakes?
(vii) If on-line proof testing is t o be carried out,
do the procedures ensure that this can be done
safely?
6.3 Has training been given appropriate t o the 000
tasks being carried out, and the personnel
involved?
6.4 If part of a redundant subsystem fails under
test:
000
(i)is the cause of failure established? ~ 0 0
(ii) are similar items inspected for a similar
potential cause of failure?
Part B Application Software Validation

6.5 Are there standards and procedures for C]ml


software testing?
6.6 Is there supervision t o ensure the application of e]0[3
standards and procedures?
6.7 Is there a procedure for generating and
maintaining adequate documentation for:
(i)the tests carried out? C]ou
(ii)the results of tests? cEl0
Checklist No. 6: Validation

Item Item Y N NA Comments

6.8 Is there a procedure for documenting and


correcting any deficiencies in the specification,

6.9 Are departures from or enhancements to the


SRS documented?
6.10 Are any SRS modifications reviewed through
management of change?
6.1 1 Is application software testing reviewed b y
those responsible for the specification, design
and programming of the application software?
6.1 2 (i) Is the final test documentation checked t o
ensure that all SRS requirements have been
tested and are met?
(ii)Is the checking carried out by persons other
than those involved in the design,
programming, or testing of the application
software? -
6.1 3 Is the software tested in the final use
environment (i.e. the target processor and the
mm
actual peripherals, memory, etc) rather than in
an emulator?
6.1 4 Is each software module tested individually as rlma
fully as possible before incorporation into the
full program?
6.1 5 (i)Are there specified criteria for the coverage flou
of tests (for example, is each control flow path
through the program tested t o ensure that
each statement is executed at least once)? 000
(ii)If not, is the coverage of the tests known?
(iii) Are test results analyzed t o reveal any
areas of the software that show an ~ClO
unexpectedly high rate of failures in test?
(iv) If so, are the reasons for the high rate of
failure established?
6.16 Have arithmetic functions been tested with the e]mn
sets of input values that give the maxirnum
and minimum computed results to ensure that
no overflow conditions are reached?
6.1 7 If any of the tests have revealed discrepancies I
11 11 I
between the documented and the actual
performance have these been resolved with the
manufacturer?
Checklist No. 8: Maintenance and Modification

Part A : Hardware maintenance and modification

Item Item Y N NA Comments


No.
8.1 Have maintenance procedures been drawn up 000
t o ensure the safety of the plant during
maintenance?
8.2 Are maintenance procedures sufficiently 000
explicit in their detail so that they do not leave
interpretations or important decisions t o be
made by maintenance personnel?
8.3 Is there supervision t o ensure the continued 000
adherence t o agreed procedures?
8.4 Are those involved i n maintenance and 000
modification activities aware of the meaning
and importance of CCF?
8.5 Has training been given appropriate t o the 000
tasks being carried out, and the personnel
involved?
8.6 Is there an administrative procedure t o ensure 000
that the maintenance procedures remain
adequate throughout the life of the SIS?

For example:
(i)Are maintenance procedures reviewed? cno
(ii)Are the training needs of maintenance 000
personnel reviewed?
8.7 Are maintenance procedures designed, 000
managed and supervised t o minimize the
introduction of CCF? For example, is the
testing staggered so that all devices i n a
redundant subsystem are tested at different
times?
8.8 Are maintenance, modification and test
activities on the SIS: ~ 0 0
(i)limited t o authorized persons following 000
agreed procedures?
(ii)reviewed as satisfactory o n completion?
8.9 On detection of a failure, is repair carried out in flm
a time consistent w i t h that assumed in any
safety requirements specification?
8.10 Is there a procedure, which strictly controls the flOn
conditions under which alarms, trips and
control functions may be bypassed?
8.1 1 (i)is the final action of any maintenance or test rinrl
procedure t o ensure that the SIF is returned t o
its normal operating state? 000
(ii)Is the above verified b y independent
inspection?
Checklist No. 8: Maintenance and Modification

8.1 2 If damage or degradation is found in one device mnrl


in a redundant configuration, do the procedures
require that the other devices be inspected for
similar faults?
8.1 3 Is there a management of change procedure
that considers the adequacy of the SIS when
changes are made to the process or its
associated protection layers that might impact

8.1 4 Is hardware configuration under management


of change control?
8.1 5 Are there procedures for addressing failures of mn[31
SIF devices?

Do these procedures recommend analysis of


the failure?
Do these procedures recommend the
incorporation of lessons learned into the SIS

Part B Software maintenance and modifications

8.1 6 Is access t o the SIS software limited t o Kt0


authorized and competent people?
8.1 7 Are there formal procedures for changes t o the
software which specify:

(i)level of authorization necessary for changes m r l


of various types? (e.g. a higher level of
authorization may be required for changes t o
functionality than for changes t o setpoints ) 80a
(ii)degree of assessment of the proposed
changes t o ensure that the original level of nu0
safety integrity is maintained?
(iii)people who may check and authorize ~ 0 0
changes of various levels?
(iv) people authorized t o carry out changes of 000
various levels? record all aspects of the
change?
(v) documentation which should be updated?
8.1 8 Are there adequate procedures for the control fl08
of software versions i n use and the update of
all similar SISs?
Checklist No. 8: Maintenance and Modification

8.1 9 For spares which contain software in


permanent memory (firmware), is there a
procedure t o ensure that either:

(i)the original software version is used? or


(ii)the version of software contained is totally
compatible with the original software h e .
upward compatible) and w i t h other existing SIS
hardware and software?
8.20 Can the software version in use be easily
checked?
8.21 Are the consequences of incorporating new,
enhanced versions of the embedded software
fully considered before use?
8.22 If errors are found i n the embedded software, nfla
are they reported t o and corrected by the
manufacturer, and incorporated into the PES
only after checking and testing of the correct

8.23 Is application software under management of r10a


change control and version tracking?
APPENDIX J : ROLES AND RESPONSIBILITIES MATRIX

One option for the management of functional safety is developing and using a roles and
responsibilities matrix. The attached roles and responsibilities matrix (Table - J1) is
provided for illustration purposes only. It will require modification each specific project.
In the roles and responsibilities matrix, each clause or step is divided into four activities
- planning, inputs, outputs, and verification.

The verification portion includes all the specific requirements (all the shall statements)
from the standard. Whoever has the review responsibility for the output activity will
need t o use the verification list to ensure that all the requirements of the standard have
I DOC. N o . KOC-1-017 I Page 105 o f 113 I
Table J - I : Example Roles & Responsibilities Matrix
Prod. Maint. Inst. Process 1
OTS
SIS Project Operation Engr. 1 Inst.
ISA 84.01-2004 Clause
Specialist Leader Process Process 1 Reliability Design
lnst Engr.
Engineer Engr. Engineer
Clause 6 - Define safety life cycle
phases incorporating standard
requirements including technical
activity inputs, outputs, and
verification steps required t o meet
the safety requirements
Clause 8 - Hazard and risk
assessment (Layers of Protection I I I I
Analysis, Layered Risk Analysis,
etc,) and
Clause 9 - Allocation of safety
L I R I A R
functions t o protection layers
Clause 10 - SIS safety
requirement specification. !SRS!
Clause 1 1 - SIS design and
I L I R I A I R
L R A R
engineering
Clause 1 2 - Requirements for
application software, including
L R A R
selection criteria for utility
software
Clause 1 3 - Factory acceptance
test (FAT) informative not L R A R
normative
Clause 14 - SIS installation and
L R A R
commissioning
Clause 1 5 - SIS safetv validation I .
L
I m
K
I H
I I - K
(SAT)
Clause 16 - SIS operation and
L R A R
maintenance
Clause 17 - SIS modification L R A R
Clause 18 - SIS decommissioning / L R A R
Clause 1 9 - Information and
L R A R
documentation requirements
Table J -1 (contd.1) : Example Roles & Responsibilities Matrix (continued)

Leqend:

A - Approval Decides when the activity or deliverable is complete.


L- Lead. May perform the work or just coordinate it. Has responsibility t o see that
the activity or deliverable is completed.
P- Participate. Performs a portion of the work. Participates as a member o f the
team as directed b y the "Lead"
R- Review. May provide initial examples or reviews the final material.
Blank - No involvement

1. A quality SIS requires a number of plant personnel. The SIS team coordinates the
work, gathers information t o make informed decisions, and gains consensus on the
final design. For each SIS project, there are core members that take responsibility
for design and implementation of the SIS. In addition, a number o f additional
resources may be needed. The SIS Team and the additional resources are provided
below.

2. SIS project members assigned t o every project:

Project Manager - Coordinates activities. Manages schedule and budget


SIS Specialist - Keeper of technology
Maintenance Representative - Coordinates maintenance issues.

3. Other project members assigned b y the unit installing the safety system:

Operations Representative - C:oordinates answers t o operational decisions, for


example, graphics design and location of manual shutdown pushbuttons.

Process Engineer - Coordinates answers t o process decisions, e.g., what the trip
set point values are and justification for value.

4. The additional resources, as needed, include representatives from the following


groups:

Maintenance
Operations
Process engineering
Reliability
Health, Safety & Environment
APPENDIX K : PROVEN IN USE EVALUATION CRITERIA

This appendix provides guidelines or1 h o w t o assess and justify the Proven In Use
applicability of an equipment item.

In order for an equipment item t o be considered acceptable for Safety Instrumented


System applications the equipment item shall meet all criteria listed below.

K 1. TimeInUse

In order for field experience t o apply, IEC 6 1 5 0 8 requires that the equipment item
has been in service for at least one year with unchanged specification [IEC 6 1 508-
7 B.5.41. IEC 6 1 51 1 has no Time In Use requirements. Before an equipment item
can be considered proven i n use it must meet either o f the following Time In Use
requirements:

1. The equipment item must have been shipping for one year without any
revisions or changes; or

2. The equipment item must have been shipping for t w o years without any
significant revisions or changes.

K 2. Hours In Use (Adeuuate Operatinu Experience)

For field experience t o apply IEC 6 1 5 0 8 requires that the equipment item has an
operating experience of 100,000 hours with equipment items i n 1 0 different
applications [IEC 61508-7 B.,5.4]. IEC 6 1 5 1 1 has no adequate operating
experience requirements.

In addition, IEC 6 1 5 0 8 lists techniques and measures t o avoid systematic failures


and their effectiveness [IEC 6 1 508-2 Table B.61. Field experience can be used as
a measure t o avoid systematic failures. In order t o claim l o w effectiveness 10,000
hours of operation time are required for at least one year of experience with at
least 1 0 devices in different applications (this is equivalent t o the 100,000 hours
requirement). The statistical accuracy claimed should be 9 5 % while t o safety
critical failures may have occurred. In order t o claim high effectiveness
10,000,000 hours of operation time are required for at least t w o years of
experience w i t h at least 1 0 devices in different applications. The statistical
accuracy claimed should be 99.9% and detailed documentation of all changes
(including minor) during past operation should be available.

The adequate operating experience requirement is that the equipment is that the
equipment item needs t o meet a minimum number of Hours in Use 30,000,000
hours. These 30,000,000 hours of estimated usage should be obtained from a
minimum of 1 0 different applications with stress conditions equal t o or above
average conditions of the application.

When estimating the number of hours in use the equipment item actual installation
dates shall be considered, not the shipment dates of the equipment items. In case
the actual installation dates are not available for the hours i n use estimation it shall
be assumed that the installation occurs six months after the equipment item
shipment.

In addition, if the equipment item has a wear out mechanism, it shall be assumed
that all units operate no longer than the useful life period. Furthermore it shall be
assumed that no wear out failures are reported t o the manufacturer (this is a
worst case assumption as wear. out failure will be considered as radon hardware
failures).

K 3. Operatinq Conditions

IEC 61 5 0 8 requires similar conditions of use, i.e. functionality and environment,


for an equipment item t o be considered Proven In Use. IEC 6 1 51 1 requires that
the operating profile of equipment items be considered in the Prior Use
assessment. Several points contribute t o the operating profile [IEC 6 1 5 1 1-2
11 5.31. For field devices the points t o consider are functionality (for example,
measurement, action), operating range, process properties (for example, properties
of chemicals, temperature, pressure), process connection, EMC, and
environmental conditions. For logic solvers points t o consider are version and
architecture o f hardware, version and configuration of system software,
application software, I10 configuration, response time, process demand rate, EMC,
and environmental conditions.

It should be pointed out that for field devices (for example, sensors and final
elements), IEC 6 1 5 1 1 allows the non-safety function experience t o be considered
in the safety function proven i n use argument. This is based on the assumption
that the function is usually identical in safety and non-safety loops [IEC 6 1 51 1-1
11.5.3.21. Though this may be the case for sensing devices like transmitters, it is
definitely not the case for valves. A control valve is usually a dynamic valve; it is
continuously moving t o adjust process parameters. A safety valve on the other
hand is usually a static valve; it is continuously open and will only move, i.e.
close, when there is a demand from the process. Partial valve stroke testing is
considered a good diagnostic for detecting stuck failures, however it does not
make the valve dynamic.

When it comes t o the operating conditions it is required that the stress conditions
of the considered prior use applications are equal t o or above the average
conditions of the application. This includes an assessment o f the functionality and
the application environmental limits.

K 4. Failure Rate Calculation

Based on the Hours in Use determined for the equipment item and the reported
field failures, a failure rate calculation shall be performed. This calculated field
failure rate should be lower than the failure rate predicted for the equipment item
using a Failure Modes, Effects, and Diagnostic Analysis (FMEDA). If the
calculated field failure rate for the equipment item is higher than the FMEDA
predicted failure rate it is an indication of systematic problems w i t h the equipment
item, and the equipment item cannot be considered Proven In Use.

Failure rates calculated o n the basis of field returns shall only consider hours
recorded during the warranty period of the manufacturer. It is t o be assumed that
all failures after the warranty period are not reported t o the manufacturer. In
addition, without evidence t o the contrary, it shall be assumed that only 5 0 % of
the failed units are returned during the warranty period and that 0 % are returned
after warranty. When calculating the field failure rate a singe-sided upper
confidence limit of at least 7 0 % shall be considered. The confidence limit is
based on clause 7.4.7.9 of IEC 61508-2, taking into consideration the more
conservative, and for safety applications more appropriate, approach o f calculating
the upper limit instead o f the lower limit.

K 5. Failure Data Comparison

In addition t o the failure rate calculation a Failure Modes, Effects, and Diagnostic
Analysis (FMEDA) must be performed for the equipment item. Part of the Proven
In Use assessment is the review o f the actual FMEDA. As indicated above, the
failure rate calculated from the field data must be less than the failure rate
predicted b y the FMEDA. If the field failure rate is larger than the predicted failure
rate this is an indication of serious systematic design issues and the equipment
item cannot be considered Proven In Use.

The FMEDA also allows for a detailed evaluation o f the Safe Failure Fraction. A n
additional requirement for a product t o be considered Proven In Use is that the
FMEDA results must show a Safe Failure Fraction greater than 80%, considering
the safe failure definition as presented in IEC 6 1 508-4. In case o f for example,
temperature transmitters, the Safe Failure Fraction threshold o f 8 0 % shall be
considered without including thermocouples or RTD. Furthermore the Failure
Modes, Effects, and Diagnostic Analysis must be verified through fault insertion
testing.
K 6. Safetv Manual

For an equipment item t o be considered Proven In Use the manufacturer must


produce a safety manual meeting the requirements o f IEC 61508. The safety
manual will describe h o w end-users shall install the equipment item for the Proven
in Use considerations t o be valid.

K 7. Qualitv Svstem

IEC 6 1 5 1 1 requires consideration of the manufacturer's quality, management, and


configuration management systems. Consequently the proven in use criteria
have, in addition t o specific equipment item requirements, requirements for the
quality system that the manufacturer has in place. The manufacturer must have
an I S 0 9 0 0 0 certified, or equivalent, quality system that covers all manufacturing
operations and field failure returns. The field failure return process is especially
important to determine an as accurate as possible field failure rate for the
equipment item. Therefore the field failure return procedures must require that
statistics be maintained on all field returns. When a trend is indicated b y the
statistics, the trend must be analyzed for root cause failure. The root cause
failure reports must be communicated t o those responsible for product
improvement and a corrective action system must be in place t o ensure that a
corrective action is taken.

In addition, the manufacturer must have a detailed version control system that
identifies all changes and revisions. The equipment item must be marked with
sufficient information t o allow the user t o identify each revision. The modification
procedures must meet the requirements o f IEC 6 1 508.

Finally, the quality system should meet specific development process


requirements. In order t o establish the maturity of the development process a
development process gap analysis must be performed per IEC 61508. For
equipment items that were first installed within the last t w o years, the process
must meet at least S l L l requirements. For products that were first installed more
than t w o years ago, the modification process must meet all requirements for IEC
6 1 5 0 8 SIL2.

K 8. Process Parameter Adjustment Only

The final Proven i n Use requirement follows the Architectural Constraints Concept
per IEC 6 1 5 1 1. In order t o reduce the required Minimum Hardware Fault
Tolerance IEC 6 1 51 1 requires that, apart from the Proven In Use argument and
that the target SIL should be less than SIL4, the equipment item allows
adjustment of process-related parameters only and that the adjustment of the
process-related parameters o f the device is protected.
This means that the equipment item should be assessed as being non-
programmable. Generally this excludes all products that are capable of running
function blocks or configurable calculations (most Fieldbus products). In addition,
the equipment item must have means t o protect parameter changes, i.e. the
equipment item should including a jumper and/or a password protection. One
option for the management of functional safety is developing and using a roles
and responsibilities matrix. The attached roles and responsibilities matrix (Table -
J1) is provided for illustration purposes only. It will require modification for each
specific project. In the roles and responsibilities matrix, each clause or step is
divided into four activities - planning, inputs, outputs, and verification.

The verification portion includes all the specific requirements (all the "shall
statements") from the standard. Whoever has the review responsibility for the
output activity will need t o use the verification list t o ensure that all the
requirements of the standard have been met.
ACKNOWLEDGEMENT

This Standard has been approved by the Standards Technical Committee (STC) consisting
of the following:

Mr. AlRedha Al-Haddad Standards Team Chairman


Mr. Mohammad Emam Insp. & Corr. Team (S&E) Deputy Chairman
Mr. S. Kumar Standards Team Secretary1 Member
Mr. A. Unnikrishnan Standards Team Member
Mr. Khalaf Hamada Design Team Member
Mr. N. Ramanathan Export Facilities Team Member
Mr. Ali Hassan Al-Failakawi HSE System Team Member
Mr. Daniel Pino Utilities Team Member
Mr. Abdul R. Al-Shamari Insp. & Corr. Team (N&WK) Member
Mr. Khalid Al-Ahmad Gen. Project Team Member
Mr. Abdul Aziz Akbar Project Mgmt. Team (NK) Member
Mr. Moataz Khalaf Information System Team Member

The draft of this Standard had been circulated t o the KOC User Teams for review and the
responses were received from the following:

ENGINEERING GROUP AHMADI SERVICES GROUP

Team Leader Design Team Leader Utilities

Team Leader Construction Team Leader Project Design

MAJOR PROJECTS GROUP (11) TECHNICAL SERVICES DIRECTORATE

Team Leader Project Support Team Leader HSE (TS)

OPERATIONS GROUP (WK) OPERATIONS GROUP lEKl

Team Leader Opns. Tech. Svcs. Team Leader Opns. Tech. Svcs.
I
HSE GROUP GAS MGMT. GROUP

Team Leader Safety Team Leader Gas Svcs.

Team Leader H&E Team Leader Consumer Networks

SECURITY & FIRE GROUP DRILLING OPNS GROUP

Team Leader Fire Team Leader Drlg. & WIO Svcs.


SOUTH & EAST DIRECTORATE WEST KUWAIT DIRECTORATE

Team Leader HSE (SEK) Team Leader HSE (WK)

EXPORT & MARINE OPNS. GROUP

Team Leader Export Tech. Svcs.

Task Force R e s ~ o n s i b l efor this Recommended Practice

The Standards Technical Committee (STC) has entrusted the preparation of this
Recommended Practice t o the Task Force No. TF-1/07, consisting of the following

Mr. Khalaf Hamada Design Team : Task Force Leader Tel. 61 8 3 3


Mr. D. Senthil Kumar Design Team : Author / Member Tel. 61 671
Mr. V.S. Kumar Opns. Tech. Svcs.-WK : Member
Mr. Barun Baruah Safety Team : Member
Mr. Ashok D. Thakare Opns. Tech. Svcs (SK) : Member Tel. 22173
Mr. Mansour Al-Qabandi Opns. Tech. Svcs (NK) : Member Tel. 23328
Mr. S. Chandra Sekhar Opns. Tech. Svcs (EK) : Member Tel. 22122
Mr. Adnan Dashti Prodn. Opns. (SK) : Member Tel. 2221 9
Mr. Ali Qasem Hussain Maintenance (EK) : Member Tel. 67565
Mr. Myad Hassan Lead Inst. Engr. (AMEC) : Member Tel. 61 0 2 3