APC9 Conference: 19/20th Sept 2011

xyzOP Studies: Principles and Application

Jonathan Love

Overview

Review hazOP:
limitations of hazOP,
impact of IEC 61508.
Proposal for xyzOP,
new guidewords,
phasing issues.
Overview of chazOP and coOP methodology.
Case study:
outline of control system,
application of methodology,
outcomes and lessons learned.
P

Details of
xyzOP
methodology
outlined in
Chapter 54

Case study:
being put into
public domain
for first time.

hazOP Studies

What is hazOP?
It is a technique to identify potential hazards,
well established and trusted,
the method of choice and used extensively,
IEC 61882 is an application guide.
It also happens to be:
labour intensive and costly,
unbelievably tedious and boring,
the only show in town.

hazOP Studies contd -2

So how does hazOP work?

It is a systematic and critical examination:
the design is scrutinised vessel by vessel, pipe by pipe,
identifies potential hazards due to malfunctions or mal
operations of individual items of equipment,
searches for causes and consequential effects,
uses a framework of guidewords.
Shall presume audience is sufficiently familiar with hazOP
to need no further explanation.

Limitations of hazOP

And how do control systems fit into hazOP?

They dont, because:
hazOP is process and/or plant orientated, and
there is no focus on the control system per se.
So how are potential hazards due to mal-functions or maloperation of control systems identified?
Answer is with difficulty and maybe not very well.

Limitations of hazOP contd -2

Current practice:
varies from superficial to thorough.
much variety in procedures and practices.
end users often rely upon suppliers and/or contractors
doing walkthroughs at design stage:
but critically dependant upon detail.
some form of chazOP is often carried out in-house,
but methods lack coherence and consistency in
terms of scope, methodology, etc.
There is virtually zero information in the public domain
about how to do this.
P

Limitations of hazOP contd -3

There is a need, in my opinion, for a methodology which is

systematic and universal:
xyzOP or equivalent,
objective is to be able to identify potential hazards due
to faulty design of control systems.
There also happens to be a particular requirement to do
so, which is compliance with IEC 61508.

The Impact of IEC 61508

But IEC 61508 is the basis for the design of protection

systems. Control systems are for controlling plant. They
are supposed to be:
separate from protection systems, and
outwith the scope of IEC 61508.
Unfortunately not!
that requirement is hard and real,
not properly understood.

Impact of IEC 61508 contd -2

At the heart of IEC 61508 are the two equations:

HR

Risk

DR x PFD

53-23

HR x C(E)

53-24

HR = hazard rate (mitigated),

DR = demand rate (unmitigated): frequency of top event,
PFD = probability of failure on demand (SIL level),
C(E) = consequence,
Risk = residual risk (target = 10-4 10-6)
P

10

Impact of IEC 61508 contd -3

In determining DR, all potential causes contributing to the

top event must be taken into account.
Clearly a control system whose design is faulty can lead
to an increase in DR:
embraces both hardware and application software.
But, how to prove that a control system does not increase
the demand rate?
Not possible, but ought to be able to demonstrate that its
design is as good as is practicable.

11

The Proposal for xyzOP

xyzOP is a family of techniques.

The basic methodology and discipline of hazOP has been
adapted and extended to the design of control systems.
chazOP focuses on the systems hardware design, its I/O
configuration and the system software.
coOP focuses on the application software.
Different, more appropriate, guidewords are proposed for
chazOP and coOP, as follows:

12

hazOP
Guideword

Meaning

Comments

No or Not

The complete negation

of the intention.

No part of the intention is achieved and

nothing else happens

More and
Less

Quantitative increase
or decrease.

Refers to quantities and properties (such as

flow rates and temperatures) as well as to
operations (such as charge, heat, react and
transfer) related to the intention.

As well

Qualitative increase,
something extra.

All the design intentions are achieved,

together with some additional activity.

Part of

Qualitative decrease, the

intention is not completed.

Only some of the intensions are completed,

others arent.

Reverse

The logical opposite of

the intension.

The reverse of the intended action or the

opposite of some effect occurs.

Other than

Complete substitution.

No part of the original intension is achieved.

Something quite different happens.

Table 54-1

Where else may be more useful in

relation to position.
13

Guideword

Meaning

Comments

chazOP

Loss

The complete or partial

loss of a function.

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

Range

The distortion of an I/O

signal.

The impact on the design intent of a signal

either being distorted (such as due to non
linearity or hysteresis) or going out of range.

Mixture

The combination of I/O

channels.

The failure pattern of inappropriate

combinations of I/O channels in relation to
the hardware organisation of the system.

Version

Incompatibility of and/or
changes to functionality
of the system software.

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 integrity of the

system.

