~HSE

Health & SafetyExecutive

HSE CONTRACT RESEARCH REPORT No. 26/1991

GUIDANCE ON HAZOP PROCEDURES FORCOMPUTER-CONTROLLED PLANTS

Peter Andow B Tech. M ChE. PhD. C Eng.MI Chern E. MBCS

KBC Process Technology Ltd

Price £20.00

~HSE

Health & safetyExet:uti'Je

HSE CONTRACT RESEARCH REPORT No. 26/1991

GUIDANCE ON HAZOP PROCEDURES FORCOMPUTER-CONTROLLED PLANTS

Peter Andow 8 Tech. M ChE. PhD. C Eng.MI Chern E. MBCS

KBC Process Technology Ltd

This report aims to give 'best practical means' advice on HAZOP procedures to medium-sized companies in theprocess industry who use programmable electronic systems (PES) in safety related applications.

The work was stimulated by the observation that many medium and/or smaller companies are reluctant to applyPES - apparently because the existing guidance is viewed as being too stringent and/or difficult to apply. The repOrtcontains recommendations based on interviews w~h a number 01 practioners w~hin the industry.

© Copyright Controller HMSO 1991 .

This report and the work ~ describes were funded by the Heallh and Safety Executive. liS contents, including anyopinions and/or conclusions expressed, are those of the authors alone and do not necessarily reflect HSE policy.No part of this publication may be photocopied or otherwise reproduced w~hout the prior permission in writing of theHealth and Safety Executive.

CONTENTS

Section 1 Background

Section 2 Introduction

2.1 Design Review Techniques2.2 Why Use HAZOP ?2.3 The Benefits of HAZOP2.4 Design Changes Arising from HAZOP2.5 Computer HAZOPs

Section 3 liming and Preparation

3.1 Timing3.2 Preliminary CHAZOP3.3 Full CHAZOP3.4 Preparation3.5 Team Composition3.6 Retrofit Projects

Section 4 Procedure and Guidewords

4.1 Preliminary CHAZOPs4.2 Full CHAZOPs4.3 Reporting

Section 5 Summary and Conclusions

5.1 Summary5.2 Other Recommendations5.3 Conclusions

Section 6 AcIalowIedgemerns

Section 7 References

Appendices

A1 Main Survey FindingsA2 Other FindingsA3 Sources of Information

- Page2 -

Page Number

3

7

77889

10

101112121515

16

161721

22

222424

25

26

2935

'38

Section 1 BACKGROUND

In 1987 the Health and Safety Executive (HSE) published two documents: .

"Programmable Electronic Systems in Safety Related Systems. 1. AnIntroductory Guide"

"Programmable Electronic Systems in Safety Related Systems. 2. GeneralTechnical Guidelines"

See References 1 and 2 for full details. Hereafter these will be referred to as "the PESdocuments" or individually as PES 1 and PES 2 respectively.

Prior to'publication, the PES documents (in draft form) had been sUbject to extensivereview and comment from ·interested parties..

The aim was outlined in the Foreword to both documents by the Director General ofthe Health and Safety Executive, Mr. J. D. Rimmington:

"It is essential that industry should be able to reap the enormousbenefits computerisation has to offer. But the sophistication andunfamiliarity of the new technology can conceal hazards, sometimesat the interface between man and the process, which could inhibit therate of advance unless we learn to recognise them ..."

It is clear from this that the HSE recognises the advantages of computerisation.Notwithstanding this statement of intent, it appears that some parts of industry havehad great difficulty in coming to terms with the PES documents. A number ofreactions can be observed:

a) The PES documents are too generic - and hence difficult to understand.

b) The gUidance recommends such high standards that PES's should beavoided if possible.

c) The guidance is difficult to apply in practice· particularly for medium-sizedcompanies that may operate large, potentially hazardous plants but don'thave the substantial technical resources of the larger, often multinationalcompanies.

. Page3 -

HSE has done much to dispel these reactions. In particular, it has emphasized that:

a) It is recognised that the guidance is generic, but it is seen within HSE asbeing only the foundation on which more detailed application-specificguidance should be based.,

b) The standards recommended are not substantially different in philosophyfrom tbose that HSE would recommend for oonventional hard-wired systems.In particular, in the PES documents there is much emphasis on the needfor redundancy and diversity in PES-based systems. In HSE's view similarconclusions can be drawn for hardwired systems - although HSE has notpublished an equivalent Guidance Note for such systems.

c) HSE supports and encourages the development of more specific guidancethat is directly applicable in particular sectors of industry. Examples ofsuch "second tier" guidance is given by:

1 From The Institution of Gas Engineers (IGE): "Use of ProgrammableElectronic Systems in Safety Related Applications in the GasIndustry".

2 From The Engineering Equipment and MateriSls Users Association(EEMUA): "Safety Related Instrument Systems for the ProcessIndustries".

See References 3 and 4 for full details. These documents cover the whole system life­cycle.

By contrast, this report is intended to cover a much narrower area. In this report thefocus is on the area referred to in both the IGE and EEMUA documents as "designreview". In the Process Industries the Hazard and Operability Study (HAZOP) techniqueis widely used as a means for identifying hazards at the design stage (see Reference5). Many companies use HAZOP as a standard that must be applied to all newdesigns and plant modifications. HAZOP is a "structured discovery" technique - itaims to find deviations from the designer's intentions by systematically applying guidewords such as MORE, LESS, NONE, OTHER etc.

The guide' words are used to generate questions about every aspect of the plantdesign· using the Piping and Instrumentation Diagram (or P & 10) as It's basis. Theguide words are used by an inter-disciplinary team. When deviations are discoveredthe team will normally recommend changes to design, operational practices or plantmanagement.

Many HAZOP findings are concerned with control and/or protective system designand operation - and for most modern plants that control system will be based onprogrammable electronics. Thi!, gives rise to 2 major implications: '

- Page4 -

1. The team must recognise that the controls on the P & 10 will normally bepart of a PES and will have a different spectrum of failure modes thanconventional single-loop controls. The PES should be HAZOPed as anintegral part of the plant design - for the same reasons that conventionalcontrols are HAZOPed as an integral part of the design.

2. The PES gives the potential for many functions that would be impracticalwith conventional hardware. In order to use a PES effectively to engineer asafe and operable plant the team need a deeper knowledge of their modeof operation, range of facilities, strengths and weaknesses. The team mayalso use this deeper knowledge to decide that the PES should not be usedfor particular functions· or that more than one PES is required.

In current practice it appears that little account is taken of the PES architecture. Someteams have recognised the problem - but expressed the view that they don't knowhow to apply HAZOP to a PES. Common practices include:,

1. Treating the PES as though it were implemented as conventional controls.

2. Treating the PES as a "black box" that does what is required.

3. Carrying out the conventional HAZOP and considering the Computer HAZOP(sometimes called CHAZOP) separately.

The purpose of the work described in this report was:

