High Integrity Protection Systems Recommended Practice

REPORT
443
FEBRUARY
2015
High Integrity Protection Systems

Recommended Practice
plan
protect
Disclaimer
Whilst every effort has been made to ensure the accuracy of the information
contained in this publication, neither IOGP nor any of its Members past, present or
future warrants its accuracy or will, regardless of its or their negligence, assume
liability for any foreseeable or unforeseeable use made thereof, which liability is
hereby excluded. Consequently, such use is at the recipients own risk on the basis
that any use by the recipient constitutes agreement to the terms of this disclaimer.
The recipient is obliged to inform any subsequent recipient of such terms.
Copyright notice
The contents of these pages are International Association of Oil & Gas Producers.
Permission is given to reproduce this report in whole or in part provided (i) that
the copyright of IOGP and (ii) the sources are acknowledged. All other rights are
reserved. Any other use requires the prior written permission of IOGP.
These Terms and Conditions shall be governed by and construed in accordance
with the laws of England and Wales. Disputes arising here from shall be exclusively
subject to the jurisdiction of the courts of England and Wales.
REPORT
443
FEBRUARY
2015

Recommended Practice
Revision history
VERSION
DATE
AMENDMENTS
1.0
February 2015
First release
High Integrity Protection Systems RP
Acknowledgements
Standards Committee
Instrumentation & Automation Subcommittee
High Integrity Protection Systems Task Force
IOGP Instrumentation and Automation Subcommittee (IASSC) HIPS Task
Force having representation from the following companies:
BG Group
BP
Maersk Oil
Petrobras
Repsol
Siemens
Statoil
Total
Yokogawa.
Photography used with permission courtesy of ndoeljindoel/
iStockphoto and Nostal6ie/iStockphoto (Front cover) and
Sharif El-Hamalawi/iStockphoto (Back cover).
Contents
Foreword 6
1 Scope
2 References
3 Terms and definitions
Abbreviations 11
4 General recommendations
12
4.1 Safety Requirements Specification
12
4.1.1 Service conditions
13
4.1.2 HIPS reliability criteria
14
4.1.3 Reliability data
15
4.1.4 HIPS reaction and response time
15
4.2 Avoidance of common-mode failures
18
4.2.1 Sensor positioning
18
4.2.2 Sensor and final element selection
18
4.2.3 Logic solver selection
18
4.2.4 Maintenance and human intervention
19
4.2.5 Utility failure
19
4.3 Hardware considerations
20
4.3.1 Electrical connections
20
4.3.2 Heat tracing and winterization
20
4.3.3 Materials of construction
21
4.3.4 Protection enclosures
21
4.3.5 Cabinet
21
5 HIPS elements
22
5.1 Sensor(s)
22
5.1.1 Sensor selection
22
5.1.2 Sensor configuration and positioning
22
5.2 HIPS automation system
23
5.2.1 Interfaces and cyber security (Programmable Logic Solvers)
24
5.2.2 Interfaces and cyber security (solid state logic solvers)
25
5.3 Final element(s)
26
5.3.1 Valves
26
5.3.2 Circuit breakers
27
6 Design testing
29
6.1 Design Validation/Typical Test (DVT)
29
6.2 Factory Acceptance Tests (FAT)
29
6.3 Integrated Factory Acceptance Test (IFAT)
30
6.4 Yard and On-Site Tests/Pre-Commissioning Tests
30
6.5 Operational Testing (OT)/Site Acceptance Test (SAT)
31
6.6 Test administration
32
6.6.1 Preparation
32
6.6.2 Procedures
32
6.6.3 Recording
32
7 Operational testing
33
7.1 Design for test and maintenance
33
7.2 Operational proof testing
34
7.3 Valves
34
8 Safety life cycle for HIPS
35
8.1 Obsolescence management
35
8.2 Maintainability
35
8.3 Spare parts
35
9 HIPS dossier
37
Foreword
High integrity protection systems (HIPS) and especially high integrity
pressure protection systems (HIPPS) are an increasingly common feature
of oil and gas facilities worldwide.
They can provide an alternative to conventional mechanical protective
devices (e.g. relief valves) or reduce the load upon them.
In some cases, they present the only practical option to facilitate field
development and/or expansion.
The application of HIPS, and the manner in which they are implemented
across IOGP Members was considered worthy of investigation by the IOGP
Instrumentation and Automation Standards Subcommittee, with a view to
providing commonly agreed upon guidance on the subject.
This Recommended Practice is the result of that process.
The intended audience for this RP is those involved in the definition,
design, implementation or operation and maintenance of HIPS.
This RP does not provide guidance upon when, if and why a HIPS
should be utilized to this end, companies should apply their own
internal methodologies.
This RP provides mainly technical recommendations.
1 Scope
The objectives of this IOGP Recommended Practice are to:
provide industry guidance in the provision, operation and
maintenance of HIPS throughout the IEC 61508 Safety Life cycle
focus upon the instrumentation aspects of that provision
support, clarify where appropriate, and not contradict or repeat
IEC61511 and/or ISO 10418 as they apply to HIPS
make it easier for vendors to deliver consistent systems across
the industry.
This IOGP Recommended Practice is intended for global application. The
following oil and gas production facility types are included:
onshore
offshore (not including subsea1)
oil and gas transmission and transport systems.
This RP is applicable to all manner of high integrity protection systems,
be they pressure, temperature, level flow or any other parameter driven.
This RP is concerned with the instrumentation elements of HIPS. The
assumption is made that the dynamic requirements associated with
many HIPS have been satisfied in each case via a separate design and
verification exercise.
This RP is applicable to the Electrical, Electronic, Programmable
Electronic HIPS related Systems.
Other HIPS based on Mechanical Technology (e.g. using direct hydraulic or
pneumatic pilot valves) are not directly covered by this RP. However, much
of the guidance within this RP may also assist in their definition and use.
API RP 17O covers subsea HIPS
10
2 References
The following documents, in whole or in part, are referenced in this
document and are recommended for its application.
API RP 14C, Analysis, Design, Installation, and Testing of Basic Surface
Safety Systems for Offshore Production Platforms
API RP 17O, Recommended Practice for Subsea High Integrity Pressure
Protection System (HIPPS)
API Standard 521, Pressure-relieving and Depressuring Systems
API Standard 598, Valve Inspection and Testing
EN 10204, Metallic products. Types of inspection documents
IEC 61508, Functional Safety of Electrical/Electronic/Programmable
Electronic Safety-related Systems (E/E/PE, or E/E/PES)
IEC 61511, Functional Safety Safety instrumented systems for the process
industry sector
IEC 62442-3-3, Industrial communication networks Network and system
security Part 3 3: System security requirements and security levels
IEC 62443, Network and system security for industrial-process measurement
and control
IEC 62443-2-4, Security for industrial automation and control systems
Network and system security Part 2-4: Requirements for IACS solution
suppliers
ISO 5208, Industrial valves Pressure testing of metallic valves
ISO 10418, Petroleum and natural gas industries Offshore production
installations Analysis, design, installation and testing of basic surface
process safety systems
ISO 23251, Petroleum, petrochemical and natural gas industries Pressurerelieving and depressuring systems
ISO/TR 12489, Petroleum, petrochemical and natural gas industries
Reliability modelling and calculation of safety systems
11
3 Terms and definitions

