Identifying Independent Protection...

6

Identifying IndependentProtection Layers

6.1. Purpose

The purpose of this chapter is to discuss the concept of an independent pro-tection layer (IPL) and its use in layer of protection analysis (LOPA). This isStep 4 of the LOPA process. Several examples are used throughout the chap-ter to illustrate specific points.

6.2. Definition and Purpose of an IPL

An IPL is a device, system, or action that is capable of preventing a scenariofrom proceeding to its undesired consequence independent of the initiatingevent or the action of any other layer of protection associated with the sce-nario. The effectiveness and independence of an IPL must be auditable.

For example, in Figure 6.1, at point A in a chain of events an installed IPLhas the opportunity to act. If it operates as intended the undesired conse-quence is prevented. If all of the IPLs in a scenario fail to perform their func-tions then the undesired consequence will occur following the initiatingevent.

The distinction between an IPL and a safeguard is important. A safe-guard is any device, system, or action that would likely interrupt the chain ofevents following an initiating event. However, the effectiveness of some safe-guards cannot be quantified due to lack of data, uncertainty as to independ-ence or effectiveness, or other factors.

75

The effectiveness of an IPL is quantified in terms of its probability of fail-ure on demand (PFD) which is defined as the probability that a system (in thiscase the IPL) will fail to perform a specified function on demand. The PFD is adimensionless number between 0 and 1. The smaller the value of the PFD, thelarger the reduction in frequency of the consequence for a given initiatingevent frequency. The “reduction in frequency” achieved by an IPL is some-times termed the “risk reduction factor.”

Figure 2.1 shows the layers of safeguards that can be employed to pre-vent or minimize the effects of incidents. Safeguards can be classified as

• active or passive,• preventive (prerelease) or mitigating (postrelease)

for the purpose of considering how they act and how effective they are inreducing the frequency or consequence of an initiating event. The characteris-tics of these layers, and whether they should be credited as IPLs in the LOPAmethod, are discussed below.

Process Design

In many companies, it is assumed that some scenarios cannot occur becauseof the inherently safer design of the process equipment. For example, theequipment might be designed to withstand the maximum pressure for a par-ticular scenario, batch size might be limited, inventory lowered, chemistrymodified, etc.; i.e., scenarios are eliminated by the inherently safer design.

76 6. Identifying Independent Protection Layers

All IPLs are safeguards, but not all safeguards are IPLs.

FIGURE 6.1. Event tree showing effect of IPL success or failure when demanded.See Figure 2.2 for the effect of multiple IPLs.

In other companies, some inherently safer process design features areconsidered to have a nonzero PFD—that is, they do have possible failuremodes that have been observed in industry. These companies consider suchinherently safer process design features as IPLs. The design of the IPL isintended to prevent the consequence from occurring. For example, a pumpmay have an impeller that is too small to generate high pressure in a down-stream vessel. The latter approach allows a company to compare the riskbetween plants designed using different equipment standards; the analysis canresult in different failure rates for similar pieces of equipment which in turnmight require additional IPLs for the equipment with higher failure rates. TheLOPA analyst should be aware that inherently safer process design featuresmay have a PFD and appropriate inspection and maintenance (auditing) mightbe required (e.g., a small impeller may be replaced with a larger impellerduring repair or maintenance, batch size may be changed, etc.).

Whether process design should be credited as an IPL, or considered as amethod of eliminating a scenario, depends upon the method employedwithin a particular organization (see also Sections 6.4 and 6.5, and Example6.5). Either approach can be used, but must be applied consistently within anorganization.

Basic Process Control Systems

The basic process control system (BPCS), including normal manual controls,is the first level of protection during normal operation. The BPCS is designedto maintain the process in the safe operating region. The normal operation ofa BPCS control loop may be credited as an IPL if it meets the appropriate crite-ria (see Section 6.5). As discussed in Chapter 5, the failure of the BPCS can bean initiating event. When considering using the BPCS as an IPL, the analystmust evaluate the effectiveness of the access control and security systems ashuman error can degrade the performance of the BPCS.

Critical Alarms and Human Intervention

These systems are the second level of protection during normal operation andshould be activated by the BPCS. Operator action, initiated by alarms orobservation, can be credited as an IPL when various criteria are satisfied toassure the effectiveness of the action (e.g., independence—see Section 6.5).Company procedures and training may improve the performance of humansin the system, but procedures themselves are not an IPL.

6.2. Definition and Purpose of an IPL 77

Inherently safer process design features are encouraged to eliminate

possible scenarios

—Inherently Safer Chemical Processes: A Life Cycle Approach (CCPS, 1996b).

Safety Instrumented Function (SIF)

A SIF is a combination of sensors, logic solver, and final elements with a spec-ified safety integrity level that detects an out-of-limit (abnormal) conditionand brings the process to a functionally safe state. A SIF is functionally inde-pendent of the BPCS. A SIF is normally considered to be an IPL and thedesign of the system, the level of redundancy, and the amount and type oftesting will determine the PFD the SIF receives in LOPA (see Section 6.5).“Interlock” is an older, imprecise term for SIF.

Physical Protection (Relief Valves, Rupture Discs, etc.)

These devices, when appropriately sized, designed and maintained, are IPLswhich can provide a high degree of protection against overpressure in cleanservices. However, their effectiveness can be impaired in fouling or corrosiveservices, if block valves are installed under the relief valves, or if the inspec-tion and maintenance activities are of poor quality. If the flow from the reliefvalves is discharged to the atmosphere, additional consequences may occurwhich will require examination (see Section 6.5). This could involve theexamination of the effectiveness of flares, quench tanks, scrubbers, etc.

Postrelease Protection (Dikes, Blast Walls, etc.)

These IPLs are passive devices which provide a high level of protection ifdesigned and maintained correctly. Although their failure rates are low, pos-sibility of failure should be included in the scenarios. Also, if automaticdeluge systems, foam systems, or gas detection systems, etc., meet therequirements of IPLs (see Section 6.5), then some credit can be taken for thesedevices in specific scenarios.

Plant Emergency Response

These features (fire brigade, manual deluge systems, facility evacuation, etc.)are not normally considered as IPLs since they are activated after the initialrelease and there are too many variables (e.g., time delays) affecting theiroverall effectiveness in mitigating a scenario.

Community Emergency Response

These measures, which include community evacuation and shelter-in-place,are not normally considered as IPLs since they are activated after the initialrelease and there are too many variables affecting their effectiveness in miti-gating a scenario. They provide no protection for plant personnel.


Table 6.1 is a summary of safeguards that are not normally considered to beIPLs.

6.2. Definition and Purpose of an IPL 79

TABLE 6.1Examples of Safeguards Not Usually Considered IPLs

Safeguards notUsually

Considered IPLs Comments

Training andCertification

These factors may be considered in assessing the PFD for operatoraction, but are not—of themselves—IPLs.

Procedures These factors may be considered in assessing the PFD for operatoraction, but are not—of themselves—IPLs.

Normal Testing andInspection

These activities are assumed to be in place for all hazard evalua-tions and form the basis for judgment to determine PFD. Normaltesting and inspection affects the PFD of certain IPLs. Lengtheningthe testing and inspection intervals may increase the PFD of anIPL.

Maintenance This activity is assumed to be in place for all hazard evaluationsand forms the basis for judgment to determine PFD. Maintenanceaffects the PFD of certain IPLs.

Communications It is a basic assumption that adequate communications exist in afacility. Poor communications affects the PFD of certain IPLs.

Signs Signs by themselves are not IPLs. Signs may be unclear, obscured,ignored, etc. Signs may affect the PFD of certain IPLs.

Fire Protection Active fire protection is often not considered as an IPL as it is postevent for most scenarios and its availability and effectiveness maybe affected by the fire/explosion which it is intended to contain.However, if a company can demonstrate that it meets the require-ments of an IPL for a given scenario it may be used (e.g., if an acti-vating system such as plastic piping or frangible switches areused).

Note: Fire protection is a mitigation IPL as it attempts to prevent alarger consequence subsequent to an event that has alreadyoccurred.

Fireproof insulation can be used as an IPL for some scenarios pro-vided that it meets the requirements of API and corporate stan-dards.

Requirement thatInformation isAvailable andUnderstood

This is a basic requirement.

Note: Poor performance in the areas discussed in this table may affect the process safety of the wholeplant and thus may affect many assumptions made in the LOPA process.

6.3. IPL Rules

In order to be considered an IPL, a device, system, or action must be

• effective in preventing the consequence when it functions as designed,• independent of the initiating event and the components of any other

IPL already claimed for the same scenario,• auditable; the assumed effectiveness in terms of consequence preven-

tion and PFD must be capable of validation in some manner (by docu-mentation, review, testing, etc.). (See also Appendix C, Documentationfor a LOPA Study.)

