Lopa for Sil

Layer of protection analysis for determiningsafety integrity level

Arthur M. Dowell III *Rohm and Haas Company, 6519 LaPorte Freeway, Deer Park, TX 77536, USA

Abstract

This paper describes the Layer of Protection Analysis (LOPA) method for determining the needed SIL (SafetyIntegrity Level) of a SIS (Safety Instrumented System). The paper also shows the relationship of LOPA to other ana-lysis methods for safety system requirements. Building on the CCPS (Center for Chemical Process Safety) Guidelines

for Safe Automation of Chemical Processes, this paper shows how to determine if additional safeguards are needed andhow to determine the needed SIL of a SIS. LOPA is a tool that can be used after the HAZOP (HAZard and OPer-ability Analysis), but before using fault tree analysis or quantitative risk analysis. Using a multi-disciplined team, the

consequences identi®ed in the HAZOP are listed as impact events and are classi®ed for severity level. The initiatingcauses are listed for each impact event and a likelihood is estimated for each initiating cause. Independent ProtectionLayers (IPLs) are listed, including process design, basic process control system, alarms and procedures, safety instru-

mented systems, and additional mitigation. Each IPL is assigned a Probability of Failure onDemand (PFD). Amitigatedevent likelihood is calculated by multiplying the initiating cause likelihood by the PFDs for the applicable IPLs. Themitigated event likelihood is then compared to a criterion linked to the corporation's criteria for unacceptable risklevels. Additional IPLs can be added to reduce the risk. The mitigated event likelihoods are summed to give an estimate

of the risk for the whole process. # 1998 Elsevier Science Ltd. All rights reserved.

Keywords: Alarm systems; Design guidelines; Documentation; Emergency shutdown system; Fault tree analysis; Final element;

Instrumentation; Interlocks; Modeling; Probability of failure on demand; Qualitative; Quantitative; Reliability; Reliability data;

Safety; Sensors; Standards; Systems design; Unavailability

1. Introduction

In the Safety Life Cycle outlined in ANSI/ISA-S84.01-1996 [1], steps are included to determine ifa SIS (Safety Instrumented System) is needed andto determine the target SIL (Safety IntegrityLevel) for the SIS. The SIL is de®ned by the PFD(Probability of Failure on Demand) of the SIS(Table 1). S84.01 gives guidance on building an

SIS to meet a desired SIL; Green and Dowell [2]outline how to set standard SIS designs. How doesone determine what SIL is appropriate for a par-ticular process?

Undesired events and their causes are identi®edin a Process Hazard Analysis. For an undesiredevent, several methods are in use in the processindustries to determine the required SIL.

1. The modi®ed HAZOP (HAZard and OPer-ability analysis) method in CCPS [3] and inthe informative annex of S84.01 [1] really

ISATRANSACTIONS1

ISA Transactions 37 (1998) 155±165

0968-0896/98/$19.00 # 1998 Elsevier Science Ltd. All rights reserved

PII: S0019-0578(98)00018-4

* Tel: 001-281-228-8258; fax: 001-281-228-8159;

e-mail: [email protected]

depends on the team comparing the con-sequence and frequency of the impact eventwith similar events in their experience, andthen choosing an SIL. If the event beinganalyzed is worse or more frequent, thenthey would choose a higher SIL. This analy-sis is usually qualitative; it is very much inthe experience and judgment of the team.Thus, the SIL chosen may depend more onwhether a team member knows of an actualimpact event like the one being analyzed, andit may depend less on the estimated fre-quency of the event.

2. The safety layer matrix listed in CCPS [3]and in the informative annex of S84.01([1], p. 49) uses categories of frequency, severity,and e�ectiveness of the protection layers.The categories are described in general termsand some calibration would be needed to getconsistent results. The matrix was originallydeveloped using quantitative calculationstied to some numeric level of unacceptablerisk [4].

