Group SHE Guidance

Management of Functional Safety

Issue 1.0 October 2023
s
Smart Science to Improve Lives™

0
 Contents
1 Introduction .................................................................................................................... 3
1.1 What is Functional Safety? ..................................................................................... 3
1.2 IEC 61508 / IEC 61511 ........................................................................................... 3
2 Purpose ......................................................................................................................... 4
3 Scope ............................................................................................................................ 4
4 SIF, SIS, SIL .................................................................................................................. 5
4.1 Safety Instrumented Functions (SIF) ....................................................................... 5
4.1.1 Modes of Operation ................................................................................................ 5
4.2 Safety Instrumented Systems (SIS) ........................................................................ 6
4.3 Safety Integrity Level (SIL) ...................................................................................... 7
5 Functional Safety Lifecycle ............................................................................................ 8
6 Functional Safety Management...................................................................................... 9
6.1 Safety Planning ..................................................................................................... 10
6.2 Competence ......................................................................................................... 11
6.3 Independence ....................................................................................................... 12
6.4 Verification ............................................................................................................ 12
6.5 Functional Safety Assessment .............................................................................. 13
6.6 Functional Safety Audit ......................................................................................... 15
7 Process Hazard and Risk Assessment ........................................................................ 15
7.1 Security Risk assessment ..................................................................................... 16
8 Allocation of Safety Functions to Protection Layers...................................................... 17
9 SIS Safety Requirements Specification (SRS) ............................................................. 19
10 SIS Design and Engineering ........................................................................................ 20
10.1 Average Probability of Failure on Demand (PFDavg) ............................................ 21
10.2 Architectural Constraints/Hardware Fault Tolerance ............................................. 23
10.3 Systematic Capability............................................................................................ 25
10.4 Overall Achieved SIL of SIS .................................................................................. 25
11 SIS Installation & Commissioning ................................................................................ 26
12 Validation ..................................................................................................................... 27
12.1 Factory Acceptance Test ...................................................................................... 27
12.2 Site Acceptance Test ............................................................................................ 27
13 SIS Operation & Maintenance ...................................................................................... 29
13.1 Operation .............................................................................................................. 29
13.2 Maintenance ......................................................................................................... 30
14 SIS Modification ........................................................................................................... 32
15 SIS Decommissioning .................................................................................................. 33

Functional Safety 1
 16 Documentation Requirements ...................................................................................... 33
16.1 SIS Safety Manual ................................................................................................ 34
16.2 Input and Output Documentation .......................................................................... 34
Appendix A: Safety Plan Template ...................................................................................... 36
Appendix B: Training Matrix for Functional Safety ............................................................... 36
Appendix C: Safety Requirements Specification Template .................................................. 36
Appendix D: Record of SIF Activation, Bypass and Failure Template ................................. 36
Appendix E: Proof Test Procedure Template ...................................................................... 36
Appendix F: Safety Manual Template ................................................................................. 36

Revision Publish
Updated by Comments
Number Date
0.1 20/08/2022 C. Murtagh First Draft
0.2 15/09/2022 C. Murtagh Second Draft
0.3 26/05/2023 A.Wright Third Draft
0.4 25/07/2023 A.Wright Fourth Draft
0.5 28/08/2023 A.Wright Fifth Draft (Pre-publish Review)
1.0 10/11/2023 A.Wright First Issue

Table 1: Table of Abbreviations used

Abbreviation Meaning
SIS Safety instrumented system
SIF Safety instrumented function
SIL Safety integrity level
BPCS Basic process control system
SRS Safety requirements specification
LOPA Layer of protection analysis
FSM Functional safety management
IEC International Electrotechnical Commission
IPL Independent protection layer
PFDavg Probability of failure on demand (PFDavg)
T1 Proof test interval
MRT Mean repair time
SFF Safe failure fraction
FIT Failures in time
LVL Limited Variability Language
FPL Fixed Programme Language

Functional Safety 2
 1 Introduction
1.1 What is Functional Safety?

The defined objective of safety is to enable freedom from risk which is not tolerable.

Functional safety is defined in the IEC 61511 standard as “the part of the overall safety of plant
and equipment that depends on the correct functioning of safety-related systems and other
risk reduction measures such as safety instrumented systems (SIS), alarm systems and basic
process control systems (BPCS).”

Essentially, functional safety is focused on the detection of potentially dangerous conditions

within a process and is dependent on the correct functioning of layers of protection and safety-
instrumented systems acting to return the process to a safe state, preventing hazardous
events. Furthermore, functional safety outlines the requirements to ensure the reliability of
these instrumented systems throughout their lifetimes.

1.2 IEC 61508 / IEC 61511

The general benchmark for good practice in functional safety is IEC 61508: Functional safety
of electrical/electronic/programmable electronic safety related systems. This is a generic basic
safety standard from which industry specific standards are derived. It defines a safety lifecycle
of technical and managerial activities. This standard applies to the manufacturers and
suppliers of devices.

An industry-specific standard has been derived from IEC 61508 for use in the process
industries – IEC 61511: Functional safety - Safety instrumented systems for the process
industry sector. This standard defines the safety lifecycle (further described in Section 5) and
how it shall be used to manage functional safety. It gives requirements for the specification,
design, installation, operation, and maintenance of safety instrumented systems so that it can
be confidently entrusted to place/maintain the process in a safe state. This standard applies
to safety instrumented system designers, integrators, and users.

Figure 1: Relationship between IEC 61508 and IEC 61511

Functional Safety 3
 IEC 61511 sets out many engineering and management requirements; however, the key
principles of the safety lifecycle are to:

 Use hazard and risk assessment to identify requirements for risk reduction.
 Allocate risk reduction to layers of protection and Safety Instrumented Systems (SIS).
 Specify the required function, integrity level and other requirements of the SIS.
 Design and implement the SIS to satisfy the safety requirements specification.
 Install, commission and validate the SIS.
 Operate, maintain and periodically proof-test the SIS.
 Manage modifications to the SIS.
 Decommission the SIS.

IEC 61511 defines the required management processes that underpin the safety lifecycle: to
plan, assess, verify, monitor, and audit (further described in Section 6).

In addition, requirements are defined for the competence and independence of personnel
engaged in functional safety work. These are further defined in Sections 6.2 and 6.3
respectively.

Furthermore, requirements are defined for Functional Safety Assessments – a

management process which is used to make a judgement as to the functional safety tasks and
safety integrity level achieved by a Safety Instrumented System. These are further defined in
Section 6.5.

The risk reduction provided by a Safety Instrumented System can only be fully relied
upon if the complete requirements of IEC 61511 are met throughout its lifecycle.

2 Purpose

The purpose of this document is to describe the processes and requirements to achieve
compliance with International Standard IEC 61511 and provides guidance on the conduct of
each stage of the functional safety lifecycle. This document also provides links to templates
for key documentation which are required at different stages of the functional safety lifecycle.

3 Scope

This document applies to manufacturing sites which use functional safety devices required to
comply with International Standard IEC 61511.

Functional Safety 4
 4 SIF, SIS, SIL

4.1 Safety Instrumented Functions (SIF)

A Safety Instrumented Function (SIF) is one or more components designed to execute a

specific safety-related task in the event of a specific dangerous condition, to bring the process
to a safe state.

Note: Each SIF is related to one specific hazardous event.

A SIF consists of three basic structural components:

 Primary Element/Sensor – Detection

 Logic Solver/Controller – Decision
 Final Element – Action

An example of a SIF would be a function which, on detecting high temperature within a

vessel, shuts off steam flow to the vessel jacket.

Figure 2: Components of a SIF

4.1.1 Modes of Operation

There are three modes of operation relating to the frequency of demands on a SIF, as
described in Table 2:

Table 2: Modes of operation of a SIF

Mode Description Frequency

