(19a) Key Issues with Implementing LOPA (Layer of Protection Analysis) – Perspective from One of the Originators of LOPA

This paper discusses certain issues and problems observed with LOPA during the first 10 years of broad use. One issue is that most companies and analyst overuse LOPA. For instance, IEC 61511 allows a qualitative PHA team to determine if a SIL is needed for a scenario and to specify a SIL 1 or 2, if one is needed. Yet, most folks believe that only LOPA or RiskGraph or QRA is valid for determining if a SIL is needed and then use the same methods to determine what SIL is needed. As a result, many people do LOPA on almost every scenario of moderate consequence or higher. The LOPA book authors expected the number of scenarios going to LOPA (after a HAZOP/PHA) be 1% to 10% (max) of those uncovered in a qualitative analysis, and some of us believed that usually a team would use LOPA only if the scenario was too complex for the PHA/HAZOP team. Many of us on the original LOPA book authorship considered LOPA a single analyst job, after a PHA/HAZOP, for just a few scenarios (maybe after 100 HAZOP nodes, you would do 1-10 LOPA). Instead, the trend appears to be that companies (or perhaps their consultants) make LOPA part of the PHA (in-situ). If the PHA/HAZOP team is properly disciplined on what qualifies as a safeguard (a qualitative definition of an IPL from LOPA), then performing LOPA in situ is overkill. In most situations, a qualitative team (HAZOP team) can make just as good or better judgment than provided by LOPA. LOPA is just another way to make a decision, has many pitfalls, and doesn't work for many types of scenarios. Another key issue discussed in the paper is that many companies use the values for an IPL or IE listed in the LOPA guideline book (CCPS, 2001) but DO NOT implement the management systems to maintain the IPL at the claimed PFD value.