3. The consequences-only method (mentionedin [1]) evaluates only the severity of theunmitigated consequence. If the severity isabove a speci®ed threshold, a speci®ed SILwould be required. This method does notaccount for frequency of initiating causes; itassumes all causes are `likely'. It is recog-nized that this method may give a higherrequired SIL than other methods. The per-ceived trade-o� is reduced analysis time. Onother hand, for events whose causes have ahigh frequency, this method could give alower SIL.

4. The fault tree analysis (FTA) method [1]quantitatively estimates the frequency of theundesired event for a given process con®g-

uration. If the frequency is too high, an SISof a certain SIL is added to the design andincorporated into the FTA. The SIL can beincreased until the frequency is low enoughin the judgment of the team.

5. Layer of Protection Analysis (described inthis paper) uses semi-quantitative categoriesfor impact event severity, numerical esti-mates of initiating event frequency, andnumerical values of PFD for each layer ofprotection. The initiating event frequency ismultiplied by the PFD for each applicablelayer of protection to calculate the mitigatedevent frequency. The SIL of an SIS can beincreased until the mitigated event frequencyis less than a target based on the corpora-tion's risk criteria. LOPA is more quantita-tive than modi®ed HAZOP, safety layermatrix, and consequences only. For a smalladditional e�ort beyond these methods,LOPA shows clearly the assumptions andreasoning for the needed SIL. LOPA isdesigned to be slightly conservative. If needed,FTA can be done for complex or specialsystems. LOPA ®ts well after HAZOP andbefore FTA.

2. What analysis is really needed?

Each method to determine SIL attempts to dealwith the following issues, either explicitly orimplicitly:

. the severity of each consequenceÐ®res, injur-ies, fatalities, environmental damage, etc.

. the likelihood, or frequency, of each initiat-ing cause of the undesired eventÐchallengeoccurs x times per year.

. the capability of non-SIS layers of protec-tionÐno layer of protection is perfect; forexample, a pressure relief valve may fail toopen 1 out of 100 times it is challenged.

. the frequency of the mitigated event com-pared to a target frequencyÐif the frequencyof the mitigated event is low enough, the riskis viewed as tolerable. The more severe theconsequences, the lower the target frequency.

Table 1

Safety integrity level (SIL) [1]

Safety integrity

level (SIL)

Probability of failure

on demand average range (PFD avg)

1 10ÿ1 to 10ÿ2

2 10ÿ2 to 10ÿ3

3 10ÿ3 to 10ÿ4

156 A.M. Dowell III/ISA Transactions 37 (1998) 155±165

Inconsistency in determining SIL often comesfrom a lack of clarity for the frequency of theinitiating cause and the target mitigated eventfrequency for which the risk is viewed as tolerable.These issues may be handled implicitly with indi-vidual team members having a di�erent perceptionof the frequencies and the risk level that is toler-able. Some methods listed in the introduction donot deal with the causes explicitly, some do notdeal with the frequencies of causes explicitly, andsome do not deal with the target frequency for arisk level that is tolerable. Yet each team memberis doing some sort of intuitive, internal analysisthat asks:

. How bad is it?

. How often could it be caused?

. How e�ective will the layers of protectionbe?

. Is the mitigated event frequency intolerableor not?

Some companies have published guidelines forthe risk the process imposes on the community [5],industrial neighbors, and employees. These guide-lines can be used to establish criteria for the SILevaluation as shown later in this paper.

On the other hand, many companies have notpublished guidelines for the risk the processimposes on the community, industrial neighbors,and employees. However, for various processcon®gurations, decisions are still made to applyfurther risk reduction via design change or addi-tional IPLs, or not to apply additional risk reduc-tion (i.e., risk is tolerable). This information canbe converted to targets for use in determining SIL.The target could take the form of the number ofIPLs and the SIL value required for a given con-sequence severity and challenge frequency.

What is needed is a way to determine therequired SIL rationally and consistently amongindividuals, teams, projects, and companies.

3. Layer of protection analysis (LOPA)

LOPA is built on concepts from Chapter 7 ofCCPS [3]. This paper is based on more than 5years' use of the technique.

LOPA uses a multi-disciplined team, like aHAZOP team. Knowledgeable representatives areneeded from:

. OperationsÐoperator, foreman

. Management

. Process Engineering

. Control Engineering

. Instrument/Electrical (craftsman, foreman,or engineer)

. Risk Analysis (hazard evaluation specialist)

At least one person must be skilled in the LOPAmethodology. One of the team members should beskilled as a meeting/team facilitator.

A HAZOP (or other hazard identi®cation pro-cedure) is done ®rst. HAZOP tables usually listDeviations, Causes, Consequences, Safeguards,and Recommendations. The HAZOP table mayalso include estimates of the Frequency for eachCause and Severity for each Consequence. Withthese estimates a risk matrix can be used to esti-mate Risk for a Cause±Consequence pair [6]. Fig.1 shows the HAZOP information and the LOPAinformation in graphical form. The solid linesshow the sequence of the HAZOP or LOPAdevelopment. The dotted lines show how HAZOPinformation is transferred to the LOPA. A sampleLOPA table is shown in Fig. 2.

3.1. Impact Event classi®cation

Each Impact Event from the Hazard Identi®ca-tion is classi®ed for Severity Level and MaximumTarget Likelihood for the impact event usingTable 2. The Impact Event, Severity Level, andMaximum Target Likelihood are written into col-umn 1 of the Layer of Protection Analysis form(Fig. 2).

3.2. Initiating Cause

For each Impact Event, the team lists all theInitiating Causes in column 2 of Table 2. Notethat a HAZOP Consequence may be listed in sev-eral sections of the HAZOP. It is important togather all the Causes. The remaining calculationsare carried out for each Initiating Cause for eachImpact Event.

A.M. Dowell III/ISA Transactions 37 (1998) 155±165 157

Fig. 1. Relationship between HAZOP and LOPA information.


Fig.2.Layer

ofprotectionanalysis.


3.3. Initiating Cause Likelihood

For each Initiating Cause, the team ®lls in theChallenge (Initiating Cause) Likelihood in column3, Fig. 2, with units of events per year. TypicalInitiating Cause Likelihoods are shown in Table 3.The team uses its experience to estimate the Initi-ating Cause Likelihood. The Initiating CauseLikelihood is also called the frequency of thechallenge.

3.4. Rules for IPLs

1. Each protection layer counted must be trulyindependent of the other protection layers.That is, there must be no failure that candeactivate two or more protection layers.

2. The frequency reduction for an IPL is twoorders of magnitude, i.e., 10ÿ2 PFD (that is,the availability is 99%).

. Exception: Risk reduction for OperatorResponse to Alarms is one order of mag-nitude, i.e., 10ÿ1.

. If an IPL is believed to be more reliable(lower value for PFD), a Quantitativemethod should be used to con®rm thePFD. (For example, if the team desires toimprove the unavailability of risk reduc-tion logic in the BPCS (Basic ProcessControl System) by adding additionalsensors or ®nal elements, the impact eventshould be reviewed by a quantitativemethod such as fault tree.)

3. The IPL is speci®cally designed to prevent ormitigate the consequences of a potentiallyhazardous event.

4. The IPL must be dependable; it can becounted on to do what it was intended todo.

Table 3

Typical Initiating Cause likelihood

Initiating Cause Likelihood

Control loop failure 1.0�10ÿ2 events per yearRelief valve failure 1.0�10ÿ2 events per yearHuman error (trained, no stress) 1.0�10ÿ2 events per number of times task was done

Human error (under stress) 0.5 to 1.0 events per number of times task was done

Other initiating events Use experience of personnel, e.g. CTW pumps trip twice a year,

total power failure once every 2 years

Table 2

Impact Event severity levels and Target Mitigated Event likelihoods

Impact Event level Consequence Target Mitigated Event

likelihood (events per year)

Basis

Minor (M) Impact initially limited to local area of event

with potential for broader consequence if

corrective action not taken

Depends on the economics of life

cycle cost of additional layers of

protection versus cost of the

impact events

Serious (S) Impact event could cause any serious injury

of fatality onsite or o�site

1.00�10ÿ6 Corporate risk criteria

Extensive (E) Impact event that is ®ve or more times worse

than a serious event

1.00�10ÿ8 2 orders of magnitude

less than serious


5. The IPL will be designed so it can be auditedand a system to audit and maintain it will beprovided.

6. If the initiating event is caused by a failure inthe Basic Process Control System (BPCS),the BPCS cannot be counted as an IPL.

7. Alarms that are annunciated on the BPCSare not independent of the BPCS; if theBPCS is counted as an IPL, then such alarmscannot be counted as an IPL.

8. A control loop (PID loop) in the BPCSwhose normal action would compensate forthe initiating event can be considered as anIPL. For example, an initiating cause forhigh reactor pressure could be failure ofa local upstream pressure regulator; thenormal action of the reactor pressurecontroller would be to close the inlet PV,thus providing protection against the impactevent.

3.5. Independent Protection Layers andProbability of Failure on Demand

The team lists all the Independent ProtectionLayers that could prevent the Initiating Causefrom reaching the Impact Event. The IPLs may bedi�erent for di�erent Initiating Causes. The teamdetermines which protection layers are independent.

The team assigns a PFD (Probability of Failureon Demand) to each Independent ProtectionLayer, typical values are shown in Table 4. TheIPLs and their PFDs are written in columns 4±7 ofFig. 2.

3.6. Additional Mitigation

The team lists Additional Mitigation layers andassigns a PFD to each layer. A mitigation layerreduces the severity of the impact, but may notprevent all aspects of the event. Examples ofmitigation layers include: relief valves, rupturedisks, over¯ows to safe location, sensors to detecta release and an evacuation procedure, sensorsand automatic deluge system. Again, each layermust be independent. The Additional Mitigationlayers and their PFDs are written in column 8,Table 2.

The team should be sure to understand theseverity of the consequence of the mitigated event.An unmitigated event might be vessel rupture withtoxic release. It could be mitigated to toxic releasefrom a relief valve. If the severity of release fromthe relief valve is serious or extensive, it should beentered into the LOPA as another impact event.

3.7. Mitigated Event Likelihood

The team calculates the Mitigated Event Like-lihood by multiplying the Initiating Cause Like-lihood (column 3, Fig. 2) by the PFDs of the IPLs(columns 4±8) and enters the number in column10. The Intermediate Event Likelihood has unitsof events per year. The Intermediate Event Like-lihood is compared with the Target MitigatedEvent Likelihoods shown in Table 2.

If the Mitigated Event Likelihood is less thanthe Target Mitigated Event Likelihood, there areprobably enough IPLs to meet the Corporate Risk

Table 4

Typical Independent Protection and Mitigation Layer PFDs

Independent Protection Layer PFD

Control loop failure 1.0�10ÿ2Relief valve failure 1.0�10ÿ2Human error (trained, no stress) 1.0�10ÿ2Operator response to alarms 1.0�10ÿ1Vessel pressure rating above

maximum challenge from internal

and external pressure sources

10ÿ2 or better, if vessel integrity is maintained (i.e. corrosion understood,

inspections and repairs in place)

Other events Use experience of personnel, e.g. CTW pumps trip twice a year, total

power failure once every 2 years


Criteria and additional IPLs may not be required.(However, further risk reduction may be desirable.)

If the Mitigated Event Likelihood is more thanthe Target Mitigated Event Likelihood, then addi-tional risk reduction is probably needed. The teamshould seek to reduce the risk, ®rst by applyinginherently safer concepts, and then by applyingadditional layers of protection. The LOPA tablewould be updated for the design changes.

3.8. Number of IPLs

The number of Independent Protection Layersis entered in column 9, Fig. 2. Serious and ExtensiveImpact events normally require at least two IPLs.

3.9. SIS needed

If the team ®nds that an SIS is needed to meetthe Target Mitigated Event Likelihood, the teamenters the SIS description in column 7 and assignsit a PFD. The SIL is entered in column 7, Fig. 2.

The team should use an SIS only if other designchanges (using inherently safer concepts) cannotreduce the Mitigated Event Likelihood to less thanthe target [7]. Avoid using safety interlocks(added-on features). If possible, use built-in fea-tures (inherent) to reduce risk.

The team continues the iterative process ofincreasing the number of protection layers andrecalculating the Mitigated Event Likelihood untilthe Mitigated Event Likelihood is less than theTarget Impact Event Likelihood.

3.10. Add up all the risk

After all the impact events are analyzed andtabulated in the LOPA Table in Fig. 2, the teamadds up all the Mitigated Event Likelihoods forSerious and Extensive Impact Events for eacha�ected population group.

The Risk of Fatality for each a�ected popula-tion is calculated by the following formulas ortheir equivalents:

Fire: Risk of Fatality =(Mitigated Event Like-lihood of Release)�(Probability of Ignition)�(Probability of person in Area)�(Probability ofFatal Injury in the Fire [usually 0.5])

Toxic Release: Risk of Fatality =(MitigatedEvent Likelihood of Release)�(Probability ofperson in Area)�(Probability of Fatal Injury inthe Release)

The team uses the Risk Analyst expertise andthe knowledge of the team to adjust these equa-tions for the conditions of the release and thework practices of the a�ected populations.

Example: The team found the likelihood of arelease that could lead to a large ®re was 2�10ÿ5per year. The probability of ignition is taken as0.5. The operator is in the area where the ®re couldoccur for about 20min each hour, so the prob-ability the operator is in the area at the time of the®re is 20/60=0.33, round to 0.3. The probabilityof fatal injury if a person is in a large ®re is takenas 0.5.

Substituting in the equation above,

Risk of fatality=(Mitigated Event Likelihoodof Release) � (Probability of Ignition) � (Prob-ability of Person in Area) � (Probability ofFatal Injury in the Fire)=(2�10ÿ5 per year)�(0.5)�(0.3)�(0.5)=1.5�10ÿ6

3.11. Corporate Risk Criteria test

The total risk from all impact events for thea�ected population should be compared to theCorporate Risk Criteria.

. If the total risk does not meet the criteria forthe a�ected population, then the team shouldseek to reduce the risk, ®rst by applyinginherently safer concepts, and then byapplying additional layers of protection.Such design changes will require an updateto the LOPA table.

. If the total risk is less than the criteria for thea�ected population and additional riskreduction can be achieved by some addi-tional cost, the Team should recommendthose additional risk reduction features tothe business [5].

. If the total risk is substantially less than thecriteria for the a�ected population, then nofurther risk reduction is needed.


The objective is to be sure the total risk from thefacility meets the Corporate Risk Criteria. Theteam should remember that employees and thecommunity may have risk from other parts of theunit, from other projects, and from other units.That additional risk must be considered againstthe Corporate Risk Criteria.

4. Sample problem

Part of a sample problem for Layer of Protec-tion Analysis is shown in Fig. 2. The system understudy is an atmospheric distillation column with asteam reboiler and an overhead condenser usingcooling tower water.

4.1. Impact Event 1

The HAZOP identi®ed high pressure as adeviation. One consequence of high pressure in thecolumn was catastrophic rupture of the column, ifit exceeded its design pressure. In the LOPA, thisimpact event is listed as Extensive for SeverityClass, since there is potential for ®ve or morefatalities. The Maximum Target Likelihood forExtensive impact events is 1�10ÿ8/year. Theimpact event, its class, and Maximum TargetLikelihood are written in column 1 of Fig. 2.

Note that Fig. 2 uses an alternate notation forscienti®c numbers for better legibility at smallerfont sizes (1�10ÿ8=1E-8).

The HAZOP listed several Initiating Causes forthis impact event. One initiating cause was loss ofcooling tower water to the main condenser. Theoperators said this happened about once every tenyears. The Initiating Cause is written in column 2of Fig. 2, and the Challenge Likelihood is writtenin column 3 (1/10 year=1�10ÿ1).

The LOPA team identi®ed one Process DesignIPL for this impact event and this cause. Themaximum allowable working pressure of thedistillation column and connected equipmentis greater than the maximum pressure that can begenerated by the steam reboiler during a cool-ing tower water failure. Its PFD is 1�10ÿ2.This design feature is listed in column 4 ofFig. 2.

The Basic Process Control System for this plantis a Distributed Control System (DCS). The DCScontains logic that trips the steam ¯ow valve and asteam remote control valve (RCV) on high pres-sure or high temperature of the distillation col-umn. This logic's primary purpose is to place thecontrol system in the shut-down condition after atrip so that the system can be restarted in a con-trolled manner. It is listed in column 5, Fig. 2,since it can prevent the impact event. However, noPFD credit is given for this logic since the valves ituses are the same valves used by the SISÐtheDCS logic does not meet the test of independencefor an IPLÐand the higher credit for the SIS willbe taken.

High pressure and temperature alarms dis-played on the DCS can alert the operator to shuto� the steam to the distillation column, using amanual valve if necessary. This protection layermeets the criteria for an IPLÐthe sensors forthese alarms are separate from the sensors used bythe SIS. The operators are trained and drilled inthe response to these alarms. This information isrecorded in Fig. 2, column 6, with the PFD of10ÿ1.

SIS logic implemented in a PLC will trip thesteam ¯ow valve and a steam RCV on highdistillation column pressure or high temperatureusing dual sensors separate from the DCS.The PLC has su�cient redundancy and diag-nostics such that the SIS has a PFD of 10ÿ3 or SIL3. This information is written in column 7 ofFig. 2.

The distillation column has Additional Mitiga-tion of a pressure relief valve designed to maintainthe distillation column pressure below the max-imum allowable working pressure when coolingtower water is lost to the condenser. Its PFD is10ÿ2. This information is recorded in column 8,Fig. 2.

The number of independent protection layers is4 (One each for Process Design, Alarm/Procedure,SIS, and Pressure Relief). This value is entered incolumn 9 of Fig. 2.

The Mitigated Event Likelihood for this cause-consequence pair is calculated by multiplying theChallenge Likelihood in column 3 by the IPLPFDs in columns 4, 6, 7, and 8:


The Mitigated Event Likelihood is entered incolumn 10 of Fig. 2. The value of 1�10ÿ9 is lessthan the maximum target likelihood of 1�10ÿ8 forextensive impact events.

Note that the relief valve protects against cata-strophic rupture of the distillation column, but itintroduces another impact eventÐa toxic release.The toxic release is entered on the Layer of Pro-tection Analysis form as Impact Event 2.

4.2. Impact Event 2

The toxic release from the distillation column isclassed as a Serious event. The impact eventdescription, Severity, and Maximum Target Like-lihood are entered in column 1 of Fig. 2.

The Initiating Cause and Challenge Likelihoodare the same for Impact Events 1 and 2. Theinformation in columns 2 and 3 in Fig. 2 is copiedinto the row for Impact Event 2.

The relief valve set pressure is less than themaximum pressure produced by the steam reboi-ler, thus, there is no process design IPL for thisimpact event. The extra cushion in the designpressure of the column does nothing to preventthe opening of the relief valve.

The Impact Event 1 information in the IPLcolumns of BPCS, Alarms, Procedures, and SISalso applies to Impact Event 2. Columns 5, 6, and7 are thus duplicated.

Obviously, the pressure relief valve does notprevent the release, so there is no additional miti-gation for this event.

The number of IPLs for this event is 2 (Oneeach for Alarm/Procedure, and SIS. ProcessDesign and Pressure Relief do not protect againsttoxic release.). This value is written in column 9 ofFig. 2.

The Mitigated Event Likelihood for this cause-consequence pair is calculated by multiplying theChallenge Likelihood in column 3 by the IPLPFDs in columns 6 and 7:

Mitigated

Challenge Alarms, Event

Likelihood Procedures SIS Likelihood

(1�10ÿ1/year) � (1�10ÿ1) � (1�10ÿ3)=1�10ÿ5/year

The Mitigated Event Likelihood is entered incolumn 10 of Fig. 2. The value of 1�10ÿ5 is morethan the maximum target likelihood of 1�10ÿ6 forextensive impact events. The team should considerif the design could be changed to be inherentlysafer to avoid the toxic release. Additional inde-pendent protection layers may be needed. Ascrubber or ¯are could be added to treat therelease from the relief valve. Alternately, the reliefvalve set pressure could be increased to the max-imum allowable working pressure of the equipment.

4.3. Add up all the risk

After all the impact events and all the causehave been analyzed and recorded in the layer ofprotection analysis form, the team will add up allthe Mitigated Event Likelihoods for all the Ser-ious and Extensive Impact Events. The Risk ofFatality will be calculated as described above inthis paper and compared with the Corporate RiskCriteria to be sure the distillation column and theother processing units do not impose intolerablerisk on a�ected populations.

5. LOPA advantages

. LOPA is more reproducible and more quan-titative in determining needed SIL than themodi®ed HAZOP method.

. LOPA avoids the generalities of the safetylayer matrix method; it includes its own cali-bration. The assumptions and included IPLsare clearly documented.

. LOPA accounts for the frequency of theinitiating causes and the presence of other

ChallengeLikelihood

ProcessDesign

Alarms,Procedures SIS

ReliefValve

MitigatedEvent

Likelihood(1�10ÿ1/year) � (1�10ÿ2) � (1�10ÿ1) � (1�10ÿ3) � (1�10ÿ2) = 1�10ÿ9/year


protection layers, giving a required SILbased on the risk (severity and frequency).LOPA avoids the problem of over- or under-estimating the required SIL associated withthe consequences-only method.

. LOPA is much less work than Fault TreeAnalysis, giving results that are slightly con-servative. LOPA can be done after theHAZOP to calculate the needed SIL formost of the SIS functions. A few complexsystems may require Fault Tree Analysis.

. LOPA focuses greater risk reduction e�ortson Impact Events with high severity and highlikelihood. It ensures that all the identi®edInitiating Causes are considered, and it con-®rms which Independent Layers of Protec-tion are e�ective for each Initiating Cause.LOPA can be used to allocate risk reductionresources e�ciently, so that one ImpactEvent is not left with too little protection,while another is overly protected.

. LOPA encourages thinking from a systemperspective. Formerly, interlocks were labeledby the sensor, as in `High Reactor Pressure'.LOPA shows the Layers of Protection fordi�erent Impact Events stemming from thesame Initiating Cause: for example, `cata-strophic rupture of the reactor' and `releaseof reactor contents through the relief valve'.

. LOPA gives clarity in the reasoning processand it documents everything that wasconsidered. While this method uses numbers,judgment and experience are not excluded.In some cases, the team's `gut feel' wasuncomfortable with the number calculated, soit went back and reviewed the assumptionsfor the frequency of the initiating event. Themethod makes the input from `gut feel'explicit, rather than implicit.