The SIF is only performed on demand to transfer the Maximum
Low demand
process into a specified safe state. once per year
The SIF is only performed on demand to transfer the Greater than
High demand
process into a specified safe state. once per year
The SIF retains the process in a safe state as part of Operates
Continuous
normal operation. continuously

Functional Safety 5
 Additionally for a SIF to be low demand the mean time to demand must be less than 2x the
proof test interval.

For example:

There are 4 LOPA scenarios caused by 4 different initiating events, each has a frequency
of 0.1/year. A single SIF is the only IPL for all 4 scenarios. The predicted demand rate is
calculated by summing the demand rate on the SIF for each scenario, this is
0.1+0.1+0.1+0.1= 0.4/year. Therefore, the mean time to demand is 2.5 years (=1/0.4). This
shows the SIF is low demand.

The additional requirement means that this SIF is only low demand if the test interval is
less than half the mean time to demand. Therefore, the maximum test proof interval in this
case is 2.5/2=1.25 years. If the test interval is longer than this then the SIF is considered
high demand mode.

Low demand is the most common mode of operation found in SIFs in the process
industries.

Though high demand SIFs will not commonly be seen, it is not uncommon to see a SIF
designed as low demand experience more than one demand per year. In this case, the
design of the process or the SIF must be revisited.

4.2 Safety Instrumented Systems (SIS)

A safety instrumented system (SIS) is an engineered set of hardware and software controls
which implement one or more safety instrumented functions (SIFs) to bring the system to a
safe state.

A SIS can be composed of one or more SIFs. A SIS therefore may be composed of any
combination of sensors, logic solvers, or final elements.

As a SIS may encompass multiple SIFs, it may act in multiple ways to prevent multiple harmful
outcomes.

Components used by a SIS must be independent from those used by the Basic Process
Control System (BPCS) to be claimed as Independent Protection Layers (IPL). I.e.,
Components must not be shared nor impact the functioning of the other in the event of a
failure.

Figure 2 shows a SIS that protects against several different initiating events using 4 SIFs. If
several SIFs want to be claimed as IPLs in a LOPA against the same initiating event then they
must be fully independent. In the case of figure 2 it is not possible to claim the full reliability of
multiple SIFs against the same initiating event unless they are fully independent. Instead an
evaluation must be made of the reliability achieved by combining the SIFs as a subsystem.
Alternatively, design two separate fully independent systems which can be claimed.

External contractors with experience and competence in functional safety can be beneficial
for consultation on the design of independent SIFs where multiple are required to achieve the

Functional Safety 6
 designed risk reduction. Equipment manufacturers may also be able to provide additional
guidance.

Figure 2: Components of a SIS

4.3 Safety Integrity Level (SIL)

Safety Integrity Level (SIL) is a quantitative target for measuring the level of performance
needed for a safety function to achieve a tolerable risk for a process hazard. It defines the
level of risk reduction related to a SIF.

There are four discrete SIL levels with different degrees of risk reduction defined as in Table
3.

Table 3: Safety Integrity Levels

Risk Reduction Factor

SIL PFDavg* (1/RRF) PFH*
(RRF)
1 >101 (>10) <10-1 <10-5
2 >102 (>100) <10-2 <10-6
3 >103 (>1000) <10-3 <10-7
4 >104 (>10000) <10-4 <10-8
*PFDavg (average probability of failure on demand) is used for low demand mode SIFs. PFH (probability of failure per hour) is used for high demand
and continuous mode SIFs.

SIL 1 & 2 SIFs will be most commonly encountered in the process industries.

SIL 3 SIFs will be rarely encountered in the process industries.

SIL 4 SIFs will never be encountered in the process industries.

Specification of a SIL 3 or SIL 4 SIF should trigger a revisit of the design.

A higher SIL rating leads to a higher degree of risk reduction and also means that there are
stricter requirements on the design, the safety function failure rate must be lower and the plant
protection availability higher.

Functional Safety 7
 SIL applies to the complete safety function (Primary Element, Logic Solver, Final Element) as
described in Section 4.1.

Whilst individual elements can have a “SIL capability” – only a complete SIF can have an
achieved SIL.

For example: The installation of a SIL 2 rated flowmeter does not mean the entire SIF
system is SIL 2 automatically.

5 Functional Safety Lifecycle

The management of functional safety is underpinned and organised by the functional safety
lifecycle, as shown in Figure 3. All projects based around the installation, design, and
maintenance of SIS must follow this entire lifecycle to provide assurance of safety integrity.

The lifecycle describes how each SIS must be managed from initial concept, to design,
implementation, operation & maintenance, and decommissioning. Figure 3 also highlights the
hazard study requirements based on the existing, well established 8-stage Hazard Study
process.

Figure 3: Functional Safety Lifecycle

In essence, the functional safety lifecycle is a means to:

 Identify the hazards and assess the risks posed.

 Ascertain how much risk reduction is required.
 Identify all control measures and specifically where SIS are to be used.
 Determine the target Safety Integrity Level (SIL).
 Design the SIS to the target SIL.

Functional Safety 8
  Install and check the SIS to achieve the target SIL.
 Maintain the SIS to the designed SIL.
 Audit and review the performance against identified criteria.

The safety lifecycle must be adhered to fully in order to ensure that the achieved SIL is
maintained throughout the entire life of the SIS.

Note: If, at any stage of the safety lifecycle, a change is required pertaining to an earlier
lifecycle phase, then that earlier safety lifecycle phase and the subsequent phases shall be
re-examined, altered as required, re-verified and documented. This requirement is further
explained in Section 14.

The required input and output documentation for each stage of the lifecycle are summarised
in Section 16.2.

6 Functional Safety Management

Activities and tasks related to the functional safety lifecycle must be properly managed as per
the requirements of IEC 61511 to ensure the safety integrity level and therefore risk reduction
of each SIS is maintained.

The site must develop its own local procedures to manage functional safety considering the
requirements of this guidance and IEC 61511.

Requirements for effective management include:

- Planning
- Identification of competent people with the correct independence
- Verification of all tasks to ensure they are technically correct
- Assessments of the SIL achieved and that the right people have done the right task
- Auditing of procedures to ensure they are fit for purpose

Note: If a site utilises external companies or suppliers to carry out functional safety work, it is
the responsibility of the site to ensure that these companies/suppliers:

- Have their own functional safety management systems in place.

- Are sufficiently competent.
- That they are included in the sites’ functional safety management systems (e.g. in
safety planning).

Figure 4 illustrates the necessary steps which must be carried out for every lifecycle task
(further detailed in the rest of this section):

Functional Safety 9
 Figure 4: Necessary activities for every safety lifecycle task

6.1 Safety Planning

For every project/area requiring functional safety, a safety plan must be produced which
includes every phase in the safety lifecycle. The safety plan ensures that all functional safety
tasks will be correctly managed to comply with the standard. Table 4 defines the content to
be included in the safety plan as well of a description of what is to be included.

Table 4: Content requirements of a Safety Plan

Required content Description

Project scope, including equipment descriptions, unit operations
Scope
and the affected stages
Organisation &
Who will complete each task (these may be internal or external)
responsibilities
The requirements to complete each task and how competence will
Competence
be demonstrated
Input Documents What documents are required for each phase of the lifecycle
What output documents are expected from each phase of the
Output Documents
lifecycle
Explanation of how to carry out each task, who will complete it
How tasks will be completed
and the independence requirements
Explanation of how to carry out verification for each task, who will
How tasks will be verified
complete it and the independence requirements
Action Management How actions from tasks will be managed, monitored and recorded
Modifications and Change How modifications to elements such are the scope and
management specification will be controlled
Note: If the project involves installation of a new SIS, then all safety lifecycle phases will be in
scope. However, if the project involves modification to an existing SIS, then only certain
lifecycle phases may be impacted (to be established by an impact assessment – see Section
14).

