REPORT JANUARY

443 2021

High Integrity Protection Systems –

Recommended Practice
Acknowledgements
This Report was produced by the High Integrity Protection Systems
Task Force, working under the auspices of the Instrumentation and
Automation Subcommittee of IOGP’s Standards Committee.

Front cover photography used with permission courtesy of

©ndoeljindoel/iStockphoto and ©Nostal6ie/iStockphoto

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

Feedback

IOGP welcomes feedback on our reports: [email protected]

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 recipient’s 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.

This publication is made available for information purposes and solely for the private
use of the user. IOGP will not directly or indirectly endorse, approve or accredit the
content of any course, event or otherwise where this publication will be reproduced.

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 JANUARY
443 2021

High Integrity Protection Systems

– Recommended Practice

Revision history

VERSION DATE AMENDMENTS

2.0 January 2021 Sections 5.2.1 and 5.2.2 updated. References and definitions added.

1.0 February 2015 First release

High Integrity Protection Systems – Recommended Practice

Contents

Introduction 6

1. Scope 7

2. References 8

3. Terms and definitions 9

4. General recommendations 11
4.1 Safety Requirements Specification 11
4.1.1 Service Conditions 12
4.1.2 HIPS reliability criteria 12
4.1.3 Reliability data 13
4.1.4 HIPS reaction and response time 13
4.2 Avoidance of common-mode failures 15
4.2.1 Sensor polluting 15
4.2.2 Sensor and final element selection 15
4.2.3 Logic solver solution 15
4.2.4 Maintenance and human intervention 16
4.2.5 Utility failure 16
4.3 Hardware considerations 16
4.3.1 Electrical connections 16
4.3.2 Heat tracing and winterisation 16
4.3.3 Materials of construction 17
4.3.4 Protection enclosures 17
4.3.5 Cabinet 17

5. HIPS elements 18
5.1 Sensors 18
5.1.1 Sensor Selection 18
5.1.2 Sensor configuration and positioning 18
5.2 HIPS automation system 18
5.2.1 Programmable Logic Solver: software integrity and cybersecurity 19
5.2.2 Solid State Logic Solvers – interfaces and cybersecurity 22
5.3 Final elements 22
5.3.1 Valves 22
5.3.2 Circuit breakers 23

4
High Integrity Protection Systems – Recommended Practice

6. Design testing 25
6.1 Design validation/typical test (DVT) 25
6.2 Factory Acceptance Tests (FAT) 25
6.3 Integrated Factory Acceptance Test (IFAT) 25
6.4 Yard and on-site test/pre-commissioning tests 26
6.5 Operational Testing (OT)/Site Acceptance Test (SAT) 26
6.6 Test administration 27
6.6.1 Preparation 27
6.6.2 Procedures 27
6.6.3 Recording 27

7. Operational testing 28
7.1 Design for test and maintenance 28
7.2 Operational proof testing 28
7.3 Valves 29

8. Safety lifecycle for HIPS 30

8.1 Obsolescence management 30
8.2 Maintainability 30
8.3 Spare parts 30

9. HIPS dossier 32

5
High Integrity Protection Systems – Recommended Practice

Introduction

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 if, when, and why a HIPS should be utilised – companies
should apply their own internal methodologies to answer these questions. This document provides
technical recommendations on how a HIPS can be utilised.

6
High Integrity Protection Systems – Recommended Practice

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

1 For subsea installations, see API RP 170 - Recommended Practice for Subsea High Pressure Protection Systems (HIPPS)

7
High Integrity Protection Systems – Recommended Practice

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
IEC 62443-4-1, Security for industrial automation and control systems - Part 4-1: Secure
product development lifecycle requirements
IEC 62443-4-2, Security for industrial automation and control systems - Part 4-2: Technical
security requirements for IACS components
IEC TR 63069, Industrial-process measurement, control and automation - Framework for
functional safety and security
IEC TR 63074, Safety of machinery - Security aspects related to functional safety of safety-
related control systems
ISA-TR84.00.09, Cybersecurity Related to the Functional Safety Lifecycle
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 – Pressure-relieving and
depressuring systems
ISO/TR 12489, Petroleum, petrochemical and natural gas industries – Reliability modelling and
calculation of safety systems

8
High Integrity Protection Systems – Recommended Practice

3. Terms and definitions

Term Definition

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. Per ISO/TR 12489, a HIPS is “a non-conventional2 autonomous safety
instrumented system with sufficiently high safety integrity to protect equipment
against exceeding the design parameters.”

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 non-operation is
major to catastrophic or disastrous.

HIPPS ISO/TR 12489 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.

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

9
High Integrity Protection Systems – Recommended Practice