1. To establish what industry is actually doing in the area of HAZOP of PES­based controls by interviewing a small number of companies on theircurrent practices. The intention was to use an "indicative" sample ofcompanies that were known to be using PES for safety-related applications.The sample was small and would not necessarily be representative of thewhole industry. It was agreed that it was desirable that participants shouldhave the option to remain anonymous in order to facilitate better access tocurrent practices.

2. To review the interview findings in order to establish recommendations for"best practical means·, It was not intended that the work should inventanything that was completely new.

3. To report the recommendations in a form that is reasonably concise andusable for the medium-size company in the Process Industries. Therecommendations are intended to be applicable to both batch and c:ontinuou'splant in all of the Process Industries (Oil, Petrochemicals, Pharmaceuticalsetc.). The work was aimed at the end-user company rather than contractorsor equipment vendors.

- PageS -

It should also be noted that when the term HAZOP is used (in this report) this doesnot necessarily imply a method that slavishly follows the guidewords and proceduresof the conventional HAZOP.

Here the term HAZOP is taken in a wider sense to be a broad framework forsystematically and critically investigating the plant design.

Essential ingredients of HAZOp'were seen as:

1. The inter-disciplinary team basis. I,2. A methodology based on questions posed to the team.

3. A systematic approach.

It is also noted that parts of the PES 2 guidance are concerned with numericalanalysis of hazards. This is considered to be outside the scope of the work reportedhere - in the same way that HAZAN is usually considered to be distinct from HAZOPin conventional safety analysis work. It is not suggested that numerical analysis is notrequired - that depends on the plant hazards, safety criteria and integrity levels, .asdefined in the PES 2 document.

• Page 6 •

Section 2 INTRODUCTION

2.1 Design Review Techniques

HAZOP has become an industry-standard, not just in the U.K but in many countries.However, it must be made clear that HAZOP is not the only "design review" technique.The most popular alternatives ~re:

a) Failure Mode and Effects Analysis (or FMEA).

b) 'What if 7" analysis (mostly in the U.SA).

Most of the comments that follow in this report apply equally to other techniques. Theterm HAZOP is used here because it is the most popular technique (particularly in tneU.K.) and because it is the technique that is most strongly oriented to the ProcessIndustries.

2.2 Why use HAZOP ?

In it's narrowest sense HAZOP is a particular technique, originating within ICI, that .employs a procedure and guide words to discover Hazards and Operability problems.In a wider sense, within ICI it was used to refer tp a a whole set of techniques thatwere applied at different stages of the plant life-cycle. The "standard" HAZOP is moreproperly seen as "HAZOP 3" in the more elaborate ICI scheme. Earlier stages seek toidentify more basic problems:

- Wt:lat are the basic hazards associated with the process 7

- Is the proposed process route really the best, when safety etc. is taken intoaccount?

• Is the site and/or country best suited for the plant now proposed 7

- etc.

~ is important to note that many of the "big" changes are only practical at this stage..Changes made later (to rectify the same underlying problem) are likely to be more··complex and costly.

Later stages are intended to:

- Systematically check the design of plant systems (e.g.blow-down systems)

- Ensure that operating procedures are as intended

- etc.

• Page 7 -

This life-cycle approach is considered more appropriate to the needs of modernindustry. The recent emphasis on Quality Assurance (largely spearheaded by as5750 in the UK) serves to confirm this approach. Getting plant safety "right first time"is part and parcel of QA.

2.3 The Benefits of HAZOP

The use of HAZOP (like CA) is also based on the assumption that money spent onHAZOP early in design is more than recouped by money saved later. If HAZOP onlyinvolved safety this would not be so easy to prove· but most HAZOPs yield far moreOperability problems than Safety problems and better operability means savings fromcommissioning right through plant life. Most (all 7) companies that have appliedHAZOP properly have recognised it's value· it improves safety and saves money.

It will never be known how many accidents HAZOP has prevented. What is clear isthat even experienced and competent designers make mistakes and omissions duringthe design process. HAZOP is not a substitute for experience. nor is it a substitutefor good people· a good design requires qood people. experience and use ofHAZOP. .

A good designer will also recognise that the team will bring a wider set of views (andexperience) into consideration· and the actions recommended by the team reflectthese wider views rather than criticism of the original design. The resulting design isbetter because a wider group has focused it's attention and experience on the designat a fairly detailed Jevel. It is also apparent that accidents will still happen even whenHAZOP is carefully applied. The number of accidents should be smaller and theirconsequences should, on average, be less severe. On the same lines, a "zerodefects" QA policy will not produce zero defects over an extended period of time· butit should produce a much lower defect rate.

2.4 Design Changes Arising from HAZOP

HAZOP usually produces a significant number of design changes. Typical examplesare:

1. Minor changes to piping and vessel design.

2. Major changes to the design. additional plant equipment (fairly rare 7)

3. Addition of instrumentation. both for routine control and plant protection(the most common type of action 7)

4. Layout ~hanges.

5. Changes to procedures and operating instructions.

- Page8-

2.5 Computer HAZOPs

Computer HAZOPs (or CHAZOPs) are necessary for the same reasons as thosementioned above for the conventional plant HAZOP:

1) A multi·disciplinary team will bring new points to light which even the mostconscientious and experienced designer may miss.

2) CHAZOP c.an find problems earlier in design. Design changes cost lessearly in the plant Iife·cycle.

3) CHAZOPs are likely to find many more Operability than Safety problems.These will save money throughout plant operation.

There are also additional reasons for using CHAZOP over and above those forHAZOP:

4) The very flexibility of the computer - that allows it to perform manysophisticated functions • also gives us the opportunity to make moremistakes than with conventional control equipment. This applies evenwhen there is a deliberate policy of only using the computer to mimic thefunctions of conventional controls. In most plants. however. the computerwill be used for more complex functions than conventional controls - givingmore scope for errors and omissions.

5) On computer systems there will inevitably be Common Mode Failures(CMFs) that cause several items to fail at the same time. The most obviousexample is that many systems will provide cards for input/output (1/0) thatcontain several channels.. A single card failure may cause all of the channelsto fail at the same time. This is not in itself surprising - but is' often notrecognised or ignored by the conventional plant-oriented HAZOP team.The existence of CMF (and perhaps more importantly. failure to take dueaccount of CMF) presents many problems in safety assessment. See the'PES 2 document for a much more comprehensive account of CMF andcheck·lists specifically concerned with eMF.

- Page 9 -

Section 3 TIMING AND PREPARATION

In this section it is recognised that CHAZOP (where used) is normally carried outseparately from HAZOP - and will nearly always be done in isolation (from HAZOP)where a new computer is retrofitted to an old plant. The procedures that followassume that this is likely to be the case. It is however rioted that a better arrangementis to integrate CHAZOP into HAZOP or to at least coordinate the two activities moreclosely. .

3.1 Timing

It has already been noted that some companies have found that the biggest gainsfrom HAZOP derive from those changes made early in the plant life-cycle. HAZOPs atthe Process Concept stage or Preliminary Process Flowsheet stage are relativelycoarse (since most of the design details have not yet been determined) but relativelyquick (for the same reason). Big changes are however possible before vessels areordered or large efforts are put into P & ID's, equipment specification and design etc.Trevor Kletz provides many examples of how plants can be made more "InherentlySafe" (see Reference 8).