The potential consequence of unauthorised

access to the system, malicious or otherwise.

Table 54-3
Security

14

Guideword

Meaning

Comments

coOP

Access

The scope for operator

intervention.

The impact on the design intent of an operator

making inappropriate interventions. Applies to
interaction of any nature, planned or otherwise.

Timing

Frequency of recurrent
events and/or order of
logical events.

The potential consequences of actions (by the

operator or otherwise) being (or not being)
carried out before, during or after specific events,
or being done in the wrong order.
Sooner/Later may be more useful in relation to
absolute time: Longer/Shorter for lapsed time.

Structure

The parallelism and/or

sequential nature of
control schemes and
strategies.

The potential consequences of components

(such as function blocks and phases) not being
selected and/or configured correctly.
Also concerns the impact on progression of the
interfaces between components being disjointed.

Conflict

The scope for high level

interactions of an adverse
nature.

The potential for conflicting decisions that are

not addressed by the previous guidewords.
Applies in particular to outcomes from
application package being overridden by another.

Table 54-5

15

Phasing

The phasing of xyzOP studies in relation to the control

system design cycle is fundamental. In practice:
the control system: its design lags behind that of the
plant itself,
the application software: its design and development
always lags behind the rest of the control system.
A single integrated xyzOP study is not feasible:
suggests need for separate chazOP and coOP studies:
there are different issues to be addressed anyway.
As with hazOP, both prelim and full studies are required.

16

Phasing contd -2

Formulate URS

Develop DFS

Design hardware

Design software

Design modules

Develop software

System acceptance

Integrate system

Integrate software

Test modules

Figure 63-1
P

17

Phasing contd -3

Plant design Conceptual

Detailed

pre hazOP

Construction

etc

full hazOP

Conceptual
Control system design
(hardware & system s/w)

Detailed

pre chazOP

etc

Build

full chazOP

Application software design Conceptual Detailed

pre coOP

Develop

etc

full coOP

18

chaZOP Studies

Preliminary chazOP may be integrated with full hazOP.

strategic decisions about segregation policy, system
layout and gross failures ought to be addressed
early in the design cycle.
A full chazOP study is carried out at a later stage when
the relevant detailed design information is available.
Focus is on hardware after design freeze.
In turn, consider each I/O signal to establish whether it is
used for any safety function:
any signal identified in the hazOP as being safety
related is a candidate for chazOP.
P

19

chazOP contd -2

Then identify all the communications channels used by

any such signal. For each 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 (Chapter 51) of
the channel and the provision for redundancy, if any.
apply the guidewords given in Table 54-3 as
appropriate.

20

Reminder

Plant design Conceptual

Detailed

pre hazOP

Construction

etc

full hazOP

Conceptual
Control system design
(hardware & system s/w)

Detailed

pre chazOP

etc

Build

full chazOP

Application software design Conceptual Detailed

pre coOP

Develop

etc

full coOP

21

coOP Studies

In essence, a coOP study is used to check that:

the logic is sound for the decisions being made,
all conceivable and relevant human factors have been
taken into account.
Focus is on application software after design freeze.
The preliminary coOP best done at software design stage,
when strategic decisions are being made (Chapter 63).
The full coOP done later once the detailed module
designs available:
outcomes feed into DFS via change control.
Can combine prelim and full coOPs for simple designs.
P

22

coOP contd -2

In turn, consider each control scheme:

establish whether it uses and/or generates any safety
related signals, others are outwith coOP:
any signal identified in chazOP as being safety
related is a candidate for coOP.
review the functionality of every such control scheme.
identify what software components (eg function blocks,
phases, etc) operate upon which safety related signals,
note the ordering of components and criteria for logic,
apply the guidewords (Table 54-5) as appropriate:
note especially the role of the operator & scope for
inappropriate interventions.
P

23

Case Study
Control System Upgrade

24

Case Study

chazOP and coOP applied retrospectively to control

system upgrade:
Offshore oil & gas platform:
80 man platform, commissioned in 1990s,
three new wells to supplement production in 2000s,
plus manifolds, feedpipes and risers, gas lift,
choke and diverter valves,
extension to hydraulic power unit,
tie ins to drains, flares & other services/utilities.

25

Control System

Original system comprised DCS with hot back up, ESD

with 2oo2 voting, F&G with 1oo2 voting and
PCS for common MMI to DCS, ESD & F&G systems,
database mangt, displays, alarm handling, servers, etc.
Upgrade affected DCS, ESD and PCS:
no impact on F&G.
additional 90 I/O signals, new I/O cards, coms cards,
racks, power supply, wiring, etc.
substantive revisions of application software for DCS,
ESD and PCS.

26

Design Process

Conventional design process for upgrade:

URS followed by vendor selection and DFS,
vendors quality procedures TickIT approved,
subject to FAT and SAT testing.
Completed in accordance with API standards, relevant
offshore legislation, companys internal design codes &
practices.
Preliminary hazID and detailed hazOP at design freeze
stage.

27

Trial of ChazOP and CoOP

Engineer familiar with platform, process and control

system,
not actively involved in design so no preconceived
ideas of outcome,
had access to the original design information.
Engineer had 15 yrs relevant C&I experience in oil & gas.
Engineer did review alone:
team approach advocated for both chazOP and coOP,
but mitigated by independent reviews of output tables.

28

Trial contd -2

The trial consisted of the following stages:

collection & familiarisation with base documentation,
identification of scope,
completion of chazOP process,
completion of coOP process.
The outcomes of both the chazOP and coOP studies were
recorded in common tabular format as per convention for
hazOP:
nine columns for item no, guideword, deviation,
possible causes, consequences, safeguards,
comments, action required and actionee.
P

29

Case Study Analysis

Study completed on a part-time basis. Excluding data

gathering, took some 50 hours effort.
Review analysis by three independent engineers was 4-6
hours per individual.
System being reviewed decomposed into:
chazOP: 23 nodes, resulting in 43 actions,
coOP: 20 nodes, resulting in 44 actions,
total of 87 actions for a system supposed to be OK!
The following data has been abstracted from the studies:

30

Results
coOP

chazOP

Metric

hazOP

No of nodes

23

20

Total no of actions

20

43

44

Applicability
of guideword

% of actions
generated by
guideword

n/a

n/a

loss
range
mixture
version
security

96%
83%
83%
91%
13%

access
timing
structure
conflict

95%
80%
65%
30%

loss
range
mixture
version
security

30%
21%
30%
16%
3%

access
timing
structure
conflict

39%
18%
25%
18%

31

Results contd -2
coOP

chazOP

Metric

hazOP

Hazard/operability

Hazard 75%

Hazard 19%

Hazard 11%

Opery 25%

Operability 81%

Operability 89%

Actionee

Affected project area

Specn & testing
Detailed design
Constn & commisg
Ops & maintenance

n/a

Inst engr
Project engr
Supplier

39%
33%
28%

Inst engr
Project engr
Supplier
Others

40%

53%

25%

25%
0%
35%

33%
7%
7%

61%
0%
14%
P

32%
25%
39%
4%

32

Outcomes

With the benefit of hindsight, key issues in original design

process that became apparent were:
time lag between process design & system design,
lack of recognition of control system failure modes
within hazOP,
no client mandated risk management system,
reliance on vendor for risk identification and mitigation
procedure.

33

Outcomes

The chazOP and coOP methodologies exposed a

significant number of issues & follow up actions, of which:
nearly 15% of issues were not identified in the original
design and commissioning and were lying dormant.
a further 14% were only identified during FAT & SAT.
the majority, but not all, were largely of an operational
nature rather than hazardous:
very different to hazOP.

34

Outcomes contd -2

Time taken to carry out study was not trivial:

approx 50 hours
sizeable investment if team of 5-6 persons.
But not disproportionate to, say hazOP, whilst covering
wide ranging scope.
Costs would be recovered through:
more efficient testing and commissioning,
system up-time greater when plant goes operational.
Methodology is very scalable:
time taken is not proportionate to the no of I/O due to
focus on interfaces and analysis of typicals.
P

35

Outcomes contd -3

An experienced team should be able to complete both

studies on a highly automated, moderately complex plant
of 10,000 I/O in 2-3 weeks.
chazOP and coOP are both qualitative, so hugely
dependant upon experience and initiative of the study
team.
Methodologies are non domain specific. Combined with
similarity in style to hazOP should increase likelihood of
acceptance and growth in use.

36

Lessons Learned

The methodology was successfully executed:

Guidewords: proven to be effective, open and probing.
Documentation: detailed design information is critical.
Full reporting of chazOP/coOP recommended:
esp justification for no action.
Team: inst engr is key for continuity within xyzOP.
Phasing issues confirmed as per diagram:
importance of h/w & s/w design freeze to full studies.
Integration: actions & issues carried downstream,
potential to identify issues missed in upstream study.
P

37

Lessons contd -2

Methodology:
define scope clearly, esp technical boundaries,
identify all interface points (h/w & s/w):
these are highest risk areas for specification issues
and implementation errors,
identify all instances of h/w and s/w typicals.
these are the building blocks and need full analysis.
analyse suitability of all configurables (h/w & s/w).
decide on granularity of signals: rack, card, channel?
quantify no of non-typicals to be analysed & hence the
time & effort required.
P

38