Advanced LOPA Topics

Transcription

1 11 Advanced LOPA Topics Purpose The purpose of this chapter is to discuss more complex methods for using the LOPA technique. It is intended for analysts who are competent with applying the basic LOPA methods presented in Chapters 3 through 8 and with event tree/fault tree techniques and methods. The approaches discussed in this chapter will enable an analyst to determine whether the conservative assumptions used in LOPA can be relaxed in certain cases (Section 11.2); and/or use LOPA to assist in more refined risk assessment studies (Sections ). The continuing examples are analyzed using a less conservative approach than employed in earlier chapters Counting Multiple Functions in One BPCS as IPLs in the Same Scenario In this section the basic LOPA assumption of complete independence of IPLs from the initiating event and other IPLs credited in the same scenario is discussed. Situations where it may be appropriate to relax this requirement are presented. Important requirements and cautions are included which the reader is urged to read and understand before using this less conservative approach. 173

2 Advanced LOPA Topics Note: Use of this approach could result in using a PFD for BPCS loop IPLs that is less than the limit required by IEC (IEC 2001). Such a change should only be made with adequate analysis and documentation. Comparison of Methods Chapter 6 briefly discussed the differences between the two approaches used for assessing the independence of IPLs involving BPCS loops to decide how many IPLs exist for a particular scenario. Approach A, which was presented in Example 6.2, assumes that a single BPCS loop failure invalidates all other BPCS loops using the same logic solver. It was used in Chapters 2 8 because its rules are clear and it is conservative. Approach B, also presented in Example 6.2, assumes that if a BPCS loop fails, it is more probable that the failed component is the sensor or the final control element, and that the BPCS logic solver remained functional. This approach may be used if the analyst is experienced and adequate data are available on the design and actual performance of the BPCS logic solver. Another approach would be to divide the initiating event (BPCS failure) into three scenarios where the initiating event is alternately the sensor, the logic solver, or the final element. Approach A In order for a device or action to be fully credited as an IPL, it must be independent of 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 assumes that a single BPCS loop failure invalidates all other BPCS loops using the same logic solver. This approach eliminates many common mode failures (see Table 6.2) affecting the PFD for the IPLs which are claimed. Approach A is straightforward to apply since its rules are unambiguous and little judgment is left to the analyst or team. Approach B This approach assumes that if a BPCS loop fails, it is most probable that the failed component is the sensor, the final control element, or another component other than the logic solver itself. The assumptions made in Approach B are exactly the same as those made in Approach A except that Approach B assumes the BPCS logic solver continues to function when the failing loop element is the sensor or final element. Industry experience is that the failure rates of the detection devices and the final control elements are usually much higher than the failure rate of the BPCS logic solver in typical installations.

3 11.2. Counting Multiple Functions in One BPCS as IPLs in the Same Scenario 175 Approach B allows a limited number of additional elements of the BPCS to serve as IPLs for the same scenario. Approach B BPCS Loop Failure Concepts Failure Mode of BPCS Loops Figure 11.1 shows the components of a simplified BPCS loop. The final control element could be a valve, solenoid, etc., or it may be an alarm that initiates human intervention. The important point is that if any one of these components fails, then the entire loop is disabled and it will not fulfill its function when challenged. Each component of the BPCS loop has its own failure rate, which is a function of its design, manufacture, installation, maintenance, etc. The probability of a component failing on demand (PFD) is related to its historic failure rate and its effective test rate. In general, for a shorter period between testing, the PFD for a component is lower. The PFD for an entire BPCS loop is approximated by summing the PFDs of all its components. One important point concerning BPCS systems is their susceptibility to human error. In many installations the BPCS is deliberately made accessible to personnel who have the ability to change set-points, bypass alarms, etc. This openness, while providing operational benefits, does leave any BPCS IPLs open to compromise due to human error. The PFD limit stipulated for all IPLs in the BPCS in IEC does, in a general manner, take account of this factor. Therefore, any method that wishes to take a lower PFD for a BPCS IPL should also consider whether the security of the existing BPCS can support such a change. In some installations it might be necessary to impose greater control over access to the BPCS to justify the use of a lower PFD, with appropriate analysis, but this could impose unacceptable operational constraints. The security constraints for access to an SIS system are usually far more severe than for a BPCS. CAUTION Situations with a high challenge rate (e.g., where the challenge frequency is similar to the effective test interval) must be examined with care (see Section 7.2 and Appendix F). FIGURE Simplified components of a BPCS loop.

