\n
One or more initiating events (causes) may lead to the effect. Each cause-effect pair is called a scenario. LOPA focuses on one scenario at a time. The frequency of the initiating event is estimated (usually from look-up tables or historical data). Next, each identified security is evaluated on two important characteristics: <\/p>\n
– Is the safeguard<\/em> effective in preventing the scenario from reaching the consequence?
– AND, is the safeguard independent of the triggering event and the other IPLs (independent layers of protection)?<\/p>\n<\/div>\n<\/div><\/div>
\n
\n
\n
\n
\n
If the security meets BOTH tests, it is an IPL. LOPA estimates the probability of the undesired consequence by multiplying the frequency of the triggering event by the product of the PFDs for the applied IPLs. It may be that a further nuance to the estimated risk is warranted. For example, an operator may only be present part of the time or another condition may be required to initiate the scenario (enabling conditions and conditional modifiers). <\/span><\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div><\/div>
\n
\n
\n
\n
LOPA<\/h3>\n\n
The result of the LOPA is a measure of the risk of the scenario – an estimate of the probability AND the consequence. This estimate can be considered a “mitigated consequence frequency”, as the frequency is mitigated by the independent layers of protection. <\/span><\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div><\/div>
\n
\n
\n
\n
\n
\n
If additional risk reduction is required, more IPLs will have to be added to the design. Another option could be to redesign the process. Ideally, this can be done by implementing inherently safer design alternatives. <\/span><\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div><\/div><\/div>![](\"https:\/\/www.pro6com.nl\/wp-content\/uploads\/2021\/07\/Layer-of-Protection-Analysis-LOPA.png\" "\\"Layer")
<\/span><\/div>Want to know more about LOPA and what pro6com can do for your plant in this?<\/h3><\/div>