Preliminary

Hazard
Identification &
Analysis Guide

The Safety Artisan, 2020

0
 Preliminary Hazard Identification & Analysis Guide

Table of Contents
Introduction .............................................................................................................................................. 1
Aim ................................................................................................................................................................ 1
Description ................................................................................................................................................. 2
Method ......................................................................................................................................................... 3
Guidance ..................................................................................................................................................... 4
Hazard Checklists .................................................................................................................................... 7
Functional Safety Analysis ................................................................................................................. 11
FMEA/FMECA ......................................................................................................................................... 16
SWIFT......................................................................................................................................................... 23
HAZOP ....................................................................................................................................................... 37

Introduction
Hazard Identification has been defined as: “The process of identifying and
listing the hazards and accidents associated with a system.”

Hazard Analysis has been defined as: “The process of describing in detail the
hazards and accidents associated with a system and defining accident
sequences.”

Preliminary Hazard Identification and Analysis (PHIA) is intended to help you

determine the scope of the safety activities and requirements. It identifies the main
hazards likely to arise from the capability and functionality being provided. It is
carried out as early as possible in the project life cycle, providing an important early
input to setting Safety requirements and refining the Project Safety Plan.

PHIA seeks to answer, at an early stage of the project, the question: “What
Hazards and Accidents might affect this system and how could they
happen?”

Aim
The aim of the PHIA is to identify, as early as possible, the main Hazards and
Accidents that may arise during the life of the system. It provides input to:

a. Scoping the subsequent Safety activities required in any Safety Plan. A

successful PHIA will help to gauge the proportionate effort that is likely to
be required to produce an effective Safety Case, proportionate to risks.
b. Selecting or eliminating options for subsequent assessment.

1
 Preliminary Hazard Identification & Analysis Guide

c. Setting the initial Safety requirements and criteria.

d. Subsequent Hazard Analyses.
e. Initiate Hazard Log.

Description
A PHIA should be performed as early as possible in order to obtain maximum
benefit by understanding what the Hazards and Accidents are, why and how they
might be realised.

A PHIA is an important part of Risk Management, project planning and

requirements definition as it helps to identify the main system hazards and helps
target where more thorough analysis should be undertaken. The relationship of
this activity with other Risk Management activities is illustrated below:

(Note that SMP stands for ‘Safety Management Procedure’.)

Usually PHIA is based on a structured brainstorming exercise using Hazard

Analysis techniques such as SWIFT (Structured What-If Technique), supported
by hazard checklists. A structured approach is necessary to minimise the
possibility of missing an important hazard, and to demonstrate that a thorough
and comprehensive approach has been applied.

2
 Preliminary Hazard Identification & Analysis Guide

Method
The capability and concept of use as set out in the requirements must be
reviewed, and potential hazards identified. This preliminary list of hazards should
then be assessed for likely impact. From this, the regulatory requirements as well
as any standards, with which the system will have to comply, might be judged.

Techniques

The form, nature and depth of the PHIA should be proportionate to the
complexity and significance of the project, considering any safety-related
functionality. There are a number of Hazard Analysis/Identification techniques
that may be used:

a. Hazard Checklist;
b. Accident and History Review;
c. Functional Failure Analysis (FFA)1;
d. Functional Failure Mode and Effects Analysis (FMEA);
e. Structured What If Technique (SWIFT); and
f. Hazard and Operability Study (HAZOP).

Different approaches and techniques are more suited to different systems and no
single approach is likely to be sufficient on its own. Usually a combination of
complementary techniques should be used in order to maximise the
proportion of hazards identified.

Records and Documentation

The Hazard Log is the primary mechanism for recording all Hazards identified
through PHIA. It is a live database or document, updated with the results of each
Hazard Analysis as they become available.

The results of the PHIA should be reported in a form which records the following:

a. The input information used;

b. The approach adopted;
c. The people consulted; and

1 Also known as Functional Safety Analysis.

3
 Preliminary Hazard Identification & Analysis Guide

d. The Hazards, Accidents and Accident Sequences identified.

These results may form part of a Safety Case body of evidence and may be
recorded in a standalone report or as part of a wider report on Safety (e.g. a Safety
Assessment Report or Safety Case Report).

Guidance
Hazard Analysis is fundamental to System Safety Management. If you do not
identify a Hazard, you can take no specific action to remove it, or
reduce the risk of the Accident(s) associated with it. Absence of a systematic
and comprehensive PHIA activity can thus severely undermine the Risk
Evaluation process.

Hazards are diverse, and many different techniques are available for hazard
identification and PHIA. While some techniques have become standard for
particular applications, it is not necessary or desirable to specify which approach
should be adopted in particular cases. The mix of techniques should be chosen to
meet the objectives as efficiently as possible given the available information and
expertise.

PHIA is usually a qualitative exercise based primarily on expert judgement. Most

PHIA exercises involve a group of experts, since few individuals have expertise on
all hazards, and group interactions are more likely to stimulate consideration of
hazards that even well-informed individuals might overlook. The techniques most
suitable for group PHIA activities are:

a. Functional Failure Analysis (FFA);

b. Structured What If Technique (SWIFT); and
c. Hazard and Operability Study (HAZOP)

In either case hazard checklists and history of similar systems should be available
as inputs.

Although FFA, SWIFT and HAZOP methods are systematic, creative

examinations by a multi-disciplinary team, they are dependent on different levels
of system information. As such, the most appropriate technique should be
selected for any particular system, in order that the Hazard Identification process
is effective.

4
 Preliminary Hazard Identification & Analysis Guide

Alignment with Environmental Protection

The key alignment opportunity here is to cross reference Environmental Features

against Safety Hazards, so that common issues are identified and where possible
assessed together, and to also to ensure that the potential environmental impact
of a safety hazard, or a safety impact of an environmental hazard are not
overlooked.

It is also important to plan and conduct assessment studies which can meet both
safety and environmental evaluation requirements. Where this is not possible,
alignment should help ensure that results of safety assessments are reviewed for
environmental implications and vice versa.

Guidance for Different Acquisition Strategies

Where the project involves a mid-life update, existing history will obviously
provide a major input to the process. Similarly, where the project is likely to
involve Commercial-Off-The-Shelf solutions the existing history of these
solutions provides a starting point. However, in all these cases there is still a need
to carry out PHIA to determine if any new Hazards are introduced by the
proposed use in a new context, through particular safety-related functionality,
new interfaces, different support and usage environments, different operational
employments, etc.

Warnings and Potential Project Risks

It is essential the appropriate team of experts are used in the PHIA process, who
together can provide a sound understanding of:

a. The System description, its boundaries, together with its interactions with
its Environment, including systems with which it interfaces and is
dependent upon;
b. Operational profiles, maintenance, operator competencies within a given
Functional Environment;
c. The application and limitations of the selected HAZID techniques;
d. The existing and/or commonly known Hazards of this or similar systems;
e. Validity of historical data adjusted to account for its context.
f. If the team contributing to the PHIA do not contain this expertise, then it
is likely that some significant hazards will be missed.

5
 Preliminary Hazard Identification & Analysis Guide

A Hazard checklist is useful for most Risk Evaluations, but should not be the only
PHIA method, except for standard installations whose hazards have been studied
in more detail elsewhere.