4 Advanced LOPA Topics BPCS Logic Solver Failures Historical data from a number of companies suggests that, for typical installations, the effective PFD for the BPCS logic solver is at least two orders of magnitude lower than the sensor or final control element of a BPCS loop. When this is true, the probability that the failure of a BPCS loop involved a failure of the BPCS logic solver is no more than approximately 1 in 100 ( ). In other words, in at least 99 cases out of 100, when the BPCS loop fails, the BPCS logic solver remains fully operational. Any claim for a lower PFD must be supported by internal data or certification by a recognized independent third party see below for important requirements and cautions. As noted above, without adequate access and security controls the potential for human error may prevent additional BPCS functionality being counted as an IPL, even if all the other conditions described in this section are satisfied. If, however, all the conditions are met, it may be justifiable to relax the rule used in the basic LOPA method (Approach A) where the failure of any BPCS loop requires all other BPCS loops using the same logic solver (or any other common component) to be considered ineffective. This is the key difference between Approach B and the basic LOPA method. For example, in Figure 11.2, there are two BPCS loops using the same BPCS logic solver. If both of these loops meet the other requirements for an IPL for the same scenario, the basic, conservative, LOPA method (Approach A) would only allow one of these loops to be credited as an IPL for the same scenario. This is due to the BPCS logic solver serving as a common element to both loops. Approach B would allow both loops to be credited as IPLs for the same scenario, provided the requirements discussed in the following sections are satisfied. FIGURE Typical BPCS logic solver with multiple loops for the same scenario.

5 11.2. Counting Multiple Functions in One BPCS as IPLs in the Same Scenario 177 Guidelines for Crediting Multiple Functions in One BPCS Logic Solver for the Same Scenario The recommended guidelines for crediting multiple BPCS loops as IPLs for the same scenario are as follows: Adequate Access and Security Procedures These are required to provide assurance that the potential for human error in programming, modifying or operating the BPCS is reduced to an acceptable level. Sensor/Final Control Elements The sensors and final control elements usually have the highest PFD values of all the components in a BPCS loop and are the most likely to cause the failure of a loop. The following general rules qualify multiple functions on a BPCS logic solver as multiple IPLs: The sensor for an additional, different BPCS function must be independent of the sensor that is part of the initiating event of the scenario. The final element used in an additional, different BPCS function must be independent of the final element that is part of the initiating event of the scenario. The sensor for an additional, different BPCS function must be independent from any other sensor used in an IPL in the scenario. The final element for an additional, different BPCS function must be independent from any other final element used in an IPL in the scenario. Therefore, no credit can be taken for multiple loops where either the sensor, or the final control element (including action by the same alarm and operator response) are common to loops that could otherwise be IPLs for a given scenario or were part of the initiating or enabling events. This is identical to the approach taken in the basic LOPA method. Thus, as shown in Figure 11.3 since the single sensor is used for both BPCS loops 1 and 2, only a FIGURE Effect of common sensors for the same scenario.