Similar considerations apply to the computer systems. At an early stage there maywell be an assumption that a Distributed Control System (or DCS) will be used formost of the control functions. There may also be a recognition that separate protectivesystems will also be required - although it may not be clear if these are to behardwired or PES-based. If we apply HAZOP-style techniques at this stage then weare more likely to correctly identify critical factors early in design that influence theoverall architecture and functionalitY of the systems. This is contrasted with thetendency to leave design of DCS until late in the project simply because DCS flexibilityallows this to be possible - which may clearly be counter-productive. This does notobviate the necessity for more detailed review later - but it does suggest that a multi­stage process is most effective overall. Comments made by some companies duringthe interviews helped to confirm this view.

There are various stages during design and implementation when CHAZOP might beapplied· Figure 2 shows the most likely ones. As noted above, it is considered veryeffective to consider the. overall architecture as earty as possible - corresponding toStage A) in Figure 2. This will be termed ·Preliminary CHAZOP". It is not so obviouswhen a more detailed CHAZOP should best be performed. The "besf' time may wellbe strongly dependent on:

1) the project organisation of the company concemed.

2) the use (if any) made of vendors in contrast to in-house impleme,ntation.

3) if the project is for a new plant or is a retrofit.

- Page 10 -

As noted in Figure 2, a CHAZOP at the "Plant P & 10 complete" stage will help todefine requirements - and this is more in line with the conventional plant HAZOP. Itappeared during the interviews that little use is made of CHAZOP at this stage - atleast in the formal sense. It appears that most companies effectively rely on the PESdesigner to take note of all the likely requirements - either from the plant HAZOP(where he. may be part of the team) or from his/her own experience. (This is alsoseen to be necessary in order to execute Step 4 of Figure 1 since this requiresdetailed specification of PES functions).

The most common practice found is to th~n apply more formal checks when codingis complete, as a finsl review. Where QA techniques are being applied, it will in any

.case be necessary to go through Flow Charts, Programs, Ladder Logic etc. as acheck on implementation of the specification. The other advantage of review at thisstage is that it fits in better with formal check-out and/or acceptance of vendor­supplied systems.

It is therefore considered that "best current practice" is to review systems in detailwhen coding is complete. This will be termed "Full CHAZOP". It is however emphasizedthat HAZOP-style review of any PES at the P & 10 stage is still considered beneficialand will in any case need to be performed by the designer if the system is to matchrequirements. .

3.2 Stage 1 - Preliminary CHAZOP

Figure 1 shows the "Design and Assessment General Framework" recommended in .PES 2. The first 2 steps are most relevant here:

. Step 1: Analyse the hazards:

a) Identify the potential hazards;

b} Evaluate the events leading to these hazards.

Step 2: Identify the safety related systems, that is, those systems on which thesafety integrity of the plant is to be assured and whose failure areincluded in the events leading to the hazards Identified in Step 1above. It is at this stage that It becomes possible to determinewhether this Q.e. PES 2) document applies:

The aim of this Preliminary CHAZOP is to complete Steps 1 and 2 as far as isreasonably practicable at this stage.

Step 1, Part a) can be reasonably attempted at an early stage in the plant life-cycle.Step 1, Part b} requires more detaiied design information if done thoroughly - but canstill be carried out on a preliminary basis at an early stage. Step 2 can also be

- Page 11 -

reasonably attempted at this early stage. Some of the points of detail may be missingbut the critical safety systems should be identifiable.

It is stressed that:

1. This preliminary CHAZOP should not be divorced from a preliminary plantHAZOP. The two activities need to be carried out at a similar stage in thedesign process and shoul~ be integrated if possible.

2. This stage should not be particularly time-consuming (compared to laterstudies). It may also lead to design changes which will reduce or eliminatethe need for complex protective systems that become necessary whenpotentially serious problems are identified later in design.

3.3 Stage 2 - Full CHAZOP

The aims of this stage are:

1. To evaluate the design in much more detail ~n particular for Step 1, Part b)of the overall PES 2 framework shown in Figure 1)..

'2. To confirm the preliminary findings in respect of Steps 1 and 2.

This stage cannot be done properly until system design is essentially complete. (Oneview expressed was that this detailed review could onlv be done when the plant wasready to be built· i.e. at design freeze if H~OP and CHAZOP were not being use9l.

As with the preliminary stage,.it is recommended that the CHAZOP should be viewedand carried out as an integral part of HAZOP. This has implications for issues such as

·team composition (see section 3.5). .

3.4 Preparation

3.4.1 Preliminary CHAZOP Preparation

For the Stage 1 Preliminary CHAZOP the following are recommended:

1. Details of process chemistry and hazards associated with the materialsinvolved at the operating conditions proposed.

2. Process Flowsheet with expected operating conditions (e.g. from othersimilar plants, pilot trials or laboratory tests).

- Page 12 -

3. Map showing:

a) Proposed location for plant on site.

b) Location and approximate size of storage tanks.

c) Map should already show existing plants, utilities etc. but shouldalso include other proposed plants, areas of housing and publicaccess, roads etc.

Maps do help to focus attention on the possible effects of a release and areparticularly important where the design team are based at a different site.Details of local climatic conditions, wind direction etc. may alSo be importantin this case.

4. Proposed overall architecture of control and protective systems - if available.(It might be argued that this information should come out of this stage - butin many cases companies have a fairly clear idea of the likely architectureeven at the Process Concept stage). Some views were expressed that aUser Requirements Specification (or similar) is needed before any CHAZOPactivity can be carried out. Normal QA procedures indicate that somedocumentation must be available at this stage. The minimum would seemto be a Functional Specification that includes:

a) An overview of the proposed systems and any links betweenthem. For example, a DCS for control functions and dual­redundant PLC's for protective systems - with the PLC's beingmonitored by the DCS.

b) An estimate of the I/O count for each system.

c) A schedule of expected protective system functions.

It will be noted that parts of the information under headings 1 to 3 above would in anycase be required for a ·coarse-scale" HAZOP.. In many companies a. "ProcessDossier" would already exist which contained most or all of this information. The effortinvolved in gathering the data for item 4 CIf not normally available) should not be farge..

• Page 13-

3.4.2 Full CHAZOP Preparation

For the Stage 2 full CHAZOP the following are recommended:

1. All of the normal plant documentation necessary for the standard HAZOP.This material will need to be available anyway for a new plant (for thestandard HAZOP) and should be provided for the CHAZOP team to referto as needed. When retrofitting a new computer system to an existingplant that has not been HAZOPed It will require a greater effort (particularlyIf P & ID's are not up to date). In this case it would be preferable If theexisting plant was HAZOPed.

2. Detailed design specifications for control schemes and protective systemswhere these are not part of the standard HAZOP material (e.g. "AdvancedControl" schemes - which are often added after a plant has been in operationfor some years). For the purposes of compliance with the PES 2recommendations, It will be necessary to estimate consequences of failureof safety-related functions. This might also usefully include categorisationof systems (e.g. as per the EEMUA scheme).

3. Detailed Design Specification(s) for all PES. This includes:

a) Details of all cabinets, data highways and I/O channels, includingdetails of which cards, controller files etc. are used for whichchannel. Planned cabling routes should also be defined.