Effectiveness

If a device, system or action is credited as an IPL it must be effective in pre-venting the undesired consequence associated with the scenario. To deter-mine whether a safeguard is an IPL, the following questions are used to guidethe team or analyst in making the appropriate judgment. Additional discus-sion of these issues is provided in Section 6.5.

• Can the safeguard detect the condition that requires it to act? This maybe a process variable, or an alarm, etc. If the safeguard cannot alwaysdetect the condition, and generate a specific action, it is not an IPL.

• Can the safeguard detect the condition in time to take corrective actionthat will prevent the undesired consequence? The time required mustinclude� the time to detect the condition,� the time to process the information and make the decision,� the time to take the required action, and� the time for the action to take effect.

• Does the IPL have adequate capacity for it to take the required action inthe time available? If a specific size (e.g., relief valve orifice, dikevolume, etc.) is required, does the installed safeguard meet theserequirements? Is the strength of the IPL adequate for the requiredaction? The strength of an IPL might consist of� physical strength (e.g., a blast wall or dike);� the ability of a valve to close under the conditions that would be pres-

ent for a particular scenario (i.e., strength of valve spring, actuator, orcomponents);

� human strength (i.e., is the required task within the physical capabili-ties of all operators?).

If the safeguard cannot meet these requirements it is not an IPL.In LOPA, the effectiveness of an IPL in reducing the frequency of a conse-

quence is quantified using its PFD. Determining, or specifying, the appropri-


ate value for the PFD of an IPL is an important part of the LOPA process. AnIPL is expected to operate as intended, but any system can fail. The lower thevalue of the PFD for an IPL the greater the confidence that it will operate cor-rectly and interrupt a chain of events. Since LOPA is a simplified method, thevalues of the PFDs are usually quoted to the nearest order of magnitude. PFDvalues range from the weakest IPL (1 × 10–1) to the strongest IPL (1 × 10–4 – 1 ×10–5). Section 6.5 discusses appropriate PFD values for various IPLs. TheLOPA team or analyst must determine whether a safeguard is an IPL, andthen assess the appropriate value of the PFD for the IPL. Caution is requiredwhen assigning the PFD for IPLs in scenarios where the initiating event fre-quency is high, i.e., where the initiating event frequency for a scenario isgreater than, or close to, the effective functional test interval for the IPL (seeSection 7.2 and Appendix F).

Independence

The LOPA method uses independence to assure that the effects of the initiat-ing event, or of other IPLs, do not interact with a specific IPL and therebydegrade its ability to perform its function. Independence requires that anIPL’s effectiveness is independent of

• the occurrence, or consequences, of the initiating event; and• the failure of any component of an IPL already credited for the same

scenario.

It is important to understand when a safeguard can and cannot beclaimed as an IPL in LOPA. Example 6.1 shows a safeguard that is an IPL forone scenario, but not for another scenario.

Example 6.1

In Figure 6.2, Initiating Event 1 shows a safeguard (high reactor tempera-

ture triggers addition of quench) that is an IPL. Initiating Event 2 illus-

trates that the same safeguard that is not an IPL because it is not

independent of the initiating event. In the second scenario, a loss of

power (the initiating event) will lead to an exothermic runaway reaction

inside a vessel, with the possibility of a pressure rise that might rupture

the vessel (the undesired consequence). The exothermic reaction and

pressure rise can be prevented by the addition of a material to quench

the reaction. The system in place to add the quench material uses electric

pumps. During loss of power (the initiating event) the electric pumps are

inoperative and, therefore, the quench system is ineffective. Thus, the

quench system is not an IPL for the second scenario. Electrical power fail-

ure may also be considered as a common-cause failure for both the initi-

ating event and the potential safeguard.

6.3. IPL Rules 81

Example 6.2

A BPCS safeguard loop might not be independent of an initiating event.

The BPCS level control loop for a tank uses the fill valve to maintain the level

at the desired set point (Figure 6.3). One scenario is overflow of the tank

with an initiating event of failure of the BPCS level control loop. Safeguards

are a high level trip in the BPCS that uses one function to stop the pump

feeding the tank and a second function to close the fill valve in the feed line

to the tank when high level is detected. However, both functions use the

same level sensor and a single failure (failure of the sensor or the BPCS)

would prevent both final control elements from acting and the high level

BPCS interlock would be ineffective. Therefore, such a safeguard arrange-

ment is not an IPL because the sensor and the BPCS are common to both

the initiating event and the high level trip functions.


COMMON CAUSE FAILURE (CCF) OR COMMON MODE FAILURE

Common cause failure is the failure of more than one component, item, or

system due to the same cause or initiating event. It is particularly important to

look for common cause failure modes when analyzing safeguards to assess

whether they are IPLs. CCF can involve the initiating event and one or more

safeguards, or the interaction of several safeguards. All of the safeguards

affected by the CCF should only be considered as a single IPL (rather than each

safeguard being credited as an IPL). See also Table 6.2.

FIGURE 6.2. Example of IPL not independent of initiating event.

Similarly, Figure 6.4 shows two arrangements. In the first there are two

final control elements, but the BPCS and the sensor are common. Similarly,

in the second, there are two sensors, but the BPCS and the final control ele-

ment are common. For the reasons discussed above, each arrangement is

only considered as a single IPL in LOPA. The redundancy provided by the

dual final control elements or the dual sensors will decrease the PFD of

these portions of the BPCS loops and, possibly, decrease the overall PFD for

the IPLs.

Two approaches are used in assessing the independence of IPLs involv-ing BPCS loops or functions to decide how many IPLs exist for a particularscenario. Approach A is generally recommended because its rules are clearand it is conservative. Approach B may be used if the analyst is experiencedand adequate data is available on the design and actual performance of theBPCS logic solver.

Approach AIn order for a device or action to be credited as an IPL, it must be independentof both

• the initiating event and any enabling event and• any other device, system, or action that is already being credited as an

IPL for the same scenario.

Approach A is conservative, since it allows only one IPL in a single BPCSand requires that IPL to be independent of the initiating event. This approacheliminates many common cause failures (see Table 6.2) affecting the PFD for

6.3. IPL Rules 83

IPL CHARACTERISTICS

It may be helpful to use the following keywords when considering IPLs. While

not every IPL fits the model, the thought process helps to eliminate safeguards

that are not IPLs.

The “three Ds” help determine if a candidate is an IPL:

Detect Most IPLs detect or sense a condition in the scenario.

Decide Many IPLs make a decision to take action or not.

Deflect All IPLs deflect the undesired event by preventing it.

The “three Enoughs” help evaluate the effectiveness of an IPL:

Big Enough?

Fast Enough?

Strong Enough?

The “Big I” is a reminder that the IPL must be independent of the initiating

event and other IPLs.


FIGURE 6.3. Common sensor and logic solver elements in BPCS loop using Approach A.

FIGURE 6.4. Common logic solver and final control elements for BPCS loop usingApproach A.

85

TABLE 6.2Causes of Dependent Failure in Systems (Including Systematic Failure)*

Engineering Operation

Design Construction Procedural Environmental

FunctionalDeficiencies

RealizationFaults Manufacture

Installation andCommissioning

Maintenanceand Testing Operation

NormalExtremes

EnergeticEvents

Hazardundetectable

Inadequateinstrumenta-tion

Inadequatecontrol

Channeldependency

Commonoperation andprotectioncomponents

Operationaldeficiencies

Inadequatecomponents

Design errors

Designlimitations

Inadequatequality control

Inadequatestandards

Inadequateinspection

Inadequatetesting

Inadequatequality control

Inadequatestandards

Inadequateinspection

Inadequatetesting andcommissioning

Imperfect repair

Imperfect test-ing

Imperfectcalibration

Imperfectprocedures

Inadequatesupervision

Operator errors

Inadequateprocedures

Inadequatesupervision

Communicationerrors

Temperature

Pressure

Humidity

Vibration

Acceleration

Stress

Corrosion

Contamination

Interference

Radiation

Static charge

Fire

Flood

Weather

Earthquake

Explosion

Missiles

Electric Power

Radiation

Chemicalsources

*From Guidelines for Chemical Process Quantitative Risk Analysis, Second Edition (CCPS 2000a).

the IPLs which are claimed. Approach A is more straightforward to apply asits rules are unambiguous and little judgment is left to the analyst or team.Approach A is used for the continuing examples discussed in Chapters 2through 8.