For the purpose of this document the following definitions apply.
bypass
Bypass (including overriding and inhibiting) input/output: action or facility
to prevent all or parts of the SIS functionality from being executed (refer
to IEC 61511).
common-mode failure (CMF)
According to UKAEA SRD R 196 (1981): A common-mode failure (CMF)
is the result of an event(s) which because of dependencies, causes a
coincidence of failure states of components in two or more separate
channels of a redundancy system, leading to the defined system failing to
perform its intended function.
For the purpose of this document, CMF is taken to include common cause
and dependent failures.
HIPS
Within the oil and gas industry, there are various company-specific
definitions as to what constitutes a HIPS. It is not the purpose of this RP
to define what constitutes a HIPS.
According to the ISO/TR 12489 definition, a non-conventional2 autonomous
safety instrumented system with sufficiently high safety integrity to protect
equipment against exceeding the design parameters is considered a HIPS.
One or more of the following may also be considered a HIPS:
a final protection layer comprising a combination of partial
mechanical and instrumented protective function
an instrumented protection layer having an integrity requirement of
SIL 3 or more
an instrumented protection layer where the consequence of nonoperation is major to catastrophic or disastrous.
Deviations from industry standards describing mechanical protection systems (e.g.

ISO 23251 = API Standard 521, ISO 10418, API RP 14C) are treated as HIPS. An ultimate
protection relying principally, but not necessary solely, on Safety Instrumented Systems
(SIS) is qualified as HIPS, irrespective of its required Safety Integrity Level (SIL).
2
12
HIPPS
ISO/TR 12489 also defines HIPPS or OPPS as, a HIPS exclusively devoted
to protection against overpressure.
HIPS reaction time
The maximum allowable time in which the HIPS should prevent a
hazardous operational condition. It is thus the time between the process
threshold value occurring and the occurrence of the hazardous event.
HIPS response time
The time between the process threshold value occurring until the final
element has reached its safe state.
13
Abbreviations
BPCS
Basic Process Control System
BR
Base Requirement
CMF
Common-Mode Failure
DVT
Design Validation Test
FAT
Factory Acceptance Test
HIPS
HIPPS
High Integrity Pressure Protection Systems
HMI
Human Machine Interface
ICSS
Integrated Control and Safety System
IFAT
Integrated Factory Acceptance Test
IS
Intrinsically Safe
ITP
Installation and Test Plan
LOPA
Layer of Protection Analysis
MCC
Motor Control Centre
MTTR
Mean Time to Repair
OPPS
Overpressure Protection System
OT
Operational Test
PFD
Probability of Failure on Demand
RE
Requirement Enhancement
SAT
Site Acceptance Test
SIF
Safety Instrumented Function
SIL
Safety Integrity Level
SIS
Safety Instrumented System
SOE
Sequence of Events
SP
Security Program
SRS
Safety Requirements Specification
14
4 General recommendations
A HIPS is normally the last in a series of process protection layers.
The others typically comprise the process control, alarm (with manual
response) and process shutdown layers.
The HIPS function should thus be seen in the context of these other
protection layers and potential process deviations, and any changes to
such should not occur without considering the potential impact upon
the HIPS function.
For an over pressure HIPS (for instance), the following should be clearly
defined:
sources of HIPS demand, and assumptions regarding how quickly
they will cause that demand
process conditions
other protection layer set points assumed in design of the HIPS.
All HIPS should be developed and implemented in accordance with the
requirements of IEC 61508 and 61511. Competency assurance through the
design, implementation and operational phases is a key requirement.
A single HIPS Integrator should be utilized to ensure that the combination
of the sensing elements, logic solver and final elements meet the
integrity, operability and maintainability targets.
4.1
Safety Requirements Specification

HIPS functions should be defined independently of other safety systems
in a specific HIPS Safety Requirements Specification (SRS), normally
produced by the end user. This should consider the complete system
comprising sensing element(s), logic solver and final element(s). The
HIPS should be developed and implemented in a similarly complete
system manner.
In addition to the requirements of IEC 61511 part 1 (SIS SRS which
includes performance requirements relating to Functionality, Availability,
Survivability and Interdependencies), the following should feature in a
HIPS SRS.
The HIPS should execute all safety functions in automatic mode.
The HIPS should be autonomous, with dedicated sensors, logic and
final elements.
The HIPS should be a physically segregated system, interfaced
with the facility automation system for monitoring only. Any
communications with HIPS should not be able to impede or override
the safety function(s).
15
The HIPS should be designed according to fail-to-safe principles.

HIPS resetting should not be possible without a clear understanding
of the initiating cause and/or fault.
Signals between sensors, logic solver and final elements should
be hardwired.
The HIPS design should define and include allowance for test and
maintenance activities. Nonetheless, HIPS sensor, logic or final
element bypass functions should be avoided. When required, bypass
functions should be subject to a thorough assessment of the risk and
consequences for system integrity.
The required performance of the HIPS will be based on the process
and facility conditions (e.g. production rates, plant line up) known/
assumed at the time of the system design and procurement. These
should be clearly identified such that the HIPS can be readily
assessed or re-validated against changing assumptions, conditions
(i.e. design basis) etc. during the plant life cycle.
HIPS packages should be designated as high focus with respect to
quality management.
4.1.1 Service conditions