Functional Safety 10
 The safety plan should be a live document which is updated throughout the life of a
project.

Each time a safety lifecycle task is completed or verified, it should be signed off as such in
the safety plan.

A safety plan template can be found in Appendix A.

6.2 Competence

A critical part of managing functional safety is assuring that all personnel performing tasks
relating to the lifecycle are deemed competent to do so.

There are three elements of competency which must be fulfilled:

 Formal training, such as external training courses

 Practical experience, such as putting training into practice by using it on a relevant
project
 Demonstration of knowledge, such as interviews, exams or verification of work by a
competent peer or independent person.

There should be a procedure and system in place to manage the competency of those
involved in functional safety activities and their management. Importantly, individuals should
not be deemed competent indefinitely: their competence should be periodically refreshed,
updated, and assessed.

The training requirements for different site roles relating to functional safety are provided in
Table 5. A Copy of this is also available in Appendix B.

Table 5: Formal Training Requirements based on Site Role

Functional Safety - Requirements of Role

TUV Rheinland
1 Day Cyber security
1/2 day SIL Approved
Functional HS leaders LOPA Program - TUV
Job title awareness / SIL determination course Course
Safety for course training Rheinland
Introduction Achieving FS
Managers approved
Engineer
Croda Croda
TUV Certified TUV Certified TUV Certified TUV Certified
Provider and Course Details Lead by TUV Certified Provider Lead by
Provider Provider Provider Provider
Group SHE Group SHE
Site Head Yes Yes No No No No No
Site Engineering Manager Yes Yes No No No Yes No
Maintenance Manager Yes Yes No No No No No
EC&I Engineer Yes No No Yes Yes No Yes
Systems Control Engineer Yes No No No No No No
Maintenance Technicians Yes No No No No No No
Process Engineers (Hazard Study Leader) Yes No Yes No No Yes No
Process Engineers Yes No No No No No No
Contractors (Maintenance) Yes No No No No No No
Contractors (SIS Design) Yes No No Yes Yes No No
Contractors (Cyber Security) Yes No No Yes No No Yes
Operators Yes No No No No No No

Practical experience and demonstration of knowledge requires knowledge to be put into

practice and checked. For functional safety the minimum requirement to be deemed fully
competent is for 3 pieces of work to have been completed and verified as meeting the
requirements for each task within 12 months of completing formal training. The verification
process provides a continual competence check but it should be remembered that verification

Functional Safety 11
 is required for every task within the functional safety lifecycle. Verification does not stop once
someone has completed these 3 pieces of work.

To provide assurance of competence over time 3 pieces of work should be submitted to for
review and feedback every 5 years. Ideally this should be reviewed by someone with equal or
higher competence at a different site. This will be supported by the growing network of
competent people within the Organisation.

6.3 Independence

Requirements are given by the standard as to the allowed independence of personnel

carrying out safety lifecycle and functional safety management activities.

Each task in the safety lifecycle must be performed, verified, and assessed. These three
requirements for each task must be performed by independent personnel. That is – one person
performs a task, a separate person verifies it to ensure it has been completed correctly, and
a third person assesses it to ensure it complies with the standard and provides the required
safety integrity level.

Assessment is achieved using Functional Safety Assessments at pre-determined stages, to

achieve the independence and competency requirements these are likely to be conducted by
external parties.

The safety plan must specify in advance who is to carry out these activities for each functional
safety task in order to demonstrate independence, as well as providing the defined
competency requirements.

6.4 Verification

Verification is an integral underpinning aspect of the functional safety lifecycle. It is a technical

check that confirms whether a task has been performed correctly. It must be done for every
task in the safety lifecycle. Verification should be completed before the next task in the lifecycle
can be started.

It must be performed by a person independent from the task with the same competence as
the person who performed the task.

Independent verification does not need to be carried out by someone external to the
company; verification may be carried out by someone within Croda, as long as they have
not been involved in the completion of the task being verified.

Verification planning must take place – the Safety Plan must define in advance who is
responsible for the verification of each lifecycle task, along with describing their required
competencies and how they have been met. Verification must take place according to the
verification planning.

Functional Safety 12
 All verification results must be documented and made readily available as per the
requirements of Section 16.

6.5 Functional Safety Assessment

Functional safety assessments (FSAs) are judgements as to the functional safety tasks
completed and safety integrity level achieved by every SIF of the SIS during the project. They
are performed by a competent person at pre-defined times throughout the safety lifecycle.

FSAs require a systematic review of all documentation to ensure there is an auditable trail
throughout the lifecycle, an FSA reviews all stages not previously assessed up to the lifecycle
phase being assessed. They determine whether compliance with IEC 61511 and all regulatory
requirements have been met, and whether suitable engineering practices have been used for
the design, installation, and engineering of the SIS.

As well as assessing the tasks completed throughout the safety lifecycle phases, FSAs also
must assess the underpinning aspects of the safety lifecycle:

 Safety planning
 Verification
 General functional safety management.

FSAs must be led by a competent person who is completely independent from the safety
lifecycle phases being assessed, and who has detailed knowledge of the standard to ensure
that the project complies. Due to the competence and independence required, it is common
for FSAs to be carried out by assessors from external organisations.

The safety plan must consider every stage for FSA planning, defining when it will take place
and who will be responsible for it.

FSAs are split into 5 stages throughout the safety lifecycle, which are highlighted on Figure 5.

Functional Safety 13
 Figure 5: Functional Safety Lifecycle highlighting FSA Stages

Stage 1 FSAs should be completed after the Safety Requirements Specification (SRS) has
been defined, and before the SIS is designed and built. This will ensure that the hazard study
and LOPA processes have been completed adequately, and that the SIS has been correctly
specified before being built.

Stage 2 FSAs should be completed after the Factory Acceptance Test has been completed,
and before the SIS is shipped to the site. This will ensure that the SIS has been correctly
designed and built to comply with the standard, the SRS and provides the desired safety
integrity.

Stage 3 FSAs should be completed after the SIS has been installed and commissioned on-
site, after the Site Acceptance Test has been completed, and before any hazards are
introduced to the system. This will ensure that the SIS has been installed correctly and retains
the required safety integrity level necessary for the introduction of hazardous materials. This
should be completed at a similar timeframe to hazard studies 4 and 5.

Stage 3 FSAs come at a crucial stage in the lifecycle of a SIS, as they are the last check
that the required safety integrity level has been reached before hazards are introduced
into the system.

As they are the last lifecycle item to be completed before the SIS goes into operation, it is
inevitable that there will be production pressures to complete it as quickly as possible.
However, it is crucial that an FSA 3 be carried out correctly and fully, despite any
external pressures which may exist.

Stage 4 FSAs should be carried out periodically throughout the operational lifetime of the SIS.
They differ from other FSA stages as they are an ongoing check of compliance, rather than a

Functional Safety 14
 stage-gate. They should check that proof testing and inspection are being completed correctly,
and that data is being recorded and analysed to confirm the performance of the SIF.

Note: It is recommended that a Stage 4 FSA is completed in line with the PRR schedule of
the plant in question. The completion of FSA4, proof test completion and their results should
be included as part of the plant PRR.

Stage 5 FSAs should be carried out whenever a modification is made to a SIS. They are split
into two parts, with part 1 to be completed before a modification occurs and stage 2 to take
place after the modification is made.

Stage 5 FSA (part 1) confirms that the correct management of change (MoC) is in place, that
an impact assessment is undertaken (to understand what parts of the lifecycle are being
affected and need to be re-assessed), and that the modification has been approved.

Stage 5 FSA (part 2) should be completed before hazards are reintroduced to the system after
modification.

6.6 Functional Safety Audit

Functional safety audits are intended to review and audit the sites’ functional safety
management systems and procedures. It ensures that the functional safety management
system itself as well as the procedure are up-to-date, fit for purpose, compliant with the
standard, and are being followed.