Approach BThis approach allows more than one IPL to be in the same BPCS or it allows aBPCS IPL with a BPCS initiating event (with independence required for cer-tain components). This approach is based on the assumption that if a BPCSfunction fails, it is probable the component that induced the failure is thedetection device or the final control element, and that failures of the IPL dueto a fault in the logic solver are much less frequent. Industrial experience indi-cates that the failure rates of the detection devices and the final control ele-ments are usually much higher than the failure rate of the BPCS logic solver.Approach B allows a limited number of other elements of the BPCS to serve asan IPL for the scenario. Details of this approach are discussed in Chapter 11together with application to the continuing examples. Approach B is lessstraightforward to apply, since it requires

• information on the design and performance of the BPCS,• full understanding of the common cause failure modes on the PFD for

an IPL, and• an analyst experienced with the definition and application of the rules

for claiming a safeguard as an IPL.

Example 6.3 discusses several issues arising from using Approach A or Bwhen deciding to claim an IPL.

Example 6.3

Consider a situation where the failure of a specific BPCS loop is the initiat-

ing event. The operator response that could mitigate the situation relies

upon obtaining information from another loop in the same BPCS in which


CAUTION

The reader is advised that the draft IEC 61511 standard—dealing with Safety

Instrumented Systems for the process industry—Part 1 states “The risk

reduction factor for a BPCS [basic process control system] (which does not

conform to this standard) used as a layer of protection shall be below 10”(IEC,

2001). This means the PFD of all risk reduction functions in the BPCS is limited

to more than 1 × 10–1.

The user should provide the analysis to support the risk reduction claimed for

multiple BPCS IPLs.

the failure has occurred. Using Approach A, LOPA would assume that once

a BPCS loop has failed any further information or action that the BPCS logic

solver might provide must be viewed as unavailable or ineffective. There-

fore, operator action in response to a BPCS alarm could not be credited as

an IPL because the information required would be obtained using the failed

BPCS logic solver.

In Approach B, the ability of the BPCS logic solver to provide information to

the operator from a separate loop would be considered unaffected, pro-

vided that the design and performance of the logic solver would support

this assumption. Approach B would allow crediting the operator action as

an IPL, provided that the alarm loop did not use any of the common compo-

nents (with the exception of the central processing unit) involved in the ini-

tiating event for the scenario. Chapter 11 discusses this issue in greater

detail. The question of assigning credit for human action is discussed later

in this section.

A device, system, or action is not independent of the initiating event andcannot be credited as an IPL for either approach if either of the following aretrue:

• Operator error is the initiating event and the candidate IPL assumesthat the same operator must act to mitigate the situation. Human erroris equivalent to the failure of a system and once a human has commit-ted an error it is not reasonable to expect the same operator to act cor-rectly later in the sequence of events. This approach is justified becausethe error may be due to illness, incapacity (drugs or alcohol), distraction,work overload, inexperience, faulty operating instructions, lack ofknowledge, etc., that are still present later when the action is required.

• Loss of a utility (electricity, air, cooling water, nitrogen, etc.) is the initi-ating event and a candidate IPL is a system that depends on that utility.

Example 6.4

The arrangements shown in Figure 6.4 (discussed in Example 6.2) are not

independent of another IPL, using either Approach A or Approach B. In the

first arrangement, the logic solver and the sensor are common. If, however,

separate sensors are used for the BPCS function that closes the valve and

the BPCS function that stops the pump, Approach B might allow each of

these functions to be claimed as a separate IPL, despite the BPCS logic

solver being common to each (see Chapter 11). Similarly, for the second

arrangement of Figure 6.4, the use of dual final control elements, one for

each BPCS function, might allow two IPLs to be claimed using Approach B.

As noted earlier, the effect of common cause failures must also be consid-ered. This is particularly important if Approach B is employed. This type offailure can be subtle and requires vigilance in identifying opportunities for itsoccurrence.

6.3. IPL Rules 87

Other examples where the IPL is not independent include

• multiple flow meters, analyzers, etc., with a calibration error due tohuman error, faulty calibration instruments, etc.;

• multiple units or SIF systems with a single source of power or acommon circuit breaker unless it can be determined that fail safe actionwill always be initiated in the event of power loss—this is true for anyother utility required for an IPL to reach a safe state;

• functional deficiency in a type of valve, sensor, etc. used in multiplesystems;

• assuming that the same operator acts correctly after operator error ini-tiated the event.

Additional examples are provided in Table 6.2 for common mode issuesfor SIFs. See also ISA S84.01 (ISA, 1996), IEC 61508 (IEC, 1998), IEC 61511(IEC, 2001), Guidelines for Engineering Design for Process Safety (CCPS, 1993a),Guidelines for Safe Automation of Chemical Processes (CCPS, 1993b).

Auditability

A component, system or action must be auditable to demonstrate that itmeets the risk mitigation requirements of a LOPA IPL. The audit processmust confirm that the IPL is effective in preventing the consequence if it func-tions as designed. The audit should also confirm that the IPL design, installa-tion, functional testing, and maintenance systems are in place to achieve thespecified PFD for the IPL. Functional testing must confirm that all the compo-nents of an IPL (sensors , logic solver, final elements, etc.) are operational andmeet the requirements for LOPA to be applied. The audit process should doc-ument the condition of the IPL as found, any modifications made since thelast audit, and track to resolution any corrective actions that are required.

Chapter 9 (Implementing LOPA) discusses additional informationrequired to support the auditing and validation of IPLs.

6.4. LOPA IPL Assessment

This section describes how the LOPA analyst determines

• if the safeguard meets the requirements for an IPL and• the appropriate PFD for the IPL.

Safeguard/IPL Assessment

The basic requirements of effectiveness, independence and auditability for anIPL are determined by several methods. The simplest is to use a written


design basis, or IPL summary sheet, which must be available for review by theLOPA team or analyst (see Table 4.1). This should include the initiating eventconsidered, the action taken by the system or device, and the effects of theseactions. Any assumptions, clarifications or calculations required to support theanalysis must be attached or referenced. If this information is not available, or ifits validity is questionable, then it must be developed for each scenario andeach safeguard reviewed. This will require experts in the process design of thesystem, the design and installation of the instrumentation and the controls andoperation of the process. This analysis should be documented.

If a SIF is being considered as an IPL, the documentation should include

• a statement of the purpose of the safety instrumented function,• the specification and the installation details of each of its components

including the logic solver, and• proof test and validation records of the SIF, or components, having

achieved the required or assumed PFD. [See ISA S84.01 (ISA, 1996),IEC 61508 (IEC, 1998), IEC 61511 (IEC, 2001).]

Alternatively, if an organization has a published set of specifications forSIF systems, certification that the system meets the requirements for a speci-fied type of SIF would be acceptable.

If a pressure relief device is being considered as an IPL, the documenta-tion should include

• the design (sizing) basis,• design scenarios (all scenarios requiring the valve to open),• the valve specification,• the required flow at the scenario conditions,• the installation details (e.g., piping arrangement), and• the test and maintenance procedures, including proof of the valve lift-

ing at the set pressure.

Where human action is credited as an IPL, the following factors should bedefined and documented (see the discussion on Human IPLs in Section 6.5):

• how the condition will be detected,• how the decision to act will be made, and• what action will be taken to prevent the consequence.

PFD Value for an IPL

The PFD for an IPL is the probability that, when demanded, it will not per-form the required task. Failure to perform could be caused by

• a component of an IPL being in a failed or unsafe state when the initiat-ing event occurs; or

6.4. LOPA IPL Assessment 89

• a component failing during the performance of its task, or• human intervention failing to be effective, etc.

The PFD is intended to account for all potential failure to danger modes.(Failure to danger means the IPL fails such that it can not perform therequired task on demand.) Thus, it is a simplified concept and must beapplied with caution. In particular, the PFD for a BPCS function includes fac-tors such as human error in programming, bypassing interlocks, and the typi-cal security systems that are in place to control access to the BPCS logic solver.The PFD values quoted in this book are for typical systems only. Each organi-zation must satisfy itself that the PFD values used for its method are appro-priate.

The analyst should evaluate the design of the candidate IPL against theconditions of the scenario to estimate the appropriate PFD for the IPL. Thecredit taken for an IPL in risk reduction is discussed in detail in Section 6.5.Documentation should be developed to justify or substantiate the PFDclaimed for IPLs. This should reference corporate standards or industrynorms, or include appropriate calculations. For relief valves claimed as IPLs,justification for the PFD claimed, particularly for polymeric, fouling or corro-sive services, is particularly important (see the discussion on Active IPLs inSection 6.5).

6.5. Examples of IPLs

This section describes various types of IPLs, together with information on thePFD values used by various companies. The PFD is the probability that, whenchallenged, the IPL will fail to perform its required function and, therefore,the scenario will continue toward the undesired consequence despite thepresence of that IPL (see Chapter 4). Factors that may influence the selectionof PFD values for IPLs are also discussed briefly in this section.

Due to different approaches and different operating environments, arange of PFD values is provided in the summary tables 6.3, 6.4, and 6.5. The