A HIPS SRS should clearly identify and describe all credible process and
ambient service conditions, such as:
process fluid compositions (all possible production scenarios)
possibility of slugging flow
fluids with plugging potential (e.g. wax, hydrates)
rate of change in process pressure, temperatures, flows
presence and worst case concentrations of H2S, CO2, solids, sand,
paraffin, etc.
high and low extreme process pressure, temperatures, flows
change of process fluid composition and properties over the facilitys
lifetime
presence and worst case concentrations of injected chemical
products
high and low extreme ambient outdoor and indoor conditions
hazardous area classification
EMC requirements.
16
The predicted or known occurrence and impact of each condition should

be clearly defined for each operational situation, e.g. shut-in, cool-down,
start-up, normal production.
This analysis will assist in defining material requirements of sensors
and final elements and the needs (if any) for heating and winterization of
HIPS components.
The HIPS should be suitable for any given situation/condition regardless
its duration (including temporary conditions such as methanol injection
or cool-down).
4.1.2 HIPS reliability criteria

HIPS components, including sensors, logic solver and final elements
should each be designed as fail-safe (i.e. failure of any component/
sensor/logic solver/power supply/motive fluids moves final elements
to the safe state).
According to IEC 61511, a HIPS integrity (SIL) assessment will be
performed and the integrity target (PFDavg or failure rate, whichever
applies according to the demand rate) included in the HIPS SRS.
HIPS components or sub-systems are then selected such that the
overall integrity (SIL) target of the HIPS Safety Instrumented Function
(SIF) is achieved.
This HIPS integrity demonstration should include a sensitivity study to
test the robustness of the HIPS integrity prediction against variances in
reliability data, the proof test period (e.g. min and max derived from an
analysis of the PFD as a function of time, as opposed to PFDavg) and
component MTTR.
The HIPS design should take into account the process availability
target, allowing for testing and maintenance activities (with or without
disturbing the process e.g. partial stroke testing requirement) and the
predicted/allowable frequency of spurious trips, and reflect these within
the HIPS SRS.
Prototype or non-proven in-use components should not be used for a HIPS.
17
4.1.3 Reliability data

The HIPS operator should approve the reliability data utilized to
demonstrate the integrity achieved by the HIPS.
Reliability data sources include, in order of preference:
1. Reliability data collected and verified on the facilities (field data)
but only where the quantity collected is sufficient to be considered
statistically significant
2. Databases/reference handbooks
Data should primarily be selected from Oil and Gas applications,
e.g. Offshore Reliability Data (OREDA3), PDS Data Handbook4, and
Stiftelsen for industriell og teknisk forskning (The Foundation for
Scientific and Industrial Research), (SINTEF5).
The data selection process should consider similar service and
environmental conditions, and maintenance regimes.
3. Failure Mode and Effect Analysis (FMEA) reports
This data needs to be suitably factored to account for potential
failures occurring due to process/operating conditions. The intended
use and stated failure modes should match the application.
4. Vendor data
The reliability data used should be adequately documented to allow
validation, including:
source of the data
assumptions underlying selection.
4.1.4 HIPS reaction and response time

The process safety time, HIPS reaction time and HIPS response time
should be defined in the HIPS SRS.
www.oreda.no
www.sintef.no/projectweb/PDS-main-page
5
www.sintef.no
3
4
18
Process Safety Time (refer IEC 61511-2)
HIPS
Reaction Time
HIPS
Response Time
Process or
BPCS failure
SIS trip
initiation
HIPS
initiation
Hazardous event
occurrence
Figure 1: Process safety, reaction and response times (showing typical

protection layers)
The HIPS response time should be determined with reference to the
process safety time and HIPS reaction time. The HIPS SRS should require:
HIPS response time < (HIPS reaction time)
(Where is less than 1, and specified with reference to the system
dynamics and practicality, design uncertainties and equipment wear
and tear)
The HIPS response time is a summation of the following:
sensor response time
logic solver response time, including input cards
final element response time, up to final safe state.
4.1.4.1 Sensor response time

The sensor response time is defined by summation of the following parts:
lag time of the process tapping, e.g. thermal inertia of a thermowell
lag time of the sensing element
processing (cycle) time of electronic instrument/transmitter
signal conditioning, e.g. dampening or filtering.
19
4.1.4.2 Logic solver response time

The logic solver response time is defined by the summation of the
following parts:
worst (longest) processing (cycle) time of any input card
processing time of the logic part and output.
In general, the processing time of the logic part and output is considered
negligible for solid state technology.
For a programmable logic solver, the response time will depend on the
processing (cycle) time of all the components.
4.1.4.3 Final element response time

The final element response time is defined by the summation of
the following:
Actuated valves case:
the response time of all control circuit components
(e.g. solenoid valves, pilot valves, and quick exhaust valves) of the
motive fluid feeding the actuator
the time required to depressurize the motive fluid before the
actuator starts to move
the inertia and mechanical slack of the moving parts in the
actuator and valve (i.e. stroking time), until the valve has reached
its safety position.
Electrical equipment case:
the response time of all control circuit components
(e.g. interposing relay, switchgear, relay and switchgear drawer)
the inertia of the machinery, until it has reached safe state
(e.g. fully stopped).
4.2
20
Avoidance of common-mode failures

In order to achieve the necessary levels of integrity, HIPS typically utilize
redundancy in the sensing and final element groups. Whilst increasing
system dependability, this also introduces the potential for common-mode
failure (CMF). The HIPS should be designed to minimize CMF between
HIPS subsystems, hardware or application software.
This should be managed with reference to IEC 61511-1:2003, 9.4 and the
following recommendations.
4.2.1 Sensor positioning

Sensors should be separated as far as reasonably practicable to reduce
the likelihood of external (environmental) and/or internal (process
e.g. wax/hydrates) factors affecting more than one simultaneously.
4.2.2 Sensor and final element selection