b) Alarm and trip schedules.

c) Communications links, speed, type and direction(s).

d) Use made of program storage media (disk, PROM, optical etc.)

e) Provision for failure detection (watch-dog(s), cross-checking etc.)and switchover (including normal status of standby machines).

f) Arrangements for power supplies and control room utilities (heating,cooling, ventilation).

g) Environmental protection (against fire, flood, over-pressure, gasrelease etc.)

h) Security considerations and prOYisions for software modifications(passwords, keys, change-oontrol procedures, back-uparr.angements, control room access etc.)

- Page 14 -

3.5 Team Composifum

If CHAZOP is fully integrated with HAZOP then the essential requirement is to ensurethat at least one member of the team is knowledgeable about the computer systems- this obviously applies to both Stage 1 and 2 CHAZOPs. During the survey, somecompanies stated that this was already current practice, but in some cases HAZOPteams seem to lack anybody with specific computer knowledge • althoughinstrumentation specialists are more common.

For Stage 1 CHAZOPs (and on small projects with a reasonably manageable team,for both stages) It may simply be more efficient to keep the same team for all HAZOPand CHAZOP activities· integration of the two activities is easier to justify.

On larger projects (perhaps involving outside plant contractors and/or computersystem vendors and/or consultants) It becomes more difficult to integrate HAZOP andCHAZOP because:

a) the team size may already be larger than desired.

b) it may be impractical to require all members of the team to be present forall meetings when, for example, some of the process engineering specialistsfind they have little to contribute to CHAZOP • and may have to travel longdistances to be present at meetings.

One solution noted during the survey was simply to depute one member of theCHAZOP team to be part of the HAZOP team and act as link-man. Even this hasdrawbacks on large projects with multiple HAZOP teams operating in parallel.

It should be noted that none of the companies surveyed seemed to be completelysatisfied with HAZOP/CHAZOP integration on larger projects - and several noted thatthey were ''feeling their way". in this area.

3.6 RetrofitPro~

It is now quite common to retrofit a computer to an older plant (or to upgradecomputer systems after, say, 10years of operation). In this case the 2-step procedurerecommended here does not really apply. It may still he/pto carry out the Stage 1Preliminary CHAZOP • particularly If the plant was never HAZOPed at all - but therewill not usually be much of an opportunity for major changes to the plant hardware.The PES guidelines do still apply • It would be difficult to argue that the guidelinesdon't apply simply because an existing (possibly unsatisfactory) design had been re­engineered using more modem equipment.

It therefore seems appropriate to carry out the Stage 2 full CHAZOP' for all retrofitprojects. If the plant had never been HAZOPed it would also be advisable to carry out .a HAZOP at this stage.

- Page 15 -

Section 4 PROCEDURES AND GUIDEWORDS

The conventional HAZOP is characterised by it's procedures and guidewords. It isrecommended that a similar framework be applied for CHAZOP • although in practice,guidewords are mostly appropriate to the Stage 2 Full CHAZOP.

The procedure recommended is an amalgam of those practices described during thesurvey. It is not a single "tried and tested" procedure. There are many places wherevariations are possible although these are not included because they would inevitablyhave the effect of making the description more fragmentary. For those companieswtro are already spending considerable effort in CHAZOP-like activities. the intentionis that the procedures below be treated as a framework for comparison with their ownmethods. It is also stressed that the procedure described is intended to be generallyapplicable whereas existing techniques may be more easily applied within the particularenvironment where they were developed.

4.1 Preliminary CHAZOPs

For Stage 1 Preliminary CHAZOPs there will not generally be enough detail availableto apply a procedure that is as strongly oriented to guidewords etc. as the conventionalplant HAZOP. It is tentatively recommended that the following issues should beconsidered:

1) Proposed architecture of system (if this is already provisionally agreed).This will include types of machines, basic functions and consideration ofhow this architecture will support redundancy and/or diversity. Thearchitecture must include both PES and non-PES where both contribute insome part to assuring the safety of the plant.

2) A review of expected safety-related functions. Even at this early stage theoperating conditions and chemicals used should give a reasonable view ofthe most critical safety functions.

3) A brief review of expected performance when:

a) One of the systems fail (e.g. a PLC or DCS machine).

b) Site power failure and/or other lJtJlities failures occurs.

This whole review should be part of the early plant HAZOP studies. Since guidewordsare not recommended it is suggested that one member of the tearn be deputed toprepare a brief presentation covering the above points. For normal QA reasons thisinitial presentation should be documented with any relevant diagrams etc.

- Page 16 -

4.2 Full CHAZOPs

The basis of the procedure outlined below.is to go through the PES gradually buildingup a detailed view of how the systems are intended to work and what will happen ifthey fail.

4.2.1 Computer System/Environment

Consider random failures of:

• a) cabinets, crates! field stations, etc. I

b) controller, 110 cards etc.

c) highways and communications links

d) operator (and other) consoles

e) power supplies and filters·

f) watch·dog timers etc.

g) other utilities (instrument air, drive power, heating, ventilating etc.)

In each case:

a) What should happen?

b) Will the operator know?

c) What should he do ?

d) Any changes needed ?

Consider gross failure of a whole machine (DCS or PLC or mini etc.):

a) W~at should happen ?

b) Will the operator know?

c) What should he do ?

d) Is there any way the failure could propagate to other machines and/orprotective systems?

e) Any changes needed?

- Page 17 -

The aim of the questions above is'to give the team a clear view of:

a) System architecture, induding (potentially disruptive) links with other systems.

b) Computer (not overall PES) failure modes.

c) Possible recovery actions.

It is suggested that the designer simply presents the information required to the restof the team with the aid of diagrams etc.

This section should not be particular1y time-consuming and might be omitted altogetherif the team had already considered the same hardware previously on other projects.

~.2.2 InpuVOutput signals

For each input signal consider, where appropriate:

a) Is the signal used for any safety-related function{s)? If so:

i) The function{s) is briefly reviewed (unless this has already beendone earlier, in the same session, for some other signal).

Ii) Any back-up (Le. redundancy) should be noted.

iii) The I/O card (or equivalent) is noted.

b) LOW signal

c) HIGH signal

d) Invariant signal

e) Drifting signal

f) BAD signal (e.g. detected as BAD by a DeS - possibly in another system).

In each case:

a) Does it matter?

b) Will the operator know?

c) Is there any action required by the operator or other systems? ,

d) Any modifications required?

- Page 18 -

For each actuator consider where appropriate what happens if:

a) DRIVEN HIGH and/or FAILURE HIGH

b) DRIVEN LOW and/or FAILURE LOW

c) FAIL TO MOVE ON DEMAND (known variously as STUCK, INVARIANTetc.) .

d) DRIFTS

In each case:

a) Does it matter"?

b) How will the operator know?

c) What action needs to be taken by operator and/or other systems?

d) Any changes needed ?

For many I/O signals that are used for monitoring and non-safety-related controlloops, these questions can be answered quickly.

4.2.3 Complex Control Schemes

For Complex Control Schemes it is recommended that the schemes themselves beused as the basis for organising the procedure. For each scheme the designer

. should outline it's function(s) and method of operation.

The team should then systematically review the scheme against each of the followingheadings:

a) It's purpose and method of operation. This should include reference toany HAZOP actions and specifically note any safety-related functions.

b) I/O signals used. These should have all been considered indiViduallyearlier in the procedure and I/O cards etc. noted.

c) Points of operator access (e.g. set:points, parameters that may be changed,cascades that may be made or broken etc.)

d) Umits applied (set-point, output, output rate-of-change).. Careful use oflimits gives a good safeguard and/or early warning that a control algorithmhas failed.

~ Page 19-

e) Interaction with other schemes, at start-up, during normal operation (includingtransients during load and/or set-point changes) and at shut-down. Anysynchronization and/or timing issues within the scheme should also beincluded. Any expected and/or required operator actions should also beconsidered.

1) Controller Tuning,lnitialisation and Wind-up considerations.

g) Relationships with trips and alarms.

h) Scheme performance monitoring.

i) Action in the event of major plant upsets. This includes loss of utilities andspurious or correct operation of Emergency Shut Down (ESD) valves. Thiscan be quite different from the efects of single variable changes consideredunder section 4.2.2.

j) Protection against unauthorised modifications.

k) For safety-related functions, failures of I/O cards etc. used for more thanone signal should be considered.

I) OTHER! This includes issues such as the effects of spreading a largescheme over more than one controller file (or equivalent) - what happens ifone file fails and the other doesn't ?

4.2.4 Batch Systems

For Batch systems the points in section 4.2.3 above will need to be considered ateach stage of the sequence. This can be very time-consuming - but is simply areflection of the fact that the system has to cope with many different circumstances.Each different circumstance provides opportunities for failure that might not havebeen considered elsewhere. Timing and synchronization must also be carefullyreviewed (under "Interaction with other schemes'~.

4.2.5 Protective Systems

For Protective Systems the points in section 4.2.3 should again be used - althoughnot all will apply.

- Page20 -

4.3 Reporting

Normal QA requirements indicate that some record be kept of all decisions. ''Traceability''will also require that documentation used in the decision will also be preserved. Thetraditional approach to HAZOP reporting has been to only report the "Actions". Thisappears to have been overtaken by events.

It is recommended that brief records be kept of responses to all the points notedabove. For the I/O points this will probably only consist of "Checkboxes" on astandardised sheet. For the more complex considerations the reporting should moreclosely follow the style used in conventional HAZOP reporting forms.

It is also recommended that any parts of the system that are very sensitive toalteration in the future should be documented. (An example might be an "enhancemenf'that would give an improvement in operab~ity under normal circumstances but seriouslycompromises safety under fault conditions). The implication is that such modifications,whilst not being prohibited from consideration, should only be contemplated whendue account has been taken of HAZOP and/or CHAZOPfindings. It would clearly bewise to go through that part of the C,HAZOP again when any modification is proposed• following the conventional wisdom that even "small changes" to plant should beHAZOPed.

- Page 21 -

Section 5 SUMMARY AND CONCLUSIONS.

5.1 Summary

All of the companies surveyed were aware of the PES.guidance documents althoughit appeared that the approach advocated was not having a strong influence onprojects. The EEMUA and IGE documents were less widely known and again, littleevidence was found of widespread use. (It is however recognised that both documentshave been available for a more limited period and that the survey carried out on thisprC?ject was by no means comprehensive).

There is also a tendency in some companies (not all) to design the plant and thendesign the PES(s) that monitor and control it. It must be recognised that the PES isan integral part and not an add-on extra that can be dealt with in isolation. If this isrecognised then many potential PES problems can be identified early in design andeliminated or reduced by changes in the plant hardware. Use of "Inherently Safe"plants is much more attractive than using PES to add ''bolt-on'' safety to a poordesign.

Several of the companies interviewed had reasonably structured approaches "to theproblem of HAZOP of PES-based systems - but there was very little commonality in

.terms of timing, procedures or guidewords. There also appears to be a tendency to"turn inwards" and "do your own thing" - because of a real or imagined lack ofpracticality in the published guidance. This is considered most disappointing and,more importantly, potentially serious - since it means that:

1) There is little interchange of information between companies.

2) Some companies are avoiding PES-based systems altogether· and thismeans that the potential for safety improvements cannot be realised.

3) It will take longer for workable "Standard Practices" to emerge. Standardsare important in the development of robust and reliable systems and areseen as being particularly desirable where safety-related systems areconcerned.

Whilst there was a reasonable consensus that PES HAZOP was desirable there was·no clear concesus on when it should be carried out. It may be that Oike theconventional HAZOP) the timing and procedure can be successfully applied at manydifferent stages • depending on the nature of the project and company culture.Notwithstanding this lack of agreement, this report tentatively recommends a 2·stageComputer HAZOP (CHAZOP) procedure:

- Page22 -

1) Preliminary CHAZOP • very early in the plant· life-cycle. The main aims ofthis step are to:

a) Analyse the hazards.

b) Identify the safety-related syst~ms.

At this preliminary stage, it is unlikely that sufficient detail is available tocomplete either of these tasks - but it should be possible to establishexpected requirements for redundancy, diversity and overall architecture.

2) Full CHAZOP • after coding is complbte. The main aims of this stage areto:

a) Evaluate the design in much more detail.

b) Confirm the findings of the Preliminary CHAZOP.

It is strongly recommended that HAZOP and CHAZOP should be tightly integrated.even though this may cause some organisational problems. It appeared that many ofthe companies interviewed were aware of this need but had been unable to achieve.asatisfactory integration as yet. ..

It must be stressed that the recommended 2-stage procedure is an amalgam ofexisting practices. Some companies are already using procedures that are moreextensive than those recommended here - although this is seen as part of a generalQA programme rather than being simply safety-oriented. It is not yet clear if the .majority of medium-sized process industries companies (the targets of this study) Y(illattempt to obtain BS 5750 certification. If this does happen then the recommendationsmade in this report should appear even more necessary. although they may need ~o

be tailored and/or extended to fit into a wider CA framework.

It is not suggested that those companies already using HAZOP-style techniquesshould change to the 2-stage system recommended here. The guidance given hereis intended mainly for those companies who are currently doing very little in the wayof PES HAZOPs or have hitherto avoided use of PES for safety-related applications. Itis however recommended that companies examine the proposed procedures andguidewords to see if there are any obvious discrepancies with methods currentlyemployed.

The report also contains recommendations for CHAZOP preparation and CHAZOPteam composition.

• Page23 -

5.2 Other Recommendations

There is a definite tendency in some companies to avoid using PES - even though insome cases the resulting systems are likely to be less safe. This must be a concernfor HSE. Perhaps it would help if more efforts were made to publicise sucgessfulapplications and/or be more active in pointing out problems with existing plants thatdo not take advantage of PES technology. It is recognised that this is not easy toachieve - but the benefits are both real and worthwhile.

The lack of information interchange between companies needs attention. There is an"inner circle" of companies and individuals who are well aware of current developments- but there are also many companies who do not seem to be anywhere near as well­informed. It is recommended that consideration be given to promoting some kind ofForum or Club that would facilitate:

1) Incident reporting • rather like the ICI Safety Newsletter approach.