6 Advanced LOPA Topics FIGURE Effect of common final control elements (including alarms) for the same scenario. single BPCS loop can be claimed as an IPL for this scenario. Similarly, in Figure 11.4, the final control element (or the same alarm and operator response) is common to both BPCS loops, and only a single BPCS loop can be claimed as an IPL for this scenario. Input Cards/Logic Solver/Output Cards The input and output cards used for transferring information into and out of the logic solver are components that may fail at a higher rate than the logic solver itself. It is recommended that no additional BPCS loops be counted as IPLs where an input or output card is common unless adequate performance can be demonstrated. In Figure 11.5, A, B, C, D are sensors and 1, 2, 3, 4 are final control elements. Provided all other requirements for an IPL are satisfied, credit would be allowed for a loop with a path of (Sensor A Input Card 1 Logic Solver Output Card 1 Final Control Element 1) as an IPL. If the second control loop has a path of (Sensor D Input Card 2 Logic FIGURE Effect of common input/output cards for the same scenario.

7 11.2. Counting Multiple Functions in One BPCS as IPLs in the Same Scenario 179 Solver Output Card 2 Final Control Element 4) then it could also be claimed as an IPL. This assumes that both loops meet all the other requirements for an IPL for the same scenario. However, if the second loop has a path of (Sensor D Input Card 2 Logic Solver Output Card 1 Final Control Element 2), no credit would be allowed for the second loop, as output Card 1 is common to both loops. Similarly, no credit would be allowed for a second loop if the path was (Sensor D Input Card 1 Logic Solver Output Card 2 Final Control Element 2) as Input Card 1 is common to both. Maximum Number and Type of IPLs Approach B makes the assumption that the failure of a BPCS loop will be due to components other than the BPCS logic solver. Thus, we make the following recommendations: The total IPL PFD taken, including that which would be taken by strictly applying the basic LOPA method, must be no less than two orders of magnitude, unless the BPCS logic solver has been certified to a higher level of reliability. That is, the additional PFD credited for the BPCS IPL should be no less than This would allow a best case overall failure probability of for the BPCS [( as per Approach A) ( )] if justified by additional analysis as described in this section). Note: This would be outside of IEC 6511 requirements for the PFD for all BPCS IPLs. No more than a total of two BPCS loops should normally be credited as IPLs for the same scenario if the initiating event does not involve the failure of a BPCS logic solver. Each of these loops must satisfy all of the requirements for an IPL discussed in Chapter 6 and also the rules and guidelines contained in this section. Thus, in Figure 11.6, if all four of the loops individually meet the requirements for an IPL for the same scenario, only two of them would normally be credited as IPLs using FIGURE Maximum number of BPCS loops credited for the same scenario.

8 Advanced LOPA Topics this method (Approach B). Only one would be credited as an IPL using the basic LOPA method (Approach A). The actions of the loops may be either two mechanical operations (e.g., shutting a valve, starting a pump) or one mechanical action and one alarm requiring human action. Credit should not be taken for two human actions as IPLs for the same scenario unless detailed analysis shows that complete independence can be achieved and both meet the requirements for human action as an IPL (see Chapter 6). If the initiating or enabling event involves the failure of a BPCS loop, then no more than one BPCS loop should normally be credited as an IPL for the same scenario. If human failure is the initiating event then it is not recommended that a BPCS alarm starting human action be counted as an IPL, unless detailed analysis shows that complete independence can be achieved and the operation meets the requirements for human action as an IPL (see Chapter 6). If the initiating event is human error and the enabling event does not involve the BPCS, then two BPCS loops can be counted as separate IPLs. Information/Expertise Required to Apply Credits for Multiple BPCS Loops In order to count additional BPCS loops as IPLs, the information and expertise that are required include: Data and Analysis Since this method relies on the assumption that the BPCS logic solver has a PFD at least two orders of magnitude lower than the other components of the BPCS loop (sensor, final control element, etc.), data to support this assumption must be available and analyzed. These data could include historical performance data for the BPCS logic solver, input/output cards, sensors, final control element, human response, etc.; data from the manufacturer of the system (such information must be examined critically to ensure that it applies to situations similar to the particular installation, the effective test periods are comparable, and any assumptions made are understood and are applicable to the system under consideration); inspection, maintenance and test data over a significant period; instrument diagrams, P&IDs, loop diagrams, standards, specifications, etc., describing the actual installation. Information on the security of access to the BPCS for programming changes, alarm bypassing, etc.