When identifying Hazards, the scope should not be restricted to the steady-state
operation, but consider all aspects of the Systems Life cycle, from installation to
final decommissioning and disposal, including Maintenance and Upgrades.
Emergency scenarios and associated Contingency Modes of Operation should also
be considered.

If the PHIA is not carried out early enough, there is a risk that unrecognised
hazards or requirements will be discovered later in the project, by which time it
may be more difficult to eliminate or mitigate them.

6
 Preliminary Hazard Identification & Analysis Guide

Hazard Checklists
This guidance contains information which can be used to generate Hazard
Checklists for use in the conduct of PHIA to identify possible Hazards and
Accidents which might be associated with a system. Any Hazard checklist must be
used in a “brainstorming”, imaginative way to stimulate discussions between
stakeholders who have a good understanding of the system, its context and
usage/maintenance environment. Checklists application in a narrow way or by
those with a vague appreciation of the system will be very much less effective.

General Hazard Checklist

The following headings provide a basis for the compilation of checklists to assist
Preliminary Hazard Listing and Preliminary Hazard Analysis. The contents of the
annex are not exhaustive. The objective is to identify hazards, their direct and
indirect causes, and significant contributing factors.

Hazardous components, e.g.:

a. Flammable substances; e.g. solid, liquid or gaseous.

b. Lasers.
c. Explosives.
d. Asphyxiants, toxic or corrosive substances.
Remember that
e. High temperature or cryogenic fluids.
checklists are good
f. Hazardous construction materials.
for identifying
g. Pressure systems.
CAUSES of hazard
h. Electrical sources.
rather than the
i. Ionising and non-ionising radiation sources.
hazards
j. Hydraulic arms or rotational machinery.
themselves!
k. Other energy sources including those due to
motion.
l. Exhaust gases.
m. Passive obstacles.
n. Hazardous surfaces.
o. Cut and puncture projections.

Safety related interfaces between the various elements of the system, e.g.:

7
 Preliminary Hazard Identification & Analysis Guide

a. Material compatibilities.
b. Electromagnetic interference and compatibility.
c. Inadvertent activation.
d. Fire and explosion initiation and propagation.
e. Hardware and software controls.

Factors due to the operating domain, or that the system may add to the operating
domain, e.g.:

a. Drop.
b. Shock and vibration, including seismic.
c. Extreme temperatures, pressures and climatic conditions.
d. Noise.
e. Exposure to toxic or corrosive substances.
f. Fire or explosion.
g. Insect, rodent or mould damage.
h. Foreign bodies and dust.
i. Electrostatic discharge including lightning.
j. Electromagnetic interference.
k. Ionising and non-ionising radiation, including laser radiation.
l. Faults in supporting systems, e.g. power supplies, hydraulic systems.
m. Exhaust gases.

Operating, test, maintenance and emergency procedures, e.g.:

a. Operation under peace, exercise, war.

b. Human factors considerations.
c. Adequacy and effectiveness of instruction, training and rehearsal.
d. Health hazards.
e. User error, including failure to activate.
f. Effect of factors such as equipment layout, ergonomics and lighting.
g. Potential exposure to toxic materials, noise and radiation.
h. Life support systems.
i. Crash safety, egress, rescue and survival.
j. Repair and salvage.

8
 Preliminary Hazard Identification & Analysis Guide

Enemy action, e.g.:

a. Hostile acts.
b. Inaction of active protective systems.
c. Ineffectiveness of passive protective systems.
d. Damage containment.

Damage control measures, e.g.:

a. Damage containment.
b. Damage repair.
c. Hazard containment.
d. Egress, rescue and survival.

Facilities, e.g.:

a. Support equipment.
b. Training.
c. Provisions for storage of hazardous material.
d. Provisions for assembly of hazardous material.
e. Provisions for proof testing of hazardous material.

The adequacy of safety related equipment, safeguards and failure containment

measures, e.g.:

a. Fire suppression systems.

Note that failures of
b. Relief valves.
controls should be
c. Energy containment vessels.
modelled as
d. Electrical protection.
imperfect controls,
e. Toxic substance control.
not hazards in their
f. Electrical, air and hydraulic supplies.
own right.
g. Personal protective equipment.
Otherwise you can
h. Ventilation.
i. Noise or radiation barriers.
go round in circles!
j. Alarms and warnings.

9
 Preliminary Hazard Identification & Analysis Guide

The defences against common mode failure, e.g.:

a. Systems redundancy and diversity.

b. Interlocks.
c. Fail safe design.

Compliance with systems safety guidelines and standards, e.g.:

a. Understanding of systems by personnel.

b. Incident recording and monitoring, including “near misses”.
c. Operator deviation.
d. Design deviation.
e. Deviation in supervision and checking.
f. Component substitution.

Threats to programmable electronic systems, e.g.:

a. Viruses.
b. Security breaches.

10
 Preliminary Hazard Identification & Analysis Guide

Functional Safety Analysis

Description of the technique, including its purpose

Functional Safety Analysis, also known as Functional Failure Analysis, is

an approach that assesses all the system functions to determine the hazards
associated with what the system does.

The purpose of Functional Safety Analysis is to identify hazards associated with

both the correct and incorrect operation and non-operation of the system, lower
level functions and human functions.

Functional Safety Analysis should be applied to all functions, including those

listed below, and should be carried out to the lowest level functions identified in
the design:

 Principal Functions;
 Subsidiary and Non-obvious Functions;
 Warning Functions;
 Warnings that provide operator indications and controls;
 Functions that protect against hazards;
 Functions provided by human operator; and
 Functions that moderate the effects of failure of other
functions.

Functional Safety Analysis should examine all functional failures that may give
rise to credible hazards, including:

 Those following directly from the behaviour of the function or

component being evaluated;
 Those due to the effects on another connected function or
component (e.g. hazards due to the loss of an oil cooling
function); and
 Those due to indirect influence (e.g. hazards due to the
generation of electro-magnetic interference (EMI) by a
component when it has failed).

The first step of Functional Safety Analysis is to create a functional representation

of the system, defining the purpose and behaviour of all functions. It is also
necessary to define the operational phase of the system, since the effect of a
system failure will depend on what the system is doing at the time. All phases of
operation should be included; these will include maintenance and emergency
phases if applicable.

For each identified function, a set of failure conditions, based on the aspects
below should be defined:

11
 Preliminary Hazard Identification & Analysis Guide

 Normal performance: What hazards might be associated

with the normal operation of the system functions?
 Specific degraded performance: What hazards are
introduced if the system is functionally degraded but still
active, for example reduced performance from a ventilation
system.
 Incorrect functioning, including inadvertent
functioning: An example might be a Radhaz transmission
failure, as a result of a physical failure of the interlock, resulting
in the radar transmitting when not expected.
 Absence of function: There may be, for example, a loss of a
function which may result in the inability of the system to
complete a required task, or part of that task (such as being able
to turn a ship to Port but not to Starboard).
 Human error: This may be due to such factors as stopping
an activity too soon or performing the right activities, but in the
wrong order.
 Mis-timing of the function occurring, that is, sequencing
too early or too late.

For each of the operational phases, the effects of the failure conditions upon the
system should be assessed in order to determine, record (and verify) associated
risk factors (severity and probability). Functional Safety Analysis can be
supported by a functionally based Failure Modes Effects and Critical Analysis
(FMECA) or Fault Tree Analysis (FTA).

When it might be used