Functional safety audits differ from FSAs, as they are focussed on ensuring the site
procedures and management system itself are compliant with the standard; whilst FSAs are
project-focussed and ensure that the installation of a SIS itself meets the required safety
integrity.

Functional safety audits should be completed at a sufficient periodic time interval, typically this
is every three years, however the interval must not exceed 5 years. This should be conducted
by an independent person with in-depth knowledge of the standard (i.e. someone not involved
with the implementation and upkeep of the functional safety management system). Typically,
an external auditor is required to achieve the correct independence and competence.

7 Process Hazard and Risk Assessment

There is a requirement to determine all hazards associated with the process and processing
equipment involved in the functional safety lifecycle. Following this, the risk associated with
each hazard must be determined, and any requirements for risk reduction must be identified.

This requirement can be fulfilled by use of the 8-stage Hazard Study process which is well-
established within Croda. Detailed requirements for the Hazard Study process are therefore
outside the scope of this Guidance document.

The outcome of the Hazard Study 2 and 3 (HAZOP) process shall be a document of all
potential hazards, an estimation of consequence for each hazard, and a review of all

Functional Safety 15
 safeguards/protection layers to be included to prevent or mitigate the hazard. The outcome of
the hazard studies should meet the output requirements for the Process Hazard and Risk
Assessment phase of the safety lifecycle.

Process Hazard and Risk Assessment is an explicit requirement of the functional safety
lifecycle. Therefore, Hazard Studies should be included as standard in the functional safety
management process and must be planned, verified, assessed, and documented
alongside all other safety lifecycle tasks.

7.1 Security Risk assessment

Further to process safety considerations there is a need to evaluate cyber security in reference
to SIFs. As there is increasing connectivity between control system and a larger dependence
on automation for safety purposes there is also increased susceptibility to cyber-attacks.

A cyber-attack could result in SIFs being;

 unavailable,
 unable to correctly perform their function
 or render them inoperable.

If SIFs are not secured both physically and systematically then there is the potential for the
SIF to be subject to a cyber-attack.

Examples of previous cyber-attacks on different systems include;

 Ukraine. Attackers gained remote access and manipulated the industrial control systems
of a regional electricity distribution company and shut down power for some 225,000
Ukrainian power customers for several hours
 Germany. An attack on a steel works in Germany causing significant damage, by
disrupting the control systems such that a blast furnace could not be properly shut down
 ‘Stuxnet worm’. Damaged centrifuges at an Iran nuclear facility (through use of USB)

To meet the requirements of IEC61511 a Security Risk Assessment should be conducted.

This risk assessment requires specialist knowledge and is likely to be conducted by an
external body with the required competence.

Key questions to be answered as part of the security risk assessment include;

 Are the instrumented systems and SIS connected to a Local Area Network (LAN), a
Wide Area Network (WAN), the Internet?
 Are the instrumented systems and SIS vulnerable to a cyber attack?
 What are the assets, threats, vulnerabilities, existing counter measures, and the
resulting cyber security risks?
 What are the cyber security requirements to reduce risk?

Functional Safety 16
 The HSE has drafted Operational guidance in reference to Cyber Security which can be
referred to support the integration of cyber security into safety management systems. A link to
this is below.

https://www.hse.gov.uk/foi/internalops/og/og-0086.pdf

8 Allocation of Safety Functions to Protection Layers

After determining the hazards present through Hazard Studies, it is then necessary to
determine the level of risk reduction required to ensure that the process is not intolerable by
Croda’s corporate standards.

“Allocation of Safety Functions to Protection Layers” can also be known as “SIL

Determination”, as it is ultimately a means of determining required safety integrity levels
for each protection layer.

Croda’s standard method of allocating safety functions to protection layers is through Layer of
Protection Analysis (LOPA). This technique is well-established within Croda and is further
detailed in the Croda LOPA Manual; therefore, detailed requirements for this technique is
outside the scope of this Guidance document. However, in some cases LOPA may not be
appropriate and a quantitative risk assessment can be used instead, for example where there
are complex or multiple fatality scenarios.

The outcome of the analysis shall be identification of all Independent Protection Layers (IPLs,
see LOPA Manual for further detail) necessary to ensure the risk is not intolerable. IPLs can
include BPCS trips, relief valves, bunds, manual operator intervention, or Safety Instrumented
Functions. Figure 6 details the relationship between SIFs and other functions which may be
used as IPLs.

Functional Safety 17
 Figure 6: Relationship between SIFs and other safety functions

IPLs which do not classify as Safety Instrumented Functions as per Figure 6 should be
managed by means other than the functional safety management system, and hence do not
come under the scope of this Guidance document. However, they remain essential means of
risk reduction, so it is important that they are managed correctly. The LOPA Manual can be
used to provide more information on their management.

In addition to allocating SIFs as an IPL, the outcome of this phase shall also be to quantify the
level of risk reduction required by a SIF, and if it should operate in a demand mode or
continuous mode. I.e., it should specify the required Risk Reduction Factor (further detailed in
Section 4.3), and therefore the required SIL of the SIF.

A specific and defined safety function description should be an output of the allocation
process (LOPA/QRA) for each SIF.

E.g. Upon sensing a temperature of 130°C within vessel V101, valve VV101 on the steam
line must close within 5 seconds to prevent further heating of the vessel. This SIF must
provide a Risk Reduction Factor of 230 as identified by LOPA – corresponding to integrity
requirements of SIL 2.

Note: if the Allocation of Safety Functions to Protection Layers results in specification of a SIL
4 SIF, then the assessment must be reconsidered: SIL 4 SIFs will never be found in the
process industries. Instead of a SIL 4 SIF, multiple IPLs or SIFs with lower integrity
requirements may be necessary to achieve a higher level of risk reduction. Calculations should
carefully consider the interactions and dependencies among the SIFs to accurately assess
the overall system reliability.

Functional Safety 18
 There are specific requirements given to BPCS trips if they are claimed as IPLs during SIL
determination.

The maximum Risk Reduction Factor that can be claimed by a BPCS protection layer is
10.

If a Risk Reduction Factor of greater than 10 is required for an instrumented function, then
a SIL rated function independent from any BPCS will be required.

Additionally – a maximum of 2 BPCS layers may be claimed in a single LOPA, and they
must be entirely independent (i.e., not affect the operation of another in the event of a
failure or fault).

9 SIS Safety Requirements Specification (SRS)

A Safety Requirements Specification specifies the requirements for each SIF and their
associated target SIL level to achieve the required functional safety as determined during
earlier lifecycle phases (Hazard studies and LOPA).

A Safety Requirements Specification is an essential document which must be prepared for

each SIF to enable detailed design and engineering. It will also be referred to throughout the
entire life of the SIF as a basis for: validation, proof testing, operation, and maintenance –
therefore, must be written for use and available for any later lifecycle phase.

The functional requirements documented in the SRS must be derived from the requirements
identified during the Hazard & Risk Assessment and from the Safety Function Allocation
phases. Therefore, the SRS acts as a “bridge” between the process engineering discipline
and the EC&I engineering discipline and allows for early alignment between the requirements
of the process and the functionality of the SIF.

IEC61511 defines a list of contents that must be included in every SRS. These include:

 Functional requirements
o Functional description of SIF
o Sensing requirements
o Trip action (energise or de-energise)
o Safe state for each SIF
 Integrity requirements
o Required safety integrity level (SIL)
o Required Risk Reduction Factor (RRF) or PFDavg
o Whether SIF is low demand, high demand, or continuous mode
o Response time (this must be less than half the process safety time)
 Operational requirements
o Proof test requirements
o Maintenance requirements
o Secondary (BPCS) trips
o SIF Lifetime