CAUTIONS

Particular care is required when

• an IPL will be challenged at a frequency that is high in relation to its effective

test frequency (see Section 7.2 and Appendix F),

• human action PFDs are outside of industry norms (justification should be

included in the documentation), or

• frequent testing is required to achieve the claimed PFD value (documentation

that such testing has been performed satisfactorily at the required interval must

be maintained).

PFD values used within an organization should be applied consistently,although variations between different facilities are appropriate if justified bydifferences in design, construction, installation, inspection or maintenance.The PFD values should also be consistent with the failure rates used todevelop initiating event frequencies and risk tolerance criteria. Individualcompanies or methods may use a different list of IPLs, but these must meetthe requirements defined in Section 6.3.

When the demand frequency for an IPL is similar to the IPL test or prooftest frequency, particular care must be taken in assigning the appropriatePFD (see Section 7.2 and Appendix F). Some companies may use a lowervalue for an IPL than the typical PFDs in Tables 6.3 to 6.5, but this requires adetailed analysis of the IPL (using fault tree, FMEA, etc.) performed by aqualified analyst. The use of such advanced techniques in IPL analysis is dis-cussed in Chapter 11.

The PFD of an IPL is usually related to its test frequency. The longer theperiod between testing, the higher the PFD. Kletz (1985) and the CCPSCPQRA books (CCPS 1989a, 2000a) discuss this issue. The assumed PFD of anIPL must be consistent with the actual test frequency.

Passive IPLs

A passive IPL is not required to take an action in order for it to achieve itsfunction in reducing risk. Table 6.3 contains examples of IPLs that achieverisk reduction using passive means to reduce the frequency of high conse-quence events. Table 6.3 also includes a typical range of PFD values for eachtype of IPL, together with a PFD value used in one method. These IPLsachieve the intended function if their process or mechanical design is correctand if constructed, installed, and maintained correctly. Examples are tankdikes, blast walls or bunkers, fireproofing, flame or detonation arrestors, etc.These devices are intended to prevent the undesired consequence (wide-spread leakage, blast damage to protected equipment and buildings, failuredue to fire exposure to vessels or piping, fire or a detonation wave passingthrough a piping system, etc.). If designed adequately, such passive systems

6.5. Examples of IPLs 91

CAUTION

The discussion in this section and the data provided in the referenced tables

are based on “typical” IPLs installed in “typical” services. If the installation or

service conditions are atypical for an IPL, the value of its PFD should be carefully

reviewed and adjusted for specific conditions. When IPLs are installed in

“severe” conditions (e.g., relief valves or sensors in fouling, polymeric, or

corrosive services), the use of higher PFD values should be considered.

can be credited as IPLs with a high level of confidence and will significantlyreduce the frequency of events with potentially major consequences. How-ever, there may be other, less serious consequences (such as a fire in dike,blast damage to some equipment) that should be analyzed in other scenarios.

Fireproofing is a means of reducing the rate of heat input to equipment(e.g., when considering the sizing basis for relief valves, for preventing a boil-


TABLE 6.3Examples of Passive IPLs

IPL

Comments

Assuming an adequate designbasis and adequate inspection

and maintenance procedures

PFD fromLiterature and

Industry

PFD Used inThis Book

(For screening)

Dike Will reduce the frequency of largeconsequences (widespread spill)of a tank overfill/rupture/spill/etc.

1 × 10–2 – 1 × 10–3 1 × 10–2

UndergroundDrainage System

Will reduce the frequency of largeconsequences (widespread spill)of a tank overfill/rupture/spill/etc.

1 × 10–2 – 1 × 10–3 1 × 10–2

Open Vent (novalve)

Will prevent over pressure1 × 10–2 – 1 × 10–3 1 × 10–2

Fireproofing Will reduce rate of heat input andprovide additional time fordepressurizing/firefighting/etc.

1 × 10–2 – 1 × 10–3 1 × 10–2

Blast-wall/Bunker

Will reduce the frequency of largeconsequences of an explosion byconfining blast and protectingequipment/buildings/etc.

1 × 10–2 – 1 × 10–3 1 × 10–3

“Inherently Safe”Design

If properly implemented can sig-nificantly reduce the frequency ofconsequences associated with ascenario. Note: the LOPA rules forsome companies allow inherentlysafe design features to eliminatecertain scenarios (e.g., vesseldesign pressure exceeds all possi-ble high pressure challenges).

1 × 10–1 – 1 × 10–6 1 × 10–2

Flame/Detona-tion Arrestors

If properly designed, installedand maintained these shouldeliminate the potential for flash-back through a piping system orinto a vessel or tank.

1 × 10–1 – 1 × 10–3 1 × 10–2

ing liquid, expanding vapor explosion (BLEVE), or for preventing an exother-mic runaway reaction due to external heat input). This could mitigate the sizeof a release or provide additional time to respond to the situation bydepressurizing the system, fire fighting, etc. If fireproofing is considered asan IPL it must be shown to be effective in preventing the consequence (aBLEVE, etc.) or provide sufficient time for other action. It should also meetthe requirements that the fireproofing remain intact when exposed directly toa fire and that it will not be displaced by the impact of a jet of water from amonitor or hose.

Other passive IPLs, such as flame or detonation arrestors, while employ-ing simple physical principles, are susceptible to fouling, plugging, corro-sion, unexpected conditions, potential maintenance mistakes, etc. These mustbe considered when assigning a PFD to such devices.

Passive IPLs, such as dikes or blast walls, where the equipment designprevents the consequence can have low PFD values for LOPA purposes, butcare must be taken to assess accurately the PFD to be applied.

In some companies, process design features (such as special materialsand inspection) are considered as IPLs if they can prevent the consequencefrom occurring. This approach allows an organization to evaluate risk differ-ences between plants that are designed using different equipment standards.With this approach inherently safer process design features also haveassigned PFDs requiring appropriate inspection and maintenance (auditing)to ensure that process changes do not change the PFD.

In many companies, the approach taken is that inherently safer designfeatures eliminate scenarios rather than mitigate the consequences of a sce-nario. For example, if equipment is designed to withstand an internal defla-gration then all the scenarios that lead to a rupture of a vessel due to aninternal explosion have thereby been eliminated. Using this approach, pro-cess design is not considered to be an IPL as there are no scenarios or conse-quences to be considered and, therefore, no IPL is required. However,appropriate inspection and maintenance (auditing) is required to insure thatprocess changes do not change the effectiveness of the inherently safer designfeature. This issue is discussed further in the following example.

Example 6.5

Consider a system where a pump feeds material to a vessel that has a

design pressure greater than the shut-off head of the pump. Some compa-

nies might view the rupture of a vessel due to overpressure from a

deadheaded feed pump as a feasible scenario. They would then count the

inherently safer design feature that the design pressure of the vessel

exceeds the deadheaded pump pressure as an IPL. Some LOPA analysts give

such an IPL a PFD range of 1 × 10–2 to 1 × 10–4; these PFDs recognize the

possibility that there may be errors in fabrication and maintenance and that

corrosion could reduce the rupture pressure of the vessel. Additionally the


potential exists for the installation of a different impeller in the pump, use

of a different liquid, etc.

Other LOPA analysts argue that catastrophic failure of the vessel at a pres-

sure lower than its design pressure (particularly with the large safety factors

built into the mechanical design codes) is not a reasonable consequence

unless there is evidence of significant corrosion in the system. Such a failure

could only occur due to errors in fabrication, or from corrosion, and would be

a different scenario from one initiated by deadheading the pump (i.e., the

initiating event frequency would be so low as to be negligible assuming the

appropriate inspection and maintenance were performed on the vessel). The

system would be hydro-tested to the design pressure required by the

mechanical code prior to installation. Additionally any failure resulting from

deadheading the pump would probably result only in localized leakage, due

to failure of the gasketed joints or instrument connections rather than a cata-

strophic failure. This approach would eliminate catastrophic failure of the

vessel due to pump deadheading as a scenario.

A truly inherently safe design would have no scenarios for a particular initi-

ating event.

A company must determine the approach to select to achieve consensusand consistent results within its organization.

Active IPLs

Active IPLs are required to move from one state to another in response to achange in a measurable process property (e.g., temperature or pressure), or asignal from another source (such as a push-button or a switch). An active IPLgenerally comprises (see Figure 6.5)

• a sensor of some type (instrument, mechanical, or human),• a decision-making process (logic solver, relay, spring, human, etc.),• an action (automatic, mechanical, or human).

Table 6.4 provides examples of active IPLs. Human intervention is dis-cussed later in this section.


NOTE

If it is not possible to use inherently safer design techniques to eliminate

scenarios, the authors strongly recommend a design that uses IPLs to reduce

the risk associated with a given scenario by lowering the frequency of a

consequence.

