4.1 Flowchart
When performing LOPA, a clear methodology and approach is needed to make the team focus on the analysis and not on how to do the analysis. The preferred approach is a developed recommended approach based on the worksheet pre-sented in IEC 61511, reproduced in Table 3.1. It is modified taking the views presented in Sections 3.5 and 3.6 into consideration using the terms described in Section 3.2. The steps in Figure 4.1 are described in the paragraphs below.
Step 1: Develop and document the risk acceptance criteria
It is of great importance that this step is done with care. The acceptance crite-ria has to respond to the requirements from the company, authorities and cus-tomers. Acceptance criteria should be established for different types of conse-quences as safety, environmental and economical. In Table 4.1 an example of acceptance criteria for safety hazards are presented. Note that the TMEL is a frequency. For economical / commercial hazards the criteria could consist of target mitigated likelihoods and monetary consequences. If acceptance criteria do already exist, these should be verified before employed.
Step 2: Gather and document data
The results from HAZOP, HAZID and WHAT-IF analysis must be gathered and documented. In addition, documentation like equipment data, maintenance plans and operational conditions and procedures are important to obtain. If the data material is not sufficient, further data must be collected. Especially, the need for further hazard identification must be evaluated.
Figure 4.1: Preferred approach
Table 4.1: Target mitigated event likelihood for safety hazards adapted from Nordhagen (2007)
Severity level Safety consequence Target mitigated event likelihood CA Single first aid injury 3 · 10−2per year CB Multiple first aid injuries 3 · 10−3per year CC Single disabling injury or
mul-tiple serious injuries
3 · 10−4per year CD Single on-site fatality 3 · 10−5per year CE More than one and up to three
on-site fatalities
1 · 10−5per year
Step 3: Transform and integrate data
The data material have to be adapted to the input that LOPA requires. Accep-tance criteria, frequencies and consequence / likelihood ratings may have to be converted. The interface between HAZOP and LOPA is discussed in Chapter 5.
Step 4: Select impact event
The impact events should be evaluated separately, one at the time.
Step 5: Screen impact event
To each impact event a consequence severity level is determined, and the im-pact event under consideration is screened by a criterion using these levels. This could have been done already in the HAZOP study, and if applicable these re-sults can be used. In Table 4.1 such severity levels are given. Let C be denoted as the consequence severity level divided into five categories. If an impact event is classified with consequence severity level C > CC (CD or CE), a QRA has to be performed. This implies that impact event consequences rated as CA, CB, or CCare evaluated with LOPA. Note that the criterion for selecting either QRA or LOPA should be adapted to how the acceptance criteria are expressed and the situation under consideration.
Step 6: Identify initiating causes
The initiating causes are most likely identified in the HAZOP study, but these may not include sub-causes. Sub-causes might be beneficial to identify to get understanding of the situation at hand. But also to get an accurate result when it comes to the calculations. Expert judgment and previous studies (as HAZOP) is used in the identification process.
Step 7: Establish / determine initiating cause frequencies
The initiating cause frequencies must be determined. In Table 4.2 initiating cause frequencies are presented. In addition expert judgment and plant specific data / company data may be helpful in determining the frequencies.
Step 8: Select initiating cause - impact event pair
One pair of initiating cause and impact event should be evaluated at the time.
Step 9: Identify IPLs and determine PFDs
The IPLs must be identified, and the assumption of independence should be evaluated with care and be thoroughly documented. If the IPL criteria are satis-fied the PFDs are added in the LOPA worksheet in 3.1. Estimates of PFDs can be found in tables in CCPS (2001) and OREDA. But company or plant specific data can also be used. Table 4.3 shows some PFDs for different IPLs. If a protection layer can not be given credit as an IPL the PFD value entered in the worksheet is 1. The inherent process design and the reduction factor this gives should be evaluated carefully. This protection layer is difficult to assess, and in most cases no risk reduction is given credit.
In addition to the PFDs the following frequency modifiers may be included:
• Occupancy
• Ignition probability
• Time at risk (for systems not continuously in operation)
The additional mitigation (restricted access) column shall include ignition prob-ability, in addition to occupancy. The occupancy factor is calculated as for the risk graph (IEC 61511, 2003). For flammable hazards ignition probability shall be considered. If there are many sources of ignition and the release is large, a conservative value should be chosen. A conservative value is in this case a value close to 1. The time at risk factor reflects the time the system is in the hazardous mode, and is evaluated only for systems not in continuous operation. All of the frequency modifiers are are a number between 0 and 1, and it should be taken care in such a way that not too much risk reduction is given credit (BP, 2006;
CCPS, 2001; Harsem Lund, 2007). Note that the frequency modifiers are optional and should be seen in relation to the impact event under consideration.
Step 10: Calculate intermediate event likelihood (IEL) fIEL,i= fi·
J
Y
j =1
P F Dij (4.1)
Table 4.2: Typical frequency values assigned to initiating causes adapted from
Table 4.3: PFDs for IPLs adapted from CCPS (2001) and BP (2006)
IPL PFD
BPCS, if not associated with the initiating event being considered
1 · 10−1 Operator alarm with sufficient time
avail-able to respond
1 · 10−1
Relief valve 1 · 10−2
Rupture disc 1 · 10−2
Flame / detonation arrestors 1 · 10−2
Dike / bund 1 · 10−2
Underground drainage system 1 · 10−2
Open vent (no valve) 1 · 10−2
Fireproofing 1 · 10−2
Blast-wall / bunker 1 · 10−3
Identical redundant equipment 1 · 10−1(max credit) Diverse redundant equipment 1 · 10−1to 1 · 10−2
Other events Use experience of personnel
SIS that typically consist of single sensor, logic and final element
1 · 10−1to 1 · 10−2 SIL 1 SIS that typically consist of multiple sensors,
multiple channel logic and multiple final el-ements (for fault tolerance)
1 · 10−2to 1 · 10−3
SIL 2 SIS that typically consist of multiple sensors,
multiple channel logic and multiple final el-ements. Requires careful design and fre-quent proof tests
1 · 10−3to 1 · 10−4
SIL 3
Equation 4.1 shows the formula to calculate the intermediate event likeli-hood, fIEL,i, for a certain initiating event, i . Let the number of IPLs range from 1 to J, and each IPL have a PFD denoted P F Dij. The product of the PFDs is multi-plied by the frequency of initiating event i , fi. The intermediate event likelihood is the expected frequency of the consequence with the credited IPLs in place.
Next initiating cause - impact event pair
If there are more initiating event - impact event pairs, they should be evaluated.
As shown in Figure 5.1 the analysis team have to go back to the pair selection phase. This process is iterative until all pairs have been evaluated
Step 11: Sum up the intermediate event likelihoods
The intermediate event likelihood of all the related initiating cause - consequence pairs have to be summed, in order to identify the total rate of demands that are not eliminated by the system (including planned / existing protection layers and mitigation). Equation 4.2 shows the applied formula to determine the total mit-igated event likelihood fIEL,total, for initiating events ranging from i = 1 to i = I .
fIEL,total= XI i =1
fIEL,i (4.2)
Target risk measurement
Column 3 in Table 4.1 shows the target mitigated event likelihood (TMEL) for different consequence severity levels. The combination of the TMEL and con-sequence category is in this case the risk acceptance criteria, which is the target risk measure. For the concerning consequence severity level - the total interme-diate event likelihood and target mitigated event likelihood are compared. If the total intermediate event likelihood is less than the target mitigated event likeli-hood, the target risk is acceptable. The next impact event can then be evaluated.
If not, a SIL should be determined. Note that even if the target risk is acceptable, introducing a SIL may still be vice due to uncertainty in the calculations.
Modifications and changes to planned / existing system should be consid-ered prior to introducing a SIF. Can the risk be reduced by enhancing the existing protection layers, or by changing the design? If the answer is yes, such measures should be evaluated, and the new intermediate event likelihood calculated and compared with the acceptance criteria. If the answer is no, a SIF with an associ-ated SIL have to be implemented.
Step 12: Determine SIL
diate event likelihood) must be eliminated by the SIF, hence the needed SIL. By dividing the target mitigated event likelihood by the total intermediate event likelihood, the PFD responding to the SIL is found. Equation 4.3 show how the acceptable frequency, fAcc, is used to determine the necessary risk reduction.
The target mitigated event likelihood is denoted fTMEL. SIL = neccesary risk reduction = fAcc
fIEL,total = fTMEL
fIEL,total (4.3)
Screen by SIL
If the resulting SIL > SIL 3, a QRA should be initiated. A high SIL requirement is stricter demanding higher reliability and performance of the SIS. LOPA includes uncertainty, and for SIL requiring high integrity a more thorough analysis is rec-ommended. If SIL < SIL 4, the flowchart loop is finished. Note that the screening criterion in this case is SIL > 3, and the criterion should be adapted to the situa-tion at hand. In some cases SIL > SIL 2 is more applicable.
Step 13: Calculate mitigated event likelihood (MEL)
The last step is to calculate the mitigated event likelihood, fmit,i. This is the fre-quency of the consequence in events per year, after the SIF has been imple-mented. The selected SIL is multiplied with the intermediate event likelihood to obtain the mitigated event likelihood, as Equation 4.4 shows.
fMEL,i= fIEL,i· SIL (4.4)
The calculation is done for all rows in the LOPA worksheet related to the concerning impact event. Note that the mitigated event likelihood is the same as the TMEL if the exact number of the calculated SIL is employed. It then serves as a check whether the acceptable risk is satisfied or not with the current calculated SIL.
This is the last step in the LOPA procedure. If there are more impact events, these shall be evaluated. Then, the analysis team go back to the pick impact event - phase. But, this is not implemented in the flowchart. The team usually continue the analysis until all process deviations from the HAZOP are evaluated.
4.2 Comments to the preferred LOPA approach
The preferred approach is an overall approach considering the planned / exist-ing system without the proposed SIF. As discussed previously several screenexist-ing tools exists, but it is chosen to screen by consequence and SIL only. Conducting a risk graph-analysis for then to initiate a LOPA cause extra work and increased engineering cost.
Only safety aspects have been considered. Usually economical and environ-mental issues are also evaluated during a LOPA analysis. Such levels may be determined to the SIF, and the integrity level giving the highest integrity level chosen. Note that this requires additional acceptance criteria (BP, 2006; Nord-hagen, 2007).
In the approach it is chosen to select an impact event before it is screened by severity level. Another possibility is to do this the other way around.
Another issue is how to express and transmit the requirements to the ven-dors or to the further allocation process. If the LOPA result in a required PFD 8 · 10−3giving SIL 2, and the suppliers design their product with a designed PFD of 1 · 10−2the outcome may be that the system do not fulfill requirements. Im-portant issues that must be covered in the interface work packages by the system vendor are: What is the requirement? How is it expressed?