Functional Safety 19
 o Environmental requirements (such as ingress protection)
 Process Safety Time (the time between a failure occurring in the process or BPCS and the
occurrence of the hazardous event if the SIF is not performed)
 Survival Time
 Application Programme (for each programmable SIS device)
o Sensor voting
o Requirements from the architecture and safety manual (limitations and constraints
on the hardware and embedded software)

The complete list is available in IEC 61511.

The application programme is specific to each SIF application and outlines the logic
sequences, permissive, setting limits and expressions that control the inputs, output,
calculations and therefore decisions required for the SIF to perform its function.

These requirements ensure safe software is used so that the system can execute a safety
function even under fault conditions and that any software has been developed according to
functional safety standards. For IEC 61511 the application programming languages are limited
to Fixed Programming Language (FPL) and Limited Variability Language (LVL). Commonly,
application programmes can be expressed using function blocks.

An SRS template has been provided in Appendix C which takes into account the
requirements listed and additional requirements listed in IEC 61511 – correctly and completely
filling out this template will ensure that an SRS is produced which meets the requirements of
IEC61511.

10 SIS Design and Engineering

Each SIS and SIF must be correctly designed to meet the target risk reduction factor (SIL
level) as specified in the SRS. Croda sites will generally not be involved in the detailed design
of a SIS – this would typically be completed by an external competent contractor. Therefore,
this section will serve only to provide a high-level overview of key design elements.

All SIFs need to be designed to fail safe in the event of a power loss wherever possible. If a
SIF is unable to fail safe in the event of a power loss then a discussion of backup power should
be held by the site, however this should be only in exceptional cases. For multi-purpose
processes the SIF must not introduce hazardous scenarios.

IEC 61511 allows the use of human actions in SIFs operation in special cases however these
are very complex and require detailed management, design and maintenance, this is not
deemed good practice and should be avoided whenever possible.

Achieved SIL Calculation reports should be produced for every SIS to demonstrate that the
integrity level of the SIS meets the required integrity level as per the SRS.

Note: Where external contractors are used, they must be included in the project’s functional
safety management procedures and functional safety plan; their work must also be verified

Functional Safety 20
 and assessed. Crucially, proof must be obtained that the external contractor has their own
functional safety management system in place.

There are three aspects of SIS design which must be included with to provide assurance of
the reliability and hence SIL achieved:

 Average Probability of Failure on Demand (PFDavg)

 Architectural Constraints/Hardware Fault Tolerance
 Systematic Capability

This Guidance document will provide a high-level overview of each of these three
requirements in turn.

10.1 Average Probability of Failure on Demand (PFDavg)

The average probability of failure on demand (PFDavg) is used for low demand SIFs as a
measure of how likely it is that the SIF will fail to act when required to stop a hazardous event
from progressing.

1
𝑃𝐹𝐷 =
𝑅𝑅𝐹
The required Risk Reduction Factor (RRF) (and hence PFDavg and SIL) of the SIF should
come from the LOPA or QRA and be specified in the SRS – the design should ensure that the
overall SIF meets this requirement. Each SIL, which should be specified in the SRS for each
SIF, has a defined range of PFDavg values associated with it.

For SIFs that operate in either high demand mode or continuous mode the SIL relates to
ranges of Probability of Failure on Demand per Hour (PFH) which is the is the probability that
a system will fail dangerously, and not be able to perform when required, on an hourly basis.

Table 6 shows the PFDavg and PFH for each SIL.

Table 6: Safety Integrity Levels

Risk Reduction Factor

SIL PFDavg (1/RRF) PFH
(RRF)
1 >101 (>10) <10-1 <10-5
2 >102 (>100) <10-2 <10-6
3 >103 (>1000) <10-3 <10-7
4 >104 (>10000) <10-4 <10-8
*PFDavg (average probability of failure on demand) is used for low demand mode SIFs. PFH (probability of failure per hour) is used for high
demand and continuous mode SIFs.

The PFDavg of the overall SIF must be found by summing the PFDavg of every component
in the SIF (sensor element(s), logic solver(s), final element(s)).

“Failures” can be categorised as safe, dangerous detected, and dangerous undetected.

Note: The symbol “λ” is used to denote failure rates.

Functional Safety 21
 Safe failure rate (λS): Safe failures occur when the process is in normal operation and the
system acts as if a hazardous event has occurred and unnecessarily acts to place the process
in a safe state (i.e. a spurious trip).

Dangerous detected failure rate (λDD): Dangerous failures prevent the SIF from acting as it
should – if called upon, the SIF would be unable to place the process in a safe state.
Dangerous detected failures are alerted by diagnostics and make personnel aware that the
SIF is in a degraded state – allowing the SIF to be repaired before it is required.

Dangerous undetected failure rate (λDU): Dangerous failures prevent the SIF from acting
as it should – if called upon, the SIF would be unable to place the process in a safe state.
Dangerous undetected failures are not visible and are not picked up by diagnostics – they can
only be discovered through proof testing or failure to act when required. This is the most crucial
type of failure: if a dangerous undetected failure occurs it will not be discovered until a proof
test is done or if a demand is placed on the SIF.

Note: A common unit of failure rate is Failure In Time (FITs), which are failures per billion
hours, expressed by 10-9 hours. E.g. 5 FITs = 5x10-9 hours

The PFDavg for a component may be calculated using the following simplified equation:

1
𝑃𝐹𝐷 = ∗𝜆 ∗𝑇
2

With λDU being the dangerous undetected failure rate of the component, which is defined by
the manufacturer; and T1 being the proof test interval (in hours) which is defined by the site
(commonly 12 months).

The system designer may use more complex equations, which includes the following terms:

λDU: Dangerous undetected failure rate, defined by component manufacturer.

λDD: Dangerous detected failure rate, defined by component manufacturer.
T1: Proof test interval, defined by site.
MRT: Mean repair time, defined by site. The time taken to repair a degraded SIF upon
detection of a dangerous fault.
MTTR: Mean time to restoration, defined by site. The time between a dangerous fault
occurring, being diagnosed, and being repaired.

Note – MRT and MTTR only apply if the process continues to operate whilst the SIF is in a
degraded state.

If a SIF is found to be failed or unable to operate then the site must consider the implications
on the risk position against the Croda Tolerability of Risk requirements. If the risks are
identified as intolerable then the Croda Management of Intolerable Risks process must be
followed.

Functional Safety 22
 The PFDavg must be calculated by the designer using variables defined by both the
component manufacturer and the site, ensuring that the calculated PFDavg meets the
specific requirements defined in the SRS.

It is generally not appropriate to use a generic PFDavg given by the component

manufacturer or taken from literature, as this will underestimate the true PFDavg of the
component in the installed system.

10.2 Architectural Constraints/Hardware Fault Tolerance

Hardware fault tolerance outlines the redundancy requirements for each SIS sub-system to
protect against random hardware failures. The level of hardware fault tolerance within a SIS
limits the maximum SIL that can be achieved by the system (also known as the architectural
constraints of the system).

𝐻𝑎𝑟d𝑤𝑎𝑟𝑒 𝐹𝑎𝑢𝑙𝑡 𝑡𝑜𝑙𝑒𝑟𝑎𝑛𝑐𝑒 (𝐻𝐹𝑇) = 𝑀 − 𝑁

where configuration is expressed using the format NooM

Example

A SIS sub-system in a 1oo2 configuration has a hardware fault tolerance of 1.

HFT = M-N = 2-1 = 1

If there is a fault in one of the devices, the SIS will still function as intended.

The architectural constraints of a component or sub-system can be determined via look-up

tables (Table 7 and Table 8) as found in IEC 61508 or IEC 61511.

IEC 61508 Route 1H (Table 7) is generally used for new devices which have no historical
performance data. The architectural constraints are based on the device type and Safe Failure
Fraction (both of which are supplied by the component manufacturer).

