410

54 Hazard Analysis

Table 54.2 Interpretation of deviation approach guidewords for HAZOP

Guideword

Type of deviation

Typical problems

None of
Reverse of

No flow
No pressure
Reverse flow

More of

More flow

Blockage. Pump failure. Valve closed or failed shut. Leak. Suction vessel
empty. Delivery pressure too high. Vapour lock.
Pump failure. Pump reversed. Non-return valve failed. Non-return valve
reversed. Wrong routing. Back siphoning.
Reduced delivery head. Surging. Supply pressure too high. Controller saturated. Valve stuck open. Faulty flow measurement.
Blockage. Hot spots. Cooling water valve stuck. Loss of level in heater.
Fouling of tubes. Blanketing by inerts.
Pump failure. Leak. Partial blockage. Cavitation. Poor suction head.
Ejector supply low. Leakage. Barometric leg level low.
High or low concentration. Side reactions. Feed composition change.

High temperature
Less of
Part of
As well as
Other than

Lower flow
Low vacuum
Change in
composition
Impurities
Extra phase
Abnormal operations

Ingress of air, water, etc. Corrosion products. Internal leakage. Wrong feed.
Start-up and shut-down. Testing and inspection. Sampling. Maintenance.
Removal of blockage. Failure of power, air, water, steam, inert gas, etc.
Emissions.

many of which may be unexpected. A good example is the failure of an analogue output card. In
general, segregation policy should be such that all
the output channels from one card are associated
with a particular item of plant or processing function. Thus, if the card fails, or is removed for isolation purposes, that item of plant only is directly
affected. However, if one of the outputs goes to a
valve on another item of plant in a different area,
perhaps because it was wired in at a later stage,
that will fail too. Such failures would appear to be
sporadic.
It is evident that there are various aspects of
the control system that need to be subject to some
form of HAZOP study. Ideally, these should be considered as part of the HAZOP study of the process
and/or plant but, in practice, the design of the control system is seldom sufficiently complete at that
stage of the design cycle for an integrated HAZOP
study.Therefore it is necessary to carry out a seperate computer hazard and operability (CHAZOP)
study on the control system. Recognising that the
design of the application software always lags behind the design of the rest of the system,it is appropriate that the CHAZOP study concentrates on the

control systems hardware design, its I/O organisation and the system software. Consideration of the
application software is deferred to a later control
and operability (COOP) study.

54.3

CHAZOP Studies

It is appropriate for CHAZOP to be carried out in

two stages:
1. A preliminary CHAZOP which may well be integrated with the full HAZOP study.
The thinking behind the preliminary CHAZOP
is that strategic decisions about segregation
policy, system layout and the handling of gross
failures ought to be addressed early in the design cycle. Making changes later is expensive
and causes delays to the project.
The results of the preliminary CHAZOP should
be incorporated in the user requirements specification (URS) for the control system, which is
described in detail in Chapter 60.
2. A full CHAZOP study carried out at a later stage
when the relevant detailed information is available.

54.3 CHAZOP Studies

411

Table 54.3 Interpretation of guidewords for CHAZOP

Guideword

Meaning

Comments

LOSS

The complete or partial absence

of a function

RANGE

The distortion of an I/O signal

MIXTURE

The combination of I/O channels

VERSION

Incompatibility of and/or changes to functionality of the system

software.

SECURITY

The integrity of the system

The impact on the design intent of the loss of a function. May

apply to either power supply, processor capability, memory,
communications channels or to I/O signals.
The impact on the design intent of a signal either being distorted (such as non-linearity or hysteresis) or going out of
range.
The failure pattern of inappropriate combinations of I/O channels in relation to the hardware organisation of the system.
The potential consequences of either changes to the hardware
platform or upgrades (new versions of or changes) to the system software on the integrity of the application software, either
in relation to its development or to its subsequent support and
maintenance.
The potential consequences of unauthorised access to the system, malicious or otherwise.

Results of the full CHAZOP should be incorporated in the hardware aspects of the detailed functional specification (DFS) described
in Chapter 62.
When applying CHAZOP the same terms are used
as in conventional HAZOP but they take on more
specific meanings. Thus:
Intention relates to the transfer of information
(signals, commands, actions) between external
elements of the control system and its internal
software functions (both application and system) via either the systems I/O and/or communications channels or by means of operator interaction.
Guidewords that are more appropriate for CHAZOP are listed in Table 54.3.
Deviations are partial or total failures of either
communications channels or processing functions.
Causes are those combinations of events that result in deviations, the consequences being outcomes that could lead to operability difficulties
and/or hazardous situations.
Recommendations are additional requirements
for inclusion in either the URS and/or DFS.

Actions are reports of errors identified in the

design upon which action is to be taken.
The basic methodology for CHAZOP is similar to
that outlined in Figure 54.1, except that rather than
being based on the vessels and pipes, the focus is
on the hardware design of the control system, DCS
or otherwise. In turn, consider each I/O signal to
establish whether it is used for any safety related
function. Clearly any signal identified in the HAZOP study for the process and/or plant as being
safety related is a candidate for CHAZOP (these
signals are normally identified as consequences
in the HAZOP). Then identify all the communications channels used by any such signal. For every
such channel:
Review the functionality of the channel.
Follow the physical route of the channel in terms
of cabling, termination and marshalling cabinets, I/O cards, racks, etc.
Note the arrangements for segregation (see
Chapter 51) of the channel and the provision
for redundancy, if any.
Apply the guidewords as appropriate. In doing
so, particular attention should be paid to the
segregation and redundancy requirements.