Functional Safety Analysis should be performed once the required functions have
been defined and it should be refined as the implementation of the functions
develops. It is therefore an iterative activity that can be refined throughout the
project lifecycle as more detail on system functions and sub-functions becomes
available.

Advantages, disadvantages and limitations to the defence sector or the

particular domain

Advantages

 Functional Safety Analysis provides an approach for

identifying system hazards at an early stage in the procurement
cycle when the means of realising functions (e.g. hardware,
software or human action) has not been defined.
 Functional Safety Analysis can be used to concentrate effort on
critical areas of the system early in the development, leading to
fundamental decisions such as whether to use software to
realise a function and where redundancy is appropriate.
 Appropriate Safety requirements, including Safety Integrity
Levels, can be derived through Functional Safety Analysis.

12
 Preliminary Hazard Identification & Analysis Guide

 The process can be applied to both software and hardware

functions.

Disadvantages

 Functional Safety Analysis is not good at examining hazards

which relate to system components or system location. It must
therefore be used in combination with other techniques.
 The value of Functional Safety Analysis is dependent on the
quality of the functional description of the system. If subsidiary
or non-obvious functions are not in the functional description,
the hazard identification may be incomplete.
 Environmental conditions may alter the effects of failure and
may need to be considered e.g. the effects of the loss of “anti-
lock” on a car’s brakes may be more serious on wet or icy roads.
 Domain specific knowledge is required to effectively perform
Functional Safety Analysis.
 Any interdependence or inter-relationship of system functions
needs to be carefully identified so that they are accounted for
in the analysis.

Sources of additional information. Standards, textbooks & web-sites.

Additional reading on the technique can be found in SAE-ARP-4761 and IEC

61508 (Functional Safety of Electrical/Electronic/Programmable Electronic
Safety-related Systems).

Functional safety and IEC 61508: A basic guide. Copyright IEC - The
International Electrotechnical Commission.

Example (Based on ARP 4761 Appendix L). An aircraft may be assessed as having
the following operational functions:

 Control Thrust
 Control Flight Path
 Determine Orientation
 Determine Heading & Position
 Control Aircraft on the Ground
 Control Cabin Environment

The function “Control Aircraft on the Ground” can be divided into a number of
lower level functions including “Decelerate Aircraft on the Ground”. The
functional failure condition considered in this example is loss of deceleration
capability (other functional failures could be “reduced deceleration capability” or
“inadvertent deceleration”). The phases of operation where deceleration of the
aircraft on the ground is required are: Taxi, Landing, and Rejected Take-off.

13
 Preliminary Hazard Identification & Analysis Guide

The example is documented below in a Functional Block Diagram (FBD) format

similar to the FMECA. The example references Failure Condition Severity
Classifications and Probabilities, which should be defined.

14
 Example data sheet:

Function Failure Phase Effects of Failure Classification References Verification /