Within HIPS: the use of identical sensors/final elements in a voting
(e.g. two out of three/2oo3) configuration has the advantage of simplifying
procurement and maintenance activities, but will increase the potential
for CMF.
For SIL 3 (and below) HIPS, it is usually acceptable to utilize identical
sensing/final element devices, but for higher integrity service diverse
(i.e. make/model) sensing and final element devices should be deployed.
At SIL 3, the potential benefits of diverse sensing and final element
devices verses the potential detriment to system maintenance should
be considered.
Within other protection layers: if identical make and model of sensing and/
or final element is utilized for both the HIPS and other protection layers,
the potential for CMF between the HIPS and other protection layers
should be addressed.
4.2.3 Logic solver selection

A HIPS logic solver should be of programmable or Solid State type.
For SIL 3 (and below) HIPS, it is generally acceptable to employ the same
logic solver type as that used for other protection layers (not including
BPCS). However, it should be fully independent of them in every respect
(I/O, PSU, CPU where applicable, etc.).
21
For higher integrity than SIL 3, the HIPS logic solver type should differ from
those used in other protection layers
Programmable Logic Solver: development, implementation, maintenance
and modification of the HIPS application program should be by competent
individuals who have not been involved in the application development for
other protective layers.
Logic Solver Input: Where a SIF has more than one sensor, each sensor
should be routed through a different logic solver input card.
Logic Solver Output: Where a SIF has more than one final element, each
final element output should be routed through a different logic solver
output card.
4.2.4 Maintenance and human intervention

CMF should be considered in the development of HIPS maintenance
routines. Particular attention should be paid where multiple simultaneous
process isolations are required, e.g. when testing a sensor voting system.
As a minimum, procedures should be defined to cover the management
of HIPS sensor line isolations. However, car seal or interlocking of sensor
line isolations is preferred.
Regular inspections to verify correct position of HIPS sensor isolation
valves are recommended.
4.2.5 Utility failure

HIPS will often need to share utilities (e.g. instrument air drying system)
with other protection layers. Where this is the case, the shared utility
should be analysed for potential common faults and where these are
considered significant diverse utilities for HIPS and other protection
layers should be deployed.
HIPS power should be from two diverse supplies, e.g. one UPS sourced,
the other from a critical systems/emergency bus.
DC power supplies can be either floating, or have positive or negative
referenced to earth. The merits of these two approaches should be
considered. In the former, the system will be less susceptible to tripping
on earth fault, but an earth fault detection system would be required.
Consistency with other facility DC earthing arrangements should also be
considered.
4.3
22
Hardware considerations
4.3.1 Electrical connections

All HIPS field devices should be hard-wired directly into the HIPS cabinet
via individual armoured instrument cables, without intermediate junction
boxes or intermediate marshalling facilities. This also applies to cables
run from the HIPS cabinet to MCC switchgear.
An exception to the direct-cable rule is given to particular field devices
which have by design a short length of cable encapsulated into the device,
such as limit switches or heater blocks. In those cases, multiple devices
of the same type might be hooked-up to a local junction box.
Junction box and cabinet terminals should be of the spring-loaded type
for both signal and power cabling. Screw type terminals should only be
permitted inside final field devices (e.g. sensors, solenoids), earth bars,
and for the power feeders and distribution inside the HIPS system cabinet.
4.3.2 Heat tracing and winterization

In colder climates, heat tracing and/or winterization of the HIPS may
be required:
heat tracing ensures that the process fluid inside the HIPS sensor
assembly and process tapping (and standpipe if any) remain
adequately fluid, i.e. avoiding potential clogging due to fluid cool-down
winterization ensures that electronic devices remain above a certain
minimum temperature.
An assessment of the expected ambient conditions and process fluid
should be made to determine which, if any, of these is required and the
HIPS SRS should include such requirement.
The heating element for each sensor should have its own dedicated
circuit breaker.
Where heat tracing of HIPS sensor assembly, process tapping,
standpipe/bridle is required, self-regulating resistive block heaters,
self-regulating heat tracing wire under thermal insulation around
quarter-turn ball valves, process tappings, level sensor chambers (and
standpipe if any), including liquid drain lines as well as the sensors/
transmitters should be provided.
23
Temperature and feeder monitoring and alarms facilities should also be

provided and transmitted to the operator interface. The HIPS SRS should
clearly state the action to be taken upon failure of a heating element,
ranging from manual intervention to automated HIPS activation after a set
time delay.
4.3.3 Materials of construction

All outdoor HIPS equipment, including sensors, manifolds, associated
mounting accessories and protection equipment, should be suited to the
environment. Where required, protection against mechanical damage (e.g.
dropped objects) should be provided.
Process wetted parts (e.g. valves, sensors, manifolds) should be as per
applicable piping class, including material certificates (e.g. EN 10204).
4.3.4 Protection enclosures

All HIPS sensors, including the process isolation valves/manifold, should
be protected against impact and environment. Therefore, enclosures
should be considered for HIPS sensor assemblies. All connections should
be bottom-mounted with the relevant cable gland assembly.
4.3.5 Cabinet
Where a cabinet is required for part of the HIPS system (typically the
logic solver), this should be separate from other equipment cabinets and
dedicated to the HIPS function only. It should preferably be located in an
acclimatized room.
Dampening systems may be provided in case of presence of vibration or
tilt effects.
Forced ventilation should be avoided. Where required, this typically
consists of redundant air extraction on the top with redundant air inlet
filters on the bottom of the front doors.
Ingress protection requirements should be defined in the SRS and
maintained throughout the HIPS life cycle.
24
5 HIPS elements
5.1 Sensor(s)
5.1.1 Sensor selection
Sensor models specifically designed for safety service are preferred.
The failure modes of concern should be identified and failure rates
pertaining to those considered in the sensor selection process, as should
the availability or otherwise of auto-diagnostic capabilities.
Process transmitters are preferred over switches.
Interfaces with other systems (e.g. asset management systems) should
be read-only. Adjustment of HIPS sensor parameters (e.g. calibration
and configuration) should be possible only from the HIPS logic solver
cabinet or locally at the sensor, requiring either password input or dip
switch adjustment.
HART or other fieldbus communication protocols should be used for
diagnostic purposes only.
Wireless sensors are not considered suitable for HIPS application.
5.1.2 Sensor configuration and positioning