There are two defined types of device: Type A and Type B.

 Type A devices are simple with well understood failure modes (e.g. a valve).
 Type B devices are complex devices (often containing a microprocessor).

The device type will be specified by the device manufacturer.

The Safe Failure Fraction (SFF) is the percentage of safe and dangerous detected failure
rates vs the total failure rates. This may be calculated by using the failure rates as specified
by the device manufacturer.
𝜆 +𝜆
𝑆𝑆𝐹 =
𝜆 +𝜆 +𝜆

Functional Safety 23
 Table 7: IEC 61508 Route 1H Look-up Table

Type A Devices Type B Devices

Safe Failure
Hardware Fault Tolerance (HFT) Hardware Fault Tolerance (HFT)
Fraction (SFF)
0 1 2 0 1 2
< 60% SIL 1 SIL 2 SIL 3 N/A SIL 1 SIL 2
60% - <90% SIL 2 SIL 3 SIL 4 SIL 1 SIL 2 SIL 3
90% - < 99% SIL 3 SIL 4 SIL 4 SIL 2 SIL 3 SIL 4
> 99% SIL 3 SIL 4 SIL 4 SIL 3 SIL 4 SIL 4

Example (IEC 61508 Route 1H)

A SIS sub-system containing a Type A device in a 1oo1 configuration (HFT = 0) with a

calculated SFF of 61% has a maximum achievable integrity of SIL 2.

Type A Devices Type B Devices

Safe Failure
Hardware Fault Tolerance (HFT) Hardware Fault Tolerance (HFT)
Fraction (SFF)
0 1 2 0 1 2
< 60% SIL 1 SIL 2 SIL 3 N/A SIL 1 SIL 2
60% - <90% SIL 2 SIL 3 SIL 4 SIL 1 SIL 2 SIL 3
90% - < 99% SIL 3 SIL 4 SIL 4 SIL 2 SIL 3 SIL 4
> 99% SIL 3 SIL 4 SIL 4 SIL 3 SIL 4 SIL 4

The IEC 61511 method (Table 8) of determining architectural constraints may be used for
devices which have been proven in use and have a measured failure rate which is suitably
low and suitably statistically significant.

Table 8: IEC 61511 Look-up Table

SIL Minimum Hardware Fault Tolerance (HFT)

1 0
2 (Low Demand) 0
2 (Continuous or High Demand) 1
3 1
4 2

Example (IEC 61511)

A SIS sub-system operating in continuous mode with a requirement of SIL 2 has a minimum
hardware fault tolerance of 1 (HFT = 1), therefore a configuration such as 1oo2 or 2oo3 is
required.

SIL Minimum Hardware Fault Tolerance (HFT)

1 0
2 (Low Demand) 0
2 (Continuous or High
1
Demand)
3 1
4 2

Functional Safety 24
 Note: Either route for determining architectural constraints may be used during Achieved SIL
Demonstration – but the reasoning must be justified and supported with data from the device
manufacturer.

10.3 Systematic Capability

As well as random hardware failures, there is a possibility of systematic failures which are
caused by a fundamental error in the design of the system – such as through human error or
procedural flaws.

The Systematic Capability of a component represents the measures put in place by the
manufacturer to prevent systematic errors: such as through having a quality management
system which meets the requirements of IEC 61508.

Note: The Systematic Capability rating of a component will match the maximum achievable
SIL of the component. That is, a component with an SC rating of 3 will have a maximum
achievable rating of SIL 3 (not considering random hardware failures or architectural
constraints).

The Systematic Capability of a component will be judged by an external Functional Safety

Professional and will be found on a certificate issued along with the component.

Components may have a Systematic Capability that certifies them as being SIL capable –
but in order to actually achieve this SIL, all components of the SIS must be considered as
a whole alongside their random hardware failure requirements and architectural
constraints.

10.4 Overall Achieved SIL of SIS

All three requirements (random hardware failure, architectural constraints, and systematic
capability) must be considered for each component of a SIF before describing the SIF as
having an achieved SIL level.

Each component must satisfy the required integrity level for all three requirements.

The overall SIL achieved by a SIF will be limited by the worst achievable SIL through any of
the three requirements.

Example

If a SIF has a PFDavg and hardware fault tolerance which is suitable for SIL3 for all
components but has a component which only has a Systematic Capability corresponding
to SIL1 – then SIL1 is the maximum achievable SIL for the overall SIF.

Note: The purpose of this section was to provide a high level overview of information required
for SIS and achieved SIL design, to allow sites to sense-check documents provided by
external companies. If provided with Achieved SIL documentation that does not take into

Functional Safety 25
 account all three of random hardware failure, architectural constraints, and systematic
capability – it is not accurate nor complete and should not be relied upon.

11 SIS Installation & Commissioning

Each SIS must be installed on-site as per the design specifications and drawings and must be
commissioned to prepare it for the final validation before operation (SAT, further detailed in
Section 12.2).

Existing site standards and procedures will generally be suitable to use for installation of a
SIS. However, this must be supervised and inspected by competent Croda personnel (if
installed by external contractors); and must be documented in the Functional Safety
Management Plan along with requirements for competence and independent verification.

Installation/commissioning planning must take place considering:

 Installation and commissioning activities

 Procedures, measures, and techniques to be used
 When the activities will take place
 Those responsible for the activities

All SIS devices must be installed as per their design, and the installation plan. It is important
that both the design and installation adhere to constraints and information provided in the
manufacturers’ manuals.

Upon completion of installation, the SIS should be commissioned in preparation for validation.
Examples of required commissioning activities include:

 Earthing
 Ensuring all energy sources correctly connected
 Ensuring all transport and packing materials have been removed
 Checking there is no physical damage present
 Checking all instruments are correctly calibrated
 Checking all field devices are operational
 Checking logic solver inputs/outputs are operational

Commissioning records must be produced to clearly document the outcomes from

commissioning activities and confirm whether the SIS is installed and commissioned in line
with the requirements from the design and the SRS.

If there are any discrepancies between the installation and the design – these should be
examined by a competent person for their impact on the functional safety of the installation. If
there is an adverse impact – the discrepancy must be resolved and documented. If there is
no adverse impact – the design documentation must be updated to “as-built”.

Functional Safety 26
 12 Validation

Validation of a SIS is the process of ensuring that the system has been designed and built to
meet the requirements specified in the SRS.

There are two elements of SIS Validation: The Factory Acceptance Test (FAT), completed
before the system is shipped to site, and the Site Acceptance Test (SAT), completed after
installation of the system on-site but before the hazards are introduced. Both are explicit
requirements of IEC 61511 and must be managed as part of the sites’ functional safety
management procedures.

12.1 Factory Acceptance Test (FAT)

A FAT must be completed to ensure that all requirements of the SRS have been met in the
SIS or SIF before it is shipped to the site for installation and commissioning.

Management of the FAT of the SIS must comply with the requirements of Clause 13 of IEC
61511. It must be included in the Functional Safety Management Plan, which must specify the
personnel responsible for completing it alongside their required competencies.

A FAT plan must be developed, which takes the following points into account:

 Functionality and performance tests

 Test cases, test descriptions, and test data
 SIS configuration (sensor, logic solver, final element)
 Dependence on other systems/interfaces
 Test success criteria
 Measures for corrective action in case of test failure
 Recording of tests conducted, data, results, and any observations

The FAT must take place in accordance with the FAT plan, and the test must show that all
logic related to the SIS performs correctly.

All results from the FAT must be fully documented, stating whether the criteria have been met
or not. If the criteria have not been met, the reasons for this must be documented and
corrective action must be implemented.

12.2 Site Acceptance Test (SAT)

