P A C T

APC9 Conference: 19/20th Sept 2011

xyzOP Studies: Principles and Application

Jonathan Love

P A C T

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.

2

Details of

xyzOP

methodology

outlined in

Chapter 54

Case study:

being put into

public domain

for first time.

3

P A C T

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.

4

P A C T

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.

5

P A C T

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

operation of control systems identified?

Answer is with difficulty and maybe not very well.

6

P A C T

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.

7

P A C T

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.

8

P A C T

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.

9

P A C T

Impact of IEC 61508 contd -2

At the heart of IEC 61508 are the two equations:

53-23

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)

PFD x DRHR

C(E) x HRRisk

10

P A C T

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

P A C T

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

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.

Where else may be more useful in

relation to position. Table 54-1

13

hazOP

Table 54-3

Guideword Meaning Comments

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

Version

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.

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.

Incompatibility of and/or

changes to functionality

of the system software.

Security The integrity of the

system.

The potential consequence of unauthorised

access to the system, malicious or otherwise.

chazOP

14

Table 54-5

Guideword Meaning Comments

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.

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

The parallelism and/or

sequential nature of

control schemes and

strategies.

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.

Sooner/Later may be more useful in relation to

absolute time: Longer/Shorter for lapsed time.

coOP

15

P A C T

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

P A C T

Figure 63-1

Formulate URS

Develop DFS

Design software

Design modules

Develop software

Test modules

Integrate software

Integrate system

System acceptance

Design hardware

Phasing contd -2

17

P A C T

Phasing contd -3

18

ConceptualPlant design

Control system design

(hardware & system s/w)

Application software design

Detailed

Conceptual Detailed

Conceptual Detailed

pre hazOP full hazOP

pre chazOP full chazOP

pre coOP full coOP

Construction etc

Build etc

Develop etc

P A C T

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.

19

P A C T

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

P A C T

Reminder

21

ConceptualPlant design

Control system design

(hardware & system s/w)

Application software design

Detailed

Conceptual Detailed

Conceptual Detailed

pre hazOP full hazOP

pre chazOP full chazOP

pre coOP full coOP

Construction etc

Build etc

Develop etc

P A C T

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.

22

P A C T

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.

23

P A C T

Case Study

Control System Upgrade

24

P A C T

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

P A C T

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

P A C T

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

P A C T

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

P A C T

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.

29

P A C T

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

P A C T

Results

31

Metric hazOP chazOP coOP

No of nodes 7 23 20

Total no of actions 20 43 44

Applicability

of guidewordn/a

loss

range

mixture

version

security

loss

range

mixture

version

security

% of actions

generated by

guideword

n/a

96%

83%

83%

91%

13%

30%

21%

30%

16%

3%

access

timing

structure

conflict

access

timing

structure

conflict

95%

80%

65%

30%

39%

18%

25%

18%

P A C T

Results contd -2

32

Metric hazOP chazOP coOP

Hazard/operability Hazard 75%

Actioneen/a

Inst engr

Project engrSupplier

Affected project area

39%

33%

28%Others

32%

25%

39%

4%

Opery 25%

Hazard 19%

Operability 81%

Hazard 11%

Operability 89%

Inst engr

Project engr

Supplier

Specn & testing

Detailed design

Constn & commisg

Ops & maintenance

40%

25%

0%

35%

53%

33%

7%

7%

25%

61%

0%

14%

P A C T

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

P A C T

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

P A C T

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.

35

P A C T

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

P A C T

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.

37

P A C T

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.

38