Abbreviations

BPCS Basic Process Control System

BR Base Requirement

CMF Common-Mode Failure

DCS Distributed Control System

DVT Design Validation Test

EWS Engineering Workstations

FAT Factory Acceptance Test

HIPS High Integrity Protection Systems

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

PLC Programmable Logic Controller

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

10
High Integrity Protection Systems – Recommended Practice

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

11
High Integrity Protection Systems – Recommended Practice

• 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 and/or
conditions (i.e., design basis) 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 facility’s lifetime
• presence and worst case concentrations of injected chemical products
• high and low extreme ambient outdoor and indoor conditions
• hazardous area classification
• EMC requirements

The predicted or known occurrence and impact of each condition should be clearly defined
for each operational situation, e.g., shut-in, cooldown, startup, normal production. This
analysis will assist in defining material requirements of sensors and final elements and
the needs (if any) for heating and winterisation 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.

12
High Integrity Protection Systems – Recommended Practice

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.

4.1.3 Reliability data

The HIPS operator should approve the reliability data utilised 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, such as the Offshore Reliability Data (OREDA), PDS Data Handbook,
and SINTEF (The Foundation for Scientific and Industrial Research). 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 the source of the data and the assumptions underlying data
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.

Process Safety Time (refer IEC 61511-2)

HIPS
Reaction Time

HIPS
Response Time

Process or SIS trip HIPS Hazardous event

BPCS failure initiation initiation occurrence

Figure 1: Process safety reaction and response times (showing typical protection layers)

13
High Integrity Protection Systems – Recommended Practice

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

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

14
High Integrity Protection Systems – Recommended Practice

4.2 Avoidance of common-mode failures

In order to achieve the necessary levels of integrity, HIPS typically utilise 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
minimise 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 polluting

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 utilise 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 utilised 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 solution

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

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.

15
High Integrity Protection Systems – Recommended Practice

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

In colder climates, heat tracing and/or winterisation 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
• winterisation ensures that electronic devices remain above a certain minimum
temperature.

16
High Integrity Protection Systems – Recommended Practice

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.

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

17
High Integrity Protection Systems – Recommended Practice

5. HIPS elements

5.1 Sensors

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

18
High Integrity Protection Systems – Recommended Practice

The HIPS automation system should be dedicated to HIPS safety functions and physically
segregated from other safety or control systems. Any non-essential 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.

5.2.1 Programmable Logic Solver: software integrity and cybersecurity

It is important to take cybersecurity into account in all phases in the HIPS software
development life cycle. The principal aim should be to:
• eliminate the insertion of vulnerabilities into the software code3
• build in measures to mitigate the consequences of vulnerabilities that cannot be
eliminated and could be exploited by malicious actors or through operator misuse

Implementation of specific security protections post deployment should be secondary to the

above.

HIPS cybersecurity should conform to IEC 62443. The system integrator should
demonstrate compliance with these security requirements for the components (including
PLC, network components and HMIs) by either completing an independent certification
of their development lifecycle and products against IEC 62443-4-1 and IEC 62443-4-24 or
providing records of self-certification with appropriate evidence.

3
This includes operating system, operating parameters, human-machine interface functions, communication, firmware, supporting
software tools, third party software components, the application program and other configurable items.
4
Many of the process requirements covered under the IEC 61508 certification overlaps with IEC 62443-4-1/2 requirements. A common
development process for compliance to both standards can be used to reduce duplication and effort. SL-3 and SC-3 certified logic solvers
are recommended for HIPS. The Operators should also request deployment specific measures and evidence for assurance and future
Operability. ISA-TR84.00.09, IEC TR 63074 and IEC TR 63069 are some reference standards on designing security for safety systems.

19
High Integrity Protection Systems – Recommended Practice

Security requirements to meet the above principle should be included in the HIPS
specification. Further, the HIPS Asset owner should specify the security program
requirements (refer to IEC 62443-2-4) to the HIPS integrator in the safety requirement
specification. A risk model5 specific to the full scope of the deployment should be developed
to reduce threats and eliminate vulnerabilities. Where the identified vulnerabilities cannot
be eliminated, the software should be designed for fault tolerance and have functions to
allow recovery from errors6.

The software should be designed using a modular architecture for separate functions7.
All internal interfaces between functional modules and external interfaces to the system
should be clearly defined and validated. The modules interfacing to external devices or
systems should be separated from the logic execution modules. Testing and maintenance
interfaces should be separate from the communication interfaces. Online testing,
diagnostics and maintenance modules should not impair the operation of the safety logic.