412

54 Hazard Analysis

Table 54.4 Examples of the use of CHAZOP guidewords

Guideword

Type of deviation

Typical problems

Loss of

No/frozen signal

I/O signal failed low/high. I/O channel disconnected (off scan).

Polarity reversed.Wrong channel used. Component failure on I/O
board.Board removed.Poor contact with back plane.Intermittent
fault.
Local 24V d.c. supply failed. Mains 110V a.c. supply failed. Watchdog timed out.
OCS dead. Operating system crashed.
Highway disconnected or damaged. Highway overloaded.
PORT and/or GATE cards disabled.
Cant access data. Disc scratched. Read/write heads damaged.
RAM chip failed.
Signal ranged incorrectly. Signal in wrong direction. Nonlinearity. Sluggish dynamics. Damping effects. Noise and interference suppression. Drifting signals. Hysteresis.
Device disconnected for calibration or repair. Signal detected as
bad. Impact of automatic ranging.
Sporadic I/O failures. Segregation not on plant item/ function
basis. Insufficient redundancy. Signals routed through two channels/cards. Schemes spread across cards/racks.
Isolation and shut down. Manual operation. Local/remote power
supply. Different failure modes across cards/racks.
May require more processor power and/or memory than existing
hardware platform with implications for timings and loadings.
Application software functions (such as alarm handling) may not
be fully supported by new version of operating system. Different
versions of system packages may not be fully compatible with
each other.
Operating system and/or system software vulnerable to hacking
and/or viruses over the internet or intranet.
Commercial information in application software unlawfully abstracted.
Application software deliberately changed without authorisation.

No power

No communication
Memory corrupted
Range of

Distortion of signal

Signal out of range

Mixture of

Channel segregation

Failure modes
Version of

Operating system
System software packages

Security of

Abnormal behaviour and/or

loss of functionality
Breach of confidentiality
Breach of trust

It is worth emphasising that it is not the intent that

the above methodology be applied to every I/O
channel but only to those used for safety related
signals. It clearly makes for effective use of time if
generic channel types can be identified and considered on a type basis. Some typical examples of
the use of these CHAZOP guidewords are given in
Table 54.4.
The design upon which the CHAZOP is based
is articulated by various documents, the key ones
being as listed below.In practice,they will be in var-

ious states of completeness according to the stage

in the design cycle at which the HAZOP is done:
the more detailed the better:
All of the documentation for the HAZOP of the
process and/or plant.
Copies of the URS and DFS (see Chapters 60 and
62).
P&I diagrams.
Architecture of control system depicting networks, highways, links, bridges, gates, etc.

54.4 The Need for COOP Studies

Configuration of control system hardware: operator stations, cards/racks/cabinets, etc.
Physical layout and siting of system cabinets,I/O
racks, terminals, etc.
Organisation of infrastructure: marshalling cabinets, field termination racks, etc.
Power and wiring arrangements: types of multicore cables, connectors, colour coding, etc.
Channel/loop diagrams.
Details of system malfunctions: failure modes,
fail-safe states, etc.
Description of functionality of any nonstandard equipment.
It is likely that the CHAZOP team will be more specialist, comprising instrument, control and electrical engineers, but there should always be some
cross membership of the HAZOP and CHAZOP
teams to provide continuity of thought.
It should be stated there is little published information about CHAZOP in the public domain,
although the technique is carried out within many
of the larger and more responsible companies on
an in-house basis. A survey of industrial practice was commissioned by HSE and published by
HMSO (1991) and an overview is provided by Kletz
(1995). The text by Redmill (1999) provides a thorough overview of CHAZOP but advocates a different approach.

54.4

The Need for COOP

Studies

Whilst all modern control systems support a wide

variety of safety functions and clearly contribute
to safe operations, their purpose is to control plant.
Control systems are not protection systems. They
do, nevertheless, contribute to plant safety to the
extent that effective control reduces the demand on
the protection systems. The converse is also true.
If a control system leads to an increase in demand
rate on a protection system, that contribution must
be taken into account in the design of the protection system. This is recognised by the IEC 61508
standard on safety systems.

413

Central to the argument is the design of the application software and human factors. Quite simply, people interact with control systems to operate plant. It is very easy for operators to make
mistakes: by making wrong decisions, by making
changes at the wrong time, by not making decisions, and so on. Thus the application software
needs to permit access by the operator to certain
functions necessary for carrying out the operators
role but, at the same time, it needs to override inappropriate decisions and not permit certain interventions.
It follows that, to prevent the protection systems being exercised unnecessarily, there should
be some systematic check on the design and functionality of the application software. This is best
deferred to a separate control and operability
(COOP) study since, as stated, the design of the application software lags behind the design of the rest
of the system, usually to a considerable extent. In
essence, a COOP study is used to check that the design of the application software has properly taken
into account all conceivable and relevant human
factors. It should also check that the logic is sound
for the decisions being made by the system. Unless
this is done systematically, by means of COOP or
otherwise, it is not possible to argue that the control system is not contributing to the demand on
the protection system.

54.5

Control and Operability

Studies

Given that a COOP study is based upon the design

of the application software for a particular system,
it is obvious that the study cannot take place until
its design is available. Referring to Figure 63.1, it
can be seen that this is later in the design cycle than
agreement on the DFS. As with CHAZOP studies,
it makes sense to think in terms of carrying out
COOP studies in two stages:
1. A preliminary COOP study. This is most appropriate at the software design stage, as described in Chapter 63, when strategic design