2) Reporting of known problems and bugs in vendor firmware and/or software..

3) Better dissemination of standard practices and design methods.

A) A more general awareness of available literature etc.

It is recognised that HSE might be unwilling to want to organise such a facility - but itcould be active in stimulating it's creation and/or in persuading industry to support it.

5.3 Conclusions

1. The survey was by no means comprehensive (it was never intended to beso) but did give some useful insights into current industry practices. Thelack of a common approach was immediately apparent.

.2. HAZOP can be applied to PES-based systems and current practices insome companies conform to the philosophy of the conventional plantHAZOP.

-3. A methodology has been tentatively recommended in this report. It isstressed that this methodology is DQ! taken from any particular currentcompany practice, but is an amalgam of practices in use In variouscompanies. It is strongly recommended that the proposed proceduresand guidewords be tested before wider dissemination.

4. There is a need for open discussion of practices, problems, known bugsetc. - (see section 5.2). We need abetter forum to stimulate this kind ofactivity.

• Page24 •

Section 6 ACKNOWLEDGEMENTS

This project was initiated during discussions with Dr. Tom Maddison of HSE. He wasthe driving force behind it's inception and funding by HSE. His help was muchappreciated.

This report could not have beEln prepared without the considerable input from usersin industry, their views, suggestions, time and willingness to co-operate were muchappreciated. The whole report is based on their comments given during the survey.Particular thanks are due to Mr. Andrew Ogden-Swift (of Simcon UK) and mycolleagues at KBC Process Technology for participation during the survey and commentson the draft report. .

The author also gratefully acknowledges advice, encouragement and feedback 'fromMr. Gordon MacDonald of HSE who coordinated and managed the project.

- Page25 -

Section 7 REFERENCES

1. "Programmable Electronic Systems in Safety Related Systems. 1. An IntroductoryGuide", (1987), available from Her Majesty's Stationery Office, London.

2. "Programmable Electronic Systems in Safety Related Systems. 2. General TechnicalGuide-lines", (1987), available from Her Majesty's Stationery Office, London.

3. "Use of Programmable Electronic Systems in Safety Related Applications in the GasIndustry", IGE/SR/15 (1989), available from The Institution of Gas Engineers, 17Grosvenor Crescer:lt, London, SW1 X 7ES.

4.· "Safety Related Instrument Systems for the Process Industries (IncludingProgrammable "Electronic Systems)", Publication No. 160 (1989), available fromThe Engineering Equipment and Materials Users Association, 14-15 Belgrave Square,London, SW1X 8PS. .

5. T. A. Kletz, "HAZOP and HAZAN· Notes on the Identification and Assessment ofHazards", (1983), available from The Institution of Chemical Engineers, 165-17.1Railway Terrace, Rugby, CV21 3 HO.

6.H. G. Lawley, "Operability Studies and Hazard Analysis", (1974), Chem. Eng. Prog.

7. "A Guide to Hazard and Operability Studies", (1977), Chemical Industries Association,Alembic House, 93 Albert Embankment, London SE1 7TU.

8. T. A. Kletz, "Cheaper, Safer Plants or Wealth and Safety at Work", (1984), availablefrom The Institution of Chemical Engineers, 165-171 Railway Terrace, Rugby, CV213 HO.

- Page26 -

Step 1: Analyse the hazards:

a) Identify the potential hazards;

b) Evaluate the events leading to thesehazards.

Step 2: Identify the safety related systems, that is,those systems on which the safety integrityof the plant is to be assured and whose failureare included in the .events leading to thehazards identified in Step 1 above. It is atthis stage that it becomes possible todetermine whether this document (Le. thePES 2 document) applies.

Step 3: Decide on the required level of safety integrityfor the safety related systems.

Step 4: Design the safety related systems using the. safety criteria appropriate for the specific

application.

Step 5: Carry out a safety integrity analysis to assessthe level of safety integrity achieved by thesafety related systems.

Step 6: Ensure, from the analysis carried out in Step5, that the specific safety integrity level (Step3), has been achieved.

Figure 1. Design and Assessment General Framework

• Page27 -

Stage Advantages Disadvantages

A) Process Flowsheet Big changes easy. No detail available.

B) P & IDs complete Good for defining May be too many options.requirements?

May get "committeedesign".

C) Completion of Coding Flowcharts and Code late - changes may causeavailable. major delays.

May be best if outside Very costly to make largevendor used. changes.

Figure 2. Stages when Computer HAZOP may be Applied

. - Page28-

APPENDIX'1

MAIN SURVEY FINDINGS

This Appendix attempts to highlight some of the survey findings. It is emphasised thatthis is not intended to be a comprehensive 'listing of all the points made duringinterviews and should not be considered as "representative" of current practices(since the number of interviews was small and the companies interviewed were, at thevery least, biased by 'being agreeable to taking part).

A.1.1 Attitudes to PES

1. The interviews with industry practitioners showed that there are a wide variety ofapproaches to the design and implementation of PES-based systems in safetyrelated applications. As noted earlier, all companies interviewed were aware of thePES documents but few seemed to be using them in the manner intended. Somecompanies expressed doubts that the existing advice was practical· a view that itwas too stringent was fairly common. In some cases companies were using the"2nd tier" guidance from IGE or EEMUA - but this was not very widespread.

2. Attitudes to use of PES varied widely. Some companies took the view that theywould always use a PES unless there was a very good reason not to do so ­including use for safety-related functions. One line of reasoning used was that theoverall hazard rate was dominated by failures of the plant and that consequencesof failure of the PES were more than balanced by it's effectiveness at handling theplant failures. Others tended to avoid PES for any safety-related functions unless

-they were very difficult to accomplish with conventional hardware.

A.1.2 Methodology

1. One strategy used in some companies (large and small) was to have one c:ontrolengineer who "owned" the project throughout It's life-cycle. The same personwould take part in plant HAZOPs, do design work and carry this through configuration,testing and commissioning. The obvious advantage is less opportunity for errorscommunicating with other members of a team. The disadvantage is that specificationerrors are less likely to be spotted later in design, implementation and testing.Where one engineer "owns" a project the need for HAZOP may therefore be evenstronger. There may also be a tendency to provide less documentation· and this

,would obviously be counter-prodUctive.

2. Some companies surveyed were adopting the recommendation (from PES 2) thatdifferent people would specify, write and test software for diverse hardware.

- Page29 -