Evidence of secure coding practices should be provided by the vendor. This includes but is not
limited to:
• avoidance of design patterns and software functions with known security weaknesses
• static code analysis and run-time analysis to determine security coding errors such
as buffer overflows/underflows, null pointer dereferencing, race conditions etc
• consistent data definitions and data types
• validation of all inputs that cross trust boundary and I/O buffering
• error handling (including operator misuse and deliberate tampering)
• removal or disabling unused functional objects, preloaded variables and interfaces
• vulnerabilities including those of external libraries are categorised and tracked to closure
• software code is signed, including on future updates of firmware or other components.

Security features should be tested by an independent team. The system integrator should
provide the test results and closure actions to the Operator. Positive and negative testing
should be used, such as:
• response time, execution time and throughput tests
• boundary/edge condition, stress and malformed, unexpected input, denial of service
tests
• memory underflow and overflow tests
• tests on successful spoofing of trusted interfaces, alteration of messages, repudiation
of user actions, disclosure of information, elevation of privilege and tampering of data
tables

Guidelines on configuration and administration of the designed security features should

describe the security features, potential settings and the impact of the setting on the
defence-in-depth and the safe functioning of the HIPS.

5 Examination of threats and their ability to exploit implementation interfaces, trusted boundaries and the application
6 For example, software HAZOP or systematic examination of the software architecture and function can reveal fault avoidance and
recovery measures.
7 such that compromising a single component of the system does not lead to the entire system being compromised. The attacker will only have
the functionality and data of the single compromised component at their disposal, not the functionality and data of the entire application.

20
High Integrity Protection Systems – Recommended Practice

Patches should be maintained up to date on the application, firmware, operating system

and configuration software. Support contracts should mandate that details of any security
updates and issues in the product are reported within a specific timeframe to the Operator,
along with resolution steps and timeline. This includes software patches for all system
components.

Changes to baselined applications and device configuration should be tracked using hash
or checksums. Primary and secondary copies of the baselined items should be available
and tested to aid recovery.

The ability to make changes to the application during operations mode should be disabled,
using physical or soft key functions. The key should be tested against tampering or being
bypassed8.

Sensor controls that protect against unauthorised or remote changes such as ‘write-
protect jumpers’ should be enabled to limit misconfigurations and miscalibrations.

Interfaces between the HIPS and other protective systems should be avoided. Further
• Remote access (off-facility) connections should not be used.
• Limit configuration/engineering interfaces to serial interface port where possible.
• Devices with the ability to make changes to the logic solvers (e.g., Engineering
Workstation) should be authenticated using pre-shared keys or digital certificates.
• Dedicated HIPS Engineering workstations (EWS) should be used. EWS should not be
permanently connected or networked to the logic solver or any other networks.
• Ethernet based interfaces (e.g., Modbus-TCP) to systems that require data or updates
from the HIPS (e.g., DCS/BPCS), should be made unidirectional from the HIPS, using
a data diode or a built-in electronic isolation.
• Tags or application variables should be configured at the least privilege (hidden/read-
only/write) for both internal interfaces between application modules and external
interfaces.
• Bypasses or Overrides from the DCS or another interfaced system should not be
possible.

Physical and logical access to configuration ports, applications and workstations that can
be used to make changes to the logic-solver should be restricted and privilege control
imposed such that more than one person will be required to successfully make a change.
This may include:
• Physical access to EWS and the logic-solver cabinet is managed through permit-to-work.
• EWS uses ‘whitelisting’, authenticates each individual user and enforces strong
passwords.
• EWS administrator and engineering privileges is not held by the same person.
Similarly, physical keys to locked cabinets are held by persons with a different
authority level.
• System and user access to the configurable items, subtasks or functional modules
or routines are based on least privilege, with a default deny. (e.g., maintenance,
programmer).

8 e.g., the physical key position can be electronically bypassed by writing to a memory register.

21
High Integrity Protection Systems – Recommended Practice

• Logic-solver configuration and software is password protected. Critical functional

segments or routines should have additional passwords to aid privilege control.
• Logging of user and device events is enabled, with the ability to forward logs and is
used for alerting operator of changes.

5.2.2 Solid State Logic Solvers – interfaces and cybersecurity

The control decisions in a solid-state logic solver are carried out by a fixed arrangement
of hardwired electronic components, with any changes to the system logic requiring
modification of the wiring. Despite this, there may still be threats to the integrity of a HIPS
package via the interfaces to other systems or the features for testing and bypasses.
Hence, the following requirements should be applied.
• 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 HIPS should only be interfaced with BPCS or SIS through hardwired or serial links.
• Data storage is generally not required. Main data, alarms and trips should be
registered via the BPCS through serial or hard-wired 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.
• 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 Final elements

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

22
High Integrity Protection Systems – Recommended Practice

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.