The SAT is the second part of validation. The SAT occurs after the SIS has been installed and
commissioned on-site, and before any hazards are introduced into the system. Like the FAT,
it is a means to ensure that the SIS that has been installed on-site meets the requirements
specified in the SRS. Therefore, the SRS must be used as the basis for all SIS validation.

As always, the task of validation must be included in the Functional Safety Management Plan,
which must specify the personnel responsible for completing it alongside their required
competencies.

Functional Safety 27
 Validation planning must occur, which should take the following into account:

 The validation activities including implementation and resolution of resulting

recommendations
 Validation of all relevant process operating modes
 The procedures, measures and techniques to be used for validation
 When the activities will take place
 Persons responsible along with required competence and independence
 Equipment and facilities which must be made available (such as isolation valves and
leak detection equipment)

The process of validation through a SAT should comply with the validation plan, and should
take the following into account:

 Confirmation that the SIS performs correctly under all operating modes identified in the
SRS.
 Confirmation that adverse operation of any BPCS do not affect operation of the SIS.
 Confirmation that the SIS properly communicates with the BPCS if necessary, including
during abnormal conditions.
 All SIS sub-systems perform as required by the SRS.
 Design documentation is consistent with the installed system.
 The proper shutdown sequence is activated.
 The SIS provides the required annunciation and operation display.
 The SIS reset functions perform as defined in the SRS.
 Bypass functions operate correctly.
 Start-up overrides operate correctly.
 Manual shutdown systems operate correctly.
 The proof-test procedures are correctly documented in the maintenance procedures.
 Diagnostic alarm functions perform as required.
 Confirmation that the SIS performs as required on loss of utilities and that, when utilities
are restored, the SIS returns to the desired state.
 Confirm the status of any offline databases, and that all parameters in these databases
are in the correct state
 Confirmation that the status/configuration of sub-systems show compliance with the SRS

All results from the validation plan activities must be recorded to produce SIS validation
documentation. The results received should be verified against the expected results – any
discrepancies should be documented, along with how they were investigated and resolved.

SIS validation (and Stage 3 FSA) is the final step in the lifecycle before hazards are introduced
into the system. Therefore, it is essential that, at the end of validation, the system is left in the
correct state for operation. That is, any bypasses, overrides, forced permissives, or test fluids
should be removed from the system in preparation for operation, the validation procedure must
contain a requirement to confirm this.

Functional Safety 28
 13 SIS Operation & Maintenance
13.1 Operation

For continued assurance of the correct level of risk reduction, each SIS must be operated and
maintained in a way that upholds the required safety integrity. As such, the Operation &
Maintenance phase of the safety lifecycle is not a “stage-gate”, but an ongoing means of
compliance with the standard.

As with all activities related with the functional safety lifecycle, planning is a key part of the
management of SIS Operation & Maintenance. The planning of Operation & Maintenance
activities should take into account the following:

 Routine and abnormal operation activities

 Inspection, proof testing, preventive and breakdown maintenance activities
 Procedures, measures and techniques to be used for operation, maintenance and
bypasses
 Operational response to faults and failures identified by diagnostics, inspections, or proof-
tests
 Verification of conformity to operations and maintenance procedures
 When these activities will take place
 Those responsible for organisation of these activities

As mentioned above, it is essential that SIS Operation & Maintenance procedures be

produced, to define the correct means to uphold the required safety integrity of the SIS.

All operators working in an area which contains SIS must have awareness and training relating
to this SIS, as showing in Section 6.2 . They must understand the functionality of the SIS
(including trip points), the hazards protected against by the SIS, correct bypass management,
manual intervention required, and verification of diagnostics.

Records must be kept which document the behaviour of the SIS. Records should include:

 Demand rates (and action taken after demand)

 Failure rates and modes of overall SIS and SIS sub-systems
 Cause of demands
 Cause and frequency of spurious trips
 Number of bypasses implemented and duration

A template for recording SIF activations, failures and bypasses is provided in Appendix D.

Monitoring and recording of this data will ensure that assumptions made during the design of
the SIS are accurate during operation; and where this is not the case, allows targeted
modifications of the SIS to ensure the required functional safety is upheld.

Only competent individuals on site are permitted to implement bypasses on SIFs and must
have senior authorisation. All records, data, books (printed or electronic) must be auditable.

Functional Safety 29
 Bypasses disable the SIS and remove protection against the hazard. The use of bypasses
should therefore be avoided unless absolutely necessary.

Where use is necessary, compensating measures to ensure continued safety must be

applied. A risk assessment must be completed to confirm the measures provide adequate
risk reduction before operation. The process for bypassing, and the required compensating
measures, must be detailed in the SRS.

Bypasses must only be available to authorised personnel – they must not be easy to
access or alter. Authorisation must only be given from senior operations personnel only
(e.g. a plant manager, operations manager or site director).

The management of bypasses must be recorded in a procedure, and operators must be

trained on this procedure and be fully aware of how to manage bypasses.

A bypass log must be maintained which records all SIS bypasses implemented, along with
the reason and the duration.

13.2 Maintenance

Maintenance of a SIS is a critical means of ensuring required safety integrity is upheld. To

ensure this is performed correctly, all personnel involved with maintenance must be trained in
the requirements of the functional safety lifecycle.

An important responsibility of maintenance personnel is the proof test of each SIS. During
normal operation the components of the SIS are subject to the potential of random failures
which can render the SIS inoperable, these can either be detected or undetected dangerous
failures. The probability of an undetected dangerous failure increases over time, therefore the
purpose of the proof test is to uncover dangerous undetected failures in a controlled manner.

The proof test demonstrates that the SIS acts in accordance with the requirements specified
in the SRS and achieves the required PFDavg.

Proof tests must be designed to test the entire SIS – including sensors, logic solvers, and final
elements, and all channels (if system has redundancy). It should also include utilities
(air/power supply), inspection for physical damage, and review of any instrument diagnostic
warnings. Equipment manuals will be able to provide guidance on how to conduct parts of the
proof test. A value of proof test coverage must be provided within the proof test documentation.

Partial tests such as valve stroke test provide assurance on that element but not the entire
system.

If a proof test does not test the entire SIS then the probability of the failure on demand
increases due to the untested components (Imperfect Proof Test), as show in Figure 7. This
figure has been exaggerated for demonstration purposes.

Functional Safety 30
 Figure 7: Impact of proof testing on PFD of a SIS in a “Perfect” and “Imperfect” proof test

Other than proof tests, the only way to reveal dangerous undetected failures is to have a
demand on the system which will result in the occurrence of the ultimate consequence.

As described in Section 10.1, proof test intervals are defined during the design of the SIS and
are used to calculate the PFDavg of the SIS components (and therefore, the achieved SIL).
Therefore, this proof test interval for a given SIS must be complied with to ensure that the
achieved SIL from the design is maintained.

Note: 12 months is a common proof test interval; however, this may differ depending on
requirements from PFDavg calculations.

Proof test procedures must be produced for every SIS – these procedures must describe every
step that must be performed during proof testing, including:

 Correct operation of sensors and final elements

 Correct action from logic solver
 Correct alarms and indicators.

A template for generating a proof test procedure is provided in Appendix E.

An example of a proof test procedure used at Rawcliffe Bridge is also provided in Appendix
E.

Additional guidance on conducting a proof test is provided by the HSE which can be used to
support the development and conducting proof tests.

https://www.hse.gov.uk/foi/internalops/og/og-
00054.htm?fbclid=IwAR1JRtPoeehD2T6nhlFcRIT870sfj0azTUhSdet1bS3HVRxRyJnzEx2o0
fw&utm_source=Method+Safety+and+Security+Ltd&utm_campaign=76799f1292-
EMAIL_CAMPAIGN_2023_03_20_09_14_COPY_01&utm_medium=email&utm_term=0_-
2f9edc4521-%5BLIST_EMAIL_ID%5D