9 11.2. Counting Multiple Functions in One BPCS as IPLs in the Same Scenario 181 Analysis of these data could include calculation of effective failure rates for BPCS loop components for the facility or system; comparison of PFD data for various components and, particularly, for the BPCS logic solver; assessment of input/output card logic and associated loop independence. This should result in assessment of whether the access and security controls are adequate; assessment of whether the use of multiple BPCS loops as IPLs for the same scenario is appropriate for a particular facility or scenario; written justification for any assumptions made in the analysis. Analyst Expertise This method should only be attempted if the analyst is fully experienced in the basic LOPA method and has demonstrated expertise in understanding the possible interrelationships among equipment, instrumentation, and humans. Experience with event tree and fault tree techniques is highly desirable, as these use structured approaches which emphasize cause-and-effect interrelationships. The analyst must be capable of judging whether the available data are sufficient and complete and whether they can be used for making the required calculations with adequate accuracy; understanding whether the design of the instrumentation and BPCS systems provides the required independence; understanding the effects of the proposed IPLs on the process or system. The analyst may be a single person or a number of people each contributing to the complete analysis, but with no single person performing the whole analysis. For example a qualified independent third party may certify a BPCS logic solver to have a low enough PFD that allows multiple BPCS loops to be used in the same scenario. A skilled instrument designer may analyze historical performance data and maintenance records to establish standard designs that meet the requirements of independence and reliability or establish the reliability of an existing BPCS loop. A process engineer working alone or in a team environment may use a tool, such as LOPA, to determine the combination of layers of protection that are needed to effectively control an undesirable consequence. This analysis may indicate that multiple BPCS loops can work independently to stop the undesired event. The process engineer, process control engineer, and instrument engineer gather all the information regarding BPCS component reliability and process requirements, then collab-

10 Advanced LOPA Topics orate to design and implement a system of multiple BPCS loops that meet the requirements of independence and reliability. The LOPA analyst must work with all of these disciplines to arrive at a final result. If analysts with these skill-sets are not available, then only the basic LOPA method should be used. Cautions When using Approach B, the restrictions discussed above must be applied. However, this is a less conservative approach to analyzing risk and, by using it, an organization increases the potential for overlooking certain important interactions, in particular common cause failures. This issue is discussed in Section 6.3 and it can be a very subtle factor in increasing risk. The basic LOPA technique is conservative, but does provide a high level of protection against common cause failures. If Approach B is used then the analyst must be especially vigilant in looking for such interactions. This will normally require additional time and resources, which may be justified by the potential for eliminating the need for additional IPL systems. CAUTION: The reader is advised that the draft IEC 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 must be more than , that is, the PFD for all the BPCS risk reduction functions is not allowed to be lower than The user should provide the analysis to support the risk reduction claimed for multiple BPCS IPLs. Continuing Examples Using Approach B Crediting Multiple BPCS Loops Two scenarios from the continuing examples used in Chapter 2 through 8 are used to demonstrate the application of Approach B and the issues that can arise. It is assumed for the purposes of this discussion that adequate data and analysis support the use of Approach B for this installation. Scenario 1a: Hexane Surge Tank Overflow Spill Not Contained by the Dike In this scenario the initiating event is the failure of the BPCS level control loop, leading to a tank overflow which is not contained by the dike and result-

11 11.2. Counting Multiple Functions in One BPCS as IPLs in the Same Scenario 183 ing in a consequence of a widespread hexane spill. Approach B allows the use of a single additional BPCS loop as an IPL for this scenario (one loop has already been accounted for in the initiating event), provided that this meets all the other requirements for an IPL. Such a BPCS loop could be either an additional level sensor which would provide a method of stopping flow to the tank (a new separate isolation valve or pump cut-off) or an additional level sensor that would sound an alarm in the control room and initiate operator action to stop flow to the tank before the tank overflowed. In either case the requirements discussed in this section regarding separate sensors, input and output cards, and final control element apply. If a separate level sensor loop is installed with an additional final control element to stop flow to the tank, the minimum PFD for this IPL would be (see Table 6.4), unless another value was justified. The adequacy of this level of risk reduction would depend on the security and access controls for the BPCS providing adequate protection against human error, the risk tolerance criteria used, and the cost benefit analysis based on the cost of installing the full SIS recommended in Chapter 8 versus the lower cost of installing only a new BPCS loop and its components and the lower total PFD. Thus, an organization would need to determine whether the increased frequency of the event based on only an additional BPCS loop is justified by the lower cost. A separate level sensor loop with an alarm and operator action to stop filling the tank could be counted as an IPL. This is possible if the rate of feed to the tank, the tank cross-sectional area, the normal level, the level at which the alarm sounded, and the dike volume allowed adequate time for the operators to respond before the tank overflowed (see Chapter 6). If this is the case, and the requirements discussed in Section 6.5 for human action are satisfied, it might be possible to use a PFD of for one separate alarm loop. If two separate sensors and alarm annunciators are used, and the operators are well trained and drilled in the action, a PFD of might be possible. Again, whether this approach would be appropriate would depend upon the risk criteria used and a cost benefit decision. Scenario 2a: Hexane Storage Tank Overflow Spill Not Contained by the Dike In this scenario the initiating event is the failure of the inventory control system due to a tank truck arriving at the storage tank with insufficient room in the tank for the contents of the truck. This leads to an overflow of the tank.