For SIL 3 systems, three sensor elements with a two out of three (2oo3)
trip logic are normally selected, each sensor being configured to go to
trip state after a detected failure occurs. This 2oo3 voting should revert
to a 1oo2 voting during a single sensor maintenance or fault detected.
The HIPS should be fitted with the necessary equipment to facilitate sensor
tests as required by the SRS, and defined within the test procedure.
Each sensor should have a dedicated process tapping.
Discrepancy HIPS sensors alarms may be configured in the HIPS,
SIS or BPCS.
HIPS sensor positioning should take into account other protection layers
(e.g. BPCS) sensor positioning.
5.2
25
HIPS automation system

The HIPS automation system consists of the complete engineered and
tested cabinet, from input terminals to output terminals, typically including:
signal converters, isolators, IS barriers and anti-surge devices
logic solver
HMI devices
engineering and maintenance workstations.
The HIPS automation system should be dedicated to HIPS safety functions
and physically segregated from other safety or control systems. Any nonessential functionality should be removed.
The HIPS automation system should include a capability to record
Sequence Of Event (SOE) data, diagnostic information and logic solver
status for post-incident data analysis.
A HIPS logic solver containing more than one HIPS SIF should be avoided.
If necessary, more than one SIF can be deployed in the same logic
solver, but only where it can be demonstrated that each of these is fully
independent of the others. That is, the failure of any HIPS SIF, and/or the
occurrence of the hazard it is designed to prevent, could not cause one or
more of the other hazards, or compromise one of the other SIFs.
In addition, each HIPS logic solver should have the capability to be
verified independently of other HIPS logic solvers dedicated to another
safety functions.
Since the final elements normally consume the majority of the PFD
budget, the HIPS logic solver should typically not consume more than
15% of the PFD budget.
Response speed of the HIPS automation system, including electrical
propagation time of the I/O channels and signal convertors, should be
assessed for each application as part of the overall process safety time.
Programmable HIPS logic solvers should have at least 60% spare CPU
load and memory capacity.
Trip thresholds (set points) should be protected/locked to prevent
adjustment through human error.
26
5.2.1 Interfaces and cyber security (Programmable

Logic Solvers)
Interfaces between HIPS and other systems should be minimized.
HIPS cyber security should conform to IEC 62443.
HIPS programmable components capabilities type should as a minimum
be SL-3 (see IEC 62442-3-3).
HIPS Asset Owner should specify the Security Program (SP) capabilities
requirements (see IEC 62443-2-4) to the HIPS Integrator in the Safety
Requirement Specification. The SP requirements are composed of the
base requirements (BRs) and requirement enhancements (REs).
For example:
For SIL 2 and below HIPS the security requirement may be made of all
the BRs and all the REs(1)
For SIL 3 and above HIPS security requirement may be made of all the
BRs, all REs(1), all REs(2), all REs(3) and all REs(4).
In particular, the following steps are recommended:
Malware prevention: Ensure malware cannot transit between HIPS
and other protection layers by restricting communications between
these layers.
Any monitoring interface between HIPS and facility automation
systems should be either hardwired or dedicated serial.
Remote access (off-facility) connections should not be permitted.
Temporary engineering machines (e.g. supplier laptops) should
not be connected to the HIPS logic solver until it has been verified
that anti-virus software is installed and fully updated and that a full
system scan has been performed showing the system to be free from
malware/infection.
The HIPS logic solver and associated workstations should be subject
to access control:
Physical by key-locked cabinets
Software by means of strong password.
27
5.2.2 Interfaces and cyber security (solid state logic solvers)

Despite the use of solid state technology, cyber threats can still pose a
direct or indirect threat to the integrity of a HIPS package.
The following design requirements should therefore be applied.
The HIPS may only be interfaced with BPCS or SIS through hardwired or ModBus links.
Remote maintenance/engineering and associated networks should
not be permitted.
The SOE function should be embedded inside the HIPS. Hard-wired
signals to BPCS/SIS input cards should be used for time-critical events.
Data storage is generally not required. Main data, alarms and trips
should be registered by via the BPCS through serial bus and/or
hard-wired links.
The Solid State Logic Solver should not be interfaced with any
support system (e.g. Plant Information, Real Time Data Base and
Instrumentation Management Systems).
The use of IT-based technology for the HIPS HMI and/or communication
links is generally not permitted. HIPS HMI should be solid state mimic
panel type.
5.3
28
Final element(s)
Final element selection should be done taking into account the particular
application, process conditions and the suitability for use in safety
applications. Final elements with a demonstrable, trusted and proven
track record in safety service should be selected over lesser alternatives.
A high and continual focus should be placed upon quality control during
the final element manufacturing and test process.
An exception alarm should be generated if a HIPS final element (e.g.
valve) is not in the required position. The necessary response to such an
alarm should be defined in the SRS.
HIPS final element assembly should be considered as a whole. This
should be taken into account in the design, the fabrication and the testing.
The relevant documentation should be managed by the same principle.
5.3.1 Valves
Where a valve is the final element, this should be considered, designed
and tested as a complete assembly including the valve body, the actuator
and the associated actuator controls.
In pressure protection, HIPPS the valve should be specified to account
for the capacity of the downstream system to absorb valve leakage when
closed. Although valves may be specified as zero, or close to zero leakage
(e.g. ISO 5208 or API Standard 598), in reality it should be assumed that
some leakage in service will always occur. As such, the downstream
process system should be able to handle a degree of leakage.
The leakage rate to be designed should be determined in conjunction with
Process design Engineers and will typically be based upon the greatest of:
100% Flow through a valve bypass (if installed) when open
that experienced following total collapse of soft seats (where fitted)
a percentage of design flow (assessed in discussion with valve
manufacturer) for metal seated valves.
29
Where a HIPS bypass is required (e.g. for pressure equalization post HIPPS
activation), this should not compromise the HIPS integrity. For example the bypass
should be locked closed or similar (e.g. interlocked) to prevent being left in the
open position. Leak tightness specification for the bypass should be equivalent to
that of the main HIPPS valves.
HIPPS re-open inhibits may also be required either to protect the valves from damage
due to opening against high differential pressure, or to prevent a rapid pressure rise
scenario should the HIPPS be re-opened onto a blocked downstream system.
As the integrity of these inhibit functions are also high, they should be part of
the HIPPS.
5.3.1.1 Fail-safe function