3. Use of formalised software design and development appears to be rare - asexpected. The use of written specifications is increasing. A contrast here was thatsome companies believe that system-independent specifications are essential inthe early stages whilst others. went straight to system-dependent specifications.No company mentioned use of an Integrated Project Support Environment althoughsome did actively support formalised design methodologies. The STARTS guidewas mentioned by two complinies but did not seem to be particularly well-known.There was some use of PC-based tools for Flowcharting. No company claimed tobe using configuration management tools at the present time, although this issuewas raised in connection with both implementation and system maintenance. Onecompany had spent a considerable effort reviewing Formal Methods and StaticAnalysis techniques. There are obvious weaknesses at the present time (e.g. multi­tasking I) but some promise for the Mure. (It should be noted that some of thesame companies were using techniques like SSADM in Data Processing applications,hence it is concluded that the required corporate enthusiasm does exist - even ifthe methodologies are currently lacking).

A.1.3 Specification and Design

1. A number of companies were using check-lists that were somewhat lesscomprehensive than HAZOP but nevertheless were of obvious benefit. These useidentified "Critical" functions, typically including:

- complete air failure

- complete electrical failure

- emergency cooling failure

- high temperature

- high pressure

The check-list may be customised for the kind of operation typically encounteredby the company concerned.

2. It is important to aim to design a fail-safe~ - instrumentation Qncluding anyPES) is extra. This is seen as a very good strategy, very much in line with TrevorKletz's 'What you don't have can't leak" theme (see Reference 8). Some of thecompanies surveyed aimed to design plants that could tolerate total PES loss forseveral hours. .

• Page30 •

3. Another common device is to use comparatively simple machine architectures:

a) Avoid disks etc. All code is in non-volatile memory.

..b) Use machines with no operator screens (although an engineer or programmermight be able to attach a terminal for changes etc.).

c) Some PES perform critical functions only. This helps to reduce complexityof hardware and software/firmware. For example, a simple PLC with itsmore limited software is used by many companies. (Note that this doesnot preclude the possibility that other PES in the same overall system willhave safety-related functions in addition to other functions - as indicated inPES 2).

4. A number of users also stressed the advantages of restricted communications linksto other machines. Users may avoid high-speed serial and/or parallel links infavour of slower serial links. "Read only" access to control machines from informationsystems is often used. In some cases all communications can only be instigatedby the control machine. In the extreme, communications do not rely on hand­shaking - data is simply transmitted from the control machine at a rate that shouldbe acceptable at the other end. .

5. Another strategy is to use conventional (non-PES) hardware for safe plant shut­down that can only be used in the event of PES failure. Interlocks prevent thehardware being used while the PES is still in operation. The rationale is that theoverall hazard for PES use is lower than that where there is an additional potentialfor errors etc. with the conventional hardware. (Note that this is quite different thanusing a strategy where the system safety is normally ensured by non-PES means.In such a case the PES documents guidance does not apply). The pre-requisitefor conventional hardware that can be locked-out by the PES is that PES failuredetection must be highly reliable - or PES failure might result in a situation where'the non-PES hardware is not available to the operator.

6. A number of companies used redundant sensors for important variables whilstothers claimed to use no redundancy at all. Where redundant sensors were usedthere was also recognition that these should be connected to the PES via separateinterface cards etc.

7. Some companies surveyed also recognise good reaSOns for separating safety­related and other functions - even when only a single PES Is used. Extra tripsetc may be implemented in parallel with the main control logic. Simple boolean­style logic may be used for this extra layer of protection.

- Page 31 -

8, There were also wide variations in attitude to alarms. Some users expected to useas alarms regularly for minor deviations - and then have to allow the operators toreset them. Others treated alarms as conditions that should be highly unusual (the"black panel" concept) and would allow; reset only when keys were inserted.

9, As expected, it was fairly common to use hard-wired trips as "last ditch" protectionfor highly-critical functions - even wher.e most reliance was placed on PES for first'line protection.

A.1.4 Implementation and Testingi

1. Testing strategies varied widely. Some companies recommended extensive testingwith simulators (sometimes just a "logical" simulation rather than a full one). Othersrelied more heavily on testing the plant with water etc. - with obvious limitations.Simulation was 'also seen as essential by some companies where either:

a) Speed of response is important

or:

b) Advanced Process Control (APC) is being implemented

or:

c) Applications were added to existing systems such that the new apprJcationwas likely to push the plant close to a safety constraint and no hardware .protection is used. For.example, a new application may raise furnacebox pressure - but over-pressure protection is rarely provided,

2. Some companies were quite happy to "pull" boards during testing, others did so ona much more selective basis - relying more strongly on vendor assurances.

3. The accent on testing seemed to be higher because it was recognised that de'signpractices were less robust than with 'conventional systems.

- Page32 -

A.1.5 Use of Vendors

1. Many users, small and large, simplify system selection by having a list of "approved"suppliers (in extreme, a single DCS vendor). This has a number of clear advantages:

a) It reduces the per-project time spent on system selection.

b) Designers and implementers are able to learn about a particular system'sstrengths and weaknesses. This can reduce design and implementationtime and produce more robust systems.

c) Early knowledge of the likely system architecture will help the team toforesee problems (and solutions) during HAZOP.

d) Operators are more flexible if systems have a common interface.

e) It will be easier to justify having adequate spares available (e.g. spareOperator Stations for DeS). Some of the companies surveyed relied onbeing able to replace hardware very quickly, at any time of the day ornight.

f) It is easier to establish good links with vendor support staff.

There are however some disadvantages which should also be borne in mind:

a) Familiarity is double-edged - it can breed contempt if not properlymanaged. In the case of PES, it would be counter-productive if known

. system weaknesses were treated in a cavalier fashion.

b) The criteria for system selection can vary widely from one project toanother. A system that is ideal for one project might be very poor foranother. For example, a system that is good for continuous control maybe poor for batch sequences.

c) Users may become "locked-in" to one or more ·favoured suppliers· andfail to keep up with (or take advantage of) improvements from othervendors.

d) Problems may arise if 2 or 3 members of a small team are lost over ashort period of time. The effects of this reinforce the need for gooddocumentation and Change-control procedures.

/

During the survey, it was noted that some users found that the advantages of asingle supplier far outweighed the disadvantages - even when thll chosen vendorssupport staff were ''thin on the ground" in the UK

- Page33 -

2. Several of the companies interviewed were having coding work done by equipmentsuppliers. Some reservations were expressed 'about the practical difficulties ofadequately specifying and/or assessing such software. One example was quotedwhere there was a serious error in vendor-supplied software that had been "accepted"by the user and was only found by accident by a third party.

3. Where outside suppliers are used the use of QA was advocated, although it wasalso recognised that quite a lot had to be taken on trust. Where regular use wasmade of outside suppliers It was considered necessary to specify in detail minimumstandards, practices and procedures that should be employed. A Quality Plan wasalso required from the supplier. No company claimed to use only BS 5750certificated suppliers yet· although there was an expectation that this was not faraway in some cases. Similar supplier/client issues arise when a central teamsupplies software to other sites· some of which may be very remote.