12 Advanced LOPA Topics If the inventory control system is part of the BPCS that also monitored the tank, Approach B allows the use of one additional BPCS loop as an IPL for this scenario, provided that this meets all the other requirements for an IPL. If the inventory control system is separate from the BPCS that monitors the tank, Approach B would allow the use of two additional BPCS loops as IPLs for this scenario. Examples of additional BPCS loops include an additional level sensor and indicator which the operator would use as a check on the tank level prior to unloading or an additional level sensor providing a method to stop the flow to the tank (separate isolation valve or pump cutoff). In either case, the requirements discussed in this section regarding separate sensors, input and output cards, and final control element apply. The risk reduction adequacy of this approach would depend on the security and access controls for the BPCS providing adequate protection against human error, the risk tolerance criteria used, and the results of a cost benefit analysis, or similar study, based on the cost of installing the full SIF recommended in Chapter 8 versus the lower cost of installing only new BPCS loop(s) and components. If a separate level sensor loop is installed with an additional final control element to stop flow to the tank, the minimum PFD for this IPL would be (see Table 6.4), unless another value was justified. The adequacy of this level of risk reduction would depend on the risk criteria used and a cost benefit decision. If the BPCS is separate from the inventory control system both the pump shutoff and operator alarm IPLs could be used, provided that the requirements above were met (e.g., separate sensors, input/output cards, final control element). This approach would require complete separation between the inventory control system and the BPCS system for the tank and no human factor interactions in the facility for these systems. A maximum PFD of for the two BPCS loops as IPLs could be claimed (see above) Summation of Risk for Multiple Scenarios In some methods the risk is assessed on a per scenario basis and this is compared with the organization s risk tolerance criteria to determine whether action is required. In other methods, the risk associated with an entire plant or even an entire complex is combined and compared with the risk tolerance criteria. Either approach can be used, but certain issues arise when calculating the risk associated with an entire plant or complex. These issues are discussed below.

13 11.3. Summation of Risk for Multiple Scenarios 185 For any facility there will be a range of scenarios which will occur at different frequencies and have a range of outcomes from minor to catastrophic. This method makes an attempt to combine these to produce an overall assessment of the risk. Applications For this approach, the total risk for a facility is determined to the level of accuracy of the method if all important scenarios have been identified. The total risk is then used to make decisions for each facility on whether it should remain in operation and to determine the priorities for applying resources (if required) to reduce risk to meet the risk tolerance criteria for the facility. However, the additional work may not be justified, since working on the individual scenarios should reveal the scenarios with the highest risk. Method The consequence categories used for this method must be appropriate for summing between different scenarios. Methods that use a fatality frequency as the risk measure can apply this technique directly by adding together all of the fatality frequencies calculated for a given facility. Methods using consequence categories can also apply this technique, but it is more cumbersome. Example 11.1 shows how to estimate the frequency of a consequence that has more than one initiating event. Example 11.1 The scenario is the catastrophic rupture of a distillation column due to high pressure. There are two initiating events for high pressure: loss of cooling water at the condenser ( /yr), and failure of the steam flow control loop ( /yr). These two scenarios can be prevented by two IPLs, each with a PFD of Equation (7-1) is used to calculate the frequency for the consequence of rupture due to no cooling, rupture no cooling no cooling 2 j no cooling j= 1 f = f PFD = f [ ] PFD PFD f rupture no cooling = ( 1 10 / yr) ( 1 10 ) ( 1 10 ) = Similarly, for rupture due to steam loop failure, rupture steam loop steam loop 2 j steam loop j= 1 f = f PFD = f [ ] IPL1 IPL /yr PFD PFD f steam loop = ( 1 10 / yr) ( 1 10 ) ( 1 10 ) = 1 10 / yr IPL IPL2