The valve fail-safe function should be achieved by spring return actuators. Other
solutions such as operating pressure inside the valve or double acting piston
actuators should only be considered if there are justifiable reasons not to use the
spring return option.
5.3.1.2 Actuator force and drive train

For ball valves, the actuator output torque should be at least 1.3, and preferably
2.0, the required valve torque throughout all stages of the opening and closing
strokes as determined by workshop tests which should simulate or otherwise be
representative of:
actual service in which the valve will be employed, i.e. gas service or liquid service
maximum design differential pressures across the valve
actual valve configurations i.e. seat type, stem extensions, etc.
closure within specified time (speed of closure affects torque required).
5.3.2 Circuit breakers

Circuit breakers and control relays are generally accepted as final elements
for specific applications due to extensive operating experience and their
mature technology, but such devices should be carefully selected considering
characteristics and available track record (proven for the application).
It should be ensured that any failure data provided covers the full breaker function,
both electrical and mechanical.
30
Failure rate data pertaining to the fail to disconnect mode should be

available and, where possible, safe fail fraction and hardware fault
tolerance data should be sought.
Circuit breakers and control relays should be fail-to-safe, i.e. contacts are
de-energized to open. Note in some cases (e.g. certain HV breakers)
energize to break is the only option.
Circuit breakers and control relays should be specified according to
following criteria:
coil provided with gravity dropout or dual springs
provision should be made for preventing HIPS relay contacts from
welding closed (e.g. energy limiting load resistance, contact arc
suppression) when dealing with high power and /or inductive loads at
the interface with breakers.
31
6 Design testing
Testing activities should be performed during several design and
development phases such as:
Design Validation/Typical Test (DVT)
Factory Acceptance Tests (FAT) of each HIPS component
Integrated Factory Acceptance Test (IFAT)
Yard and On-Site Tests/Pre-commissioning
Operational Testing (OT)/Site Acceptance Test (SAT)
HIPS Performance Tests.
The aim of these tests is to demonstrate that the HIPS supply and
configuration meet the HIPS SRS at each one of the above stages.
A HIPS testing plan should document which of these tests will take place,
and address the items listed in the remainder of this section.
6.1
Design Validation/Typical Test (DVT)

Design validation testing may apply to the logic solver(s) and smart valve
testing systems only. It is a validation test of the interface principles and
technologies between the HIPS logic solver and other systems including
smart valve testing systems.
The purpose is to define and test how HIPS data are transferred to other
Systems as well as the SL-3 requirement level (IEC 62442-3-3) and the
Security Program (SP) requirements BRs and (REs) (IEC 62443-2-4).
6.2
Factory Acceptance Tests (FAT)

Separate factory acceptance tests (FAT) should be conducted for all HIPS
components. All test and measurement equipment should have valid
calibration certificates and labels from a certified laboratory.
The purpose of the FAT is to ensure that the HIPS sensors assembly, the
HIPS Logic Solver and the HIPS Final elements function as per the HIPS
SRS. The FAT should also consider the interface with other systems testing.
6.3
32
Integrated Factory Acceptance Test (IFAT)

An IFAT should be performed after successful completion of the individual
components FATs. The HIPS arrangement during IFAT should reflect the
final HIPS configuration on-site. All HIPS components should be hooked-up
and connected together. Interfaces with other systems (dummy systems
during the IFAT) should be part of the IFAT.
Simulation of physical measurement for actuating some sensors
(e.g. pressure and level) should be included in the IFAT.
During the IFAT, black-out (after which the HIPS will fail safe) and
black-start (after which the HIPS will remain in the fail safe state)
tests should be performed.
6.4
Yard and On-Site Tests/Pre-Commissioning Tests

Once the HIPS components have arrived in the yard or site after IFAT,
the HIPS should be unpacked, installed and the HIPS components should
be hooked-up.
The pre-commissioning should consist a series of tests to demonstrate
that:
the integrity of HIPS components has not been affected in transport
the components are installed in the correct way, segregated from
other systems, etc.
field components are adequately protected against impact, flooding, etc.
interconnections between actuators and control panels are adequate
(length, protection, etc.)
power supply to cabinets and heat tracing are adequately installed,
segregated, etc.
heat tracing and thermal insulation are adequately applied, etc.
interfaces with other systems (e.g. BPCS) are fully operational
cabling of installed sensors and final elements is adequately
installed and functions.
6.5
33
Operational Testing (OT)/Site Acceptance Test (SAT)