Where a HIPS bypass is required (e.g., for pressure equalisation 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.

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.

23
High Integrity Protection Systems – Recommended Practice

Circuit breakers and control relays should be fail-to-safe, i.e., contacts are de-energised to
open. Note in some cases (e.g., certain HV breakers) energise 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.

24
High Integrity Protection Systems – Recommended Practice

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

25
High Integrity Protection Systems – Recommended Practice

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 test/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 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
• energising 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.

26
High Integrity Protection Systems – Recommended Practice

6.6 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 Manufacturer’s internal tests
• resources and equipment list
• predefined test report and correction (punch) list for each test
• HIPS test log (see 6.6.3 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

27
High Integrity Protection Systems – Recommended Practice

7. Operational testing

The appropriate testing of HIPS is fundamental to ensuring that the integrity requirements
for the safety function are satisfied9. 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.

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

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

28
High Integrity Protection Systems – Recommended Practice

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.

29
High Integrity Protection Systems – Recommended Practice

8. Safety lifecycle 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, utilising 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.

30
High Integrity Protection Systems – Recommended Practice

Table 1: Key elements in the IEC 61511 safety life cycle

Safety Lifecycle Phase Objectives Inputs Outputs

1. Process Hazard Identification, description and PFDs, P&IDs, Layouts, HAZID and HAZOP reports
analysis (PHA) evaluation of hazardous events Operating philosophy, Manning Identify SIFs requiring HIPS
and scenarios Philosophy, ESD and Blowdown
Philosophy, safety targets

2. Safety Integrity (SIL) To assign a numerical (RRF) and HAZID and HAZOP reports and Integrity (SIL) Targeting Report
Targeting Integrity (SIL) target to each SIF all inputs detailed above (detail targets for each HIPS)

3. HIPS Specification To specify the user requirements Integrity (SIL) Targeting Report HIPS Safety Requirements
(User) pertaining to each HIPS such Relevant Philosophies Specification
that an equipment provider can
generate a specification specific
to their equipment offering

4. HIPS Specification To generate an equipment HIPS Safety Requirements Functional Design Specification
(Supplier) specific specification that Specification (FDS) for each HIPS
meets the requirements of Dynamic analysis Comprises hardware (including
the HIPS SRS System Architecture) and
software requirements
Verify Phase 4 with 3

5. HIPS Design To generate a hardware and HIPS SRS and FDS System diagrams AFC (e.g. Hook
software HIPS design that up drawings, panel layouts)
meets the FDS requirements Software algorithms (e.g. flow
charts, C&E)
Verify Phase 5 with 3

6. HIPS Engineering To engineer the HIPS in FDS Physical hardware

compliance with the design System diagrams AFC Software code
To verify the design against the Software algorithms SIL Verification report
numerical (RRF) and integrity
Operation and Test procedures
target
Verify Phase 6 with 5 (FAT)

7. HIPS installation, To integrate and test the HIPS. HIPS Safety Requirements Fully functioning HIPS in
commissioning and To validate that the HIPS meets Specification conformance with the SRS
validation the SRS HIPS FDS Verify Phase 7 with 5 (SAT)
To install and commission the Test and Validation Plan FSA Report
HIPS
Commissioning and handover As-built documentation
Workpacks

8. HIPS Operation and To ensure the integrity of the HIPS Safety Requirements Maintenance plan
Maintenance HIPS is maintained during Specification Maintenance records
operation and maintenance Proof testing and routine Maintenance schedule updates
maintenance procedures
Spares listing

9. HIPS Modification To make corrections, HIPS Safety Requirements MOC approvals

enhancements or adaptations Specification Documentation (Philosophy/
to the HIPS, ensuring that the Management of Change (MOC) SRS/FDS/drawings etc.)
required safety integrity level is Procedures (including software updates as required to maintain
achieved and maintained change control) alignment with installed system
FSA Report FSA Report update

10. Decommissioning To ensure proper planning for MOC Procedures HIPS placed out of service
decommissioning
To remove HIPS from service
without compromising the safety
integrity of the facility

31
High Integrity Protection Systems – Recommended Practice

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.

32
High Integrity Protection Systems – Recommended Practice

This page is intentionally blank

33
 www.iogp.org
Registered Office Brussels Office Houston Office
City Tower Avenue de Tervuren 188A 15377 Memorial Drive
Level 14 B-1150 Brussels Suite 250
40 Basinghall Street Belgium Houston, TX 77079
London EC2V 5DE USA
T +32 (0)2 790 7762
United Kingdom
[email protected] T +1 (713) 261 0411
T +44 (0)20 3763 9700 [email protected]
[email protected]

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.