14 Advanced LOPA Topics Equation (7-7) is used to determine the consequence frequency for both events, 2 rupture both C rupture no cooling rupture steam loop f = f = f + f i= f rupture both = ( 1 10 yr) + ( 1 10 yr) = 2 10 yr In LOPA, correction for both events happening simultaneously is not normally done (this correction is called subtracting the event intersection). Omitting this correction as shown in this example slightly overestimates the risk, but it is a reasonable, conservative simplification. Using purely additive methods for combining risk assumes that an organization s tolerance for risk is linear (e.g., 1 fatality in 100 years is equivalent to 10 fatalities in 1000 years). This is questionable, as most governments that have addressed this issue have produced criteria that are less accepting of high consequence events compared to low consequence events. However, the additive method is appropriate to combine risk of single fatality scenarios Using LOPA to Develop F/N Curves An F/N curve plots the cumulative frequency (F) versus the number of fatalities (N) and is intended to incorporate a number of scenarios into a single figure (see Figure 11.7 for a typical F/N curve). LOPA may be used to generate an F/N curve only when the consequence of each scenario is stated in terms of fatalities or another consequence parameter (such as serious injury, business loss) consistent with the organization s risk tolerance criteria. The data shown on an F/N curve is only as accurate as the method used. Therefore, F/N curves generated using LOPA should be used with caution. Uses An F/N curve is useful for visually assessing the risk associated with a scenario or facility and to compare it to risk tolerance criteria that can be plotted on the same graph. The frequency intercept of the line at N = 1 and the shape of the curve provides additional information. The frequency at which the number of fatalities is at least equal to 1 provides a baseline risk for the scenario or facility which can be compared directly. The shape of the curve allows the analyst to assess whether the risk is to a relatively small population, in which case the curve would fall steeply. Alternatively, if the risk were to a large population, the curve would be expected to fall only gradually with increasing values of N. As discussed in Chapter 8, most guidelines that have

15 11.4. Using LOPA to Develop F/N Curves 187 FIGURE Typical F/N curve. been developed by governmental agencies and individual companies are less tolerant of high consequence events than low consequence events. The F/N curve presents data in a form that allows the direct comparison with such criteria. Method The method to construct an F/N curve using LOPA is as follows: 1. Generate all the scenarios for a given facility or complex. 2. Tabulate the mitigated frequency for each scenario. 3. Tabulate the number of fatalities for each scenario. 4. Starting with the largest consequence (number of fatalities), calculate the cumulative frequency of that consequence by adding the frequencies of all scenarios with that number of fatalities. This is the first, and extreme right hand point, on the curve. 5. For the next highest consequence, add the sum of the frequencies of all the scenarios with that consequence to the frequency for the largest consequence. This is the second point on the curve and is located to the left of the point obtained in Step Continue adding the frequencies for each successively lower consequence, until the lowest consequence has been reached. 7. If the lowest consequence is not one fatality, add a point with a consequence of one fatality at the same frequency as that calculated in Step 6.

16 Advanced LOPA Topics Operator Response Issues Human action as an IPL is discussed in Section 6.5. This section addresses more advanced issues but, as noted previously, extreme care should be used in examining human factors in assigning IPL credits. Immediate versus Delayed Feedback of an Erroneous Human Action In certain cases an operator receives immediate feedback that an action was in error. In other cases the results of an incorrect human action are not apparent for minutes, or even hours. For both cases, human error is the initiating event, but the question is, if there is immediate feedback, can human action be considered an IPL? If, for example, an operator opened a small quarter-turn valve expecting the line to be depressurized, and material started issuing from the valve, the operator would be immediately aware of the erroneous action. In most cases the operator would immediately close the valve, and no harm would occur. However, the possibility exists that the operator might be disabled, or in a panic, and the valve would remain open. An analyst must consider whether to credit human action as an IPL in such a case and, if it is decided that immediate feedback is an IPL, what PFD should be assigned. Obviously, with delayed indication of an error, no credit can be taken. Multiple Operator Response In some situations the BPCS alarms, or other systems, may notify multiple operators of a potentially unsafe condition independently (by using multiple sensors, multiple annunciators, etc.). This situation could be credited as multiple IPLs (e.g., one for each separate notification loop); or as a single IPL with a lower PFD, particularly if the time available for action is substantial for all of the operators (see Table 6.5). If one operator has only a short period of time to respond, it would not be appropriate to reduce the PFD for human response. Again, care is required in such an approach, as inadequate training may be a common cause for all operators failing to take the correct action. Example 11.2 For some cases, a scenario may proceed slowly enough that one, or possibly more, shifts of operators may have an opportunity to respond to an alarm and to prevent the consequence. The PFD for such an IPL would be lower if each new shift checks the status of all the alarms upon assuming their duties. It is also possible that inadequate training may be a common cause for several shifts to fail to respond to an alarm.