Inspections are another method which should be performed to ensure the SIS remains fit for
purpose. This is a periodic visual check, and by nature is less in-depth than a full proof test. It
should involve checking the equipment to ensure that there are no unauthorised modifications

Functional Safety 31
 or obvious physical deterioration (such as missing bolts, open wires, or missing insulation).
Whilst an inspection will not reveal dangerous undetected failures in the same manner as a
proof test; it could pick up problems which may indicate an increase in the likelihood and
frequency of these failures.

Every proof test and inspection that is completed must be documented and recorded, detailing
a description of the test/inspection performed, when it was performed, personnel who
performed it, and the complete results of the test.

14 SIS Modification

All modifications to a SIS must be controlled to ensure they do not have an adverse impact on
the safety integrity of the system, and that the required safety integrity of the SIS is maintained.

Note: This does not apply exclusively to the SIS itself – it also applies to modifications of
equipment which affect the requirements of the SIS (such as modifications to the BPCS).

There must be procedures in place for identifying and requesting modifications, authorising
and controlling them, and identifying any hazards which may be affected. In practice, the site’s
existing Management of Change systems should satisfy this requirement as long as this
system considers changes to SIS within it.

Before making any changes, the entire safety lifecycle and safety plan for the SIS in question
should be reviewed. An impact assessment must be carried out to perform this review and
determine the impact on functional safety for all lifecycle phases as a result of the change. If
this impact assessment shows that the change could impact functional safety, then the
functional safety lifecycle must be revisited from the first phase impacted by the modification.

Like the initial installation of the SIS – a safety plan should be completed for the modification,
considering all lifecycle phases identified by the impact assessment. The safety plan must
include plans for re-verification of all safety lifecycle tasks.

Any relevant existing documentation for the SIS must be updated if it is affected by the
modification (such as proof test procedures or Achieved SIL calculations).

Furthermore, documentation relating to the modification itself must be produced and

maintained. This should describe the modification, the reason for the modification, identify all
hazards and SIFs that may be affected, record required approvals, and detail all SIS
modification activities.

A 2-part Stage 5 FSA should be completed during the process of making a modification to a
SIS. Stage 5 FSA (part 1) should be completed before the modification occurs – and should
confirm that the correct MoC is in place, that an impact assessment is in place, and that the
modification has been approved. Stage 5 FSA (part 2) should be completed before hazards
are reintroduced to the system after modification, to confirm that the system is ready to return
to operation.

Functional Safety 32
 15 SIS Decommissioning

Decommissioning and removal of a SIS is, in itself, a modification. Therefore, it must be

managed through the same methods as any other modification.

Decommissioning activities should be controlled through the same Management of Change

processes as other modifications: as before, this must include identifying and requesting
modifications relating to decommissioning, authorising and controlling them, and identifying
any hazards which may be affected.

An impact assessment should also be carried out in order to ascertain the overall impact to
functional safety caused by decommissioning activities. This assessment should return to the
first phase of the safety lifecycle (Hazard & Risk Assessment) to determine the scope of impact
to the entire safety lifecycle.

The assessment should also consider how functional safety will be upheld whilst the
decommissioning activities are being performed, and what impacts the decommissioning of
the SIS will have on adjacent operating units and facilities.

Relevant documentation, approvals, and authorisations must be present before

decommissioning activities can proceed.

16 Documentation Requirements

Correct documentation is essential for the management of functional safety and is crucial for
providing proof and assurance of compliance with the requirements of a complete safety
lifecycle.

Documentation ensures that all necessary information is available so that all phases of the
lifecycle can be effectively performed, verified, and assessed.

All documentation must be accurate, easy to understand for its intended audience and
purpose, and must be maintained so that is it easily accessible when required.

Documentation should be managed and controlled under the site’s existing document control
procedures. This must ensure that documentation is properly maintained, has unique identities
for cross referencing, clearly states the title, author, and date published, has an audit trail of
reviews and approvals, and has traceability to the requirements of the standard.

Key documentation requirements include:

 Results of the H&RA and related assumptions

 Equipment used for the SIS together with safety requirements
 Organisation responsible for maintaining functional safety
 Procedures necessary to achieve and maintain functional safety of the SIS
 Any modification information (further detailed in Section 14)
 Safety manual

Functional Safety 33
  Design, implementation, test, and validation documentation (including calculations).
 Functional Safety Audits
 Bypass and Activation Records

Relevant documentation should be maintained for the lifetime of a given SIS, and for 7 years
after decommissioning.

16.1 SIS Safety Manual

The SIS Safety Manual is an essential document which must be produced and controlled for
every SIS present on-site.

It must collate all relevant information generated throughout every safety lifecycle phase in
the management of the SIS in question.

The safety manual should be a live document – it should be updated in the event of any
modifications to the SIS.

It is the responsibility of the site to produce the SIS safety manual – though it may include
documentation supplied from the equipment supplier or SIS designer, such as operations
manuals or SIL verification calculations.

A SIS safety manual template may be found in Appendix F. This template must be fully
completed for every SIS on-site to be in compliance with IEC 61511.

16.2 Input and Output Documentation

Table 9 provides an overview of necessary input and output documentation which should be
generated for each safety lifecycle, to be in compliance with the standard.

Functional Safety 34
 Table 9: Input and Output Documentation for each lifecycle phase

Safety Life-cycle
Input Documents Output documents
Phase
- Process Flow Diagrams (PFDs) - Hazard Study Report
Hazard & Risk - Piping and Instrumentation - Descriptions of required Safety
Assessment Diagrams (P&IDs) Functions and associated risk
(Hazard Studies) - Process Descriptions reduction
- Layout drawings - Actions list
- Description of safety
Allocation of requirement allocations
safety functions - Hazard Study Report
- LoPA Report detailing all SIFs
- Descriptions of required Safety
to protection and IPLs
Functions and associated risk
layers - SIF descriptions
reduction
(LOPA) - Safety integrity requirements
of each SIF
SIS Safety - Safety Requirement
Requirements - Description of safety Specifications of all SIS
Specification requirement allocations - Application program safety
(SRS) requirements
- Safety Requirement - Design of SIS Hardware
Specifications of SIS - Design of Application
SIS design and
- Application program safety programme in line with SIS
engineering
requirements Safety requirements
- FAT plan - FAT results documents
- SIS Design
SIS installation, - Commissioning Documents
- SIS integration plan
- As built drawings
commissioning, - Safety Requirement
- SAT results document
and validation Specifications of SIS
- Recording of achieved SIL
- SAT Plan
- SIS Design
- Safety Requirement
- Bypass Records
SIS operation & Specifications of SIS
- Maintenance Records
maintenance - Proof Test Procedures
- Proof test Records
- Operational procedures
- Maintenance Procedures
- Revised SIS Safety requirement
SIS modification N.B. Dependant on modification - Results of SIS modification
required
- As built drawings
- As built requirements
Decommissioning - Safety measures during
- Process information
decommissioning
- Results of verification for each
SIS verification - Verification plan for each task
task
- FSA Planning (Safety Manual)
SIS FSAs - Safety Requirement - Results of FSA
Specifications of SIS
Safety lifecycle
- Safety Plan
structure and - N/A
- Safety Manual
planning

Functional Safety 35
 Appendix A: Safety Plan Template
Appendix B: Training Matrix for Functional Safety
Appendix C: Safety Requirements Specification Template
Appendix D: Record of SIF Activation, Bypass and Failure
Template
Appendix E1: Proof Test Procedure Template
Appendix E2: Proof Test Procedure Example
Appendix F: Safety Manual Template
Click the link below to access the appendices
https://croda.sharepoint.com/:f:/r/sites/CorporateSHE/Standards%20%20Guidance/Process%20Safety/Functional%20Safety/Functional%20Safety%20Appendices?csf=1&web=1&e=uA8AtA

Functional Safety 36