Condition on Aircraft / Crew (Severity) Target
(Hazard Probability
description)
Crew unable to
1a. Unannounced Landing /
decelerate aircraft Aircraft Fault
loss of deceleration Rejected Catastrophic
resulting in high speed Tree
capability. Take Off
overrun.
Crew unable to stop the
aircraft on the taxi way
1b. Unannounced
or gate, resulting in low Remote (1.0 E-5
Decelerate loss of deceleration Taxi Major
speed contact with or better
Aircraft on capability.
terminal, aircraft or
the Ground.
vehicle.
Crew selects more
suitable airport, notifies Emergency landing
1c. Unannounced
emergency ground procedures in case Aircraft Fault
loss of deceleration Landing Hazardous
support and prepares of loss of stopping Tree
capability.
occupants for a landing capability.
overrun.
1d. Unannounced
Crew steers the aircraft Frequent (1.0 or
loss of deceleration Taxi No safety effect
clear of any obstacles. better)
capability.

15
FMEA/FMECA

A description of the technique, including its purpose

Failure modes and effects analysis (FMEA) was one of the first systematic techniques for
failure analysis. It was developed in the United States military (Military Procedure MIL-P-
1629, titled ‘Procedures for Performing a Failure Modes, Effects and Criticality Analysis’,
November 9, 1949) as a reliability evaluation technique to determine the effect of system
and equipment failures. Failures were classified according to their impact on mission
success and personnel, equipment and safety. In the 1960’s it was used by the aerospace
industry and NASA during the Apollo program. More and more industries - notably the
automotive industry - have seen the benefits to be gained by using FMEAs to complement
their design processes.

This qualitative technique helps identify failure potential in a design or process i.e. to
foresee failure before it actually happens. This is done defining the system which is under
consideration to ensure system boundaries are established and then by following a
procedure which helps to identify design features or process operations that could fail. The
procedure requires the following essential questions to be asked:

 How can each component fail?

 What might cause these modes of failure?
 What could the effects be if these failures did occur?
 How serious are these failure modes?
 How is each failure mode detected?
 What are the safeguards in place to protect against accidents resulting
from the failure mode?

As an aid in structuring the analysis and ensuring a systematic approach, results are
recorded in a tabular format. Several different forms are in use, and the form design can be
tailored-made to suit the particular requirements of a study. Examples of forms can be
found in BS5760 and HSE Marine Risk Assessment Report.

The FMEA analysis can be extended if necessary by characterising the likelihood, severity
and resulting levels of risk of failures. FMEAs that incorporate this criticality analysis (CA)
are known as FMECAs. A FMECA is an analytical quantitative technique which ranks
failure modes according to their probability and consequences (i.e. the resulting effect of
the failure mode on the system, mission and personnel). It is referred to as a “bottom-up
approach” as it starts by identifying the potential failure modes of a component and
analysing their effects on the whole system. It can be quite complex depending how the
user drives the technique.

It is important to note that the FMECA does not provide a model by which system
reliability can be quantified. Hence, if the objective is to estimate the probability of events,
a technique which results in a logic model of the failure mechanisms must be employed,
typically a fault tree and/or an event tree.

16
 Preliminary Hazard Identification & Analysis Guide
A FMEA or FMECA can be conducted on either a component or a functional level. A
functional FMEA/FMECA only covers hardware aspects but a functional FMEA/FMECA
can cover all aspects of a system. For either approach the general principle remains the
same.

When it might be used

FMEA is applicable for any well-defined system but is primarily used for reviews of
mechanical and electrical systems. It can be used in many situations, for example, to assess
the design of a product in terms of what could go wrong in manufacturing and in service as
a result of the weakness in design. It can also be used to analyse failures in the
manufacturing process itself and during service. It is effective for collecting information
needed to troubleshoot system problems and improving maintenance and reliability of
plant and equipment (defining and optimising) as it focuses directly and individually on
equipment failure modes.

The FMECA technique is best suited for detailed analysis of system hardware, and should
preferably be carried out by the designer in parallel with system development. This will not
only speed up the analysis itself, but also force the design team to think systematically
about the failure characteristics of the system. The primary use of the FMECA is in
verifying that single component failures cannot cause catastrophic system failure.

There are a number of areas today in which the use of FMECA has become mandatory to
demonstrate system reliability. Examples of such requirements are in classification of
Dynamically Positioned (DP) vessels and in a number of US military applications for which
MIL-STD documents apply.

Advantages, disadvantages and limitations to the defence sector or the

particular domain

Advantages

 It is widely-used and well-understood, and easy to understand and

interpret
 It can be performed by a single analyst, or more if required
 Qualitative data about the causes and effects can be incorporated into
the analysis
 It is systematic and comprehensive, and should identify hazards with an
electrical or mechanical basis
 The level of detail incorporated can be varied to suit the analysis
 It identifies safety-critical equipment where a single failure would be
critical for the system
 Even though the technique can be quite time consuming it can lead to a
thorough understanding of the system being considered

17
 Preliminary Hazard Identification & Analysis Guide
Disadvantages

 The technique adopts a bottom-up approach and if conducting a

component level FMEA or FMECA this can be boring and repetitive
 The benefit gained is dependent upon the experience of the analyst or
the group.
 It requires a hierarchical system drawing as the basis for the analysis,
which the analyst usually has to develop before the FMEA process can
start
 It is optimised for mechanical and electrical equipment, and does not
apply easily to Human Factor Integration, procedures or process
equipment
 It is difficult for the technique to cover multiple failures as equipment
failures are generally analysed one by one therefore important
combinations of equipment failures may be overlooked
 Most accidents have a significant human or external influence
contribution and these are not a usual failure mode with FMEA
 More than one FMEA may be required for a system with multiple modes
of operation
 Due to its wide use there can be temptation to read across data from
ARM or ILS projects where, for example, the fault-tree technique has
been used. As a consequence, the safety perspective can be lost as human
error has been excluded and the focus has been solely on determining
faults and on not on more far-reaching safety issues
 Perhaps the worst drawback of the technique is that all component
failures are examined and documented, including those, which do not
have any significant consequences.
 For large systems, especially those with a fair degree of redundancy built
into them, the amount of unnecessary documentation is a major
disadvantage. Hence, the FMECA should primarily be used by designers
of reasonably simple systems. It should however be noted that the
concept of the FMECA form can be quite useful in other contexts, e.g.
when reviewing an operation rather than a hardware system. Then the
use of a form similar to the FMECA can provide a useful way of
documenting the analysis. Suitable columns in the form could for
example include; operation, deviation, consequence, correcting or
reversing action, etc.

Sources of additional information, such as Standards, textbooks and web-

sites

BS 5760: Part 5 Reliability of Systems, Equipment and Components: Part 5 Guide to

Failure Modes, Effects and Criticality Analysis.
HSE Website - Marine Risk Assessment, Offshore Technology Report 2001/063
IET - Health and Safety Briefing 26a - Quantified risk assessment techniques – Part 1
(failure modes and effects analysis – FMEA).

18
 Preliminary Hazard Identification & Analysis Guide

A simple example of an FMEA/FMECA

An example extract from an FMEA of a ballast system is shown below. This can be found in
the HSE Marine Risk Assessment Report. The column headings are based on the US
Military Standard Mil Std 1629A, but with modifications to suit the particular application.
For example, the failure mode and cause columns are combined. The criticality of each
failure is ranked as minor, incipient, degraded or critical.

19
 Preliminary Hazard Identification & Analysis Guide

Filling ballast tanks under gravity

Mitigation /
System/
Compensation / Overall
Ref Equipment Cause Effect Detection Overall assessment
System Response criticality
Failure
/ Safeguards

Valve position In a worst case where

indicators. failure was not acted
Tanks do not full. i. Clean chest with upon quickly then a
Ballast tank level steam
Reduced stability, degraded state could
1BF Sea Chest 1. Blocked radar/sounding D
change of heel/trim ii. Redundancy 3 arise where the
system.
increased hull stresses other sea chests ballasting operation of
If severe, angle of several tanks could be
heel/trim. affected

Ingress of foreign Valve position

bodies possible indicators. In a worst case where
blockage of control failure was not acted
2. Loss of valves and suction Ballast tank level i. Clean chest with upon quickly then a
sea chest piping. Tanks do not radar/sounding steam degraded state could
1BF Sea Chest system. D
grid fill. Build-up of debris ii. Redundancy 3 arise where the
integrity in system. Reduced If severe, angle of other sea chests ballasting operation of
stability, change of heel/trim. several tanks could be
heel/trim increased affected
hull stresses.

Valve position
i. Clean chest with Overall effect
indicator.
1. Partial steam considered incipient
2BF Sea Chest Reduced filling rate. Ballast tank level I
Blockage ii. Redundancy 3 due to detection ability
radar/sounding and redundancy
other sea chests
system.

20
 Preliminary Hazard Identification & Analysis Guide

i. Continuously
pumped to maintain
Valve position correct level.
Loss of ballast control indicator. Loss of control in a tank
1. Leak at ii. Isolate with sea
3BF Sea Chest in affected tank. Ballast tank level chest blanks. is considered as D
sea chest
Change of heel/trim. radar/sounding degraded
system. iii. Equalises to
exterior sea height
in affected tank.

21
 Preliminary Hazard Identification & Analysis Guide

Additional comments (e.g. Computer tools available, related techniques,

different names)

Failure Modes and Effects and Criticality Analysis (FMECA) is an analytical QRA
technique, used by ARM and ILS systems engineers, most commonly and effectively at the
late design, test and manufacture stage of a project. It requires the breakdown of the
system into individual components and the identification of possible failure modes or
malfunctions of each component, (such as too much flow through a valve). Referred to as a
bottom up approach, it starts by identifying the potential failure modes of a component
and analysing their potential effects on the whole system. Numerical levels can be assigned
to the likelihood of the failure and the severity or consequence of the failure.

Note: It is important to recognise that FMEA/FMECA Standards have different

approaches to criticality. Failure mode severity classes 1 – 5 for Standards MIL1629A and
ARP926A go from Class 1 being the most severe (e.g. loss of life) to Class 5 being less
severe (i.e. no effect), whereas BS 5760 deals with criticality in the opposite direction
where Class 5 is the most severe.

22
 Preliminary Hazard Identification & Analysis Guide

SWIFT

A description of the technique, including its purpose

The Structured What-If Checklist Technique (SWIFT) combines the use of checklists with
a brainstorming ‘What if?’ approach. It was initially developed for hazard identification in
the chemical process industry. The technique was developed as an efficient alternative to
HAZOP for providing highly effective hazard identification in situations and systems where
HAZOP is not appropriate. SWIFT can also be used in conjunction with or complementary
to a HAZOP.

The Structured What-If Checklist is a thorough, systematic, multi-disciplinary team

orientated analytical technique. Whereas, HAZOP examines the facility item-by-item,
procedure-by-procedure, etc. by applying guidewords, SWIFT, on the other hand, is a
systems-oriented technique which examines complete systems or subsystems. To ensure
comprehensive identification of hazards, the technique relies on a structured
brainstorming effort by a team of experienced experts which is supported by
supplementary questions from a specifically developed checklist. It requires specialists,
who have the domain knowledge required of the area being considered, to evaluate the
consequences of hazards that might result from the various potential failures or errors they
have identified. When answering all the questions raised about realistic deviations from
the normal intended operation of a system, design or operation, the team assesses the
likelihood of an incident, the potential consequences and the adequacy of safeguards to
prevent or mitigate it.

Its effectiveness in identifying hazards comes from asking questions in a variety of

important areas, according to a structured plan. The aim is to ensure complete coverage of
all the various types of failures or errors which are likely to result in a hazard within the
system being examined.

The “What-if?” questions, which can be posed by any team member (including the SWIFT
leader and Recorder) are structured according to various question categories. The SWIFT
analysis is further strengthened through the use of category specific checklists at the
conclusion of each question category resulting in an additional level of thoroughness.
Information resulting from the SWIFT meeting is recorded on log sheets in columns as
“What If”, “Consequences”, “Existing Safeguards” and “Recommendations”.

When it might be used

SWIFT is generally applicable for almost every type of risk assessment application,
especially those dominated by relatively simple failure scenarios. It can be used alone, but
most often used to supplement other, more structured techniques.

23
 Preliminary Hazard Identification & Analysis Guide
Advantages, disadvantages and limitations to the defence sector or the
particular domain
Advantages

 The technique is efficient because it generally avoids lengthy discussions

of areas where hazards are well understood or where prior analysis has
shown no hazards are known to exist.
 It is very flexible, and applicable to any type of installation, operation or
process, at any stage of the lifecycle.
 It is quick, because it avoids repetitive consideration of deviations.
 It uses the experience of operating personnel as part of the team.
 If the subject matter experts are not available for the SWIFT session
their questions can be gathered in advance and included in the checklist.
 The checklists used are robust as the questions asked intuitively cover
historical incidents that have happened in the past

Disadvantages
 Adequate preparation of a checklist in advance is critical to achieve
completeness.
 Its benefit depends on the experience of the leader and the knowledge of
the team.
 SWIFT relies exclusively on the knowledge of the participants to identify
potential problems. If the team fails to ask important questions, the
analysis is likely to overlook potentially important weaknesses.
 Reviewing a what-if analysis to detect oversights is difficult because
there is no formal structure against which to audit.
 Most what-if reviews produce only qualitative results; they give no
quantitative estimates of risk-related characteristics. This simplistic
approach offers great value for minimal investment, but it can answer
more complicated risk-related questions only if some degree of
quantification is added (for example using Risk Matrices).

Sources of additional information, such as Standards, textbooks and web-sites

US Coast Guard Website - www.uscg.mil/hg/cgs/cgs211/risk.asp

HSE Website - Marine Risk Assessment, Offshore Technology Report 2001/063
- http://www.hse.gov.uk/research/otohtm/2001/oto01063.htm

24
 Preliminary Hazard Identification & Analysis Guide
Additional comments
Question Categories

Typical question categories that could be used are:

 External Factors or Influences
 Operating Errors and Other Human Factors
 Maintenance
 Measurement Errors
 Equipment/Instrument Malfunction
 Loss of Integrity
 Emergency Operations
 Utility Failures
 Environmental and Health

Sample Checklist

The basic structure of the SWIFT system as developed originally for the process industry
translates well to the marine industry. Some changes to topic list are necessary, but these
are not extensive. The following list provides a starting point for the derivation of a
checklist for a specific problem or range of problems.

This list would be extended by accident reviews, task analysis, codes and standards, and
legislation. In the area of accident reviews, often the classification system of the accident
database can be helpful in generating checklist questions. These words are helpful to the
team in brainstorming causes of hazardous events.

Checklists should not be handed out to experts involved in the brainstorming and should
be kept for prompting by the SWIFT Leader.

External Factors or Influences

Natural:
 Strong wind
 Fog/reduced visibility
 Flood
 Heat
 Cold
 Humidity (wet/dry)
Human caused - security issues:

 Vandalism
 Fire (accidental or arson)
 Bomb threat

25
 Preliminary Hazard Identification & Analysis Guide
 Crowd problems/civil disturbance,
 Sabotage

Operating Errors and Other Human Factors

This section is too broad to derive a specific checklist in advance. It requires the specific
situation to be analysed in advance with respect to the types of topics and influences
described below. This would be assisted by reference to a task analysis or accident review.

 Base and vessel crew – manning levels

 Task characteristics, information and workload
 Errors (slips, lapses, mistakes) and violations
 Ergonomics and work environment
 Training and competence
 Management, organisation – shift patterns, procedures, Personal
Protective Equipment
 Work practices (permits, testing, maintenance, inspections)

Maintenance
Hand-overs and controls:

 Activity physical boundaries/responsibilities

 Access authorisations/contractor issues
 Communication of information at hand-overs
Inspection and Testing:

 Material problems
 Access and safety
Maintenance:

 Procedures and permits

 Hot work, confined space entry
 Electrical protections (e.g. 110 V, 220 V, other)
 Scaffolds
 Crane lifts
 Monitoring/inspections/approvals

Measurement Errors
 Navigational systems
 Mechanical/electrical systems

26
 Preliminary Hazard Identification & Analysis Guide
Equipment/Instrument Malfunction
 Structure
 Machinery systems
 Navigational equipment
 Platform management systems and bridge systems

Loss of Integrity
 Hull
 Superstructure
 Tanks/vessels

Emergency Operations
Procedures:
 Clear definitions of emergencies
 Implications for operations
 Communications
 Changed roles, specific duties conflicts, equipment, etc.
 Night, poor weather, etc

Utility Failures
Air failure:
 Combustion
 Heating and ventilation
Water failure:
 Firewater
 Cooling water
 Drinking water
 Sanitation
Effluent system failure:
 Sewage system
Communications:
 Local communications, on board ship
 External communications, to other ships, within the MOD
Other utility issues:
 Mixing new utilities with old

Environmental and Health

27
 Preliminary Hazard Identification & Analysis Guide
Water contamination:
 Cargo spillage (dangerous goods - fuels, chemicals, pesticides,
explosives)
 Storage (temporary/permanent)
 Disposal
Air:
 Dust and fumes
 Noise and vibration
Health Issues:
 Potential for injuries (accidental)
 Potential for injuries (chronic)
 Healthcare provisions
A simple example of a SWIFT study log-sheets
Log-sheets for a SWIFT study of the fuel transfer operation:

Revision: 0 Node: 001 Page: 1

Project: Fuel Transfer System Date: Time:

Session: 0 Team:

Leader:
Recorder:
Node Description:
Ship to Ship Fuel Transfer Operation Organisation: XYZ

Location: Various

Design Intention:
To transfer fuel from the tanker storage to the
ship storage tank.

Normal Process Conditions (Range):

Temperature: Ambient P&ID's Rev #'s
Pressure: Negative static head from tanker, 3
bars maximum at pump discharge. Storage
tanks are at atmospheric pressure. Capacity of
tanker is 50 m3, ship tank is 20 m3.
Flow rate: 500 litres per minute

Team Members:

28
 Preliminary Hazard Identification & Analysis Guide

Project: Fuel Transfer System Node: 001 Page: 2

Node Description:
Ship to Ship Fuel Transfer Operation

Question Rec Recommendation

What If Consequences Safeguards
Category #

Transfer is not carried

Potential
out in > force 4. A gap
External collision
of 50 metres is
Factors or Heavy sea. between tanker
maintained between
Influences and receiving
the ships during
ship.
transfer.

Ensure that
Operator
destination fuel
connects
Operating tank is correctly
up to the
Errors and Possible overfill configured
wrong Operator training and
other of ship storage R1 before starting
tank on competence.
Human tank. transfer. This
the
Factors should be
receiving
independently
ship.
checked.

Inspection and testing Provide actuated

of hoses. Visual valves on the fuel
Discharge of
inspection before delivery and
fuel on tanker or
use. 6 monthly test as receipt points
receiving
Hose part of planned (i.e. on each
ship. Potential R2
ruptures maintenance. Operato ship) such that
fire and
r can stop the transfer the fuel supply
pollution
pump locally and can be quickly
incident.
isolate using the isolated in the
manual valves. event of a spill.
Loss of
integrity
Check that fuel
transfer pumps
Discharge of are not cast iron
Pump fuel on (cast iron pumps
casing fails tanker. Potentia Annual pump have been found
R3
due to cold l fire and inspection. to crack in cold
weather. pollution weather). If the
incident. pump is cast iron
it should be
replaced.

Tanker and/or Review the

Emergenc Tanker or Possible hose design of the
receiving ship would
y ship has to rupture and hose connections
instruct for hoses to be R4
Operation manoeuvr discharge of and if necessary
disconnected before
s e in fuels (fire and modify so that
manoeuvring.
hoses can be

29
 Preliminary Hazard Identification & Analysis Guide

emergency pollution quickly

. incident). disconnected if
needed in an
emergency.

30
 Preliminary Hazard Identification & Analysis Guide

Planning and conducting a SWIFT session

Planning and Preparation

A team comprised of 4 to 8 members including the SWIFT Leader and technical Recorder is
recommended. At a minimum, the team should consist of one or more persons who have
expertise in vessel technical issues (naval architect, marine engineer, etc.) and one or two
who have relevant operating experience (Captain, Navigation Officer, etc.). Depending upon
the precise nature of the system or the change being examined, additional team members
might include representatives from maintenance, instrumentation, quality control, safety,
and other disciplines.

The SWIFT Leader should compile a checklist of issues relating to the system based on
legislation, accident / incident reports, standards, guidance documents, existing checklists,
task analysis, etc. and circulate it to all the team members for review prior to the first session.

The reference documents necessary for conducting a SWIFT review are identical to those
required for HAZOP. Just as with a HAZOP, the more comprehensive and up-to-date the
data available to the team, the more efficient and effective the analysis.

In contrast to HAZOP, the leader of a SWIFT review does not have to refrain from
participation in the team discussion. This is because the Leader may have been actively
involved in generating the checklist. Depending upon the circumstances, a leader with a high
level of expertise in the system can benefit the efficiency and effectiveness of the study.
However, the leader should have SWIFT leadership training so he/she can recognise the
importance of issues, control the flow of the study, and keep it on track. Also, he/she must
still be careful to ensure that he/she does not assert undue influence over the direction and
outcome of the proceedings, particularly because he/she is now a “participant”.

For studies of narrow scope, it is also acceptable for the SWIFT leader to double as the
technical Recorder. However, if a study is likely to last longer than a half a day, it would
probably be more efficient and effective if the proceedings are transcribed by qualified
individual other than the SWIFT leader. The significant danger of combining the roles of
SWIFT leader and Recorder is that incomplete minutes will be obtained due to time
pressures. In normal circumstances it is routine for the Recorder to be typing the last
discussion minutes, while the team moves on to the next item.

Initial Discussions

Once the preparations are completed and the SWIFT team assembles, the leader should
spend a brief period of time reminding or training the team as necessary in how the SWIFT
analysis will be conducted. Next he or she should orient the team to the basics of the design
or system under review.

31
 Preliminary Hazard Identification & Analysis Guide
In many cases, the study is likely to involve the analysis of a proposed change in some part
of the process or its mode of operation. If such is the case, the details of that change should
be discussed. To ensure compliance with Management of Change procedures, this pre-
analysis discussion should focus on, but not be limited to:

 The technical reason or basis for the change.

 The expected impact the change might have on safety and health.
 The need to change or modify operating procedures / training.
 The intended duration of the change and if possible an estimate of how
long its start-up is likely to take.

As a result of this discussion, the scope and objectives of the study can then be established.
At a minimum these should include setting the boundaries of the system(s) to be examined,
specifying the types of on site and off site issues of concern (safety, health, environment,
quality, productivity), and clearly defining any other objectives of interest to the
organisation.

Selecting a Study Section

As necessary, the system to be examined should be divided into an appropriate number of

smaller subsystems. Examining the unit at a systems level often makes it easier to recognise
interactions of various components within the system or with other systems in the
processing unit. However, since each item of equipment is not being individually treated as
in a HAZOP, caution should be exercised – it is preferable to err on the side of caution and
be too detailed rather than miss something critical. Usually, a team should be able to
examine unit/operation- sized sections without difficulty. Some systems representative of
those which typically can be analysed successfully as a single section might include:

 Ship’s propulsion system.

 Procedures undertaken from departure/arrival at a berth up to
leaving/entering harbour.
 All logically associated equipment on a single drawing / schematic.

However, smaller sections may need to be considered if:

 Unusually high hazard materials are involved.

 Extreme conditions are present.
 The system or its controls are very complex.
 Unusual types of equipment are involved.
 The potential consequences are severe (Major Accident Hazards:
multiple fatalities or loss of platform)

32
 Preliminary Hazard Identification & Analysis Guide
It may be appropriate to use HAZOP to evaluate specific sub-sections meeting these criteria
should the SWIFT leader consider it advisable, as HAZOP is more systematic and rigorous
than SWIFT and can identify failures that are not immediately obvious.

Just as when picking nodes or sections for a HAZOP, experience will enable the SWIFT
leader to become adept at choosing systems for study which ensure both efficient use of team
time and effectiveness in identifying the hazards.

Conducting the Discussions

Once the scope of a system section is defined, the design intent, conditions and other
appropriate details should be discussed and entered into the log-sheet. Except for the
structured posing of “what if” questions, the discussion during a SWIFT review should be
similar in all aspects to those encountered during a HAZOP study. All team members should
participate and all should be permitted to express their opinions and concerns. Although the
SWIFT leader will also be a participant in a SWIFT study, he or she must be careful not to
dominate the discussions and ensure that the discussions are restricted to relevant topics.

The leader should begin the discussion by asking for and summarising team input for each
of the regulatory requirements listed below:

 Hazards of the activity or procedure

 Previous incidents
 Engineering and administrative controls.
 Consequences of failures of engineering and administrative controls.
 Siting/layout issues
 Qualitative evaluation of safety and health effects.
 Other regulatory issues.

Next, he or she should begin the discussion by stating the category of questions (below) for
discussion and then by either asking the team to brainstorm “What If” questions or offering
an initial question.

The structure for questioning in the original SWIFT (developed for process industry)
is provided by the following categories:

 Material Problems (MP).

 External effects or influences (EE/I).
 Operating errors and other human factors (OE&HF).
 Analytical or sampling errors (A/SE).
 Equipment/instrumentation malfunction (E/IM).

33
 Preliminary Hazard Identification & Analysis Guide
 Process upsets of unspecified origin (PUUO).
 Utility failures (UF).
 Integrity failure or loss of containment (IF/LOC).
 Emergency operations (EO).
 Environmental release (ER).

For process industries, the categories would be tackled in the above order. For other
industries, the SWIFT leader must get the group to prioritise the categories according to the
hazards associated with the system under investigation. Once this has been established, the
top category is addressed and then each subsequent category in turn.

Question categories summarises the intent of each of these question categories. If needed,
the SWIFT leader or team member may obtain additional ideas of the types of questions
which are appropriate for each category by consulting Structured Checklists. It is best,
however, for the team to initially “brainstorm” each category individually and then to use
the questions on the corresponding checklist to help ensure completeness. This approach
will help minimise the tendency for the team to become dependent upon the SWIFT
Checklists as a sort of “cheat sheet” which could stifle team creativity.

The “What if” Questions

The “What-if” questions often may often begin with the words “What-if” but they don’t have
to. “How could”, “Is it possible,” or any other form of question is perfectly acceptable. The
intent is to ask questions which will cause the group to carefully consider and think through
the potential scenarios and ultimate consequences that such an error or failure might
precipitate. When the multidisciplinary team is unable to draw upon or extrapolate their
experience to imagine any additional “What-if” questions in a given category, they should
consult the SWIFT checklists to prompt additional questions as appropriate.

Although the questions can be answered as they are raised, it is usually best to pose and
record as many questions as possible in a “brainstorming” manner before trying to answer
them. Interrupting the train of thought when brainstorming may result in questions being
forgotten or perhaps never even being posed. Additional questions can always be added to
the discussion list as they are raised. The SWIFT study leader needs to be aware that this is
not an unusual occurrence during the discussions of the initial questions.

Answering the Questions

When the flow of ideas subsides, the leader should ask the Recorder to read each “What if”
question in turn and ask the team to comment on how the system, adjoining systems or the
whole unit is likely to respond. The Recorder should enter a brief summary of the discussion
in the log sheet just as would be done during a HAZOP. Similarly, the possible consequences
are then examined and if the team considers current detection/safeguards or mitigation to
be sufficient, the next question should be discussed.

34
 Preliminary Hazard Identification & Analysis Guide
By applying his experience, the leader may further reduce the study time by selectively
changing the order of discussion of the questions posed by the team. By first considering
those questions which appear to involve the most severe potential consequences, the team
can often make a more comprehensive recommendation which covers many of the same
issues which will be identified during the discussion of the remaining questions. When this
approach is used, however, care must be taken to adequately consider all of the “What-if”
questions on the list to ensure that every known important issue has been raised, discussed
and recommendations written where necessary.

Recommendations

Just as in a HAZOP, if the team is not satisfied with the level of protection or otherwise
perceives a need for further analysis, recommendations for further action should be
proposed for management consideration. Such recommendations need to include a brief
description of the potential hazard, a description of what equipment, instrumentation or
procedures currently in place are relied upon to prevent the development of the hazard and
finally, the objectives which must be achieved to provide a solution to the potential problem.
Care should be taken to provide enough factual information but not too many specific details
of how the correction should be implemented. This provides the designers with as much
flexibility as possible in providing a solution which will meet the objectives necessary to
eliminate or manage the potential hazard.

It is important to remember that (as with HAZOP) a member of the SWIFT team has the
responsibility of identifying and adequately explaining to management what hazards might
be present and taking responsibility for moving forward with any recommendations.

Recommendations should always remain flexible. They should clearly state the perceived
deficiency and the objectives which the team considers important for eliminating or
managing the hazard. Ideas for a potential modification which came to mind during the
discussions can and should be documented, however, care must be taken not to state them
in such a manner that can be construed as the only solution to the identified problem or as
binding upon management.

Completing the Analysis

The procedure described above should be carried out for each question category. After the
final category is discussed, the leader should ask the team if there is “anything else” which
comes to mind that just didn’t come up in the discussions. If so, the questions should be
posed and answered. When the analysis of a system or subsystem is complete, the procedure
is repeated for any remaining sections until the agreed upon scope has been completely and
satisfactorily addressed. To wrap up the study of the major system section, the leader should
direct the team in reviewing and updating their thoughts on each of the regulatory
requirements which were used to initiate the discussions. Finally, the review of an entire
unit or plant may consist of a series of several studies, each having a scope comparable to
the typical major section just described.

35
 Preliminary Hazard Identification & Analysis Guide
As with a HAZOP, the team should prioritise the issues identified by the SWIFT study to
provide management with a clear understanding of the most significant issues to be
addressed. The report format for a SWIFT analysis should be no different from that of a
HAZOP, and the recommendations should be prioritised, tracked and completed in the same
manner.

SWIFT Reporting, Documentation and Follow Up

The SWIFT analysis is recorded on a SWIFT log sheet which is very similar to that used for
HAZOP recording. The main difference is that the left-hand column is completed with
“What-if” questions rather than guidewords. The organisation of the report and follow up
should be handled in a manner identical to that used for HAZOP.

36
 Preliminary Hazard Identification & Analysis Guide

HAZOP
A description of the technique, including its purpose

Hazard and Operability (HAZOP) studies methodology was developed by ICI in the United
Kingdom during the early 1960s as it required a more formalised technique for critical
analysis of plant design and operation. They had reviewed the techniques being used in
various parts of the company, and concluded that their quality was too heavily dependent
on the people who made up the study teams. They asked the Method Study experts in the
company to devise a formal review technique, and to hand it over to the engineers for use in
new plant reviews. The basic HAZOP methodology was then devised by the team to fulfil
these requirements.

After the Flixborough disaster, where 28 people died, the technique started to be widely used
within the chemical process industry. The approach was then adopted by the petroleum
industry where there was another obvious potential for major disaster. The food and water
industries subsequently employed HAZOP although more for contamination analysis rather
than explosions or chemical releases.

The HAZOP procedure involves a multi-disciplinary team who has substantial experience of
the system or design to be studied. The team consider taking a full description of a process
and systematically question every part of it to establish how deviations from the design
intent can arise. For each credible deviation the group considers possible causes and
consequences and decides if additional safeguards should be recommended when
consequences are found to have a negative effect upon the safe and efficient operation of the
plant. This examination of the design is structured around a specific set of guidewords,
which ensure complete coverage of all possible problems whilst allowing sufficient flexibility
for an imaginative approach.

Each HAZOP has a set of objectives, which are particular to that study and are decided as
near to the beginning of the study as possible. However, there are four overall aims for any
HAZOP:
a. To identify all deviations from the way the design is expected to work;
their causes, and all the hazards and operability problems associated
with these deviations.
b. To decide whether action is required to control the hazard, or the
operability problem, and if so to identify the ways in which the problem
can be solved.
c. To identify cases where a decision cannot be made immediately and to
decide on what information or action is required.
d. To ensure that actions decided upon are followed through.

The HAZOP technique is very versatile, and can be applied to both continuous and batch
processing. Generally, the HAZOP methodology is intended for use on a continuously
operating system, although in concept it is equally applicable to a batch process. In fact,
if one considers the start-up and shutdown procedures of a continuous process plant, it can

37
 Preliminary Hazard Identification & Analysis Guide
be shown that it is nothing more than a batch plant with a long reaction cycle. However,
there are several important differences in the HAZOP procedure, such as, data required,
preparation time, and study time that must be understood in order to plan and carry out
such a study. These differences apply when the complete process unit is operated batchwise
and also when there is only a single batch process step in a large continuous unit.

In addition to the normal data collected, it is necessary to have details of the sequence of
operations for the batch process. This may be in the form of an operating procedure for
manually operated equipment, or as a sequence flow chart for an instrument-or computer-
controlled system. Important elements of this information are:
a. All steps must be specified, and the process state for each defined (e.g.
fill line open, stirrer running etc.).
b. Any interlock operating during the step must be known (e.g. solenoid
operation removes signal from a valve, which must be closed).
c. The condition necessary to move to the next step must be known (e.g.
time from beginning of step, temperature set point reached etc.).
d. Details of any ’watchdogs’ must be given (e.g. if action is not completed
within 30 minutes an alarm is generated or processing stops).

If a batch process is converted to continuous, it will almost always result in a system with
more main plant items. It is, therefore, almost always true that the study time required will
be significantly greater for a batch system than for a similar Process and Instrumentation
Diagram of a continuous process.

When it might be used

As mentioned, HAZOP is primarily used for identifying safety hazards and operability
problems of continuous process systems and for the review of procedures and sequential
operations. Overall, HAZOP has become a standard tool across a variety of sectors (e.g.
petrochemical, offshore) and procedural HAZOP is widely used for both simultaneous
operations and the assessment of evacuation systems. However, other HAZID techniques
may be more efficient for many marine hazards depending upon the experience and
availability of the team, the phase of the design, the information available, etc.

Advantages, disadvantages and limitations to the defence sector or the

particular domain

Advantages
 It is widely-used and its advantages and disadvantages are well
understood and well known
 It uses the experience of operating personnel as part of the team
 It is systematic and comprehensive, and should identify all hazardous
deviations from the design intent and also from the operability
perspective

38
 Preliminary Hazard Identification & Analysis Guide
 It is effective for both technical faults and human errors. It recognises
existing safeguards and develops recommendations for additional ones
 The team approach is particularly appropriate to requiring the
interaction of several disciplines or organisations
 It provides a means of assessing hazards before a system becomes
operational
 The method aids the derivation of corrective and preventive measures
that may be incorporated into the system.
Disadvantages
 Its success depends on the facilitation of the leader and the knowledge
of the team. It is vital that the HAZOP leader understands the batch
process in some detail before the study begins. Otherwise, he/she may
be inefficient during the team study if most other team members
understand the process
 It is optimised for process hazards, and needs modification to cover
other types of hazards
 One procedure for a batch HAZOP is called 'step by step'. In this
procedure each batch process step is taken in turn, and the guideword
study of the system is carried out for that step. After completing the
study for the first process step the other steps are taken in sequence,
using the same technique. The technique can be very repetitive but it is
necessary in order to be systematic and complete
 It is a rigorous analysis tool and therefore requires development of
procedural descriptions and access to detailed design and operational
information which are often not available in appropriate detail.
However, the existence of these documents will benefit use of the
technique
 Documentation is lengthy (for complete recording)
 The method is labour intensive and time consuming in that many subject
matter experts from across various disciplines are required
 The method may not be able to provide adequate design solutions to the
human error problems it highlights
 It focuses on identifying single failures. Not all combinations of events –
more detailed techniques such as Fault Tree Analysis may be needed.

Sources of additional information. Standards, textbooks & web-sites.

Petroleum and Natural Gas Industries – Offshore Production Installations – Guidelines on

risk assessment (ISO17776:2000)
Hazard and operability studies (HAZOP studies) - Application guide (IEC 61882 (2001-05))
US Coast Guard website
HSE Website - Marine Risk Assessment, Offshore Technology Report 2001/063
Eurocontrol (European Organisation for the Safety of Air Navigation) HIFA (Human Factors
Integration in Future ATM systems) website

39
 Preliminary Hazard Identification & Analysis Guide

A simple example of a HAZOP

Figure 1 Refuelling at sea

Fuel oil is transferred from a tanker to a ship as shown in Figure 1. A simple sketch
describing part of the system is shown in Figure 2. In this example we shall apply
the HAZOP technique to the equipment shown. We are interested in safety
hazards and environmental aspects.

Fuel is removed from one of the fuel storage tanks on the supply vessel by pump
and transferred to the fuel storage tank on the receiving ship via permanent
pipework and a flexible hose connection. There are manual valves on the suction
and discharge to the transfer pump and also a filter to prevent solids from being
transferred. There is also a manual valve at the delivery on the receiving ship.
Couplings are provided at each end of the hose to enable quick connection.

40
 Preliminary Hazard Identification & Analysis Guide
The fuel is at ambient temperature; the pressure is negative static head at the
pump suction and 3 bars maximum at pump discharge. The storage tanks are at
atmospheric pressure with capacities of 50 and 20 m3 respectively for the tanker
and receiving ship. Fuel flow rate is 500 litres per minute. It is assumed that level
measurement in the tanks is by manual dipping and that the pump is started and
stopped using a local pushbutton. A procedure is in place for correct configuration
of the pipework and equipment and subsequent transfer of the fuel.

An example of the completed log sheet for this HAZOP study is shown in the Table
below.

41
 Preliminary Hazard Identification & Analysis Guide

Revision: 0 Node: 001 Page: 1

Project: Fuel Transfer System Date: Time:

Session: 0 Team:

Leader:
Recorder:
Node Description:
The hose connections from the tanker to the ship tank connection pipe including the pump,
Organisation: XYZ
filter and manual valves on the pump inlet and outlet.
Location: Various

Design Intention:
To transfer fuel from the tanker to the ship tank via the installed pump.

Normal Process Conditions (Range):

P&ID's Rev #'s
Temperature: Ambient
Pressure: Negative static head from tanker, 3 bars maximum at pump discharge
Flow rate: 500 litres per minute

Team Members:

1.1.6.6.

Project: Fuel Transfer System Node: 001 Page: 2

Node Description: The hose connection from the tanker to the ship tank including the pump and manual valves on the pump inlet
and outlet.

Guideword/Deviation Causes Consequences Safeguards Rec# Recommendation

42
 Preliminary Hazard Identification & Analysis Guide

Operators
No transfer of fuel. Pump knowledge and
starved of liquid, which could training. Provide low level / dry running
Manual valve on cause mechanical damage and cut out for the pump to prevent
pump inlet closed possible leakage from the Local stop which R1 pump damage on loss of
pump to sea. Possible fire if will be used by suction.
there is an ignition source. operator if pump
leaks or is noisy.

No transfer of fuel. Pumps Develop a checklist for use by

No Flow runs against a closed As before. Also the operator when carrying out
Manual valve on
discharge, which could cause this valve is tanker transfers. Ensure checks
pump outlet
overheating, mechanical normally kept of manual valve positions are
closed
damage and leakage if left for open. included in this checklist for all
too long. R2 stages of fuel delivery.

As above. Line or
Line or filter filter blockage is
As above.
blocked. unlikely since fuel
delivered is clean.

Operator closes
Spillage of fuel on ship with manual valve
Backflow of fuel Install a non-return valve in the
potential spillage to sea and before
when line to the ship fuel tank.
fire hazard. disconnecting
disconnecting
Reverse Flow hose. R3
tanker hose at
ship due to
Operator could be splashed Operator wears
siphoning.
with fuel when disconnecting gloves and
hose. goggles.

Hoses and Develop oil spill containment

Tanker hose or Discharge of fuel from hose or pipework are response procedures and check
More Flow transfer pipe pipe to sea causing R4
rated for 7 bars suitability of hardware for
rupture. environmental pressure. spillage clean up.

43
Preliminary Hazard Identification & Analysis Guide

pollution. Potential for fire if Maximum pump Review adequacy of the

there is a source of ignition. pressure is 3 R5 firefighting equipment on the
bars. ship.

This Guide contains copyright

material taken and modified from a
UK Government Website. This is
permitted under the Creative
Commons 4.0 Licence that applies
to that content.

44