tues 11.00 xyzop j love
Post on 06-Oct-2015
13 Views
Preview:
DESCRIPTION
TRANSCRIPT
-
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
top related