Once the HIPS pre-commissioning and facility commissioning has been
completed, an OT/SAT should be performed prior to facility start-up.
The purpose of the OT/SAT is to verify and test the following:
HIPS installation and pre-commissioning successful
linking with other systems (e.g. ICSS)
safety and Interlocking logic
energizing the sensors and the final elements by the HIPS
interacting between HIPS and BPCS and other systems (if any)
integration of the HIPS mimics in the BPCS (if required)
storage of HIPS data in the relevant SOE
HIPS trip functions (sensors including combinations of voted
components)
HIPS performance test (end to end, including full closure where the
final elements are valves)
HIPS SOE recording.
The HIPS performance test should demonstrate that the achieved HIPS
response time is equal to or better than target. As far as practical, the OT/
SAT should be performed by creating real process conditions. In addition
a confirmation that valves are sealing adequately should be sought.
6.6
34
Test administration
6.6.1 Preparation
Prior to each test phase, a comprehensive Inspection & Test Plan (ITP)
should be prepared covering the following:
full set of test procedures (see below)
testing schedule, including Manufacturers internal tests
resources and equipment list
predefined test report and correction (punch) list for each test
HIPS test log (see below).
6.6.2 Procedures
Dedicated test procedures should be issued for each test phase, covering
individual HIPS components and overall HIP system as required:
sensors, including isolation valves, heating and protective enclosures
logic solvers
valve control panels, including smart valve testing systems
valve actuator
HIPS valves
electrical switchgear
end-to-end HIPS.
Test procedures should clearly indicate the test criteria (values) which
are to be met, referencing the appropriate (e.g. company) standard from
which the criteria are derived.
6.6.3 Recording
After each test, a test log should be issued. It should include the following
as a minimum:
test procedure
test results/report
correction/punch/exception lists.
35
7 Operational testing
The appropriate testing of HIPS is fundamental to ensuring that the
integrity requirements for the safety function are satisfied6. The required
proof test interval for the HIPS function should have been established via
reliability analysis.
Any proposed changes in test frequency throughout a HIPS life should
be validated via an update to such analysis (this should in any case be
covered by facility management of change procedures).
Unrealistically short test intervals (e.g. less than three months) should be
avoided. (The more frequent testing becomes, the greater the impact on
production availability for components that cannot be tested off-line.)
One potential downside of increased test frequency is increased
intervention, given that each intervention may present opportunities to
compromise the HIPS (e.g. by not returning the system to operation state
following test).
Whilst the operation of individual HIPS loop components may be tested
separately, an overall system performance test should be conducted in
line with the test interval embedded in the SRS. This test should verify
both the end to end HIPS function and its response time (sensing to
completed trip/closure).
7.1
Design for test and maintenance

HIPS should be designed to facilitate the required testing, of the complete
HIP function, with minimal operational impact. Description of required
tests (including high level procedures) should form part of the SRS.
Proof test procedures should be produced by the system designer in
conjunction with the Operator as part of the design deliverables package.
These should be completed early enough in the system design life cycle to
enable any additional testing facilities to be provided.
Similarly maintenance procedures should be developed as part of the
design package and implications for facility operation (e.g. shutdown
requirements, access requirements) should be communicated to the
Operator by the system designer to enable appropriate facilities to be
provided in the wider facility design and operational plan.
A performance standard should be provided for every HIPS, which should capture test
interval, trip setting, maximum allowed response time, underlying assumptions (e.g. on
flowrate, process conditions, plant line-up). Any proposed change in any parameter in the
performance standard should only occur with full management of change applied.
6
7.2
36
Operational proof testing

HIPS typically comprise redundant elements (e.g. 2oo3 sensors and 1oo2
solenoids). HIPS testing should be planned and procedures produced
such that the correct function of each and every redundant element is
verified at each proof test and the outcome recorded.
7.3 Valves
Where the final element is a valve a leakage test may be required, typically
carried out by means of pressure build up. Where required, this is unlikely
to be able to detect small volume leaks (such as can be found in factory
acceptance testing) and should be designed with a view to detect gross
leakage (albeit within the capacity of the downstream relief device) only.
If the ability to detect very small leaks is required, consideration may be
given to acoustic valve leak detection techniques.
Partial stroke testing can provide a benefit in terms of improved HIPS
PFD, and/or increased interval between full proof tests. The downside is
the provision of partial stroke capability increases the complexity of an
otherwise simple system. And partial stroke means partial coverage
a significant portion of the HIPS (particularly the valve stroke) remains
untested and should eventually be covered via full stroke testing.
Valve signatures can be obtained via monitoring and recording of the valve
closure characteristic. These can then be used to provide timely indication
of impending valve problems. This typically requires actuator pressure
monitoring and valve position indication (via transmitter) and may be
supplied as part of a partial test system.
37
8 Safety life cycle for HIPS

HIPS should be designed, constructed, tested, operated and maintained
according to the IEC 61511 and IEC 61508.
Integrity targeting for the overall HIPS function should be performed
according to IEC 61511 part 3 utilizing either the LOPA or quantified
analysis methodologies.
HIPS verification should be managed by the Operator and not
deferred to the system provider, ensuring adequate levels of
independence.
Table 1 takes the IEC 61511 safety life cycle and suggests the key
elements required at each of the normal HIPS development phases.
8.1
Obsolescence management
A dedicated obsolescence management plan should be established for
the HIPS. The HIPS supplier should provide an inventory list with all
lifetime statuses.
As part of the obsolescence management strategy, local (e.g. in-country)
support from the HIPS supplier or agent should be considered.
8.2 Maintainability
A maintenance management plan should be prepared for each HIPS
detailing maintenance procedures and intervals, and listing required
equipment. This should be developed by the HIPS Integrator, reviewed and
approved by the operator.
8.3
Spare parts
Commissioning and operational spares should be identified, procured and
stored commensurate firstly with the maintenance plan, and secondly
allowing for unexpected failures.
Reference should be made to each HIPS component MTTR when
determining spares quantities and storage locations.
Stored items should be subject to a preservation plan.
Safety Life cycle Phase
38
Objectives
Inputs
Outputs
Process Hazard
analysis (PHA)
Identification, description and

evaluation of hazardous events
and scenarios
PFDs, P&IDs, Layouts,

Operating philosophy, Manning
Philosophy, ESD and Blowdown
Philosophy, safety targets
HAZID and HAZOP reports
2.
Safety Integrity (SIL)

Targeting
To assign a numerical (RRF) and

Integrity (SIL) target to each SIF
HAZID and HAZOP reports and

all inputs detailed above
Integrity (SIL) Targeting Report

(detail targets for each HIPS)
3.
HIPS Specification
(User)
To specify the user requirements

pertaining to each HIPS such
that an equipment provider can
generate a specification specific
to their equipment offering
Integrity (SIL) Targeting Report
HIPS Safety Requirements

Specification
HIPS Specification
(Supplier)
To generate an equipment
specific specification that meets
the requirements of the HIPS
SRS

Specification
Functional Design Specification

(FDS) for each HIPS
Dynamic analysis
Comprises hardware (including

System Architecture) and
software requirements
1.
4.
Relevant Philosophies
Identify SIFs requiring HIPS
Verify Phase 4 with 3

5.
HIPS Design
To generate a hardware and