17 11.7. Focused Fault Tree/Event Tree Analysis of IPL Components Normal Plant Operations as Tests of IPL Components Many of the components of safety systems, particularly those in BPCS loops, are used during the normal operation of the process. Under some conditions the successful performance of normal tasks can be used as an effective test of the device or system and, thereby, potentially decrease the PFD of the device, and possibly the system. Section 6.6 discusses the equations used to calculate the PFD using the historical failure rate data and the effective test period. Generally, if the time between tests is decreased, the PFD for the device or system tested will also be decreased. If, for example, a temperature sensor is monitored on a regular basis and is compared with other sensors (perhaps ones used in a SIS) then the period between comparisons might be used as the effective test period. However, care must be taken with this approach (see below). Another example would be a valve that is cycled regularly so that its shutoff can be confirmed. This could be considered a test of the valve s capability to provide a tight shut-off. The period between the operation of the valve could be used as the test interval and the PFD of the valve thereby decreased (improved). Such an analysis would normally be applied to the components with the highest PFDs (sensors, valves, etc.), rather that the BPCS logic solver, in order to decrease the PFD for an entire system. Care must be taken in applying this concept to ensure that the tests are appropriate, complete and are continued on a regular basis for the life of the component while it is part of an IPL system; full independence is maintained between the testing and other IPL components; the appropriate calculations are performed to determine the PFD for the component and the BPCS loop or associated SIF; other reasons why multiple instruments could report similar readings are explored before accepting such readings as the equivalent of a test Focused Fault Tree/Event Tree Analysis of IPL Components In some cases uncertainty may exist as to the appropriate numeric value assigned to a component of a scenario (initiating event frequency, enabling event or condition probability, PFD for an IPL, consequence size or type). Alternatively, it may be desired to reduce the conservatism in the LOPA technique by using numerical values that are more rigorously calculated, rather than the tabulated values used by a given organization. In such cases it may be appropriate to perform a focused fault tree or event tree analysis. Such an analysis can, when applied selectively, improve the confidence in the results

18 Advanced LOPA Topics of the LOPA study and generate support for the conclusions. The Guidelines for Chemical Process Quantitative Risk Analysis, Second Edition (CCPS, 2000a) describes quantitative (CPQRA) techniques. Effective Initiating Event Frequency An event tree is useful to understand how a scenario is initiated when the initiating event frequency may depend upon one or more enabling events or conditions. For complex scenarios a fault tree may be appropriate. Common Cause Issues A fault tree can be valuable in clarifying interactions and resolving concerns when common cause issues can interact between initiating events and IPLs, or between several IPLs. IPL Component/Overall PFD If a question exists on the appropriate PFD to use for the components of an IPL, or of the IPL itself, a fault tree can be used to demonstrate interactions and provide a rigorous calculation of the appropriate PFD value. In certain cases a fault tree is used to demonstrate that a particular IPL has a PFD significantly higher, or lower, than that which would be assigned using an organization s standard reference tables. This approach is useful if an organization is designing an IPL with a very low PFD to provide the required risk reduction at lower cost or without making major modifications to a process or system. CAUTION The level of accuracy of such quantitative studies should be no greater than that of the LOPA method. Any effort beyond this is wasted for the purposes of LOPA.