Inherently safer design concepts reduce risk by eliminating scenarios,

particularly those with large consequences, and, where practical, should be the

preferred option.

Instrumented Systems

These systems are a combination of sensors, logic solvers, process controllers,and final elements that work together, either to automatically regulate plantoperation, or to prevent the occurrence of a specific event within a chemicalmanufacturing process. Two types of instrumented systems are consideredin the basic LOPA method. Each has its own purposes and characteristics.One, the continuous controller (e.g., the process controller that regulatesflow, temperature, or pressure at an operator supplied set-point value) gener-ally provides continuous feedback to the operator that it is functioning nor-mally (although unannounced malfunctions can occur). The second, the statecontroller (the logic solver which takes process measurements and executeson–off changes to alarm indicators and to process valves) monitors the plantconditions and only takes control actions when predefined trip points arereached. State control actions may be referred to as process interlocks andalarms, such as a reactor high-temperature trip that closes the steam valve.Faults in a state controller (logic solver and the associated field devices) maynot be detected until the next manual proof test of the failed safety function.Both continuous and state controllers are found in the BPCS and the SIS. TheBPCS and the SIS differ significantly in the level of risk reduction achievable.

Basic Process Control System (BPCS)

The BPCS is the control system that continuously monitors and controls theprocess in day-to-day plant operation. The BPCS may provide three differenttypes of safety functions that can be IPLs:

• continuous control action, which keeps the process at set point valueswithin the normal operating envelope and thus attempts to prevent theprogression of an abnormal scenario following an initiating event.

• state controllers (logic solver or alarm trip units), which identify pro-cess excursions beyond normal boundaries and provide this informa-tion (typically, as alarm messages) to the operator, who is expected totake a specific corrective action (control the process or shut down).

• state controllers (logic solver or control relays), which are intended totake automatic action to trip the process, rather than attempt to return


FIGURE 6.5. Basic components of active IPL.


TABLE 6.4Examples of Active IPLs

IPL

Comments

Assuming an adequate design basis andinspection/maintenance procedures


Industry


(For screening)

Relief valve Prevents system exceeding specifiedoverpressure. Effectiveness of thisdevice is sensitive to service andexperience.

1 × 10–1 – 1 × 10–5 1 × 10–2

Rupture disc Prevents system exceeding specifiedoverpressure. Effectiveness can bevery sensitive to service and experi-ence

1 × 10–1 – 1 × 10–5 1 × 10–2

Basic ProcessControlSystem

Can be credited as an IPL if not asso-ciated with the initiating event beingconsidered (see also Chapter 11). (SeeIEC 61508 (IEC, 1998) and IEC 61511(IEC, 2001) for additional discussion.)

1 × 10–1 – 1 × 10–2

(>1 × 10–1 allowedby IEC)

1 × 10–1

SafetyInstrumentedFunctions(Interlocks)

See IEC 61508 (IEC, 1998) and IEC 61511 (IEC, 2001) for life cycle require-ments and additional discussion

SIL 1 Typically consists of:

Single sensor (redundant for fault tol-erance )

Single logic processor (redundant forfault tolerance)

Single final element (redundant forfault tolerance)

≥1 × 10–2–<1 × 10–1

This book doesnot specify aspecific SILlevel.Continuingexamplescalculate arequired PFDfor a SIF


“Multiple” sensors (for fault toler-ance)

“Multiple” channel logic processor(for fault tolerance)

“Multiple” final elements (for faulttolerance)

≥1 × 10–3–<1 × 10–2


Multiple sensors

Multiple channel logic processor

Multiple final elements

≥1 × 10–4–<1 × 10–3

Note: Multiple includes 1 out of 2 (1oo2) and 2 out of 3 (2oo3) voting schemes

“Multiple” indicates that multiple components may or may not be required depending upon thearchitecture of the system, the components selected and the degree of fault tolerance required toachieve the required overall PFD and to minimize unnecessary trips caused by failure of individualcomponents (see IEC 61511 (IEC, 2001) for guidance and requirements).

the process to within the normal operating envelope. This actionshould result in a shutdown, moving the process to a safe state.

The BPCS is a relatively weak IPL, as there is usually

• little redundancy in the components,• limited built-in testing capability, and• limited security against unauthorized changes to the internal program

logic.The limited security arrangements are particularly important when con-

sidering the effectiveness of the BPCS as an IPL. Human error (in modifyinglogic, bypassing alarms and interlocks, etc.) can significantly degrade theanticipated performance of BPCS systems if security is not adequate.

IEC 61511 (IEC, 2001) limits the combined PFD to not less than 1 × 10–1 forall the BPCS IPLs that can be applied to a unique initiating event–conse-quence pair (i.e., combined PFD must be more than 1 × 10–1). For LOPA pur-poses, some companies use a PFD of 1 × 10–1 for each BPCS IPL that can beapplied to a unique initiating event–consequence pair, based on analysis oftheir system configuration, implementation, maintenance and testing.

The following examples demonstrate the types of action taken by the BPCS.

Example 6.6: BPCS Normal Control Loop Action as an IPL

Consider the example of an initiating event due to abnormally high pres-

sure of the fuel gas supply to a furnace. An upstream unit causes the high

pressure. The consequence is a high temperature in the furnace. If the fuel

gas flow control loop is pressure compensated, the normal action of the

loop will reduce the volumetric flow as the pressure goes up. This loop

could be an IPL if it is capable of preventing the high-pressure upset from

becoming the high-temperature consequence in the furnace.

Example 6.7: BPCS Alarm Action as an IPL

In a furnace similar to that of Example 6.6, consider the case where the fuel

gas flow control loop is not pressure compensated. However, the BPCS has

discrete logic to generate an alarm on high fuel gas pressure. The operator

would then be expected to take action to control the gas pressure or shut-

down the furnace. This BPCS loop, in conjunction with the operator action,

could be an IPL.

Example 6.8: BPCS Logic Action as an IPL

In a furnace similar to that of Example 6.6, consider again the case where

the fuel gas flow control loop is not pressure compensated. However, the

BPCS has discrete logic to trip (shutdown) the furnace on high fuel gas pres-

sure to prevent the high furnace temperature consequence. This BPCS loop

could be an IPL.


Safety Instrumented System (SIS)

A safety instrumented system (SIS) is a combination of sensors, logic solversand final elements that performs one or more safety instrumented functions(SIFs). SIFs are state control functions, sometimes called safety interlocks andsafety critical alarms. An assembly of SIFs makes up the SIS (also known as anemergency shutdown system). ISA S84.01 (ISA, 1996), IEC 61508 (IEC, 1998),IEC 61511 (IEC, 2001), and the CCPS Safe Automation book (CCPS, 1993b) dis-cuss the design requirements of SIS and SIF in detail and specify the life cyclerequirements (specification, design, commissioning, validation, maintenanceand testing) to achieve the desired PFD. Important design details include thefollowing:

• SIFs that are functionally independent from the BPCS. Measurementdevices, logic processors, and final control elements used for a SIF areisolated from similar devices in the BPCS, except where signals can beshared without sacrificing the PFD of the SIF.

• A safety system logic solver (typically comprising multiple redundantprocessors, redundant power supplies, and a human interface) thatprocesses several (or many) safety instrumented functions.

• Extensive use of redundant components and signal paths. Redun-dancy can be achieved in several ways. The most obvious is to installmultiple sensors or multiple final elements (e.g., valves) for the sameservice. Diverse technologies will reduce common cause failure forredundant components. Examples 6.9 and 6.10 provide methods bywhich redundancy is added to a system other than by just replicatingsystem components.

• Use of voting architectures and logic that are tolerant of failures ofsome components without the effectiveness of the SIS being compro-mised and without causing spurious trips of the process.

• Use of self-diagnostics to detect and communicate sensor, logic solver,and final control element faults. Such diagnostic coverage can reducethe mean time to repair failed SIFs to only a few hours. Internal testingof the multiple logic solvers can occur many times a second.

• A deenergized to trip philosophy where a low PFD is required.

Each of the SIFs will have its own PFD value based on

• the number and type of sensors, logic solvers, and final control ele-ments; and

• the time interval between periodic functional tests of system compo-nents.

The risk reduction performance of a SIF is defined in terms of its PFD.International standards have grouped SIFs for application in the chemical


process industry into categories called Safety Integrity Levels (SILs). Theseare defined as:

SIL 1 PFD ≥ 1 × 10–2 to <1 × 10–1 [IEC 61511 (IEC, 2001)]. These SIFs arenormally implemented with a single sensor, a single SIS logicsolver and a single final control element.

SIL 2 PFD ≥ 1 × 10–3 to <1 × 10–2 These SIFs are typically fully redundantfrom the sensor through the SIS logic solver to the final control ele-ment.