. In addition, LOPA o�ers a rational basis formanaging Layers of Protection that may betaken out of serviceÐe.g. interlock bypass.

. LOPA is more quantitative than the qualita-tive hazard consequence and likelihood cate-gories often used to estimate risk rankings in

a HAZOP, but it is less work than Fault TreeAnalysis or Quantitative Risk Analysis.

Acknowledgements

To the CCPS and ISA committees who wrotethe Guidelines for Safe Automation of ChemicalProcesses and the ISA-S84-01, respectively. ToDallas Green, David Patlovany, Rich Sypek, andMieng Tran, who sharpened my thinking as wewrote internal interlock guidelines. To W. H.Johnson Jr., who gives excellent training in LOPA.To Paul Gruhn, who asks excellent questions.

Disclaimer

Although we believe the information containedin this paper is factual, no warranty or repre-sentation, expressed or implied, is made withrespect to any or all of the content thereof, and nolegal responsibility is assumed therefore. Theexamples shown are simply for illustration, and assuch do not necessarily represent any company'sguidelines. The readers should use data, method-ology, and guidelines that are appropriate for theirsituations.

References

[1] Instrument Society of America (ISA); Application of

Safety Instrumented Systems to the Process Industries,

ANSI/ISA-S84.01-1996. Instrument Society of America,

Research Triangle Park, NC, 1996.

[2] D.L. Green, A. M. Dowell III, How to design, verify, and

validate emergency shutdown systems, ISA Transactions

34 (3) (1995) 261±272.

[3] Center for Chemical Process Safety (CCPS), Guidelines

for Safe Automation of Chemical Processes. American

Institute of Chemical Engineers, New York, 1993.

[4] D.L. Green, personal communication, 1993.

[5] F.M. Renshaw, A major accident prevention program,

Plant/Operations Progress 9 (3) (1990) 194±197.

[6] C. Fryman, Managing HazOp recommendations using an

action classi®cation scheme. AIChE Spring National

Meeting, New Orleans, LA, 25±29 February, 1996.

[7] Center for Chemical Process Safety (CCPS), Inherently

Safer Chemical Processes: A Life Cycle Approach. Amer-

ican Institute of Chemical Engineers, New York, 1996.


Documents

Lopa for Sil