software HIPS design that
meets the FDS requirements
HIPS SRS and FDS
System diagrams AFC (e.g. Hook

up drawings, panel layouts)
Software algorithms (e.g. flow
charts, C&E)
Verify Phase 5 with 3
6.
HIPS Engineering
To engineer the HIPS in

compliance with the design
To verify the design against the
numerical (RRF) and integrity
target
FDS
Physical hardware
System diagrams AFC
Software code
Software algorithms
SIL Verification report

Operation and Test procedures
Verify Phase 6 with 5 (FAT)
7.
HIPS installation,
commissioning and
validation
To integrate and test the HIPS.

To validate that the HIPS meets
the SRS
To install and commission the
HIPS
8.
HIPS Operation and

Maintenance
To ensure the integrity of the

HIPS is maintained during
operation and maintenance

Specification
Fully functioning HIPS in

conformance with the SRS
HIPS FDS
Verify Phase 7 with 5 (SAT)
Test and Validation Plan
FSA Report
Commissioning and handover

Workpacks
As-built documentation

Specification
Maintenance plan
Proof testing and routine

maintenance procedures
Maintenance records
Maintenance schedule updates
Spares listing
9.
HIPS Modification
10. Decommissioning
To make corrections,
enhancements or adaptations
to the HIPS, ensuring that the
required safety integrity level is
achieved and maintained
To ensure proper planning for

decommissioning

Specification
MOC approvals
Management of Change (MOC)

Procedures (including software
change control)
Documentation (Philosophy/
SRS/FDS/drawings etc.)
updates as required to maintain
alignment with installed system
FSA Report
FSA Report update
MOC Procedures
HIPS placed out of service
To remove HIPS from service

without compromising the safety
integrity of the facility
Table 1: Key elements in the IEC 61511 safety life cycle
39
9 HIPS dossier
Whilst the HIPS performance standard (within the SRS) provides a
summary of the key elements and basis for each HIPS, it is also important
to develop and retain concise documentation covering all aspects of the
design for each HIPS, both as a record of the work done and a basis for
life cycle maintenance and update of the HIPS.
A HIPS Dossier should therefore be compiled and maintained for each
HIPS by the operator and should include as a minimum the following
elements from the safety and instrumentation perspective:
justification for HIPS selection, design and configuration
HIPS SRS Performance standards (Response time, Integrity
requirement etc.)
dynamic analysis
HIPS drawings (e.g. P&IDs, architecture, wiring, hook-ups, system
schematic, block diagrams)
hazard and consequence analysis studies/reports Assumptions
pertinent to the Hazard analysis and integrity target
quantified/reliability analysis supporting selection of PFD/SIL targets
and relevant test intervals, capturing assessment of diagnostic
coverage of failures and common cause failure analysis
pertinent cause and effect charts
HIPS maintenance, testing and repair plans/procedures and records
HIPS operating and re-start procedures (including bypass etc.)
FSA report (according to IEC 61511)
HIPS Obsolescence plan.
All HIPS should be added to the facility safety critical systems/items register.
Registered Office
Level 5
209215 Blackfriars Rd
London SE1 8NL
United Kingdom
Brussels Office
Bd du Souverain,165
4th Floor
B-1160 Brussels
Belgium
T +44 (0)20 3763 9700

F +44 (0)20 3763 9701
reception@iogp.org
T +32 (0)2 566 9150

F +32 (0)2 566 9159
High integrity protection systems

(HIPS) and especially high integrity
pressure protection systems
(HIPPS) are an increasingly
common feature of oil and gas
facilities worldwide.
They can provide an alternative to
conventional mechanical protective
devices (e.g. relief valves) or reduce
the load upon them.
In some cases, they present the
only practical option to facilitate
field development and/or expansion.
This RP provides mainly technical
recommendations for those
involved in the definition, design,
implementation or operation and
maintenance of HIPS.
www.iogp.org

High Integrity Protection Systems Recommended Practice

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

High Integrity Protection Systems Recommended Practice

Uploaded by

Copyright:

Available Formats

REPORT

High Integrity Protection Systems

High Integrity Protection Systems

High Integrity Protection Systems RP

3 Terms and definitions

4.1 Safety Requirements Specification

4.1.1 Service conditions

4.1.2 HIPS reliability criteria

4.1.3 Reliability data

4.1.4 HIPS reaction and response time

4.2 Avoidance of common-mode failures

4.2.1 Sensor positioning

4.2.2 Sensor and final element selection

4.2.3 Logic solver selection

4.2.4 Maintenance and human intervention

4.2.5 Utility failure

4.3 Hardware considerations

4.3.1 Electrical connections

4.3.2 Heat tracing and winterization

4.3.3 Materials of construction

4.3.4 Protection enclosures

5.1.1 Sensor selection

5.1.2 Sensor configuration and positioning

5.2 HIPS automation system

5.2.1 Interfaces and cyber security (Programmable Logic Solvers)

5.2.2 Interfaces and cyber security (solid state logic solvers)

5.3 Final element(s)

5.3.2 Circuit breakers

High Integrity Protection Systems RP

6.1 Design Validation/Typical Test (DVT)

6.2 Factory Acceptance Tests (FAT)

6.3 Integrated Factory Acceptance Test (IFAT)

6.4 Yard and On-Site Tests/Pre-Commissioning Tests

6.5 Operational Testing (OT)/Site Acceptance Test (SAT)

6.6 Test administration

7.1 Design for test and maintenance

7.2 Operational proof testing

8 Safety life cycle for HIPS

8.1 Obsolescence management

8.3 Spare parts

High Integrity Protection Systems RP

High Integrity Protection Systems RP

High Integrity Protection Systems RP

API RP 17O covers subsea HIPS

High Integrity Protection Systems RP

High Integrity Protection Systems RP

3 Terms and definitions

Deviations from industry standards describing mechanical protection systems (e.g.

High Integrity Protection Systems RP

High Integrity Protection Systems RP

Basic Process Control System

Design Validation Test

Factory Acceptance Test

High Integrity Protection Systems

High Integrity Pressure Protection Systems

Human Machine Interface

Integrated Control and Safety System

Integrated Factory Acceptance Test

Installation and Test Plan

Layer of Protection Analysis

Motor Control Centre

Mean Time to Repair

Overpressure Protection System