SIL 3 PFD ≥ 1 × 10–4 to <1 × 10–3 These SIFs are typically fully redundantfrom sensor through the SIS logic solver to the final control ele-ment and require careful design and frequent proof tests toachieve low PFD figures. Many companies find that they have alimited number of SIL 3 SIFs due to the high cost normally associ-ated with this architecture.

SIL 4 PFD ≥ 1 × 10–5 to <1 × 10–4 These SIFs are included in the IEC 61508and 61511 standards, but such SIFs are difficult to design andmaintain and are not used in LOPA.

Draft ISA TR84.0.02 (ISA, 2001) provides guidance to calculate the PFDfor a SIF design or SIF installation.

Example 6.9

It is possible to provide redundancy for the detection of the loss of a gas

compressor by using single devices to measure gas flow, amps to the com-

pressor motor, gas pressure drop, etc. All of these can detect the same

event, but in different ways (i.e., they provide diversity as well as redun-

dancy), and are also used for separate reasons for monitoring the process.

However, care must be taken to insure that the signals from these instru-

ments are truly independent (e.g., that they do not all pass through the

same input card).

Example 6.10

It is possible to provide redundancy in valving without adding additional

valves in the main process piping. Such valves can require the installation of

parallel piping for each valve with the associated block valves, etc., to allow

on-line testing to be performed. Such piping systems can be extremely

expensive to retrofit into existing plants. For example, as shown in Figure

6.6, the heat input to a steam reboiler can be halted either by closing the

steam flow control valve (XV-411) or by opening the vent valve (XV-101) to

reduce the steam chest pressure below that required for boiling the liquid

in the process. The vent valve can be tested on-line by closing the upstream

block valve (which is sealed or locked open when not being tested). These

valves would qualify as redundant systems if:


• Each system meets the requirements for an IPL.

• The initiating event does not involve the failure of one of these valves.

• The vent valve is adequately sized so that the pressure in the reboiler islowered to reduce the temperature driving force on the reboiler andeliminate, or adequately reduce, heat input to the unit.

The PFD for this IPL would depend on

• the test frequency of the vent valve,

• how the proven operation of the flow control valve could be used todetermine its PFD when required to reduce steam flow when demanded,and

• the PFD of the other components comprising the system.

An alternative design would be an additional SIF valve in the steam supply

line. On-line testing might require additional block valves to isolate the SIF

valve and a bypass valve around the SIF valve. It can be seen that the total

number of valves required is reduced significantly and only simple modifi-

cations are required to the piping system.


FIGURE 6.6. Example of arrangement for providing multiple final elements for haltingheat input to column from steam reboiler.

Vendor Installed Safeguards

Many equipment items are supplied with various safeguards and interlocksystems designed by the equipment vendors. Examples include

• Fired Equipment—burner management systems including fire-eyes,purging cycles, etc. In a scenario involving a potential explosion in aboiler, if fuel gas were fed to the burners without the pilot lights func-tioning, the burner management system would be an IPL if designed,installed, maintained, and integrated into the safety system adequately.

• Rotating Equipment—vibration switches, high-temperature detection,overspeed protection, antisurge protection, etc. In a scenario wheresevere production losses could arise as a result of damage to a largecompressor, vendor supplied interlocks would be IPLs if designed,installed, maintained, and integrated into the safety system adequately.

It is appropriate to consider such devices as IPLs for the purposes ofLOPA based on their meeting the LOPA rules. Factors that would influencethis decision and the PFD value include

• the design of the SIFs (interlocks).• historical data (which should be available from the vendors, but

should be reviewed with care).• the integration of the SIFs into the BPCS and/or SIS (see above).

Deluges, Sprays, Foam Systems, and Other FirefightingMitigation Systems

Deluges, water sprays, foam systems may be considered as IPLs for prevent-ing the ultimate release (e.g., a BLEVE, or exothermic runaway reaction initi-ated by external heat input) if well designed and maintained automaticsystems are installed and meet the requirements defined in Section 6.3. Industryexperience with these systems indicates that they should usually be consideredsafeguards rather than IPLs for normal responses to fires, releases, etc., if the pos-sibility of damage from the fire or explosion could render them ineffective.

Pressure Relief Devices

Pressure relief valves open when the pressure under the valve exceeds thepressure exerted by the spring holding the valve closed (pilot operated reliefvalves operate in a slightly different manner—see the Guidelines for PressureRelief and Effluent Handling Systems; CCPS, 1998b). Some systems use a rup-ture disc to protect equipment, and the inability of this device to close after it


has ruptured can lead to more complex scenarios. With a relief valve, thematerial passes from the vessel through the valve, either directly to the atmo-sphere or to some form of mitigation system (vent stack, flare, quench tank,scrubber, etc.) before passing to the atmosphere. The pressure vessel codesrequire that relief valves protecting a vessel or system are designed for allanticipated scenarios (fire, loss of cooling, control valve failure, loss of cool-ing water, etc.) and do not impose any other requirements. This implies thatthe relief valve is the only IPL needed for overpressure protection.

The LOPA team or analyst should evaluate the appropriate value for arelief valve PFD for each service. In particular, relief valves in fouling, corro-sive, or two-phase flow, or where freezing of material in the relief header mayoccur, can experience conditions that would result in the expected flow notbeing achieved. These potential service problems may be overcome by usingnitrogen purges, rupture discs under the valve, heat tracing, installing paral-lel relief valves to allow on-line inspection and maintenance, and usingDIERS methods for sizing devices for two-phase flow cases as shown in theCCPS Pressure Relief book (CCPS, 1998b). The characteristics of each systemmust be carefully considered when deciding the PFD value claimed for eachservice. As human action interacts with relief valve installation and mainte-nance (designing, installing, testing, use of block valves, etc.) and is known toresult in error, the effective PFD in a LOPA analysis for these devices is usu-ally higher than might otherwise be anticipated.

Relief systems are intended to provide protection against overpressure,but the relief flow is eventually sent to the atmosphere. This may result inadditional scenarios (e.g., toxic cloud, flammable cloud, environmentalrelease) depending on the material, the types of control, and environmentalprotection systems (flares, scrubbers, etc.). The LOPA analyst must deter-mine the frequency of the consequence of the new scenario with the reliefdevice IPL operating as intended and determine if other IPLs may be neededto meet the risk tolerance criteria (see Chapter 8). The risk of overpressuremay be tolerable, but the frequency of environmental release from the reliefvalve may be higher than desired.

Additional scenarios could involve leakage of the relief valve or the fail-ure of the relief valve to close after a demand.


For IPLs that mitigate the consequence, consider evaluating the mitigated

consequence as a separate scenario.

Example: a relief valve reduces the frequency of vessel overpressure but it

generates another scenario of release through the relief valve, given that it

works as designed. The additional scenario can be compared with risk tolerance

criteria.

Human IPLs

Human IPLs involve the reliance on operators, or other staff, to take action toprevent an undesired consequence, in response to alarms or following a rou-tine check of the system. The effectiveness of humans in performing routineand emergency tasks has been the subject of several publications (Guidelinesfor Preventing Human Error in Process Safety; CCPS 1994b, and Swain 1983).Overall, human performance is usually considered less reliable than engi-neering controls and great care should be taken when considering the effec-tiveness of human action as an IPL (see Table 6.5). However, not creditinghuman actions under well-defined conditions is too conservative. The gen-eral requirements for crediting human action as an IPL are the same as thosediscussed in Section 6.3, but are often described in different terms. Humanaction should have the following characteristics:

• The indication for action required by the operator must be detectable.The indication must always be:� available for the operator,� clear to the operator even under emergency conditions,� simple and straightforward to understand.

• The time available to take the action must be adequate. This includesthe time necessary to decide that action is required and the time neces-sary to take the action. The longer the time available for action, the


TABLE 6.5

Examples of Human Action IPLs*

IPL

Comments

Assuming adequate documentation,training and testing procedures


Industry


(For screening)

Human actionwith 10 minutesresponse time.

Simple well-documented actionwith clear and reliable indicationsthat the action is required

1.0 – 1 × 10–1 1 × 10–1

Human responseto BPCS indica-tion or alarmwith 40 minutesresponse time

Simple well-documented actionwith clear and reliable indicationsthat the action is required. (ThePFD is limited by IEC 61511; IEC2001.)

1 × 10–1

(>1 × 10–1

allowed by IEC)

1 × 10–1

Human actionwith 40 minutesresponse time

Simple well-documented actionwith clear and reliable indicationsthat the action is required

1 × 10–1 – 1 × 10–2 1 × 10–1

* Based on Inherently Safer Chemical Processes: A Life Cycle Approach (CCPS 1996b), Handbook of HumanReliability Analysis with Emphasis on Nuclear Power Plant Applications (Swain 1983).