4. Some of the companies surveyed also found that §!! PES software should be donein-house. This again has the advantage that familiar design and coding standardscan be used, allows expertise to build up and may reduce the problem of ''vetting''supplier software.

A.1.6 Operation and Maintenance

1. Some companies encouraged operators to "challenge" the system (e.g. by trying to"jump" steps in sequences) whilst others gave operators strict instructions not todeviate from planned usage patterns.

2. Few organisations seem to place much emphasis on Change Control procedures• a worrying aspect here is that '1he small change" is recognised as being potentiallyvery dangerous.

3. It was noted that problems with DeS sometimes arose because access to DeSconsoles is often poorly controlled and can lead to unauthorised/unplanned changeswhile schemes are on-line.

4. Many companies use "permit to work" systems for maintenance on the plant· butsimilar systems for software changes are few and far between.

'.

• - Page34-

APPENDIX·2

OTHER FINDINGS

The points below are included for various reasons:

a) Because they were unexpected.

b) Because they give cause for concern.

c) Because they are considered to be of some interest to potential users withno previous experience of PES.

1. It was apparent (confirmed in interview) that some companies take no account at allof the computer system during the plant HAZOP. Even where hardwired protectiononly is used (which puts the PES outside of the PES guidance) this seems badpractice since:

a) It effectively ignores the fact that a poorly-designed PES canplace a higher demand-rate on the protective systems.

b) It ignores effects of common-mode failures that cause multipleloops to fail simultaneously. Put another way, it does not givethe team the opportunity to consider how control functions beallocated across different PES I/O cards etc.

c) It ignores the effect of having some control functions spreadacross more than one I/O card. such that some actions maywork at a time when others fail.

2. There were also some doubts expressed about the use of HAZOP at all (particularlywhere human error considerations are relevant) • although this may say moreabout the composition and/or experience of the HAZOP team than about thetechnique.

3. The PES guidance recommends the use of numerical hazard analysis (sometimescalled HAZAN) where appropriate. Most of the companies surveyed did not doany numerical analysis and, in some cases, had fairly strong views that it was notnecessary. This seemed odd because some of the relevant calculations are verystraightforward. In the author's opinion this may be due. at least in part, to'a lackof control-oriented people with an appreciation of the benefits jlnd ,techniques ofhazard analysis.

- Page 35 -

4. A number of companies noted tliat the use of "standard practices and procedures"in general (not just for computer systems) was considered very important. A routeto improved design and implementation of PES is to establish more intemal standards.Experienced people are then able to achieve more by ensuring that:

a) Less experienced staff follow the standards for "routine" jobs.

b) Work is properly supervised by those who understand thelimitations of the standards.

c) There is provision for independent review (cross-checking) byother experienced people.

The increasing use of OA throughout industry is nkely to reinforce the need forstandard procedures and practices. Particular emphasis was placed on theadvantages of internal "monitors" and "starters". One comment was to the effectthat this was an area that was often either very poor or completely lacking in in­house software. Some companies are also using OA combined with a project life­cycle approach. This requires well-defined milestones, documentation at eachstage, formalised checks that requirements are met etc.

5. The "Barriers model" of protective systems was mentioned more than once. It wasnoted that the use of PES can cause the barriers to merge into one another whilstindependence is highly desirable. Separation of control and prQtection functions isimportant in this respect.

6. It was noted that one way to satisfy the PES documents requirement that no'system depends on a single PES channel was to use an independent "Saf~ty

. Monitor" to continually check PES output signals against input signals. The SafetyMonitor uses a truth table of allowed and illegal patterns of signals. If a PES fail~re

occurs that causes an illegal pattern then the Safety Monitor initiates a shut-down.The Safety Monitor sits in parallel with the PES and so provides diverse hardwareand software. The Safety Monitor itself uses only simple EPROM-based logic thathas been checked very carefully in order to give high safety integrity. Usedproperly, this architecture can give high reliability at reasonable cost without sacrificingthe flexibility of the user-programmed PES. .

7. There are some examples of replacement of traditional ha~Wired protective systemscompletely by (for example) a comprehensively tested, triplicated PES. A commentwas also made that non-UK vendors appeared to bemore willing to do this. It isnot clear whether this indicates p;lnservatism by U.K vendors, a higher concern forsafety or the restraining effect of the PES guide-lines.

8. Several comments were made about the desirability of "minimUm -standards" or"do's and don't's" from HSE - although the dangers of prescriptive legislation werealso recognised.

- Page36 -

9. Some users drew attention to the difference between systems that required lots ofcoding and systems that required configuration.. In general, configuration will bebetter - particularly for less experienced staff. The use of standard, well-engineeredcontrol schemes that are configured for various applications was considered to beadvantageous but not widely used.

10. Several companies used mains power without UPS back-up whilst others statedthat they always used an UPS, even though this was sometimes considered "overthe top". Standby generators were mentioned several times· but in each case itwas very much "cold standby". It was also noted that even where lightningprotection was provided some problems could still occur.

11. One comment was that little account seems to be taken of local legislation whenvendors sell into overseas markets.

12. It was also found that some users are very wary' of failure of vendor-suppliedwatch-dog timers. Two instances of failure were reported during the survey (witha relatively small number of operating years). This could be a statistical aberration,but is otherwise regarded as an unacceptably-high failure rate for a device withsuch a critical function. Some users are using tl'leir own watch-dog card il'1steadof (or in addition to) the vendor offerings. It cannot be good for the industry thatcompanies feel that they have to resort to this practice - and does not reflect wellon vendors. .

13. A common complaint during the survey was concerned with the need for morespecific guidance from HSE and/or better examples.

14. An instance was quoted of a simple operator error on DeS that had occurred andhad caused system failure. The vendor had allegedly queried why an operatorwould make that kind of error I It is not known if the vendor has taken anysubsequent action to remove the bug or make other users aware of it's existence.

- Page 37 -

IChemE

EEMUA

APPENDIX 3

SOURCES OF INFORMATION

The Health and Safety ExecutiveMagdalen HouseStanley PrecinctBootie .MerseysideL203QZ Tel: 051·951-4000

The Institution of Chemical Engineers165-171 Railway TerraceRugbyCV21 3 HQ Tel: 0788-578214

The Institution of Electrical Engineers·Savoy Hill HouseSavoy HillLondonWC2R OBS Tel: 071-240-1871

The Institution of Gas Engineers17 Grosvenor CrescentLondonSW1X 7ES Tel: 071·245-9811

British Computer Society13 Mansfield StLONDONW1M OBP Tel: 071·637·0471

Chemical Industries AssociationAlembic House93 Albert EmbankmentLondonSE1 7TU Tel: 071-834-3399

The Engineering Equipment and Materials Users Association14-15 Belgrave SquareLondonSW1X 8PS Tel: 071-235-5316/7

- Page 38 -

Available from HSE Sales PointRoom 414

Sf Hugh's HouseStanley Precinct

Trinity RoadBootie

MerseysideL203QY

Telephone; 051-951 4450

iSBN 0 7176 0367 9

ISBN 0-11-885977-3