lower the PFD given for human action as an IPL. The decision makingfor the operator should require:� no calculations or complicated diagnostics,� no balancing of production interruption costs versus safety.

• The operator should not be expected to perform other tasks at the sametime as the action required by the IPL, and the normal operator work-load must allow the operator to be available to act as an IPL.

• The operator is capable of taking the action required under all condi-tions expected to be reasonably present. As an example, consider a pro-posed IPL where an operator is required to climb a platform to open avalve. If a fire (as the initiating event) could prevent this action, itwould not be appropriate to consider the operator action as an IPL.

• Training for the required action is performed regularly and is docu-mented. This should involve drills in accordance with the written oper-ating instructions and regular audits to demonstrate that all operatorsassigned to the unit can perform the required tasks when alerted by thespecified alarm.

• The indication, and action, should normally be independent of anyalarm, instrument, SIF or other system already credited as part ofanother IPL or initiating event sequence (see Chapter 11 for additionaldiscussion of this point).

Management practices, procedures, and training may be considered asmethods that would assist in establishing the PFD claimed for human action,but should not be considered IPLs by themselves.

6.6. Preventive IPLs versus Mitigation IPLs

When considering how an IPL will reduce the risk associated with a scenario itis important to maintain a clear understanding of what the IPL is intended todo. Some IPLs are intended to prevent the scenario from occurring and may betermed preventive IPLs. Other IPLs may be termed mitigation IPLs and areintended to reduce the severity of the consequence of the initiating event. Miti-gation IPLs reduce the frequency of the original high consequence scenario,but permit a less severe consequence to occur, as shown in Example 6.11.


CAUTION

Human action has been shown to be a relatively weak protection layer. Analysts

and teams should be cautious about claiming PFD values lower than those

recommended in Table 6.5 with the specific qualifications regarding the time

available for the action to be taken.

Example 6.11

Consider a scenario M1-Original that has a high severity consequence with

an unacceptable frequency. Recalling Chapters 4 and 5, Initiating Event A

occurs at a certain frequency. The other IPLs reduce the frequency of the

high severity consequence, but the consequence can still occur at some fre-

quency as shown below. In the scenario M1-Modified, adding a mitigation

IPL prevents (reduces the frequency of) the high severity consequence of

the initial scenario. Again, the high severity consequence can still occur if all

the IPLs fail, but at a lower frequency than the original scenario.

However, the mitigation IPL allows another scenario to proceed towards

another (usually less severe) consequence (scenario M2). The frequency of

the less severe consequence for M2 is essentially the same as the frequency

of the original scenario.

• Scenario M1-Original:Initiating Event A ⇒ Other IPLs fail ⇒ High Severity Consequence—fre-quency too high for risk tolerance criteria

• Scenario M1-Modified:Initiating Event A ⇒ Other IPLs fail ⇒ Mitigation IPL fails ⇒ High SeverityConsequence—reduced frequency

• Scenario M2:Initiating Event A ⇒ Other IPLs fail ⇒ Mitigation IPL successful ⇒ LessSevere Consequence—frequency similar to M1-Original

Each additional less severe scenario resulting from a mitigation IPLwould be different from the first scenario and would require its own analysis.The two scenarios of Example 6.11 (M1-Modified and M2) are evaluated sep-arately, assuming the company chooses to study the new scenarios leading toless severe consequences. Frequently, the company has determined that cer-tain types of less severe consequences do not need further study, for example,a spill into a dike of a flammable liquid at a temperature below its normalboiling point.

Examples of preventive IPLs are SIFs (e.g., steam valve closure, emer-gency cooling water flow, inhibitor addition) that would halt a runaway reac-tion and avoid overpressure. If these work then the reaction will be haltedwithout a vessel rupture or emission to the atmosphere.

Examples of mitigation IPLs are pressure relief devices that are intendedto prevent the catastrophic rupture of a vessel, but whose satisfactory opera-tion then results in other consequences (another scenario). For example, arelief device that passed a flammable or toxic material to the atmospherewould cause the analyst to consider whether the risk associated with thesecond scenario was acceptable or not. If the risk was considered unaccept-able, then the analyst might examine whether additional IPLs are required toreduce the frequency of the relief valve opening to the atmosphere. Alterna-tively, an analyst could consider whether the relief flow from the valve

6.6. Preventive IPLs versus Mitigation IPLs 105

should be passed to a flare, scrubber, quench tank, etc., to reduce the risk.Another example is a dike (release into dike with the potential for evapora-tion, fire, explosion, etc.). In these two examples the range of scenarios associ-ated with the IPL being effective, partially effective or ineffective can becomequite complex.

These issues are discussed in greater detail in Dowell (1997) and Dowell(1999a).

6.7. Continuing Examples

For the continuing example problems introduced in Chapter 2, the varioussafeguards are reviewed to identify which are IPLs. The reasons for not con-sidering some safeguards as IPLs for the purposes of LOPA are discussed.This section also reviews possible additional IPLs and their appropriate PFDvalues.

Chapter 8 discusses the decision-making process for determining if addi-tional IPLs are required to satisfy risk tolerance criteria. This section discussescandidate safeguards and potential IPLs. In a real-world solution to this prob-lem, the thought process would be iterative and the analyst would moveamong examination of the current installation, the required risk reductionopportunities, and possible methods of adding additional risk reduction.

The solutions in this chapter employ Approach A—that is, only one IPL isallowed in a single BPCS and that IPL must be independent of the initiatingevent. Solutions using Approach B are presented in Chapter 11.

Table 6.6 contains the LOPA summary sheet for Scenario 1a (HexaneSurge Tank Overflow) using the matrix consequence risk assessmentmethod. Table 6.7 contains the LOPA summary sheet for Scenario 2a (HexaneStorage Tank Overflow) using the fatality frequency method. These twotables include information on the safeguards and IPLs for these examples.


POTENTIAL PITFALL

Does a mitigation IPL reduce the severity of the consequence 100% of the

time?

Answer: No, every IPL has a nonzero PFD (probability of failure on demand).

When it succeeds, a mitigation IPL

• reduces the frequency of the severe consequence, and

• allows or generates a less severe consequence, therefore, constituting a differ-

ent scenario and requiring a separate analysis.

These are two separate scenarios for the purpose of LOPA.

107

TABLE 6.6Summary Sheet for Continuing Example 1a—Risk Matrix Consequence

Categorization Method (Method 1 of Chapter 3)

ScenarioNumber

1a

Equipment Number Scenario Title: Hexane Surge Tank Overflow.Spill not contained by the dike.

Date: Description ProbabilityFrequency(per year)

ConsequenceDescription/Category

Release of 10,000–1000,000 lb hexaneoutside the dike due to tank overflowand spill of hexaneSeverity Category 4

Risk Tolerance Criteria(Category or Frequency)

Initiating Event(typically a frequency)

Loop failure of BPCS LIC. (PFD fromTable 5.1) 1 × 10–1

Enabling Event orCondition

Conditional Modifiers (if applicable)

Probability of ignition N/A

Probability of personnel in affected area N/A

Probability of fatal injury N/A

Others N/A

Frequency of Unmitigated Consequence 1 × 10–1

Independent Protection Layers

Dike (PFD from Table 6.3) 1 × 10–2

SIF Candidate 1 × 10–2

Safeguards(non-IPLs)

Human intervention/BPCS

Total PFD for all IPLs Note: Including added IPL 1 × 10–4

Frequency of Mitigated Consequence

Risk Tolerance Criteria Met? (Yes/No):

Actions Required to Meet Risk Tolerance Criteria: Consider adding SIF (see Chapter 8)

Notes

References (links to originating hazard review, PFD, P&ID, etc.):

LOPA analyst (and team members, if applicable):

Note: Frequency calculations are presented in Chapter 7 and comparison with risk tolerance criteria iscontained in Chapter 8.

108

TABLE 6.7Summary Sheet for Continuing Example 2a—Fatality Frequency Criteria Method

(Method 3 of Chapter 3)

ScenarioNumber

2a

Equipment Number Scenario Title: Hexane Storage Tank Overflow.Spill not contained by the dike.

Date: Description ProbabilityFrequency(per year)

ConsequenceDescription/Category

Tank overflow and spill of hexaneoutside dike. Potential for flash fireand pool fire with probable ignition,injury, and fatality.

Risk Tolerance Criteria(Category or Frequency)

Initiating Event(typically a frequency)

Arrival of tank truck with insufficientroom in the tank due to failure of theinventory control system. Frequencybased on plant data.

1

Enabling Event orCondition

Conditional Modifiers (if applicable)

Probability of ignition

Probability of personnel in affected area

Probability of fatal injury

Others

Frequency of Unmitigated Consequence

Independent Protection Layers

Dike (PFD from Table 6.3) 1 × 10–2

Human action to check level prior tofilling (PFD from Table 6.5)

1 × 10–1

SIF Candidate 1 × 10–2

Safeguards(non-IPLs)

BPCS loop

Total PFD for all IPLs Note: Including added IPL 1 × 10–5

Frequency of Mitigated Consequence

Risk Tolerance Criteria Met? (Yes/No):

Actions Required to Meet Risk Tolerance Criteria: Consider adding SIF (see Chapter 8)

Notes

References (links to originating hazard review, PFD, P&ID, etc.):

LOPA analyst (and team members, if applicable):

Note: Frequency calculations are presented in Chapter 7 and comparisons with risk tolerance criteriaare contained in Chapter 8.

Appendix A contains the completed LOPA summary sheets for all four sce-narios and for all the methods discussed in Chapters 7 and 8. In addition,LOPA sheets for a method used by one chemical company are also included.

Continuing Example 1: Hexane Surge Tank Overflow

Scenario 1a: Hexane Surge Tank Overflow—Spill Not Contained bythe Dike

INITIATING EVENT

The initiating event is failure of the BPCS level control loop. This means thatno credit can be taken for the BPCS logic solver as part of any other IPL. Alter-natively, a common cause failure (loss of power, cable damage, etc.) could bethe cause of the failure of the BPCS level control loop and all, or many, otherloops associated with the system, again rendering, other potential BPCSbased IPLs useless.

IPLs IN PLACE

Once the spill has occurred from the tank, the dike is in place to contain it.Only if the dike fails to operate will a widespread spill occur with the poten-tial for fire, damage and fatalities. The dike meets the requirement for an IPLfor the following reasons:

• It will be effective in containing the spill from the tank if it operates asdesigned.

• It is independent of any other IPL and of the initiating event.• Its design, construction, and present condition can be audited.

For the purposes of this example the dike is assigned a PFD of 1 × 10–2 (seeTable 6.3); that is, it will fail to contain the spill once in every 100 times it ischallenged. Each organization should consider what PFD should be assignedfor a particular IPL.

SAFEGUARDS THAT ARE NOT IPLs FOR LOPA

A hazard evaluation team may have considered alarms generated by theBPCS and subsequent human actions as safeguards. In this example, no creditis given for human action as an IPL for the following reasons:

• The operator is not always in attendance and so it cannot be assumedthat operator action would be effective in detecting and preventing aspill, independently of any alarm, before it had reached a stage where asignificant release would occur if the dike failed.

6.7. Continuing Examples 109

• The failure of the BPCS level control loop (initiating event) must beassumed to result in the failure of the system to generate an alarm thatwould enable the operator to take manual action to stop the flow to thetank. Therefore, any alarm generated by the BPCS would not be fullyindependent of the BPCS system (using Approach A) and thereforecould not be credited as an IPL. Approach B might allow the use of aseparate BPCS-generated alarm with human intervention as an IPL(see Chapter 11).

The relief valve on the surge tank will not be effective in preventing thespill from the tank and, therefore, is not an IPL for this scenario.

IPLs PROPOSED

For methods requiring risk reduction (see Chapter 8) the existing installationdoes not offer opportunities to develop an IPL with the existing BPCS or oper-ator using Approach A as the existing instrumentation, BPCS and operatorsare involved with either the initiating event or existing IPLs. Thus, additionalequipment must be added to reduce the risk. One approach is to install a SIFwith a PFD of 1 × 10–2 to lower the frequency of the consequence as shown inChapter 8. In order to meet the requirements for an IPL with this PFD the SIFcould require

• An independent level measurement device, separate from any otherexisting level measurement devices already in place on the tank.

• A logic solver to process the signal from the level switch and send asignal for action if a high level is detected. This logic solver must beindependent of the existing BPCS system. It may be appropriate to uti-lize a safety system logic solver with multiple processors with self-test-ing capabilities. If this is not selected then the logic solver must be ableto achieve the required PFD performance in order for the whole SIF tomeet the assumed PFD figure of at least 1 × 10–2.

• An additional final element to isolate flow to the tank (pump shut-off,isolation valve, etc.) activated by a logic solver upon receipt of thesignal from the new level measurement device. This final elementmust be independent of any other system in place for halting flow tothe tank.

• A specified testing protocol for all of the components in the SIF systemto enable the overall PFD figure to be achieved.

• Documentation of the SIF, the testing requirements and the results ofthe testing.

Note: If Approach B is used it might be possible to add only a single inde-pendent sensor and claim operator action in response to a high level alarm asan IPL. The PFD for this IPL would depend upon the time available for the


operator to respond to the alarm in order to prevent a significant spill shouldthe dike fail to contain the spill. See Chapter 11.

Scenario 1b: Hexane Surge Tank Overflow—Spill Contained by theDike

INITIATING EVENT

The initiating event is failure of the BPCS level control loop. This means thatno credit can be taken for any other IPLs associated with the BPCS.

IPLs IN PLACE

There are no IPLs in place for this scenario, as the dike cannot be effective asan IPL where, as defined in the scenario description, the spill is containedwithin the dike.


See discussion for Scenario 1a (above)

IPLs PROPOSED

For methods that require risk reduction, the use of a SIF with a PFD of 1 × 10–2

is proposed to lower the frequency of the consequence (see Chapter 8).The requirements for this SIF are described in Scenario 1a.Note: If Approach B is used it might be possible to add only a single inde-

pendent sensor and claim operator action in response to a high level alarm asan IPL. However, the best PFD might be 1 × 10–1 for this scenario if the time forthe operator to respond to an alarm and prevent the tank overflowing isshort. This might not provide enough risk reduction. See Chapter 11.

Continuing Example 2: Hexane Storage Tank Overflow

Scenario 2a: Hexane Storage Tank Overflow—Spill Not Contained bythe Dike

INITIATING EVENT

For this case, the inventory control system fails and a truck arrives at the tankwith insufficient space in the tank for the contents of the truck. This could bedue to an error in ordering, or unit shutdown after the truck was ordered.From operating data, the hazard evaluation team estimates this occurs once ayear.

IPLs IN PLACE

The operator checks the level in the tank on the BPCS LIC before unloading toconfirm that there is room in the tank for the contents of the truck, but does noother tasks. The procedure of the operator checking the level in the tank is anIPL because it meets the criteria of:

6.7. Continuing Examples 111

• Effectiveness—if it is performed correctly, the level is read correctly, andthe operator does not initiate loading if a high level is detected, then anoverflow will not occur.

• Independence—it is independent of any other action, operator action, orinitiating event since the failure was in the inventory ordering system.

• Auditability—The performance of the instruments and operators can beobserved, tested and documented.

This IPL includes BPCS level measurement/display loop and the opera-tor performing the required action. The operator has no other indication ofthe level. From Table 6.5, the PFD for human response to a BPCS loop is 1 ×10–1 as the task is simple and there are no time constraints.

The dike can prevent the consequence of a spill outside the dike; thus it isan IPL. The dike has a PFD of 1 × 10–2 (see Table 6.3).

Thus the total PFD for the IPLs in place for Scenario 2a is 1 × 10–2 × 1 × 10–1

= 1 × 10–3 as both IPLs must fail before the consequence occurs.


The BPCS level control loop detects high level and sounds an alarm. This isnot independent from the first safeguard as it uses the same LI sensor andBPCS logic solver as the IPL procedure that the operator follows prior tounloading. Human action other than response to a BPCS alarm is not an IPLfor this scenario.

IPLs PROPOSED

For methods that require risk reduction, the use of a SIF with a PFD of 1 × 10–2

is proposed to lower the frequency of the consequence (see Chapter 8). Therequirements for this SIF are described in Scenario 1a (above). The LOPASummary Sheet for Scenario 2a is shown in Table 6.7.

Note: If Approach B is used it might be possible to add only a single inde-pendent sensor and claim operator action as an IPL.

Scenario 2b: Hexane Storage Tank Overflow—Spill Contained by theDike

INITIATING EVENT

See Scenario 2a.

IPLS IN PLACE

See Scenario 2a.

SAFEGUARDS THAT ARE NOT IPLS FOR LOPA

See Scenario 2a. The dike is not an IPL for this scenario since the spill is insidethe dike.


IPLS PROPOSED

For methods that require risk reduction an additional IPL as described in Sce-nario 2a would apply.

Note: If Approach B is used it might be possible to add only a single inde-pendent sensor and claim operator action as an IPL.

6.8. Link Forward

Chapter 7 shows how to calculate the mitigated scenario frequency using thescenarios identified from prior chapters, and Chapter 8 shows how to makerisk decisions with the IPLs identified in Chapter 6.

6.8. Link Forward 113

Identifying Independent Protection...

Documents

Transcript of Identifying Independent Protection...