[Center for chemical_process_safety_(ccps)]_layer_(book_fi.org)

Layer of Protection Analysis

SIMPLIFIED PROCESS RISK ASSESSMENT

Center for Chemical Process Safety

of the

American Institute of Chemical Engineers

3 Park Avenue

New York, New York 10016-5991

Copyright © 2001American Institute of Chemical Engineers3 Park AvenueNew York, New York 10016-5991

All rights reserved. No part of this publication may be reproduced,stored in a retrieval system, or transmitted in any form or by anymeans, electronic, mechanical, photocopying, recording, or otherwisewithout the prior permission of the copyright owner.

Library of Congress Cataloging-in-Publication DataCIP Data applied for.

ISBN 0-8169-0811-7

It is sincerely hoped that the information presented in this volume will lead to an even more impressive safety

record for the entire industry. However, the American Institute of Chemical Engineers, its consultants, CCPS

Subcommittee members, their employers, and their employers’ officers and directors disclaim making or

giving any warranties or representations, express or implied, including with respect to fitness, intended pur-

pose, use or merchantability, and/or correctness or accuracy of the content of the information presented in this

document. As between (1) American Institute of Chemical Engineers, its consultants, CCPS Subcommittee

members, their employers, and their employers’ officers and directors and (2) the user of this document, the

user accepts any legal liability or responsibility whatsoever for the consequences of its use or misuse.

Acknowledgments

The American Institute of Chemical Engineers and the Center for ChemicalProcess Safety express their gratitude to all the members of the Layer of Pro-tection Analysis Subcommittee for their generous efforts and technical contri-butions in the preparation of this Concept Series book.

Layer of Protection Analysis: Simplified Process Risk Assessment was writtenby the Center for Chemical Process Safety Layer of Protection Analysis Sub-committee.

Chair:Arthur M. Dowell, III, P.E. Rohm and Haas Company

The primary authors wereWilliam G. Bridges ABS Consulting (includes former JBF Associates)Arthur M. Dowell, III, P.E. Rohm and Haas CompanyMartin Gollin Consultant, formerly of ARCO ChemicalWarren A. Greenfield International Specialty ProductsJohn M. Poulson now retired from Union Carbide CorporationWilliam Turetsky International Specialty Products

Providing support and valuable contributions throughout the project wereJohn T. Marshall The Dow Chemical CompanyStanley A. Urbanik E. I. Du Pont de Nemours and Company

Providing important guidance in the conceptual phases of the book wereRodger M. Ewbank Rhodia Inc.Robert J. Gardner now retired from E. I. Du Pont de Nemours and CompanyKumar Bhimavarapu Factory Mutual ResearchJohn A. McIntosh The Proctor & Gamble Company

xiii

R. Peter Stickles A. D. LittleArthur W. Woltman Equilon Enterprises LLC, formerly Shell

CCPS Staff ConsultantRobert E. Bollinger Center for Chemical Process Safety

EditorDr. Daniel A. Crowl Michigan Technological University

The Subcommittee acknowledges the support and contributions of theiremployer organizations in completing this book. Dr. Jack Weaver and Mr.Les Wittenberg of CCPS sponsored and supported this project and providedaccess to the resources of CCPS and its sponsoring organizations. The authorsthank the following for their contributions in creation of figures and tables,setting up committee meetings and teleconferences and other administrativefunctions that were essential to the completion of this book: Ms. Jill Johnsonand Mr. Paul M. Olsen, ABS Consulting; Ms. Sandy Baswell, Ms. MargeKillmeier, Ms. Angella Lewis and Ms. Jackie Rico’t, Rohm and Haas Com-pany.

Before publication, all CCPS books are subjected to a thorough peerreview process. CCPS also gratefully acknowledges the thoughtful com-ments and suggestions of the peer reviewers. Their work enhanced the accu-racy and clarity of the book.

Steve Arendt ABS Consulting (includes former JBF Associates)Helmut Bezecny Dow Deutschland Inc.Alfred W. Bickum Goodyear Tire and Rubber CompanyDennis Blowers, C.S.P. Solvay Polymers, Inc.Michael P. Broadribb BP Amoco CompanyDavid Campbell Concord AssociatesBill Carter CCPS Staff ConsultantCurtis Clements E. I. Du Pont de Nemours and CompanyKimberly F. Dejmek Wilfred Baker EngineeringRichard R. Dunn E. I. Du Pont de Nemours and CompanyJim Evans Union Carbide CorporationRodger M. Ewbank Rhodia Inc.Dave Fontaine Chevron CorporationRaymond A. Freeman ABS ConsultingRaymond W. French Exxon Mobil CorporationDallas L. Green Rohm and Haas CompanyDennis C. Hendershot Rohm and Haas CompanyWilliam H. Johnson E. I. Du Pont de Nemours and CompanyPeter N. Lodal, P.E. Eastman Chemical CompanyDonald M. Lorenzo ABS Consulting (includes former JBF Associates)

xiv Acknowledgments

Vic Maggioli Feltronics CorporationRick Mann Union Carbide CorporationPeter McGrath Olin CorporationNorman McLeod ATOFINA Chemicals, Inc.Steve Metzler Primatech Inc.Dr. Hans Pasman TNOJack Philley, C.S.P. Det Norske Veritas (DNV)Michael E. G. Schmidt, P.E. Industrial Risk InsurersArt Schwartz Bayer CorporationAdrian Sepeda Occidental Chemical CorporationBastiaan Schupp Delft University of TechnologyRobert Stankovich Eli Lilly and CompanyPeter Stickles A. D. LittleDr. Angela E. Summers, P.E. SIS-Tech Solutions, LLCClark Thurston Union Carbide CorporationAnthony Torres Eastman KodakJan Windhorst NOVA Chemicals

Acknowledgments xv

Acronyms and Abbreviations

AIChE American Institute of Chemical Engineers

ALARP As Low as Reasonably Practicable

ANSI American National Standards Institute

API American Petroleum Institute

ASME American Society of Mechanical Engineers

BI Business Interruption

BLEVE Boiling Liquid Expanding Vapor Explosion

B.P. Boiling Point

BPCS Basic Process Control System

C Consequence factor, related to magnitude of severity

CCF Common Cause Failure

CCPS Center for Chemical Process Safety,American Institute of Chemical Engineers

CEI Dow Chemical Exposure Index

CPQRA Chemical Process Quantitative Risk Assessment

CW Cooling Water

D Number of times a component or system is challenged

(hr–1 or year–1)

DCS Distributed Control System

DIERS Design Institute for Emergency Relief Systems,American Institute of Chemical Engineers

DOT Department of Transportation

xvi

EBV Emergency Block Valve

ERPG Emergency Response Planning Guideline

EuReData European Reliability Data (series of conferences)

F Failure Rate (hr-1 or year-1)

f Frequency (hr-1 or year-1)

F&EI Dow Fire and Explosion Index

F/N Fatality Frequency versus Cumulative Number

FCE Final Control Element

FMEA Failure Modes and Effect Analysis

FTA Fault Tree Analysis

HAZOP Hazard and Operability Study

HE Hazard Evaluation

HRA Human Reliability Analysis

IEC International Electrotechnical Commission

IEEE Institute of Electrical and Electronic Engineers

IPL Independent Protection Layer

ISA The Instrumentation, Systems, and Automation Society(formerly, Instrument Society of America)

LAH Level Alarm—High

LI Level Indicator

LIC Level Indicator—Control

LFL Lower Flammability Limit

LNG Liquefied Natural Gas

LOPA Layer of Protection Analysis

LOTO Lock-Out Tag-Out

LT Level Transmitter

MAWP Maximum Allowable Working Pressure

MOC Management of Change

N2 Nitrogen

OSBL Outside Battery Limits

OREDA The Offshore Reliability Data project

OSHA Occupational Safety and Health Administration (U.S.)

P fatality Probability of Fatality

P ignition Probability of Ignition

P person present Probability of Person Present

P Probability

P&ID Piping and Instrumentation Diagram

Acronyms and Abbreviations xvii

PFD Probability of Failure on Demand

PHA Process Hazard Analysis

PI Pressure Indicator

PL Protection Layer

PM Preventive Maintenance

PSM Process Safety Management

PSV Pressure Safety Valve (Relief Valve)

R Risk

RV Relief Valve

SCE Safety Critical Equipment

SIF Safety Instrumented Function

SIL Safety Integrity Level

SIS Safety Instrumented System

T Test Interval for the Component or System (hours or years)

VCE Vapor Cloud Explosion

VLE Vapor Liquid Equilibrium

XV Remote Activated/Controlled Valve

xviii Acronyms and Abbreviations

Preface

For over 40 years the American Institute of Chemical Engineers (AIChE) hasbeen involved with process safety and loss control in the chemical, petro-chemical, hydrocarbon process and related industries and facilities. TheAIChE publications are information resources for the chemical engineeringand other professions on the causes of process incidents and the means of pre-venting their occurrences and mitigating their consequences.

The Center for Chemical Process Safety (CCPS), a Directorate of theAIChE, was established in 1985 to develop and disseminate information foruse in promoting the safe operation of chemical processes and facilities andthe prevention of chemical process incidents. With the support and directionof its advisory and management boards, CCPS established a multifacetedprogram to address the need for process safety technology and managementsystems to reduce potential exposures to the public, the environment, person-nel and facilities. This program entails the development, publication and dis-semination of Guidelines relating to specific areas of process safety;organizing, convening and conducting seminars, symposia, training pro-grams, and meetings on process safety-related matters; and cooperating withother organizations and institutions, internationally and domestically to pro-mote process safety. Within the past several years CCPS extended its publica-tion program to include a “Concept Series” of books. These books are focusedon more specific topics than the longer, more comprehensive Guidelines seriesand are intended to complement them. With the issuance of this book, CCPShas published 65 books.

CCPS activities are supported by the funding and technical expertise ofover 80 corporations. Several government agencies and nonprofit and aca-demic institutions participate in CCPS endeavors.

xi

In 1989 CCPS published the landmark Guidelines for the Technical Manage-ment of Chemical Process Safety. This book presents a model for process safetymanagement built on twelve distinct, essential, and interrelated elements.The foreword to that book states:

For the first time all the essential elements and components of a model of atechnical management program have been assembled in one document. Webelieve the Guidelines provide the umbrella under which all other CCPSTechnical Guidelines will be promulgated.

This Concept Series book supports several of the twelve elements of pro-cess safety enunciated in the landmark Guidelines for the Technical Managementof Chemical Process Safety including Process Risk Management, Incident Inves-tigation, Process Knowledge and Documentation, and Enhancement of Pro-cess Safety Knowledge. The purpose of this book is to assist designers andoperators of chemical facilities to use Layer of Protection Analysis (LOPA) toevaluate risk and to make rational decisions to manage risk with a simplifiedmethodology.

xii Preface

Contents

Preface xi

Acknowledgments xiii

Acronyms and Abbreviations xvi

1Introduction

1.1. Audience 1

1.2. History of LOPA 2

1.3. Use of LOPA in the Process Life Cycle 5

1.4. Linkage to Other CCPS Publications 7

1.5. Annotated Outline of the LOPA book 8

2Overview of LOPA

2.1. Purpose 11

2.2. What Is LOPA? 11

2.3. What LOPA Does 12

2.4. When to Use LOPA 14

v

2.5. How LOPA Works 16

2.6. How to Implement LOPA 24

2.7. Limitations of LOPA 24

2.8. Benefits of LOPA 26

2.9. Introduction of Continuing Examples 27

3Estimating Consequences and Severity

3.1. Purpose 31

3.2. Consequences of Interest 31

3.3. Consequence Evaluation Approaches for LOPA 33

3.4. Continuing Examples 40

3.5. Link Forward 42

4Developing Scenarios

4.1. Purpose 43

4.2. LOPA Scenarios and Components 43

4.3. Identifying and Developing Candidate Scenarios 47



5Identifying Initiating Event Frequency

5.1. Purpose 63

5.2. Initiating Events 63

5.3. Frequency Estimation 68

5.4. Expression of Failure Rates 73


5.6. Limitations (Cautions) 74


vi Contents

6Identifying Independent Protection Layers

6.1. Purpose 75

6.2. Definition and Purpose of an IPL 75

6.3. IPL Rules 80

6.4. LOPA IPL Assessment 88

6.5. Examples of IPLs 90

6.6. Preventive IPLs versus Mitigation IPLs 104



7Determining the Frequency of Scenarios

7.1. Purpose 115

7.2. Quantitative Calculation of Risk and Frequency 115

7.3. Look-up Table Determination of Risk or Frequency 122

7.4. Calculation of Risk or Frequency with Integer Logarithms 124



8Using LOPA to Make Risk Decisions

8.1. Purpose 131

8.2. Introduction 131

8.3. Comparing Calculated Risk to Scenario Risk Tolerance Criteria 133

8.4. Expert Judgment 137

8.5. Using Cost–Benefit to Compare Alternatives 137

8.6. Comparison of Approaches, Pros and Cons 137

8.7. Cumulative Risk Criteria versus Scenario Criteria 139


8.9. Cautions 148


vii

9Implementing LOPA

9.1. Purpose 151

9.2. Is the Company Ready for LOPA? 151

9.3. What Is the Current Foundation for Risk Assessment? 152

9.4. What Data Are Required? 153

9.5. Will the IPLs Remain in Place? 155

9.6. How Are the Risk Tolerance Criteria Established? 156

9.7. When Is LOPA Used? 158

9.8. Typical Implementation Tasks 158

10Using LOPA for Other Applications

10.1. Purpose 163

10.2. Using LOPA in Capital Improvement Planning 164

10.3. Using LOPA in Management of Change 165

10.4. Using LOPA in Mechanical Integrity Programs or Risk-BasedInspection/Risk-Based Maintenance Programs 166

10.5. Using LOPA in Risk-Based Operator Training 166

10.6. Using LOPA in Emergency Response Planning 167

10.7. Using LOPA to Determine a Credible Design Basisfor Overpressure Protection 167

10.8. Using LOPA in Evaluating Facility Siting Risks 169

10.9. Using LOPA to Evaluate the Need for EmergencyIsolation Valves 170

10.10. Using LOPA to Evaluate Taking a Safety System Out of Service 171

10.11. Using LOPA during Incident Investigations 172

10.12. Using LOPA in the Determination of SIL for SIF 172

11Advanced LOPA Topics

11.1. Purpose 173

11.2. Counting Multiple Functions in One BPCS as IPLs in theSame Scenario 173

viii Contents

11.3. Summation of Risk for Multiple Scenarios 184

11.4. Using LOPA to Develop F/N Curves 186

11.5. Operator Response Issues 188

11.6. Normal Plant Operations as “Tests” of IPL Components 189

11.7. Focused Fault Tree/Event Tree Analysis of IPL Components 189

APPENDIX A: LOPA Summary Sheets for the Continuing

Examples 191

APPENDIX B: Worked Examples from CCPS’s

Safe Automation Book 211

APPENDIX C: Documentation for a LOPA Study 231

APPENDIX D: Linkage with Other Publications 237

APPENDIX E: Industry Risk Tolerance Criteria Data 243

APPENDIX F: High Initiating Event Frequency Scenarios 247

APPENDIX G: Additional Reading 251

References 255

Glossary of Terms 259

Index 265

Contents ix

1

Introduction

Layer of protection analysis (LOPA) is a semiquantitative tool for analyzingand assessing risk. This book

• describes the LOPA process,• discusses the strengths and limitations of LOPA,• describes the requirements for implementing LOPA in an organiza-

tion, and• provides worked examples that show how several different companies

have applied LOPA.

This chapter

• identifies the audience for this book,• provides the history of LOPA,• shows the use of LOPA in the process life cycle,• discusses the linkage to other publications, and• provides an annotated outline for the book.

1.1. Audience

This book is intended for:

• Executives who are considering expanding their corporate strategy formanaging risk by adding LOPA to their existing risk analysis process.For the executive audience, the following chapters are recommended.Chapter 2 summarizes the LOPA method and its benefits. Chapter 9discusses the questions that an organization must answer when decid-ing whether to use LOPA and the required steps to implement the pro-

1

cess effectively. Chapter 10 describes other processes (such asmanagement of change, identification of safety critical equipment, etc.)which can be enhanced by LOPA. The appendices contain summaryforms and worked examples that demonstrate the LOPA product.

• Safety specialists who are familiar with existing methods (such asHAZOP, fault tree analysis, event tree analysis, etc.) or who mayalready have some experience with LOPA (analysts, participants,reviewers, auditors, etc.). For this audience, Chapters 3, 4, 5, 6, 7, 8 dis-cuss the steps of the LOPA process in detail, with several continuingexamples used to demonstrate the method. The appendices containadditional worked examples and other supporting documentation.

• Process and process control engineers, chemists, operations and main-tenance personnel, and others who may participate in LOPA reviewsor who may be affected by LOPA recommendations. This includesthose who implement the recommendations and those who receive theoutcomes from LOPA. Chapters 1, 2, and 6 may be helpful for thisaudience.

• Persons around the world who are responsible for compliance withprocess safety regulations—including the US Process Safety Manage-ment rule (OSHA, 1992), Seveso II Regulations in EU member coun-tries—and related standards—including ISA S84.01 (ISA, 1996), IEC61508 (IEC, 1998) and IEC 61511 (IEC, 2001).

1.2. History of LOPA

In a typical chemical process, various protection layers are in place to lowerthe frequency of undesired consequences: the process design (includinginherently safer concepts); the basic process control system; safety instru-mented systems; passive devices (such as dikes and blast walls); activedevices (such as relief valves); human intervention; etc. There has been muchdiscussion among project teams, hazard analysts, and management about thenumber of and strength of protection layers (see text box below). Decisionswere sometimes made using subjective arguments, emotional appeals, andoccasionally simply by the loudness or persistence of an individual.

LOPA has its origins in the desire to answer these key questions using arational, objective, risk-based approach. In LOPA, the individual protection

2 1. Introduction

KEY QUESTIONS FOR PROTECTION LAYERS

• How safe is safe enough?

• How many protection layers are needed?

• How much risk reduction should each layer provide?

layers proposed or provided are analyzed for their effectiveness. The com-bined effects of the protection layers are then compared against risk tolerancecriteria. Characteristics of the answers provided by LOPA are listed in thetext box above.

The genesis of this method was suggested in two publications:

1. In the late 1980s, the then Chemical Manufacturers Association pub-lished the Responsible Care® Process Safety Code of Management Practiceswhich included “sufficient layers of protection” as one of the recom-mended components of an effective process safety managementsystem (American Chemistry Council, 2000). The Chemical Manufac-turers Association is now the American Chemistry Council.

2. In 1993, CCPS published its Guidelines for Safe Automation of ChemicalProcesses (CCPS, 1993b). Although it was called the risk-based SISintegrity level method, LOPA was suggested as one method to deter-mine the integrity level for safety instrumented functions (SIFs). (SeeTable 7.4 in Safe Automation; CCPS, 1993b.) “Interlock” is an older,imprecise term for SIF. The method used was not as fully developed asthe LOPA technique described in this book. However, it did indicate apath forward, which was pursued by several companies independ-ently. The reasons for this effort included the desire to

• classify SIF to determine the appropriate safety integrity level (SIL)(this was the starting point for some companies),

• develop a screening tool to reduce the number of scenarios requir-ing a full (chemical process) quantitative risk assessment (CPQRA),

• develop a tool that would identify “safety critical” equipment andsystems to focus limited resources,

• develop a semiquantitative tool to make consistent risk based judg-ments within an organization,

• harmonize terminology and methodology with recently developedand developing international process sector standards, and

• facilitate communication (e.g., SIS, SIF, SIL, IPL) between the hazardand risk analysis community and the process control community(e.g., integrators, manufacturers, instrument and electrical engi-neers, plant personnel).

1.2. History of LOPA 3

LOPA answers the key questions about the number and strength of

protection layers by

• providing rational, semiquantitative, risk-based answers,

• reducing emotionalism,

• providing clarity and consistency,

• documenting the basis of the decision,

• facilitating understanding among plant personnel.

The initial development of LOPA was done internally within individualcompanies, in some cases focusing on existing processes, e.g., converting acontrol system to DCS. However, once a method had been developed andrefined, several companies published papers describing the driving forcesbehind their efforts to develop the method, their experience with LOPA, andexamples of its use (Dowell, 1997; 1998; 1999a; 1999b; Bridges and Williams,1997; Fuller and Marszal, 1999; Lorenzo and Bridges, 1997; Ewbank and York,1997; Huff and Montgomery, 1997). In particular, the papers and discussionamong the attendees at the CCPS International Conference and Workshop on RiskAnalysis in Process Safety in Atlanta in October 1997 brought agreement that abook describing the LOPA method should be developed.

In parallel with these efforts, discussions took place on the requirementsfor the design of safety instrumented functions (SIF) to provide the requiredPFDs (probability of failure on demand). United States (ISA S84.01, (ISA,1996)) and international standards (IEC 61508, (IEC, 1998) and IEC 61511,(IEC, 2001)) described the architecture and design features of SIFs. Informa-tive sections of the ISA and IEC standards suggested methods to determinethe required SIL (safety integrity level), but LOPA was not mentioned untilthe draft of IEC 61511, Part 3 appeared in late 1999. These issues were summa-rized in the CCPS workshop on the application of ISA S84.01 (CCPS, 2000c).

In response to all this activity, CCPS assembled in 1998 a team from A. D.Little, ARCO Chemical, Dow Chemical, DuPont, Factory Mutual, ABS Con-sulting (includes former JBF Associates), International Specialty Products,Proctor and Gamble (P&G), Rhodia, Rohm and Haas, Shell (Equilon), andUnion Carbide to tabulate and present industry practice for LOPA in this book.

This book extends the method outlined in Safe Automation of Chemical Pro-cesses (CCPS, 1993b) by

• developing concepts and definitions for use throughout industry,• showing how numerical risk tolerance criteria have been developed by

different companies,• defining the requirements for a safeguard to be considered an inde-

pendent protection layer (IPL),• demonstrating how LOPA can be used for purposes other than the

classification of SIF systems, and• recommending documentation procedures to ensure consistency of

application within an organization.

While the LOPA methods used by various companies differ, they sharethe following common features:

• a consequence classification method that can be applied throughoutthe organization;

• numerical risk tolerance criteria. Individual companies use differentcriteria which include:

4 1. Introduction

� frequency of fatalities,� frequency of fires,� required number of independent protection layers (IPLs), and� maximum frequency for specified categories of consequence based

on release size and characteristics or lost production;• a method for developing scenarios;• specific rules for considering safeguards as IPLs;• specified default data for initiating event frequencies and values for

IPLs;• a specified procedure for performing the required calculations; and• a specified procedure for determining whether the risk associated with

a scenario meets the risk tolerance criteria for an organization and, if itdoes not, how this is resolved and documented.

1.3. Use of LOPA in the Process Life Cycle

LOPA can be effectively used at any point in the life cycle of a process or afacility (see Figure 1.1), but it is most frequently used during:

• the design stage when the process flow diagram and the P&IDs areessentially complete. LOPA is used to examine scenarios, often gener-ated by other process hazard analysis (PHA) tools, such as HAZOP,what-if, checklist, etc.; as part of the SIF design; or as part of a designstudy on a system to classify the various process alternatives and toselect the best method;

• modifications to an existing process or its control or safety systems (i.e.,management of change).

1.3. Use of LOPA in the Process Life Cycle 5

FIGURE 1.1. The process life cycle showing where LOPA is typically used (after Inher-ently Safer Chemical Processes: A Life Cycle Approach, CCPS 1996b)

However, LOPA can also be used in all phases of the process life cycle:

• LOPA can be used during the initial conceptual process design toexamine basic design alternatives and provide guidance to select adesign that has lower initiating event frequencies, or a lower conse-quence, or for which the number and type of IPLs are “better” thanalternatives. Ideally, LOPA could be used to design a process that is“inherently safer” by providing an objective method to compare alter-native designs quickly and quantifiably.

• LOPA can be used during the regular cycle of process hazard analyses(PHAs) performed on a process. Experience with LOPA at several com-panies has shown that its scenario-focused methodology can revealadditional safety issues in fully mature processes that have previouslyundergone numerous PHAs. In addition, its objective risk criteria haveproven effective in resolving disagreements on PHA findings.

• LOPA can readily determine if the risk is tolerable for a process. If anSIF is required, LOPA can determine the required SIL. LOPA canexamine alternatives to a SIF (modifying the process, adding otherIPLs, etc.). Note that IEC 61508 (IEC, 1998) and IEC 61511 (IEC, 2001)define a safety system life cycle that covers all the activities associatedwith safety instrumented functions. LOPA can be a valuable tool inthat safety system life cycle.

• LOPA can be used to identify equipment that, as part of an IPL, isrelied upon to maintain the process within the tolerable risk criteriaof an organization. Such equipment may be denoted as “safety criti-cal” (ISA S91.01, 1995) and is subjected to specified testing, inspectionand maintenance. At least one company has found that LOPA hassignificantly decreased the number of safety critical equipment items.(The amount of safety critical equipment had erroneously grownover time by adding equipment on a qualitative “better safe thansorry” basis.)

• LOPA can be used to identify operator actions and responses that arecritical to the safety of the process. This will allow focused training andtesting to be performed during the life of the process and for the oper-ating manuals to reflect the importance of a limited number of processvariables, alarms and actions.

LOPA can also be used for other risk assessment studies within an orga-nization, including transportation studies (road, rail, pipeline), terminaloperations, toll conversion operations, auditing of third parties, loss preven-tion and insurance issues, etc.

In some companies LOPA is now used for a wide variety of purposesbeyond the initial use for which it was developed (see Chapter 10).

6 1. Introduction

1.4. Linkage to Other CCPS Publications

CCPS has published many books dealing with process safety issues in thechemical industry. LOPA depends on techniques described in the followingCCPS books. Connections with other publications are cited in Appendix D.

A key input to LOPA is scenarios obtained from hazard identification.Guidelines for Hazard Evaluation Procedures, Second Edition with Worked Exam-ples (CCPS, 1992a) describes methods used to identify and assess the signifi-cance of hazardous situations found in process operations or activitiesinvolving hazardous chemicals. Generally, LOPA uses scenarios developedby hazard identification methods—usually qualitative (HAZOP, what-if,etc). However, companies have found that LOPA will often uncover scenar-ios overlooked by other methods because of the rigor in applying the conceptof IPLs to the scenario. LOPA should be considered an extension to the Guide-lines for Hazard Evaluation book as it provides a consistent, objective,semiquantitative method for addressing the issues covered.

LOPA is a semiquantitative approach. It can be viewed as a simplificationof the quantitative risk analysis methods described in Guidelines for ChemicalProcess Quantitative Risk Analysis (CCPS, 1989a) and the Second Edition (CCPS,2000a). CCPS (2000a) builds upon the information contained in CCPS (1989a)to demonstrate how to make quantitative risk estimates for the hazards iden-tified by the techniques described in the Guidelines for Hazard Evaluation book.LOPA adds simplifying assumptions concerning the numerical values for thecomponents of the scenario (initiating event frequency, enabling event/con-dition, number of IPLs, numerical value for an IPL) and in the calculationtechniques employed. The simplifications are intended to be conservative sothat, if a study were to be performed using a full quantitative analysis (eventtree, fault tree, etc.), the results would show less risk associated with the sce-nario when compared to the results of an LOPA analysis. In order to ensurethis, an analyst must understand the issues involved in performing a fullquantitative risk analysis and what issues are important. Chapter 11describes situations where a focused quantitative study can be performed onone component of a LOPA scenario to provide useful additional confidencein the numerical values used.

Evaluating Process Safety in the Chemical Industry: A User’s Guide to Quanti-tative Risk Analysis CCPS (2000b) is a brief and relatively inexpensive intro-duction to the concepts of CPQRA. These concepts also apply for usingLOPA.

The LOPA book is a direct extension to concepts briefly described in Guide-lines for Safe Automation of Chemical Processes (CCPS, 1993b). The LOPA bookshows how to determine the required safety integrity level (in terms of the

1.4. Linkage to Other CCPS Publications 7

probability of failure on demand or PFD) of safety instrumented functions(SIF) that may be implemented in a safety instrumented system (SIS).

LOPA is an alternative method to the techniques described in Tools forMaking Acute Risk Decisions with Chemical Process Safety Applications (CCPS,1995c). CCPS (1995c) discusses methods used for decision making whererisks have been assessed. In addition to chemical process risk, other factors,including financial cost, corporate image, employment of workers, etc., maybe involved in a decision. The Making Acute Risk Decisions book (CCPS, 1995c)provides a collection of decision aids to assist a company in making a deci-sion. LOPA should be considered an alternate method for making such deci-sions as it employs objective, quantified risk tolerance criteria. Some of themore qualitative factors (company image, morale, etc.) cannot be directlyincluded, but that is the case for all other objective methodologies. SomeLOPA risk tolerance criteria include a range where a cost–benefit study—oranother type of judgment—is required to assist in making the decision onwhether a risk should be tolerated or mitigated. Analysts using LOPA shouldbe familiar with the techniques in the Making Acute Risk Decisions book(CCPS, 1995c).

More detailed links to other CCPS books and other publications areshown in Appendices D and E.

1.5. Annotated Outline of the LOPA book

Chapter 1 (this chapter) is an Introduction to the book.

Chapter 2 (Overview of LOPA) provides an outline of the LOPA process, dis-cusses concepts and definitions unique to LOPA, and introduces the continu-ing examples used throughout the book.

Chapter 3 (Estimating Consequences and Severity) describes the concept ofconsequence, and its definition, in the LOPA process and provides examplesof consequence categories used by some companies.

Chapter 4 (Developing Scenarios) discusses the concept of a scenario as usedin LOPA, including the components that comprise a scenario. A format forpresenting the results of LOPA studies is presented.

Chapter 5 (Identifying Initiating Event Frequency) discusses various initiat-ing and enabling events and summarizes typical frequency data. The impor-tance of using consistent initiating event frequencies for LOPA studies withinan organization is emphasized.

Chapter 6 (Identifying Independent Protection Layers) discusses independ-ent protection layers (IPLs). The requirements for a device, system, or action tobe considered an IPL are defined and the concept of the probability of failure

8 1. Introduction

on demand (PFD) for an IPL is presented and discussed. Examples of active,passive and human IPLs are given together with typical ranges of PFD.

Chapter 7 (Determining the Frequency of Scenarios) presents the calcula-tions for the continuing example problems using several methods. Theseshow how different organizations would combine the individual compo-nents of a scenario to calculate the frequency of the consequence type specificto their method.

Chapter 8 (Using LOPA to Make Risk Decisions) discusses how the resultsof calculations are used to make decisions on whether the frequency of theconsequence for a given scenario meets the risk tolerance criteria for a partic-ular organization. Methods from various companies are used to demonstratethe concepts.

Chapter 9 (Implementing LOPA) discusses the implementation of LOPAwithin an organization. Reference materials, standards, and procedures,together with personnel expertise and training issues, are discussed.

Chapter 10 (Using LOPA for Other Applications) discusses other uses, apartfrom risk assessment, for which LOPA may be considered.

Chapter 11 (Advanced LOPA Techniques) discusses advanced LOPA topics.Situations where some of the inherently conservative assumptions made inLOPA may be modified are reviewed. The use of LOPA for other risk assess-ment applications is discussed.

Appendix A (LOPA Summary Sheets for the Continuing Examples) con-tains the complete LOPA sheets for all of the scenarios in the continuingexamples using all of the methodologies discussed in the book.

Appendix B (Worked Examples from CCPS’s Safe Automation Book) pro-vides an analysis of the problem discussed in Chapter 7 of CCPS (1993b).Important issues regarding the application of the rules for an IPL are dis-cussed.

Appendix C (Documentation for a LOPA Study) summarizes the minimumdocumentation requirements for a LOPA study and discusses why suchinformation is required, the appropriate level of detail, and other uses of thedocumentation.

Appendix D (Linkage with Other Publications) discusses other publications.Included are the use of LOPA to address regulatory or other process safetyissues, and how other publications can assist in the implementation of LOPA.

Appendix E (Industry Risk Tolerance Criteria Data) lists typical data relatedto risk tolerance criteria.

1.5. Annotated Outline of the LOPA book 9

Appendix F (High Initiating Event Frequency Scenarios) describes LOPAcalculations when the initiating event frequency is high compared to the testfrequency of the independent protection layer.

Appendix G (Additional Reading) is a list of other books and articles thatmay be of interest to the reader.

10 1. Introduction

2

Overview of LOPA

2.1. Purpose

The purpose of this chapter is to introduce layer of protection analysis(LOPA) by describing what LOPA is, what it does, when it is used, how itworks, and how it is implemented. The limitations and benefits of LOPA arealso discussed. This chapter also introduces two example problems usedthroughout the book to illustrate each step in the LOPA process.

2.2. What Is LOPA?

LOPA is a simplified form of risk assessment. LOPA typically uses order ofmagnitude categories for initiating event frequency, consequence severity,and the likelihood of failure of independent protection layers (IPLs) toapproximate the risk of a scenario. LOPA is an analysis tool that typicallybuilds on the information developed during a qualitative hazard evaluation,such as a process hazard analysis (PHA). LOPA is implemented using a set ofrules.

Like many other hazard analysis methods, the primary purpose of LOPAis to determine if there are sufficient layers of protection against an accidentscenario (can the risk be tolerated?). As illustrated in Figure 2.1, many typesof protective layers are possible. A scenario may require one or many protec-tion layers depending on the process complexity and potential severity of aconsequence. Note that for a given scenario, only one layer must work suc-cessfully for the consequence to be prevented. However, since no layer is per-fectly effective, sufficient protection layers must be provided to render therisk of the accident tolerable.

11

LOPA provides a consistent basis for judging whether there are sufficientIPLs to control the risk of an accident for a given scenario. If the estimated riskof a scenario is not acceptable, additional IPLs may be added. Alternativesencompassing inherently safer design can be evaluated as well. LOPA doesnot suggest which IPLs to add or which design to choose, but it assists injudging between alternatives for risk mitigation. LOPA is not a fully quanti-tative risk assessment approach, but is rather a simplified method for assess-ing the value of protection layers for a well-defined accident scenario.

2.3. What LOPA Does

LOPA provides a risk analyst with a method to reproducibly evaluate the riskof selected accident scenarios. A scenario is typically identified during a qual-itative hazard evaluation (HE), such as a PHA, management of change evalu-ation, or design review. LOPA is applied after an unacceptable consequence,and a credible cause for it, is selected. It then provides an order of magnitudeapproximation of the risk of a scenario.

Once a cause–consequence pair is selected for analysis, the analyst canuse LOPA to determine which engineering and administrative controls (oftencalled safeguards) meet the definition of IPLs, and then estimate the as-is risk

12 2 . Overview of LOPA

FIGURE 2.1. Layers of defense against a possible accident.

LOPA is limited to evaluating a single cause–consequence pair as a scenario.

of the scenario. The results can then be extended to make risk judgments andto help the analyst decide how much additional risk reduction may berequired to reach a tolerable risk level. Other scenarios or other issues may berevealed while performing LOPA on a scenario.

Another way to understand LOPA is to view it relative to quantitativerisk assessment (CPQRA). In this context, a LOPA scenario represents onepath (typically we choose the path to the worst consequence) through anevent tree. Figure 2.2 shows an event tree for a given initiating event. Anevent tree shows all the possible outcomes (consequences) of an initiatingevent. A comprehensive treatment of the use of event trees and other quanti-tative risk assessment methods is provided by the CCPS CPQRA booksGuidelines for Chemical Process Quantitative Risk Analysis and Guidelines forChemical Process Quantitative Risk Analysis, Second Edition (CCPS, 1989a,2000a) and Guidelines for Hazard Evaluation Procedures, Second Edition withWorked Examples (CCPS, 1992a). For LOPA, the analyst (or team) must limiteach analysis to a single consequence, paired to a single cause (initiatingevent). In many applications of LOPA, the goal of the analyst is to identify allcause–consequence pairs that can exceed the organization’s tolerance for risk.

2.3. What LOPA Does 13

FIGURE 2.2. Comparison of LOPA and event tree analysis.

In others, the analyst chooses the cause–consequence pair that likely repre-sents the highest risk scenario from many scenarios that may be similar to theone chosen. The approach taken depends upon the analyst’s experience withLOPA and with the process under consideration - this is not always straight-forward.

In practice, the analyst who will apply LOPA will not have the benefit ofpicking a scenario from a fully developed event tree. Instead, LOPA typicallybegins with scenarios identified by a qualitative hazard review team. Asmentioned earlier, LOPA is a method that falls between qualitative and quan-titative methods and is applied when the analyst decides it is the best tool forjudging risk. The goal is to choose scenarios that the analyst believes repre-sent the most significant risk scenarios, as described in the next section.

2.4. When to Use LOPA

LOPA is typically applied after a qualitative hazard evaluation (e.g., PHA)using the scenarios identified by the qualitative hazard review team. How-ever, “typically” means just that—LOPA can also be used to analyze scenar-ios that originate from any source, including design option analysis andincident investigations. LOPA can also be applied when a hazard evaluationteam (or other entity)

• believes a scenario is too complex for the team to make a reasonablerisk judgment using purely qualitative judgment, or

• the consequences are too severe to rely solely on qualitative risk judg-ment.

The hazard evaluation team may judge the “scenario as too complex” ifthey

• do not understand the initiating event well enough,• do not understand the sequence of events well enough, or• do not understand whether safeguards are truly IPLs.

LOPA can also be used as a screening tool prior to a more rigorous quan-titative risk assessment (CPQRA) method. When used as a screening tool,each scenario above a specified consequence or risk level will first go throughLOPA analysis, and then certain scenarios will be targeted for a higher levelof risk assessment. The decision to proceed to CPQRA is typically based onthe risk level determined by LOPA or based on the opinion of the LOPA ana-lyst (i.e., the scenario is too critical or complex to rely on LOPA for risk assess-ment).

Figure 2.3 depicts the spectrum of risk assessment tools: from purelyqualitative to rigorous application of quantitative methods. At the far left arequalitative tools; these are typically used to identify scenarios and qualita-


tively judge if the risk is tolerable. In the middle are semi-quantitative tools(or simplified quantitative tools); these include LOPA and are used to pro-vide an order-of-magnitude estimate of risk. Finally at the far right are quan-titative tools; these allow analysis of more complex scenarios and providerisk estimates for comparison and risk judgment. The percentages shown inFigure 2.3 are for illustration purposes only. Typically all scenarios are identi-fied and evaluated qualitatively, and some that are too onerous or complexproceed to semiquantitative risk assessment, and a few scenarios may needmore rigorous evaulation than is than possible with LOPA. Thus, LOPA canbe applied to evaluate scenarios that are too complex or consequential foronly qualitative review and LOPA can screen which scenarios need morequantitative scrutiny (which need to go beyond LOPA to CPQRA).

Later chapters provide examples of how companies have incorporatedLOPA into their risk assessment approaches. In general, the writers believethat if the analyst or team can make a reasonable risk decision using onlyqualitative methods, then LOPA may be overkill. However, LOPA can bemuch more efficient than qualitative methods for judging the sufficiency ofIPLs; in a qualitative hazard review these decisions can quickly digress intoshouting matches. LOPA should not be used as a replacement for quantita-

2.4. When to Use LOPA 15

FIGURE 2.3. Spectrum of tools for risk-based decision making.

tive analysis. If complex human behavior models or equipment failuremodels are required to understand the risk of a scenario, then quantitativeanalysis is more appropriate.

2.5. How LOPA Works

Like all analytical methods, LOPA has rules that are provided in this book.Like other methods, LOPA can be divided into steps. The LOPA steps are out-lined in Figure 2.4 and summarized below. Figure 2.4 also identifies the rele-vant chapter for each step. The steps below refer to Figures 2.5 through 2.11and show how the results are selected from the figures. These figures are dis-cussed in detail in later chapters.

Step 1: Identify the consequence to screen the scenarios. Since LOPA typi-cally evaluates scenarios that have been developed in a prior study, a firststep by the LOPA analyst(s) is to screen these scenarios, and the most


FIGURE 2.4. How LOPA works.

common screening method is based on consequence. The consequence is typ-ically identified during a qualitative hazard review (such as a HAZOP study)(see Figure 2.5). Next the analyst evaluates the consequence (including theimpact) and estimates its magnitude. Some companies stop at the magnitudeof a release (of material or energy), which implies, but does not explicitlystate, the impact to people, the environment, and the production system (seeFigure 2.6). Other companies will model the release (see Figure 2.7) and moreexplicitly estimate the risk to people, the environment, and production byaccounting for the likelihood of harm resulting from a specific scenario, forinstance by also accounting for the probability of operators being in harm’sway during a release scenario. Chapter 3 describes the methods used for con-sequence estimation within LOPA.

Step 2: Select an accident scenario. LOPA is applied to one scenario at a time.The scenario can come from other analyses (such as qualitative analyses), butthe scenario describes a single cause–consequence pair (see Figure 2.5). Chap-ter 4 provides rules and examples for identifying scenarios.

Step 3: Identify the initiating event of the scenario and determine the initi-ating event frequency (events per year). The initiating event must lead to theconsequence (given failure of all of the safeguards). The frequency mustaccount for background aspects of the scenario, such as the frequency of themode of operation for which the scenario is valid. Most companies provideguidance on estimating the frequency to achieve consistency in LOPA results(see Figure 2.8). Chapter 5 provides guidance on selecting an appropriate ini-tiating event and in determining a reasonable frequency in the context of theaccident scenario being analyzed.

Step 4: Identify the IPLs and estimate the probability of failure on demandof each IPL. Recall that LOPA is short for “layer of protection analysis.” Someaccident scenarios will require only one IPL, while other accident scenariosmay require many IPLs, or IPLs of very low probability of failure on demand,to achieve a tolerable risk for the scenario. Recognizing the existing safe-guards that meet the requirements of IPLs for a given scenario is the heart ofLOPA. Most companies provide a predetermined set of IPL values for use bythe analyst, so the analyst may pick the values that best fits the scenario beinganalyzed (see Figure 2.9). Chapter 6 provides the rules (requirements) thatare applied to select existing IPLs and also describes how various companiesestimate the effectiveness of existing and proposed IPLs.

Step 5: Estimate the risk of the scenario by mathematically combining theconsequence, initiating event, and IPL data. Other factors may be includedduring the calculation, depending on the definition of consequence (impact

2.5. How LOPA Works 17


FIGURE 2.5. Choosing the scenario.

19

FIGURE 2.6. Determining the consequence and its severity.


FIGURE 2.7. Mathematical modeling of consequence.

FIGURE 2.8. Choosing initiating event frequency.

From

Click for high resolution graphic

21

FIGURE 2.9. Choosing IPL values.

From

event). Approaches include arithmetic formulae and graphical methods.Regardless of the methods, most companies provide a standard form for doc-umenting the results (see Figure 2.10). Chapter 7 describes how to use LOPAdata to estimate risk, using the initiating event frequency (discussed in Chap-ter 5), the IPL values (discussed in Chapter 6), and the consequence value(discussed in Chapter 3). Chapter 7 also discusses how to include the proba-bility of reaching the impact event, given the stated consequence (such as arelease of a hazardous substance) occurs; and how to estimate the frequencyof the scenario (by factoring the probability of the presence of people in thevicinity, probability of escape, probability of ignition, etc.).


FIGURE 2.10. LOPA documentation.

From

23

FIGURE 2.11. Estimating the risk and required action.

Step 6: Evaluate the risk to reach a decision concerning the scenario. Chap-ter 8 describes how to make risk decisions with LOPA. This includes compar-ing the risk of a scenario to a company’s tolerable risk criteria and/or relatedtargets (see Figure 2.11).

Chapter 10 describes other uses of LOPA results. Chapters 8 and 10 alsodescribe how the results can be used to prioritize risk management activities,such as identifying which equipment components to focus on within amechanical integrity program.

2.6. How to Implement LOPA

LOPA is most effective when an organization adopts a consistent approach toLOPA and sets criteria for when to use LOPA and who is qualified to use it.Chapter 9 provides general guidance for effective implementation of LOPAand includes lessons learned from several international companies. Trainingof personnel in LOPA is a key implementation task. Chapter 11 describesadvanced LOPA topics.

LOPA can be applied in a team setting, such as during or immediatelyfollowing a HAZOP- or What-If–based review (e.g., PHA) used to identifyaccident scenarios. LOPA can also be applied by a single analyst; in this case,the scenarios have typically already been identified for the analyst (such as bya hazard evaluation team). Note that a single analyst rarely works in avacuum and will almost inevitably need to clarify issues with others in theorganization. Many companies practice LOPA with a subteam composed ofthe analyst and a process engineer or production specialist (someone inti-mately familiar with the process); a larger team or an independent LOPA ana-lyst may review their work.

2.7. Limitations of LOPA

LOPA is just another risk analysis tool that must be applied correctly. Thelimitations imposed on LOPA result in a work process that is much less com-plex than quantitative risk analysis, while generating useful, somewhat con-servative, estimates of risk. LOPA is subject to the following limitations:

• Risk comparisons of scenarios are valid only if the same LOPA method(i.e., using the same methods for choosing failure data), and compari-sons are based on the same risk tolerance criteria or to the risk of otherscenarios determined by LOPA. The numbers generated by a LOPAcalculation are not precise values of the risk of a scenario. This is also alimitation of quantitative risk analysis.


• LOPA is a simplified approach and should not be applied to all scenar-ios. The amount of effort required to implement LOPA may be exces-sive for some risk-based decisions and is overly simplistic for otherdecisions.

• LOPA requires more time to reach a risk-based decision than qualita-tive methods such as HAZOP and What-if. This extra time is offset bythe improved risk decision compared to using only qualitative meth-ods for moderately complex scenarios. For simple decisions, the valueof LOPA is minimal. For more complex scenarios and decisions, LOPAmay actually save time compared to using only qualitative methods,because LOPA brings focus to the decision making.

• LOPA is not intended to be a hazard identification tool. LOPA dependson the methods used (including qualitative hazard review methods) toidentify the hazardous events and to identify a starting list of causesand safeguards. The more rigorous procedure of LOPA frequentlyclarifies ill-defined scenarios from qualitative hazard reviews.

• Differences in risk tolerance criteria and in LOPA implementationbetween organizations means the results cannot normally be com-pared directly from one organization to another. This is true of CPQRAtechniques as well.

2.7. Limitations of LOPA 25

MYTH: Since LOPA uses numbers, the results express the precise risk of the

scenario.REALITY: This is NOT true. Like other techniques, LOPA gives approximations of

risk that are useful in making comparisons (which help to allocate limited

resources for risk control). For many purposes, LOPA analyses have sufficient

precision to adequately quantify the risk of a particular process scenario.

MYTH: Since LOPA provides quantitative results, LOPA is better than HAZOP.

REALITY: The two are different techniques with different goals and cannot be

compared directly.

• HAZOP is ideally suited for brainstorming or uncovering what could go wrong

and at identifying potential accident scenarios; a HAZOP team can also qualita-

tively judge the risk of a scenario.

• LOPA allows the analyst to take a predefined scenario and estimate the risk of

the scenario in a consistent and simplified manner.

LOPA complements HAZOP or other hazard identification methodologies.

2.8. Benefits of LOPA

LOPA has many benefits that justify investment by company managementand risk analysts. As with most new tools, however, the benefits often cannot

be fully appreciated until LOPA is applied to everyday problems. Some gen-eral benefits of LOPA include:

• LOPA requires less time than quantitative risk analysis. This benefitapplies particularly to scenarios that are too complex for qualitativeassessment of risk.

• LOPA helps resolve conflicts in decision making by providing a consis-tent, simplified framework for estimating the risk of a scenario andprovides a common language for discussing risk. LOPA provides abetter risk decision basis compared to subjective or emotional argu-ments based on “the risk is tolerable to me.” This is particularly benefi-cial for organizations making the transition from qualitative to morequantitative risk methods.

• LOPA can improve the efficiency of hazard evaluation meetings byproviding a tool to help reach risk judgments quicker.

• LOPA facilitates the determination of more precise cause–consequencepairs, and therefore improves scenario identification.

• LOPA provides a means of comparing risk from unit to unit or plant toplant, if the same approach is used throughout the company.

• LOPA provides more defensible comparative risk judgments than quali-tative methods due to the more rigorous documentation and the specificvalues assigned to frequency and consequence aspects of the scenario.

• LOPA can be used to help an organization decide if the risk is “as lowas reasonably practicable” (ALARP), which may also serve to meetspecific regulatory requirements.

• LOPA helps identify operations and practices that were previouslythought to have sufficient safeguards, but on more detailed analysis(facilitated by LOPA), the safeguards do not mitigate the risk to a toler-able level.

• LOPA helps provide the basis for a clear, functional specification for anIPL [ISA S84.01 (ISA, 1996) and IEC 61508 and IEC 61511 (IEC, 1998;2001)].

• Information from LOPA helps an organization decide which safe-guards to focus on during operation, maintenance, and related train-ing. For instance, many companies decide to focus their inspection,test, and preventive maintenance activities on the IPLs identifiedduring LOPA; these companies often decide to run the remaining safe-guards (those not identified as IPLs) to failure or subject them to lessrigorous test and maintenance schedules. Therefore, LOPA is a tool for


implementing a wise PSM mechanical integrity or risk-based mainte-nance system, and it aids in the identification of “safety critical” fea-tures and tasks.

2.9. Introduction of Continuing Examples

The following two examples will be used to illustrate the concepts of LOPAthroughout this book. Note that LOPA methods vary throughout the indus-try. Each example shows only one of the many approaches. Variations will beshown or discussed in the following chapters and appendices. The solution

steps for each example will be shown in each chapter. For each of these exam-ples:

• Chapter 3 discusses how to identify consequences and classify themfor severity.

• Chapter 4 shows how to identify scenarios in LOPA terms.• Chapter 5 shows how to identify the initiating events in a scenario, and

how to calculate the initiating event frequency.• Chapter 6 shows how to identify potential Independent Protection

Layers (IPLs), how to test for independence, and how to estimate theprobability of failure on demand (PFD) for the applicable IPLs.

• Chapter 7 shows how to calculate the frequency of the scenario withthe IPLs in place.

• Chapter 8 describes how to use LOPA to evaluate risk and make deci-sions.

Continuing Example 1: Hexane Surge Tank Overflow

The following process, shown in Figure 2.12, will be used as a continuingexample to illustrate the concepts of LOPA throughout this book.

DesignHexane flows from another process unit (not shown) into a hexane surgetank. The hexane supply pipeline is always under pressure. The surge tanklevel is controlled by a level control loop (LIC-90) that senses the level in thetank and throttles a level valve (LV-90) to control the level. Hexane is used bya downstream process (also not shown). The LIC loop includes a high levelalarm (LAH-90) to alert the operator. The tank normally operates half full; thetotal tank capacity is 80,000 lb of hexane. The tank is located in a dike that cancontain up to 120,000 lb of hexane.

The designs in the examples are for illustrative purposes only. Thedesigns are not necessarily endorsed by the authors. Readers are cautioned touse designs appropriate for their applications.


ScopeThis example provides a limited illustration of LOPA for a process safetydecision based on the use of a safety instrumented function (SIF) as an inde-pendent protection layer (IPL). During the process hazard analysis (PHA),the team discussed the need for a high level SIF to help prevent overfillingaccidents. They decided to use LOPA to help structure this process safetydecision. The PHA team identified other scenarios that would lead to releasesof hexane from the surge tank and related process equipment, but these otherscenarios are not modeled here.

Hazard InformationThe hazard information was prepared as part of the PHA, prior to conductingthe LOPA. This included identification of the hazards, scenarios, consequences,safeguards, and subsequent recommendations. The consequences identified are:overflow of the tank; possible failure of the dike; and subsequent dispersion offlammable hexane vapors, which if ignited, will result in a pool fire.

Continuing Example 2: Hexane Storage Tank Overflow

The following process, shown in Figure 2.13, will be used as a second continu-ing example to illustrate the concepts of LOPA throughout this book.


FIGURE 2.12. Continuing Example 1: Hexane surge tank overflow (as is).

DesignHexane is unloaded from a tank truck (50,000 lb) via pump 3-40 into makeupstorage tank T-301, which has a capacity of 80,000 lb. The surrounding dike isdesigned to contain 120,000 lb of hexane. The truck is unloaded once every 4days or about 90 times per year. The makeup storage tank is equipped with alevel indicator (LI-80) and a high level alarm (LAH-80) that annunciates in thecontrol room. Two operators are typically involved in this operation; one inthe field who initiates the transfer with the delivery truck driver and one inthe control room who monitors and operates various process functions froma computer interface. The driver is required to supervise the transfer.

ScopeThis example provides a limited illustration of LOPA for a process safetydecision on the use of a safety instrumented function (SIF), as an independentprotection layer (IPL). During the process hazard analysis (PHA), the teamdiscussed the need for a high level SIF to trip the feed pump and close an inletvalve (to be installed) to help prevent overfilling accidents. They decided touse LOPA to help structure this process safety decision. The overflow sce-nario of concern is initiated by arrival of a truck when there is insufficient


FIGURE 2.13. Continuing Example 2: Hexane storage tank overflow (as is).

room in tank T-301 for the truck contents. This could be due to a number ofsituations, including an error in ordering, or the unit was shut down after thetruck was ordered. The PHA team identified other scenarios that would leadto releases of hexane from the surge tank and related process equipment, butthese other scenarios are not analyzed here.

Hazard InformationThe hazard information was prepared as part of the qualitative PHA, prior toconducting the LOPA. This included identification of the hazards, scenario,consequences, safeguards, and subsequent recommendations. The conse-quences are overflow of the tank; possible overflow of the dike; and subse-quent dispersion of flammable hexane vapors, which if ignited, will result ina pool fire.


Click here to go to Chapter 3

3

Estimating Consequencesand Severity

3.1. Purpose

One component of the risk of any accident scenario is its consequence. InLOPA, the consequences are estimated to an order of magnitude of severity,which requires much less effort than mathematical modeling, and yet stillfacilitates comparison of risk from different scenarios. This chapter describesthe various types of consequence analysis used in LOPA. The continuingexamples illustrate consequence analysis using the principles outlined in thischapter. This is Step 1 of the LOPA method.

3.2. Consequences of Interest

Consequences are the undesirable outcomes of accident scenarios. One of thefirst decisions an organization must make when choosing to implementLOPA is how to define the consequence endpoint. Some companies stop atloss of containment; others estimate the final impact in terms of harm ordamage. The most common scenario of interest for LOPA in the chemical pro-cess industry is loss of containment of hazardous material or energy. Loss ofcontainment can occur by a variety of mechanisms such as a leak from avessel, rupture of a pipeline, and lifting of a relief valve. The typical sequenceof consequences of a release of flammable/toxic material is shown in Figure3.1 and explained below.

31

The material released may be in a liquid, gas, or solid form, or a combina-tion of these. If the released material is flammable, ignition may result in anexplosion and/or fire. In case of immediate ignition of a pressurized gas ortwo-phase release, jet fires may ensue. In the absence of immediate ignition,material may disperse to form a vapor cloud with delayed ignition as a flashfire or explosion. Liquid spills may burn as pool fires if ignited. If the releasedmaterial is toxic, plant personnel or the public may be exposed to unhealthyconcentrations. The radiation flux from fires, overpressures from explosions,and toxic concentrations from toxic releases are called physical effects. Thephysical effects have “impact” on personnel, environment and property, andmay result in losses such as injuries, fatalities, environmental harm, andproperty damage. In addition to these initial effects, there could be follow-onlosses due to business interruption, loss of quality of product, demolitionrequirements, and loss of credibility with the public, regulators, customers,and stockholders.

The range of consequence endpoints for a loss of containment scenarioinclude the release of the hazardous material, the dispersion of the hazardousmaterial, physical effects from fires, explosions and toxic releases; and thelosses from the impact of physical effects. All of these consequence endpointsare quantifiable by some estimation method. For example, a release can bemeasured in terms of the released quantity; the dispersion in terms of disper-sion distance/area (for specific concentrations); and the losses in terms ofnumber of injuries and fatalities, property damage, financial losses or indirectlosses.

32 3. Estimating Consequences and Severity

FIGURE 3.1. Potential consequences from a flammable/toxic release.

3.3. Consequence Evaluation Approaches for LOPA

Consequence evaluation is an integral part of any risk assessment methodol-ogy. What consequences should be evaluated, and how rigorously theconsequences are evaluated depend on several factors, including the riskassociated with the accident scenarios, and the risk assessment methodologyadopted by the organization, and the resources the organization is willing toexpend to refine the estimate. These implementation issues are discussed ingreater detail in Chapter 9. The different types of consequence evaluation are:

• Release size/characterization• Simplified injury/fatality estimates• Simplified injury/fatality estimates with adjustments• Detailed injury/fatality estimates

Each of these methods has its advantages and disadvantages, which arediscussed in the following sections. The method used for consequence cate-gorization should be consistent with the company’s risk tolerance criteria.

Any organization implementing LOPA should carefully consider thelevel of detail for consequence analysis, as this choice can significantly affectthe level of effort and training required. Figure 3.1 shows a generic releaseevent and possible outcomes. Some companies choose to stop the analysis atidentifying and quantifying the type and size of the release. Their risk toler-ance criteria assume that releases of certain magnitudes have a certain likeli-hood of harming the environment, people, or production/assets. In thesecompanies, the primary risk tolerance criterion is matched to the fact that theconsequence categorization stops at the “release.” Other companies choose toexplicitly account for the likelihood of some impact event (e.g., employeeinjury), and therefore their consequence categories are also more explicit inthe degree of harm done. It should be noted that either approach can (andtypically does) provide comparable risk decisions.

Method 1: Category Approach without Direct Referenceto Human Harm

This method typically uses matrices to differentiate consequences into vari-ous categories. It avoids estimating the number of potential injuries or fatali-ties, thereby:

• avoiding any overt appearance that injuries and fatalities are tolerable,and

• helping the team make more accurate judgments about relative risk,since it is very difficult to estimate qualitatively the number of peoplewho might be harmed and how severe the harm might be. For instance,falling down a flight of stairs could result in a spectrum of conse-


quences, ranging from a slight bruise to a fatality. Or, a toxic releasecan result in one or more fatalities or no harm at all, depending on theproximity of people to the release point and the time and capabilitythey have to escape.

Table 3.1 is an example that includes a simple approach to categorize theconsequences from a chemical release. Each consequence is assigned anumerical category from 1 to 5, with 5 being the most severe. Table 3.1includes three matrices:

• The upper matrix relates release size and the physical and toxicologicalproperties to consequence categories (this avoids the need for quantita-tive calculations of dispersion, etc.).

• The middle matrix relates plant type and type of damage or productionloss to consequence categories.

• The lower matrix relates equivalent cost factors to consequence catego-ries.

Note that the middle and lower matrices are used when

• the scenario does not involve a material release, or• the severity category for the scenario is higher on one of the lower

matrices than it is on the upper matrix, or• the analyst judges the lower matrices better describe the consequence.

[Note that the consequence category for vapor releases can be reduced inseverity if dispersion modeling (quantitative analysis) is performed andshows that a lower impact category is warranted.] Once the release categoryhas been assigned, it is combined with the anticipated or calculated frequency(see Chapters 5, 6, and 7) of the consequence to assess whether the risk is tol-erable (see Chapter 8).

The advantages of this method:

• The method is simple and easy to use because the size and properties ofthe release are relatively easy to assess. No case-by-case modeling isrequired. A release of a certain size is assigned a certain consequencevalue independent of the eventual effect (fire, explosion, toxic release,injury, fatality, etc.). The criteria for loss of production are similarlysimple to assess.

• When combined with a matrix showing the organization’s risk toler-ance criteria, the method allows visual assessment of where a givenrisk lies in relation to the organization’s guidelines.

The disadvantages of this method:

• It requires either the acceptance of the consequence categorizationmatrix or the development of such a matrix by baseline modeling. The


35

TABLE 3.1Example Consequence Categorization

ReleaseCharacteristic

Size of Release (beyond a dike)

1- to 10-poundrelease

10- to 100-poundrelease

100- to1,000-poundrelease

1,000- to10,000-poundrelease

10,000- to100,000-poundrelease

>100,000-poundrelease

Extremelytoxic aboveBP*

Category 3 Category 4 Category 5 Category 5 Category 5 Category 5

Extremelytoxic below BPor highly toxicabove BP


Highly toxicbelow BP orflammableabove BP


Flammablebelow BP


Combustibleliquid


*BP = atmospheric boiling point

ConsequenceCharacteristic

Magnitude of Loss

Spared ornon-

essentialequipment

Plantoutage

<1 month

Plantoutage 1–3

months

Plantoutage

>3 months

Vesselrupture3,000 to

10,000 gal100–300 psi

Vesselrupture>10,000

gal>300 psi

Mechanicaldamage tolarge mainproduct plant


Mechanicaldamage tosmall by-prod-uct plant


ConsequenceCharacteristic

Consequence cost (U.S. dollars)

$0–$10,000$10,000–$100,000

$100,000–$1,000,000

$1,000,000–$10,000,000 >$10,000,000

Overall cost ofevent

Category 1 Category 2 Category 3 Category 4 Category 5

Note: This table of values is for example only, to indicate what one or more companies use to catego-rize consequences. CCPS does not endorse one method over another.

baseline modeling is time consuming and requires a good basic under-standing of modeling techniques and physical processes.

• The endpoints are not presented in terms of specific injury/fatal-ity/cost figures, which can cause interpretation problems in someorganizations.

Method 2: Qualitative Estimates with Human Harm

This method uses the final impact to humans as the consequence of interest,but arrives at the value using purely qualitative judgment. For each scenario,the human consequences are estimated directly by the LOPA analyst, usingpast experience, previously generated look-up tables, or knowledge of priordetailed release modeling of similar releases. Table 3.2 shows the conse-quence categorization resulting from this method.

The resulting risk of an injury/fatality can be compared directly to afatality risk tolerance criterion (see Chapter 8) for an individual event, or all ofthe events associated with a process or plant can be summed and then com-pared to process/plant risk tolerance criteria.

The advantages of this method are:

• Simplicity of understanding: Many people tend to better understand con-sequence in terms of harm rather than expressing risk in terms ofrelease size.

• Direct comparison with corporate guidelines: Many companies alreadyhave established guidelines for risk of a fatality/injury, or for risk of acertain monetary loss.

The disadvantages of this method are:

• Implicit assumptions for the probability of ignition for flammablereleases, for the probability of injury, and the probability that a personis present in the area may over- or underestimate the risk of fatality.

• Look-up tables such as Table 3.2 are even less precise (more subjective)than release categorization tables such as Table 3.1.

• The estimation of the consequence severity may vary between differ-ent analysts, unless some guidance is provided across the company.

Method 3: Qualitative Estimates with Human Harm withAdjustments for Postrelease Probabilities

Alternatively, the LOPA analyst can initially estimate the magnitude of arelease “qualitatively” similar to Method 2 (but not as subjective as a look-uptable similar to Table 3.2), and then later (as described in Chapter 7) adjust theevent frequency by the probability that:



TABLE 3.2

Qualitative Categorization (Combined Loss Categories)

Low Consequence

Personnel Minor or no injury; no lost time

Community No injury, hazard, or annoyance to public

Environment Recordable event with no agency notification or permit violation

Facility Minimal equipment damage at an estimated cost of less than $100,000 andwith no loss of production

Medium Consequence

Personnel Single injury, not severe; possible lost time

Community Odor or noise complaint from the public

Environment Release that results in agency notification or permit violation

Facility Some equipment damage at an estimated cost greater than $100,000 andwith minimal loss of production

High Consequence

Personnel One or more severe injuries

Community One or more minor injuries

Environment Significant release with serious offsite impact

Facility Major damage to process area(s) at an estimated cost greater than$1,000,000 or some loss of production

Very High Consequence

Personnel Fatality or permanently disabling injury

Community One or more severe injuries

Environment Significant release with serious offsite impact and more likely than not tocause immediate or long-term health effects

Facility Major or total destruction of process area(s) at an estimated cost greaterthan $10,000,000 or a significant loss of production

Note: This table of values is for example only, to indicate what one or more companies use to catego-rize consequences. CCPS does not endorse one method over another.

• the event will result in a flammable or toxic cloud;• for a flammable cloud, an ignition source will be present;• an individual will be present in the area when the event occurs;• the individual will experience a fatal (or injurious) consequence.


• Simplicity of understanding: People tend to better understand conse-quence in terms of harm rather than expressing risk in terms of releasesize.

• Direct comparison with corporate guidelines: Many companies alreadyhave established guidelines for risk of a fatality or injury.

• Frequency adjustments: The frequency adjustments may give a betterestimate of the risk of human harm.


• The simplifications made in assessing the probabilities of the eventssubsequent to the release. The results of real-world events have provento be both significantly less and significantly greater than those calcu-lated by analysts. However, if consistent approaches are used, it is rea-sonable to expect that this method will highlight scenarios withrelatively higher risk.

• Extra parameters for the probability of reaching the stated impact oroutcome must be included in the risk calculation (described in Chapter7), and these may change over time (e.g., the number of people or theirlocation changes).

• The estimation of the consequence severity may vary between differ-ent analysts, unless some guidance is provided across the company.

• This method would need to be augmented to address business impactor economic risk.

Method 4: Quantitative Estimates with Human Harm

This method is similar to the qualitative estimates with human harm method(Method 3), but uses detailed analyses in determining the effects of a releaseand its effects upon individuals and equipment. This method involves the useof mathematical models (typically complex computerized models) to simu-late the release itself (also called “source term” modeling), the subsequentdispersion, and the toxic or blast/thermal effect. Figure 3.2 illustrates the typ-ical results from detailed modeling of the release of a highly toxic material.Refer to Guidelines for Consequence Analysis of Chemical Releases (CCPS, 1999)for more details on quantitative modeling.



• A greater degree of certainty concerning the predicted consequences.• Direct comparison with corporate guidelines.


• Although the modeling programs are much more sophisticated thanthe estimation methods, the results of real-world events have beenboth significantly less and significantly greater than those calculatedby analysts. Modeling results are strongly affected by the exact releaseconditions (e.g., is the pipe severed or cracked? is the break near thetank or mid-run? is the release oriented up or down?), atmospheric sta-bility, wind direction, time to ignition, etc. There are thousands of pos-sible permutations to consider. Inevitably only a few “representative”cases can be chosen.

• The level of sophistication required for modeling the consequence of ascenario is disproportionate to that used to estimate the order of mag-nitude frequency of the scenario with LOPA.

• The training, experience and effort required to perform the modelingcan be prohibitive, and such analysis is usually only applied to scenar-ios that have already been judged to have potentially fatal results.


FIGURE 3.2. Typical vulnerability zone from detailed (mathematical) modeling. ERPG 2 isthe maximum airborne concentration below which it is believed that nearly all individu-als could be exposed for up to one hour without experiencing or developing irreversibleor serious health effects or symptoms which could impair an individual’s ability to takeprotective action.

For these reasons, this method is typically used only for compounds thatare new to a company, or for scenarios requiring a higher level of scrutinythan LOPA can provide. Modeling is frequently reserved for scenarios thatrequire CPQRA—the step beyond LOPA.

3.4. Continuing Examples

In this section, consequences are assessed for the scenarios described in thecontinuing examples. We will use two methods in this chapter to categorizethe consequences to illustrate the concepts used for LOPA.

The first (Method 1) will use a category, look-up method, using Table 3.1as the reference table. For this approach, only the boiling point, flammabilitydata, and total quantity of the material are required.

The second (Method 3) will qualitatively estimate the scenario conse-quences using prior experience of the authors. Method 3 is further addressedin Chapter 7, where we include consideration of the probability of ignition,probability of harm, etc.

In writing this book, we also confirmed the consequence severity by adetailed dispersion calculation and flammable effects model (Method 4), butthe results are not shown in the book. This method required

• flammability data for hexane,• past experience with similar incidents in the industry, and• a general understanding of fires and explosions and the models that

describe these phenomena.


Scenario 1a: Hexane Surge Tank Overflow—Spill Not Contained bythe DikeFor this case, we will assume that the total overflow can be as large as 40,000lb of hexane, and that the dike is present as an IPL (addressed in detail inChapter 6). The dike has a probability of failure with the release spreadingbeyond the dike.

METHOD 1

Using this method, the consequence category from Table 3.1 for a release of40,000 lb of a flammable liquid below its boiling point is Category 4.

METHOD 3

For this method up to 40,000 lb of hexane is released which could result in alarge pool fire. In view of the low volatility of hexane, a flammable cloud is


not expected beyond the pool. A flash fire is considered unlikely, based on theflash point of hexane at process temperatures. The fire has the capacity toinjure personnel in the immediate area of the spill, which now includes anarea beyond the dike. This qualitative interim result will be combined inChapter 7 with the probability of ignition, probability of personnel present,and probability of harm done to personnel, given they are present.

Scenario 1b: Hexane Surge Tank Overflow—Spill Contained by theDikeGiven the flow rate into the vessel, the frequency of operator rounds, and themany other upstream limitations and safeguards, the plant engineers esti-mate that the maximum overflow (after completely filling the vessel) is 40,000lb of hexane. Scenario 1b assumes that the dike will work perfectly to containthe spill.

METHOD 1

Using this method, there is no consequence since the release is completelycontained by the dike. Table 3.1 ignores spills of flammable liquid into dikes,if the dikes are assumed not to fail.

METHOD 3

For this method we have up to 40,000 lb of hexane in the dike which couldresult in a contained pool fire. In view of the low volatility of hexane, a flam-mable cloud is not expected beyond the pool. A flash fire is consideredunlikely, based on the flash point of hexane at process temperatures. The firehas the capacity to injure personnel in the immediate area. This qualitativeinterim result will be combined in Chapter 7 with the probability of ignition,probability of personnel present, and probability of harm done to personnel,given they are present.


Scenario 2a: Hexane Storage Tank Overflow—Spill Not Contained bythe DikeFor this case, we will assume that the total overflow can be as large as 40,000lb of hexane, and that the dike is present as an IPL (addressed in detail inChapter 6). The dike has a probability of failure with the release spreadingbeyond the dike.

METHOD 1

Using this method, the consequence category from Table 3.1 for a release of40,000 lb of a flammable liquid below its boiling point is Category 4.


METHOD 3

For this method up to 40,000 lb of hexane are released which could result in alarge pool fire. Again, in view of the low volatility of the hexane, a flammablecloud is not expected beyond the pool. A flash fire is considered unlikely,based on the flash point of hexane at process temperatures. The fire has thecapacity to injure personnel in the immediate area of the spill, which nowincludes an area beyond the dike. This qualitative interim result will be com-bined in Chapter 7 with the probability of ignition, probability of personnelpresent, and probability of harm done to personnel, given they are present.

Scenario 2b: Hexane Storage Tank Overflow—Spill Contained by theDikeFor this case, we will assume that the total overflow can be as large as 40,000lb of hexane, and that the dike will not fail.

METHOD 1

Using this method, there is no consequence since the release is completelycontained by the dike. Table 3.1 ignores spills of flammable liquid into dikes,if the dikes are assumed not to fail.

METHOD 3

For this method up to 40,000 lb of hexane may be present in the dike whichcould result in a contained pool fire. Again, in view of the low volatility of thehexane, a flammable cloud is not expected beyond the pool. A flash fire isconsidered unlikely, based on the flash point of hexane at process tempera-tures. The fire has the capacity to injure personnel in the immediate area. ofthe spill. This qualitative interim result (a release of 40,000 lb of hexane intothe dike) will be combined in Chapter 7 with the probability of ignition, prob-ability of personnel present, and probability of harm done to personnel, giventhey are present.

3.5. Link Forward

Chapter 4 will explain how scenarios are selected and developed for pur-poses of LOPA. As mentioned earlier, categorizing the consequences is oftenthe screening criteria for selecting the scenarios for LOPA. Other criteria canalso be used. Chapters 5 and 6 will complete the data collection and scenariodevelopment efforts for a LOPA scenario.


4

Developing Scenarios

4.1. Purpose

Scenario development is the LOPA step in which the team or analyst con-structs a series of events, including initiating events and the failure of IPLs(independent protection layers), that lead to an undesired consequence. Thepurpose of this chapter is to describe the components of a scenario and giveexamples of how scenarios can be developed from hazard evaluations andother sources. This chapter discusses Step 2 of the LOPA process.

4.2. LOPA Scenarios and Components

A scenario is an unplanned event or sequence of events that results in anundesirable consequence. Each scenario consists of at least two elements (seeFigure 4.1):

• an initiating event (e.g., loss of cooling) that starts the chain of eventsand

• a consequence (the potential for overpressuring the system, release oftoxic or flammable material to the atmosphere, fatality, etc.) that resultsif the chain of events continues without interruption.

Inherently safer concepts attempt to reduce risk by eliminating scenarios,usually by preventing or reducing the consequence of an initiating event. For

43

example, if a process is modified to significantly reduce the inventory of atoxic material that could be released, the consequence, and thus the risk, asso-ciated with a vessel rupture can be significantly reduced. Again, if a vessel isdesigned to resist an internal explosion, or the shut-off head of a pump, or arelief flow is passed to a flare rather than directly to the atmosphere, the riskassociated with scenarios with these consequences may be reduced or elimi-nated. How inherently safer concepts can be incorporated into LOPA is dis-cussed in more detail in Chapter 6.

Each scenario must have a unique initiating event/consequence pair. Ifthe same initiating event can result in different consequences, additional sce-narios should be developed. In some cases many scenarios may spring from acommon initiating event (e.g., loss of a utility to a facility) and separate sce-narios should be developed for individual sections of the plant.

In addition to the initiating event and consequence, a scenario may alsoinclude

• enabling events or conditions that have to occur or be present beforethe initiating event can result in a consequence (see Figures 4.2 and 4.3).

• the failure of safeguards (which may be IPLs), as shown in Figure 4.4.Not all safeguards are IPLs, but all IPLs are safeguards. (See Chapter6.)

Methods that use consequence end-points of fatalities, or harm to busi-ness or the environment, may also include some or all of the following factors,or outcome modifiers, in the scenario:

• the probability of ignition of a flammable material (liquid or vaporrelease),

• the probability of a person being present in the area affected by theevent,

44 4. Developing Scenarios

FIGURE 4.1. Minimum requirements for a scenario

FIGURE 4.2. Coincident initiating and enabling events.

• the probability that a fatal injury will result from exposure to the effectsof the fire, explosion, or toxic release—includes evacuation or protec-tive action, or

• the probability that an estimated financial loss to the facility of a certainmagnitude will result.

Other methods may utilize other factors or probabilities.

Example 4.1

Loss of cooling (the initiating event) can result in a runaway exothermic

reaction in a batch reactor and overpressure, but only during a portion of

the reaction (the enabling condition) when the system is in the reaction

exotherm phase and thus vulnerable to loss of cooling.

In most scenarios there will be at least one safeguard that can be consid-ered an IPL for the purposes of LOPA. If this IPL operates as intended, it willbreak the chain of events and prevent the undesired consequence from occur-ring (see Figure 4.4 and Chapter 6).

4.2. LOPA Scenarios and Components 45

FIGURE 4.3. Coincident initiating event and enabling condition.

FIGURE 4.4. Effect of IPL failing to operate as intended.

Example 4.2

For the batch reactor of Example 4.1, there may be many safeguards in

place against overpressure (alarms, operator interaction, manual venting,

SIFs, relief devices, etc.) that may have been identified by a hazard evalua-

tion team. In this case a review of these safeguards might determine that

only two of these might be considered as meeting the requirements of an

IPL for LOPA.

• a BPCS (basic process control system) function (i.e., interlock) designedto detect high temperature/pressure and take action to prevent the run-away exothermic reaction; and

• a correctly sized and maintained relief valve to prevent the overpressureof the system following an exotherm.

Figure 4.5 shows the scenario for Example 4.2 for loss of cooling leadingto overpressure of the reactor:

1. Loss of cooling (Initiating Event) AND2. Reactor in a condition where exotherm can occur if cooling is lost

(Enabling Condition) AND3. BPCS fails to act correctly (Failure of IPL) AND4. Relief valve fails to act correctly (Failure of IPL) RESULTING IN:5. Overpressure of reactor system (Consequence—flange leakage

and/or potential rupture with large release of energy and/or hazard-ous material and potential for fatalities, injuries, or property or envi-ronmental damage).

As discussed in Chapter 3, the LOPA method used by a particular organi-zation will affect how the consequences of each scenario are developed andcompleted.

The effectiveness of the LOPA method relies heavily on the thoroughnessof the detail presented in the scenario. Each scenario must be adequately doc-umented (see Section 4.3 and Appendix C).


FIGURE 4.5. Scenario path for reactor Example 4.2.

4.3. Identifying and Developing Candidate Scenarios

This section examines methods for identifying and developing scenarios tothe level of detail required for LOPA.

Identifying Candidate Scenarios

The most common source of information for identifying scenarios are hazardevaluations (HE) developed and documented for existing processes and per-formed during the design of new and modified processes. The purpose of anHE is to identify, assess and document the hazards associated with the pro-cess (see Guidelines for Hazard Evaluation Procedures, Second Edition withWorked Examples; CCPS, 1992a). Most HE methods are qualitative and do notenable an analyst or team to quantify whether the risk associated with a docu-mented hazard is acceptable (so their judgment may be inconsistent). The HEmay have already identified the initiating event for a given scenario, butenabling events and safeguards are often neglected, not included appropri-ately, or are not fully understood or documented. Figure 4.6 shows howinformation from a HAZOP type review could be used in developing a sce-nario for LOPA. HAZOP reports usually contain adequate information todescribe the components of a scenario. LOPA can take HAZOP informationand assign numeric values for initiating event frequency, failure frequencyand probability of failure on demand (PFD), and (using the LOPA rules)determine whether a safeguard is an IPL. Thus, in Figure 4.6, the causes iden-tified in the HAZOP are used to specify the initiating event and the LOPAmethod will assign a frequency to this event. Similarly, if the HAZOP identi-fies a safeguard, LOPA will determine whether this is an IPL for the scenario,and if so, what PFD should be assigned. A HAZOP study uses qualitative(voting) judgments of risk whereas LOPA uses order-of-magnitude estimatesto make judgments of risk.

Other sources for identifying candidate scenarios for LOPA are

• issues related to plant operation. This could involve unexpectedbehavior, or operating conditions outside normal ranges, etc.;

• incidents in the process, or from other processes, which reveal an initi-ating event or scenario not previously considered or which was notconsidered credible;

• the requirement to change the process, which could involve new ormodified scenarios;

• interlock reviews to assess whether the safety instrumented function(SIF)—interlock—is required and, if so, the type of SIF required to meetthe corporate risk guidelines.



FIGURE 4.6. HAZOP Information and LOPA.

Scenario Development

Once a scenario has been identified, it must be developed and documented tothe level where a basic understanding of the events and safeguards isachieved. The scenario may not be initially understood completely and mayundergo revisions. New scenarios may also be revealed that must be ana-lyzed separately. Table 4.1 shows one method for presenting the informationrequired for full development of a scenario. Table 4.1 is discussed in moredetail in Appendix C. Any format is acceptable, provided that it is compre-hensive and applied consistently within an organization.

Include All Steps of the ScenarioA scenario requires identification and documentation of all the importantsteps required for an event to progress from the initiating event to the conse-quence. Any factor that could affect the numeric calculation of the conse-quence frequency or consequence size or type should be included anddocumented (see Appendix C). It is critically important to maintain the linkbetween a specific initiating event, a specific consequence, and specific IPLs.Otherwise, IPLs may not be credited appropriately.

Example 4.3

One scenario for a reactor would be loss of cooling leading to overpressure

and possible leakage and rupture. A second scenario would be external fire

leading to overpressure and possible leakage and rupture, and a third

might be loss of reflux leading to the same consequence. A high tempera-

ture trip (a candidate IPL) might protect against the first and third scenarios,

but might provide no protection against external fire in the second sce-

nario. While it may be that the relief valve is sized for the largest of these

relief loads, each of the scenarios must be examined for appropriate relief

protection to ensure the relief valve is an IPL.

Once the initiating event is identified for a specific scenario, the analystmust determine whether any enabling events or conditions are required forthe initiating event to lead to the consequence. Again, an understanding ofhow events could unfold is required. Chapter 5 deals with these issues ingreater detail.

The next step is to confirm that the consequence is stated using the samecriteria as the LOPA method (see Chapter 3). If the LOPA method beingapplied categorizes the size and type of release or damage (Methods 1 and 2,Chapter 3), then this must be calculated or estimated for each scenario. If themethod uses fatality frequency (Methods 3 and 4, Chapter 3), then appropri-ate probabilities must be assigned before the calculation for the scenario canbe completed (see Chapter 7).



TABLE 4.1Example of Summary Sheet for LOPA Scenario Documentation and Calculations

Scenario Number Equipment Number Scenario Title

Date: Description ProbabilityFrequency(per year)

Consequence Descrip-tion/Category

Risk Tolerance Criteria(Category or Frequency)

Initiating Event(typically a frequency)

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

BPCS

Human intervention

SIF

Pressure relief device

Other protection layers(must justify)

Safeguards(non-IPLs)

Total PFD for all IPLs

Frequency of Mitigated Consequence

Risk Tolerance Criteria Met? (Yes/No):

Actions Required to Meet Risk Tolerance Criteria:

Notes:

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

LOPA analyst (and team members, if applicable):

The next step in developing the scenario is to identify the safeguards thatare in place, which, if they operate as intended, may prevent the scenariofrom proceeding to the consequence. It is best to list all of the safeguards for aparticular scenario before deciding which are truly IPLs. This practice docu-ments the issues considered and enables subsequent reviewers to understandwhy some safeguards were or were not considered to be IPLs. Chapter 6describes the requirements for a safeguard to be considered as an IPL inLOPA. Care must be taken in applying these guidelines to ensure that a par-ticular safeguard meets the requirements of an IPL.

Example 4.4 demonstrates the development of a scenario for the reactorexotherm discussed in Examples 4.1 and 4.2.

Example 4.4

Consider a typical hazard evaluation of the reactor runaway exotherm sce-

nario presented in Examples 4.1 and 4.2:

• The HE team would almost certainly have identified the potential for arunaway exotherm on loss of cooling. However, a qualitative HE mightnot have documented:� That the potential for a runaway exotherm is only present during a spe-

cific portion of the batch cycle; and� The frequency at which loss of cooling is expected to occur.

Thus, the LOPA analyst would need to calculate the effective initiating

frequency for this particular scenario. This would require such data as: a

history of loss of cooling incidents at the facility, the batch cycle time, the

number of batches run in a year for that particular recipe, the reaction

kinetics, and the vapor liquid equilibria of the reaction feeds, intermedi-

ates and products, etc.

• The consequence described by the HE team may not match the classifica-tion used within an organization for making risk based judgments. TheLOPA analyst must state the consequence in a manner consistent withthe method being applied.

• The HE team may have listed multiple safeguards against overpressuringthe system, but may not have considered whether these safeguards werefully effective and independent of the initiating event and other protec-tion layers. These safeguards might include operator action, alarms, mul-tiple BPCS loops, SIF loops, relief devices, etc. The LOPA analyst shouldreview the list of safeguards generated by the HE to identify those con-sidered as true IPLs in LOPA.

Clarification/Modification of Initial ScenarioRegardless of how the initial scenario is generated and developed, the sce-nario, or the process it relates to, may not be completely understood. Scenariodevelopment often clarifies or modifies the initial path(s) by which a giveninitiating event can result in an undesired consequence. Additional informa-


tion becomes available as the analysis progresses and questions are oftenasked concerning the assumptions made earlier. This new information maydemonstrate that the consequence is less serious than initially thought, thatthere are more IPLs than originally included in the analysis, or that the initiat-ing frequency is lower, etc. In other cases the analysis may show that the riskis greater than first thought, due to safeguards not being truly independent oreffective, or due to the initiating event frequency or consequence beinggreater than originally assumed. In some cases this analysis can lead to devel-opment of new scenarios as a greater understanding of the system is gained.This new understanding may also affect how similar scenarios are viewed inother processes. This is one of the side benefits of the LOPA process.

A documentation and tracking system should be used to ensure that the sce-nario and associated issues, recommendations, references, assumptions, etc.are fully documented and recommendations are resolved (see Appendix C).


Tables 4.2 and 4.3 present the results of a HAZOP for the continuing exam-ples used in this book. Chapter 2 provided the basic problem descriptionstogether with the P&IDs and other relevant information. Chapter 3 identifiedthe undesired consequences.

In some LOPA methods the spill itself is the consequence end-point (theevent itself must be prevented and the probabilities of ignition of the flamma-ble material and the presence of personnel are viewed as irrelevant). Otherapproaches use the fatality frequency due to ignition of the spill inside or out-side of the dike, including the various probabilities discussed in Examples 4.1and 4.2 of Section 4.2.

The HAZOP method and results shown in Tables 4.2 and 4.3 are for illus-tration and use a generic approach with key words for the deviation (low flowor no flow, high temperature, etc.) used to initiate discussion. The HAZOPtables then show whether a cause, or causes, for this deviation are present inthe system and what consequences could result. Any safeguards are then listedagainst the cause leading to the deviation. Finally, any recommendations thatare considered appropriate are listed, using a qualitative ranking approach.

The results of the HAZOP for both installations indicate that loss of con-tainment from the tank is a significant concern. There are several scenariosrelating to loss of containment in Tables 4.2 and 4.3, but the scenarios selectedfor demonstrating the LOPA methodology in this book involve high liquidlevel leading to an overflow. Table 4.4 shows Scenario 1a of Example 1 devel-oped using a matrix method for consequence and risk assessment (Method 1from Chapter 3). In Table 4.5, Scenario 2a of Example 2 is developed using thefatality frequency method for consequence and risk assessment (Method 3from Chapter 3). These tables only contain information on the consequence


TABLE 4.2HAZOP for Hexane Surge Tank Section 1—

Line from the “prior process” to Hexane Surge Tank T-401Drawing: P&ID for Continuing Example 1 Figure 2.12

Item Deviation Causes Consequences SafeguardsRecom-

mendations

1.1 High flow Flow control valvetransfers or failsopen

High level—HexaneSurge Tank T-401(see 2.1)

1.2 Low flowor no flow

Blocked flow (e.g.,plugged line)

Downstreammanual blockvalve inadver-tently closed orgate falls

Low pressure (see1.7)

Low level—HexaneSurge Tank T-401(see 2.2)

Potential overheat-ing and failure ofupstream pump sealoutside battery limit(OSBL) of study

1.3 Reverseflow

Low pressure (see1.7)

Possible loss of con-tainment (see 1.9)

Check valve

1.4 High tem-perature

No credible causesidentified

1.5 Low tem-perature

No consequences ofinterest

1.6 High pres-sure


1.7 Low pres-sure

Upstream pump(OSBL) fails off

Low flow or no flow(see 1.2)

Reverse flow (see1.3)

Local pressuregauge at dis-charge ofupstreampump (OSBL)

1.8 High con-centrationof contam-inants

No consequence ofinterest—contami-nation downstream,possibly resulting inunit upset

1.9 Loss ofcontain-ment

Corrosion/erosion

External fire

External impact

Gasket, packing,or seal failure

Hydraulichammer(continued onnext page)

Release of hexane;fire hazard affectinga large area (conse-quence category 4or 5)

Operation/maintenanceresponse asrequired,including isola-tion if needed

Capability tomanually iso-late the line

(continued onnext page)



mendations

1.9cont.

Loss ofcontain-ment

Impropermaintenance

Instrument orinstrument linefailure

Material defect

Thermal expan-sion with equip-ment blocked in

Reverse flow (see1.3)

Check valve toprevent a largeback-flowthrough a linebreach

Corrosionprobes

Periodic non-destructiveinspection

2.1 High level High flow—Linefrom the “priorprocess” toHexane SurgeTank T-401 (see1.1)

High pressure (see2.5)

Level indica-tion with highlevel alarm(audible incontrol room)

Unitoperatingprocedures

Considerinstallingan SIS toshut offinlet flowon high-high levelin T-401

2.2 Low level Low flow or noflow—Line fromthe “prior process”to Hexane SurgeTank T-401 (see1.2)

No safety conse-quences—Potentialprocess interruptionif not refilled beforedownstream feedtank is empty




Low ambient tem-perature whilethere is water con-tamination in thetank (see 2.7)

Possible freezing ofaccumulated waterin the heel of thetank or in the tank’sdrain line or instru-ment lines, resultingin fracture of thedrain line and loss ofcontainment (see 2.8)

2.5 Highpressure

High level (see 2.1) Release of hexanethrough the reliefvalve into the tank’sdike; fire hazardaffecting a large areaif not contained bythe dike (consequencecategory 4 or 5)

Loss of containment(if the overpressurecause exceeds thetank pressure rating)(see 2.8)



mendations

2.6 Lowpressure

Tank blocked inbefore cool-down,following steam-out

Equipment damageresulting from col-lapse of the tankunder vacuum

Standard pro-cedures andchecklist forsteam-out ofvessels


Water not com-pletely drainedfollowing a steam-out or washout

Possible freezing ofaccumulated waterin the tank during aperiod of low ambi-ent temperature (see2.4)


Corrosion/erosion

External fire

External impact


Improper mainte-nance


Material defect

Sample stationvalve leaking

Vent or drainvalve leaking

Low temperature(see 2.4)

High pressure (ifthe overpressurecause exceeds theequipment pres-sure rating) (see2.5)

Release of hexane;fire hazard affectinga large area, particu-larly if the capacityof the dike isexceeded (conse-quence category 4or 5)

Operation/maintenanceresponse asrequired,includingisolation ifneeded

Capability tomanuallyisolate the tank

Periodic non-destructiveinspection perAPI recom-mendedpractices andASME code

Relief valvethat dischargesto the tank’sdike

Dike sized for120,000 lb ofhexane (1.5times capacityof tank)

Emergencyresponseprocedures

and the initiating event; the remaining fields in the tables, including numericdata, will be completed as the continuing example problems are discussed inthe other chapters of this book. Appendix A contains the completed LOPAsummary tables for all continuing examples using the risk matrix, fatality fre-quency, and required number of IPL methods, which are discussed in Chap-ter 8.


TABLE 4.3AHAZOP for Hexane Storage Tank Section 1—Line from the Tank Truck to Hexane

Storage Tank T-301 Through Hexane Unloading Pump 3-40Drawing: P&ID for Continuing Example 2 Figure 2.13

Item Deviation Causes Consequences Safeguards

3.1 High flow No consequences of interest

3.2 Low flow orno flow

Blocked flow (e.g.,plugged line)

Downstream manualblock valve inadver-tently closed or gatefalls

Low pressure (see 3.7)

Potential overheatingand failure of pumpseal (see 3.9)

Low level—HexaneStorage Tank T-301(see 4.2)

3.3 Reverseflow

Drain valve inadver-tently left open whileunloading pump is off

Low pressure (see 3.7)

Possible loss of con-tainment (see 3.9)

Check valve




No consequences of interest

3.6 Highpressure


3.7 Lowpressure

Unloading pump failsoff

Lowflow or no flow(see 3.2)

Reverse flow (see 3.3)

Local pressure gauge

3.8 High con-centrationof contami-nants

Contamination(organic, moisture, ordebris) in flexibleunloading lines

Contamination in thetank truck

Receiving or spottingthe wrong tank truck

High concentration ofcontaminants—Hexane Storage TankT-301 (see 4.7)

Hexane unloadingprocedures

Caps for flexibleunloading line

Material testing pro-cedure prior tounloading

3.9 Loss ofcontainment

Corrosion/erosion

External fire

External impact

Gasket, packing, orseal failure

Hydraulic hammer

Improper mainte-nance

Instrument or instru-ment line failure

Material defect

Thermal expansionwith equipmentblocked in

Low flow or no flow(see 3.2)

Reverse flow (see 3.3)

Release of hexane;fire hazard affectinga large area (conse-

quence category 4or 5)

Operation/mainte-nance response asrequired, includingisolation if needed

Capability to manu-ally isolate the line

Check valve to pre-vent a large backflowthrough a line breach

Corrosion probes

Periodic nondestruc-tive inspection

TABLE 4.3BHAZOP for Hexane Storage Tank—Hexane Storage Tank T-301

Drawing: P&ID for Continuing Example 2 Figure 2.13


mendations

4.1 High level Flow from tanktruck not discon-tinued beforetank capacity hasbeen reached

Inventory controlerror—Truckarrives beforeneeded

High pressure (see4.5)

Level indicationwith high levelalarm (audiblein control room)

Hexane unload-ing procedureswith checklistthat includeschecking fieldreading of tanklevel beforeunloading

Considerinstallingan SIS toshut offinlet flowon high-high levelin T-301

4.2 Low level Inventory controlerror—Truckarrives too late

Lowflow or noflow—Line fromthe Tank Truck toHexane StorageTank T-301Through HexaneUnloading Pump3-40 (see 3.2)

No safety conse-quences—Potential processinterruption if notrefilled beforedownstream feedtank is empty


No crediblecauses identified


Low ambienttemperaturewhile there iswater contamina-tion in the tank(see 4.7)

Possible freezing ofaccumulated waterin the heel of thetank or in the tank’sdrain line or instru-ment lines, result-ing in fracture ofthe drain line andloss of containment(see 4.8)

4.5 Highpressure

High level (see4.1)

Release of hexanethrough the reliefvalve into thetank’s dike; firehazard affecting alarge area if notcontained by thedike (consequencecategory 4 or 5)

Loss of contain-ment (if theoverpressure causeexceeds the tankpressure rating)(see 4.8)

Continued on next page


mendations

4.6 Lowpressure

Tank blocked inbefore cool-down, followingsteam-out

Equipment damageresulting from col-lapse of the tankunder vacuum

Standard proce-dures and check-list for steam-outof vessels


Water not com-pletely drainedfollowing asteam-out orwashout

High concentra-tion of contami-nants—Line fromthe Tank Truck toHexane StorageTank T-301Through HexaneUnloading Pump3-40 (see 3.8)

Possible freezing ofaccumulated waterin the tank during aperiod of low ambi-ent temperature(see 4.4)


Corrosion/erosion

External fire

External impact


Impropermaintenance


Material defect

Sample stationvalve leaking

Vent or drainvalve leaking

Low temperature(see 4.4)

High pressure (ifthe overpressurecause exceeds theequipment pres-sure rating) (see4.5)

Release of hexane;fire hazard affect-ing a large area,particularly if thecapacity of the dikeis exceeded (conse-quence category 4or 5)

Operation/maintenanceresponse asrequired, includ-ing isolation ifneeded

Capability tomanually isolatethe tank

Periodic nonde-structive inspec-tion per APIrecommendedpractices andASME code

Relief valve thatdischarges to thetank’s dike

Dike sized for120,000 lb ofhexane (1.5times capacity oftank)

Emergencyresponse proce-dures


To complete the analysis for this system, the LOPA team or analystwould also consider other scenarios (such as rupture of the flexible fillinghose, pump seal failure, etc.), develop quantitative values for the variouscomponents of the scenario, and determine whether the existing risk meetsthe relevant criteria. Chapters 5–8 demonstrate this procedure for the contin-uing examples.


As this is a continuous process, the control of the liquid level in the tank is adynamic process that relies upon instrumentation to take action. The dike hasadequate capacity to contain the overflow for a period of time sufficient forthe operator to detect the spill for the normal flow rate into the tank. The initi-ating event for this example is failure of the LIC (a BPCS loop), whichincludes instrumentation failures and operator errors if the level control is setto manual or is bypassed. This could lead to overfilling of the tank and a spillinto the dike surrounding the tank. The size or type of consequence dependson whether this dike contains the spill. The two separate scenarios developedfor this case follow.

Scenario 1a: Hexane Surge Tank Overflow—Spill Not Contained bythe DikeThe initiating event is failure of the level loop leading to tank overflow andrelease outside the dike due to the dike failure. The consequence (dependingupon the method adopted) is a release, or fire outside the dike with possibleinjuries or fatalities. Existing safeguards, which are candidate IPLs for thisscenario, include human intervention (operator response to alarms via theBPCS, and procedures), and the dike. The safeguards will be tested in Chap-ter 6 to determine if they are IPLs. The LOPA summary sheet for this scenariousing the risk matrix method is shown in Table 4.4. Summary sheets for theother methods are shown in Appendix A.

Scenario 1b: Hexane Surge Tank Overflow—Spill Contained by theDikeThe initiating event is failure of the level loop leading to tank overflow withthe spill contained by the dike. The consequence (depending upon themethod) may be the spill itself or a fire in the dike with possible injuries orfatalities. Existing safeguards, which are candidate IPLs for this scenario,include human intervention (operator response to alarms via the BPCS, andprocedures) and the dike. The safeguards will be tested in Chapter 6 to deter-mine if they are IPLs. The LOPA summary sheets for this example for all ofthe methods are shown in Appendix A. The risk matrix method would notconsider this a scenario, since the consequence of a spill inside the dike wouldnot be considered a significant event (see Chapter 3).


60

TABLE 4.4Summary Sheet for Continuing Example Scenario 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 dike


ConsequenceDescription/Category

Release of hexane outside the dikedue to tank overflow and spill ofhexaneSeverity Category 4



Loop failure of BPCS LIC.



Probability of ignition N/A

Probability of personnel in affected area N/A

Probability of fatal injury N/A

Others N/A



None identified at this stage of theanalysis.See Notes (below) for candidate IPLs


See Notes (below)





Notes Consider if the following devices, systems or actions are IPLs:human intervention, other BPCS control loops, dike




The potential exists for liquid overflow of the tank if the truck arrives forunloading with insufficient room in the tank. This would result in a spill intothe dike. The scenarios developed for this case follow.

Scenario 2a: Hexane Storage Tank Overflow—Spill Not Contained by the DikeThe initiating event is failure of the inventory control system, allowing thetank truck to arrive with insufficient room in the tank. The result is liquidoverflow of the tank with spillage outside the dike. The consequence is arelease outside the dike with the potential for fire and/or injury. A candidateIPL is the dike. Other existing safeguards, which are candidate IPLs for thisscenario, include human intervention (operator response to alarms via theBPCS, and procedures). The LOPA summary sheet for this scenario using thefatality frequency methodology is shown in Table 4.5. Summary sheets forthe other methodologies are shown in Appendix A.

Scenario 2b: Hexane Storage Tank Overflow—Spill Contained by the DikeThe initiating event is failure of the inventory control system, allowing thetank truck to arrive with insufficient room in the tank. The result is liquidoverflow of the tank with spillage inside the dike. The consequence is arelease inside the dike with the potential for fire and/or injury. Other existingsafeguards, which are candidate IPLs for this scenario, include human inter-vention (operator response to alarms via the BPCS, and procedures) and thedike. The safeguards will be tested in Chapter 6 to determine if they are IPLs.The LOPA summary sheets for this example, for all of the methods, areshown in Appendix A. The risk matrix method would not consider this as ascenario, since the consequence of a spill inside the dike would not be consid-ered a significant event (see Chapter 3).

An issue arising from these scenarios is that some organizations wouldnot evaluate scenarios 1b and 2b for release within the dike, based on theirexperience of the severity of the consequence. This judgment is dependentupon the material released and the conditions of the release (temperature,pressure, location, etc.). This applies to flammables, but not to materials thatcould form vapor clouds or for materials with the potential for toxic effects(see Chapter 3).

4.5. Link Forward

Chapter 5 discusses initiating events and enabling events/conditions andhow to estimate these values accurately.

4.5 Link Forward 61

62

TABLE 4.5Summary Sheet for Continuing Example Scenario 2a—Fatality Frequency Criteria

Method (Method 3 of Chapter 3)

Scenario Number

2a

Equipment Number Scenario Title: Hexane Storage Tank Over-flow. Spill not contained by the dike


Consequence Descrip-tion/Category

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



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

Enabling Event or Con-dition





Others



None identified at this stage of theanalysis.See Notes (below)

Safeguards(non-IPLs) See Notes (below)





Notes: Consider if the following devices, systems or actions are IPLs:human intervention, other BPCS control loops, dike



5

Identifying Initiating EventFrequency

5.1. Purpose

The purpose of this chapter is twofold. First, it provides guidance on identify-ing true initiating causes (called initiating events in LOPA) of incident scenar-ios, and second, it provides guidance on estimating the frequency of initiatingevents. This chapter addresses Step 3 of the LOPA methodology described inChapter 2.

5.2. Initiating Events

Expression of Initiating Events

For LOPA, each scenario has a single initiating event. The frequency of theinitiating event is normally expressed in events per year. Some sources useother units, such as events per 106 hours.

Types of Initiating Events

Initiating events are grouped into three general types: external events, equip-ment failures, and human failures (also called inappropriate actions). Theseare shown in Figure 5.1.

A root cause is defined as “An underlying system-related (the most basic)reason why an incident occurred” (Guidelines for Investigating Chemical ProcessIncidents; CCPS, 1992b). Initiating events can be the result of various underly-

63

ing root causes such as external events, equipment failures, or human fail-ures, as shown in Figure 5.1. Root causes are not the same as initiating events,and care should be taken to avoid going too far into root causes in identifyinginitiating events. Root causes can, however, contribute to determining the fre-quency of occurrence of the initiating event. Therefore, it may be appropriateto consider some root causes (e.g., inadequate procedures and/or training)when estimating the frequency of the initiating events as described in Section5.3 of this chapter.

External Initiating EventsAs depicted in Figure 5.1, external events include natural phenomena such asearthquakes, tornadoes, or floods, “knock-on” events from fires or explosionsin adjacent facilities; and third party intervention such as mechanical impacton equipment or supports by motor vehicles, or construction equipment. Sab-otage and terrorism are initiating events that require special treatment,because a true saboteur may defeat, or attempt to defeat, IPLs as well. It maybe impossible to protect against sabotage and terrorism.

Equipment-Related Initiating EventsAs depicted in Figure 5.1, equipment-related initiating events can be furtherclassified into control system failures and mechanical failures. Controlsystem failures include, but are not limited to:

64 5. Identifying Initiating Event Frequency

FIGURE 5.1. Types of initiating events.

• basic process control system (BPCS) component failures,• software failures or crashes, and• failure of control support systems (e.g., electricity, instrument air).

Similarly, mechanical failures include, but are not limited to

• vessel or piping failure caused by wear, fatigue, or corrosion;• vessel or piping failure caused by design, specification, or manufactur-

ing/fabrication defects;• vessel or piping failure caused by overpressure (e.g., thermal expan-

sion, pigging/blowing) or underpressure (vacuum collapse);• vibration-induced failures (e.g., in rotating equipment);• failures caused by inadequate maintenance/repair, including substitu-

tion of improper materials of construction;• failures resulting from high temperature (e.g., fire exposure, loss of

cooling) or low temperature and resulting brittle fracture (e.g., auto-refrigeration, low ambient temperature);

• failures resulting from flow surge or hydraulic hammer; and• failures resulting from internal explosions or decompositions or other

uncontrolled reactions.

For a more comprehensive listing of equipment-related initiating causes,refer to Guidelines for Design Solutions for Process Equipment Failures (CCPS,1998a).

Human Failure-Related Initiating EventsAs depicted in Figure 5.1, causes related to human failures are either errors ofomission or errors of commission, and include but are not limited to

• failure to execute the steps of a task properly, in the proper sequence oromitting steps (something not done) and

• failure to observe or respond appropriately to conditions or otherprompts by the system or process (something done wrongly).

Management systems are not normally listed as potential initiatingevents, although ineffective management systems are quite often a root causeof human error. For the purposes of LOPA, a cause-identification methodol-ogy stopping at a specific human error as the initiating event is sufficient. Theanalyst should avoid carrying the initiating event analysis too far into rootcauses of human error, at least at this stage. However, further analysis may beappropriate at the end of the LOPA, when appropriate means of safeguard-ing are being considered.

For a more comprehensive discussion of human error and proceduralcauses, refer to Guidelines for Preventing Human Error in Process Safety (CCPS,1994b), or other public domain sources.


Verification of Initiating EventsPrior to assigning frequencies to initiating events, all causes from the scenariodevelopment step should be reviewed and verified as valid initiating eventsfor the consequence identified (i.e., there must be a unique cause–conse-quence relationship). Any causes that are incorrect or inappropriate shouldbe either discarded or developed into valid initiating events. Examples ofinappropriate initiating events include

• Inadequate operator training/certification: This is a possible underlyingcause of an initiating event (site- or company-specific levels of trainingand certification are assumed in assigning failure rates).

• Inadequate test and inspection: This is a possible underlying cause of aninitiating event (site- or company-specific normal levels of test andinspection frequency are assumed in assigning failure rates).

• Unavailability of protective devices such as safety valves or overspeed trips(other events must first initiate the scenario before a protective deviceis challenged).

The analyst should also verify that all the potential initiating events weredetermined by viewing the process from a system perspective, and ensuringthat any causes normally generic to this process or similar processes have notinadvertently been excluded. In addition, the analyst should reduce each causeinto discrete failure events. For example, the cause “loss of cooling” could bethe result of a coolant pump failure, power failure, or control loop failure. List-ing these separately is useful, because the existing (and new) potential layers ofprotection (described in Chapter 6) may be different for each initiating event. Inaddition, the analyst should ensure that initiating events in all modes of opera-tion (e.g., normal operation, startup, shutdown, utility outages) and equipmentstates (e.g., standby, under maintenance) have been identified/examined. Anyof these may involve discrete failures that could cause loss of cooling and inturn result in the consequence of interest.

A spurious trip of a safety instrumented function (SIF), which is an inde-pendent protection layer for an accident scenario, is only considered an initi-ating event for scenarios that result from transitional operating states (e.g.,emergency shutdowns) and is not normally a valid initiating event in itself.This is another example of the principle noted in the first paragraph of thissection, where failure of a relief device to operate on demand is not a valid ini-tiating event of an “overpressure leads to vessel failure” scenario. However,there are circumstances under which spurious trips of protective systems canaffect frequencies of initiating events and result in challenges to other protec-tive layers. This is shown in Example 5.1 below.

Example 5.1

A spurious trip of a boiler flame safeguard system can result in the necessity

to restart the boiler. This increases the potential for a hazardous event


involving a possible firebox explosion and its attendant hazards by increas-

ing the frequency of startups (restarts).

Enabling Events/ConditionsIn some scenarios, the initiating event may not be obvious. As the PHA orLOPA team identifies scenarios that lead to safety consequences, some will bedeveloped where the initiating or triggering event is not clear. In such com-plex scenarios, there may be other factors that are neither failures nor protec-tion layers. These factors are called enabling events or conditions, andconsist of operations or conditions that do not directly cause the scenario, butwhich must be present or active in order for the scenario to proceed. Enablingevents are expressed as probabilities, and can include such things as themode of operation (startup or shutdown) or the operation being in a specificphase or step. In such cases, the initiating event may be the combination of anenabling event (probability) and a subsequent failure or inappropriate action(frequency). This is shown in Examples 5.2 and 5.3 below. Some companiesuse enabling events/conditions to modify initiating event frequencies. Somedo not because of the resulting complexity and potential for underestimationof initiating event frequency.

Example 5.2

At the start of a batch reaction, operator error may result in the addition of

twice the correct amount of catalyst. This error will overpressure and possi-

bly rupture the reactor, unless it is prevented by the protection provided by

the rupture disc (i.e., the rupture disc must be sized properly for this upset),

or an emergency “kill” SIF — safety instrumented function, which will also

prevent substantial overpressure. It is assumed that no other protective sys-

tems are capable of stopping this upset, once it has started.

Solution: The initiating event frequency for this scenario is a function of

how frequently a batch is run (an enabling event), and the chance that

twice the catalyst is added to this reaction (the initiating event). It is impor-

tant for the LOPA team to understand that this initiating event is a combi-

nation of the number of batches run per year AND the chance that the

catalyst double charge mistake is made. This is key to the calculations. The

team must note that if the number of batches per year changes, then the

risk of reactor rupture also changes.

Example 5.3

While moving cylinders to a phosgene cylinder hookup station, an operator

drops an uncapped cylinder, resulting in the valve breaking off and releas-

ing phosgene.

Solution: Two approaches are possible for this example. In the first, the ini-

tiating event is dropping the uncapped phosgene cylinder during move-

ment; note that the initiating event has two parts, moving the uncapped

cylinders and dropping one. Thus, the frequency of the initiating event is


based on the number of times phosgene cylinders are moved per year, the

probability that the cylinder is uncapped, and the subsequent probability

that one is dropped. In the second approach, the initiating event frequency

is based only on the number of times phosgene cylinders are moved per

year and the subsequent probability that one is dropped. Checking that the

cylinder is capped before it is moved is considered as a human IPL and

would be addressed in the IPL evaluation step of LOPA.

The search for the initiating event involves identifying the hazardousevent whose frequency of occurrence is the key factor driving the scenario.

The likelihood of an error is dependent on the number of times per year theoperation or activity is carried out. However, as a task is done more frequently,many factors influence the likelihood of an error occurring on the task, and anyskill improvements as a result of performing the task more frequently may bemore than offset by the sheer number of opportunities for error. Therefore,some LOPA analysts use only a few discrete values for human error, ratherthan adjusting for enabling event frequency. This avoids the underestimationof the likelihood for human error for tasks done only a few times per year. Fur-thermore, estimation of the error probability for a complex task is often verydifficult, and probably outside the scope of LOPA. The organization mustdevelop a consistent set of rules for estimating the likelihood of human error,and then adhere to those rules within LOPA. If the rules do not seem appropri-ate to a specific LOPA evaluation, then perhaps the analyst should considerperforming a quantitative risk analysis for that case.

5.3. Frequency Estimation

Failure Rate Data

SourcesA number of sources of failure rate data are available for assigning consistentvalues to the initiating event frequency. These include

• industry data such as the Guidelines for Chemical Process QuantitativeRisk Analysis (CCPS, 1989a) and the Second Edition (CCPS, 2000a),Guidelines for Process Equipment Reliability Data (CCPS, 1989b), andother public domain sources such as IEEE (1984), EuReData (1989), andOREDA (1989, 1992, 1997). CCPS also has a project underway for shar-ing failure rate data among participating companies.

• company experience (including hazard analysis team experience),where enough historical data are available to be statistically signifi-cant. (Note: Operator experience is often a better source for specificevents, whereas generic industry failure rate data are often better foroverall equipment failures, because many companies do not have agood internal database for failure data.)


• vendor data, which are typically optimistic, since the data are devel-oped in clean, well-maintained settings, or may be based on compo-nents returned to the vendor—many failed components are thrownaway, rather than returned.

When a cause may have multiple component failures, use of simplifiedfault trees or event trees may be appropriate to derive the combined failurefrequency (e.g., primary control loop failure). In general, such techniquesshould only be used selectively to prevent the LOPA process from becomingoverly complex. Remember, LOPA is a methodology that falls betweensimple qualitative and more elaborate quantitative analysis techniques.

Selection of Failure RatesFailure rates should be selected with a number of issues in mind:

• Failure rates should be consistent with the basic design of the facilityand be consistent with the company method for making risk-baseddecisions.

• All the failure rates used should be from the same location in the datarange (e.g., upper bound, lower bound, or midpoint), providing a con-sistent degree of conservatism for the entire process.

• The failure rate data selected should be representative of the industryor operation under consideration. If historical data are available, theyshould be used only if sufficient data are available over an adequateperiod of time to be statistically significant. If general industry data areused, they should be adjusted (usually by consideration of limitedplant data and expert opinion) to reflect local conditions and situa-tions. Where such data may not be directly available, judgment mustbe used in deciding which data from outside sources are most applica-ble to the situation (e.g., use of US Department of Transportation pipe-line failure data for in-plant piping systems).

Many failure rate databases contain data presented with two or more sig-nificant places. This is much more precision than required for LOPA (and alsooften much more precise than the data warrants!). LOPA only requires order-of-magnitude approximation, and such data should be rounded up to thenearest whole order of magnitude. As noted earlier, caution should also beused in applying vendor-supplied data, as such data are often developedfrom best-achievable or laboratory performance.

Underlying assumptions are always involved in selection of failure ratedata. These normally include, among others, assumptions on the range ofoperating parameters, the specific chemicals processed, basic testing andinspection frequency, operator and maintenance training programs, andequipment design quality. It is therefore important to ensure that the failurerate data used for a process is consistent with the basic assumptions inherent


with the data. (For instance, it would be inappropriate to apply OREDA datadeveloped by the petroleum industry for North Sea off-shore oil rigs directlyto chemical operations in Kansas.) These assumptions should be documentedso that future data selections are made consistently.

The LOPA method also assumes that the failure rate is constant. This isnot always true, since equipment failure rates are typically higher when theequipment is new (“infant mortality”) and when it ages (“old age”). How-ever, for most equipment the longest period of operation involves a constantfailure rate. For the purposes of LOPA, a constant failure rate is adequate.

Failure Rates in LOPATypically, for LOPA, a company should lump discrete initiating event fre-quencies into a representative set of initiating event categories. This improvesthe consistency of risk estimates across an organization. Typical initiatingevent frequencies used by LOPA analysts in the chemical industry are shownin Table 5.1.

For control system failures, the overall loop failure rate typically includesfailure of any of several components (transmitter, air supply, DCS, valve,sensor, etc.) and can include other factors such as improper set points, mis-calibration, operation on manual or off-cascade.

Derivation of Initiating Event Frequency from Failure DataFailure data are sometimes expressed as a probability of failure on demand(PFD). For example, human error to execute a task may be expressed as 1 ×10–1 per opportunity, or a crane load drop may be expressed as 1 × 10–4 per lift(see Table 5.1). When this is the case, the initiating event frequency must bederived. This involves estimating the number of times per year (or times per106 hours) that a demand is placed on the system (or person). This may be asstraightforward as counting the number of times the operation is carried outper year and multiplying by the probability of failure on demand (assumingthe two values are not interdependent). Or, it may be as complex as usingfault tree techniques to estimate the number of challenges per year to whichthe system is subjected. LOPA is a simplified approach, and the analystshould move on to more rigorous techniques if the scenario is overly complexor more precision is desired.

Time at RiskFor systems/operations that are not continuously operated (loading/unloading, batch processes, etc.) failure rate data must be adjusted to reflectthe ‘time at risk’ for the component or operation under consideration. Since



TABLE 5.1Typical Frequency Values, fI, Assigned to Initiating Events

Initiating Event

Frequency Range

from Literature(per year)

Example of aValue Chosen by

a Company forUse in LOPA

(per year)

Pressure vessel residual failure 10–5 to 10–7 1 × 10–6

Piping residual failure—100 m—Full Breach 10–5 to 10–6 1 × 10–5

Piping leak (10% section)—100 m 10–3 to 10–4 1 × 10–3

Atmospheric tank failure 10–3 to 10–5 1 × 10–3

Gasket/packing blowout 10–2 to 10–6 1 × 10–2

Turbine/diesel engine overspeed with casingbreach

10–3 to 10–4 1 × 10–4

Third party intervention (external impact bybackhoe, vehicle, etc.)

10–2 to 10–4 1 × 10–2

Crane load drop 10–3 to 10–4 per lift 1 × 10–4 per lift

Lightning strike 10–3 to 10–4 1 × 10–3

Safety valve opens spuriously 10–2 to 10–4 1 × 10–2

Cooling water failure 1 to 10–2 1 × 10–1

Pump seal failure 10–1 to 10–2 1 × 10–1

Unloading/loading hose failure 1 to 10–2 1 × 10–1

BPCS instrument loop failure Note: IEC 61511limit is more than 1 × 10–5/hr or 8.76 × 10–2/yr(IEC, 2001)

1 to 10–2 1 × 10–1

Regulator failure 1 to 10–1 1 × 10–1

Small external fire (aggregate causes) 10–1 to 10–2 1 × 10–1

Large external fire (aggregate causes) 10–2 to 10–3 1 × 10–2

LOTO (lock-out tag-out) procedure* failure*overall failure of a multiple-element process

10–3 to 10–4 peropportunity

1 × 10–3 peropportunity

Operator failure (to execute routine procedure,assuming well trained, unstressed, not fatigued)

10–1 to 10–3 peropportunity

1 × 10–2 peropportunity

Note: Individual companies should choose their own values, consistent with the degree of conserva-tism of the company’s risk tolerance criteria. Failure rates can also be greatly affected by preventivemaintenance (PM) routines

most failure rate data are expressed with units of “per year” (yr–1), it is neces-sary to adjust the data to reflect that the component or operation is not subjectto failure during the entire year, but only that fraction of the year when it isoperating or ”at risk.” This is normally done by multiplying the base failurerate by the fraction of the year the component is operating.

Example 5.4

Consider a frequently used unloading hose. The hose has an in-service base

failure rate of 1 × 10–2/yr, but is only subject to failure and release of haz-

ardous material or energy during unloading. The loading process takes 2

hours and is carried out 40 times per year, so the failure rate becomes:

F = (1 × 10–2/yr hose failure rate) × (40/yr × 2 hr) / 8000 hr/yr)

= 1 × 10–4/yr

This assumes that the hose is physically tested for integrity (e.g., subjected to

full operating pressure with air or nitrogen) prior to each unloading to detect

out-of-service failures, and there is no common cause dependency between

the values. If the base failure rate was developed for intermittent service,

then the testing would be built into the failure rate as a basic assumption.

Example 5.5

Consider a batch operation with a flow measurement loop. The loop failure

can only be an initiating event for a hazardous release during charging. If

the base loop failure rate is 1 × 10–2/year, and the charging operation takes

only one hour and is carried out eight times per year, then the failure rate

becomes:

F = (1 × 10–2/yr base loop failure) × (8 hr/8760 hr, the fraction of theyear that the operation is at risk) = 1 × 10–5/yr

This adjustment for time at risk will normally be made during the initiating

event frequency determination step in the LOPA process.

Adjustment of Frequency RatesSome LOPA methodologies adjust the unmitigated consequence frequencyto reflect such factors as probability of personnel being exposed to a hazard,probability of ignition, and probability of injury or fatality should an expo-sure occur. This adjustment may be made either in the determination of theinitiating event frequency, or in the calculation of the final scenario fre-quency, as described in Chapter 7.

Generally, analysts do not go to this level of detail, since LOPA is a sim-plified technique. If this level of accuracy is necessary, fault trees or eventtrees may be necessary, and the scenario should be analyzed using thosemore rigorous methods. Users of LOPA have noted that higher levels of scru-tiny do not always provide a better risk decision.


High Demand ModeWhen the initiating event frequency is more than twice the first IPL test fre-quency, it is called high demand mode. Section 7.2 and Appendix F discusshow to select the initiating event frequency for LOPA calculations for highdemand mode.

5.4. Expression of Failure Rates

There are several ways of expressing failure rates used in LOPA. The methodused should be consistent with the basic criteria and design of the LOPAmethodology. The methods include

• decimal systems,• scientific notation- or exponent-based systems, and• integer systems.

Examples of these types of expression are shown below in Table 5.2.

Qualitative values, such as low, medium, or high, or Category 1, 2, or 3,are sometimes used in even simpler versions of LOPA, or in situations wheremore definitive failure rates are not available.



For the tank overflow scenario resulting from instrument failure, the obviousinitiating event is failure of the tank level indicator/controller (LIC). Its initi-ating event frequency is, from Table 5.1

f I = 1 × 10–1/yr loop failure rate


TABLE 5.2Various Ways to Express Failure Rates

Designation Failure Rate 1 Failure Rate 2

Decimal 0.01 /yr 0.00001 /yr

Scientific notation 1 × 10–2 /yr 1 × 10–5 /yr

Exponent E-2/yr E-5 /yr

Integer logarithm 2 /yr 5 /yr

Note: In this book, scientific notation form will normally be used.


For this example, the overflow of the hexane storage tank is initially causedby an inventory control error. This results in inadequate room for unloadingthe truck. The initiating event frequency will be the number of times per yearthat the inventory control system fails. This has been determined by the PHAteam to be once per year. Thus, the initiating event frequency is

f I = 1/yr inventory error

The probability of failure or error in the inventory control system is afunction of the lead time for ordering hexane, the frequency of inventory veri-fication, and the plant shutdown frequency (which would lead to reductionin usage and slower than normal depletion of the hexane inventory).

5.6. Limitations (Cautions)

The LOPA method is a simplified (semiquantitative) method, and is notexhaustive (see the risk decision tools spectrum, Figure 2.3).

If a more detailed analysis is required, a method such as fault tree orevent tree analysis may be more appropriate. Also, LOPA may be inappropri-ate for very high consequence events since the risk tolerance is significantlylower for these events. It may be necessary to proceed to risk assessment tech-niques nearer to CPQRA in such cases.

One trap to avoid is incorporating an IPL failure into the initiating eventfrequency. Referring to the phosgene cylinder in Example 5.3, the twoapproaches treat the probability of the cap being missing differently andmust not be intermingled. Either approach works, provided it is applied con-sistently. The existence, or lack, of a procedure to check that a cylinder iscapped before it is moved could affect the probability that a cylinder isuncapped when it is moved. Alternatively, it could affect the PFD for ahuman IPL in checking that the cylinder is capped before it is moved.

5.7. Link Forward

Chapter 6 will discuss the subject of independent protection layers (IPL) andtheir application in the next step in LOPA. The reader will see how variousforms of IPLs are applied and their subsequent reduction of the scenario fre-quency to the final risk value.


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.


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.


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


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).


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.



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



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






Others N/A

Frequency of Unmitigated Consequence 1 × 10–1


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

SIF Candidate 1 × 10–2


Human intervention/BPCS

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



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

Notes



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.



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



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

1






Others



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


BPCS loop




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

Notes



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.


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.


• 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.


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:


• 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.


7

Determining the Frequencyof Scenarios

7.1. Purpose

This chapter shows how to use the identified scenarios and independent pro-tection layers (IPLs) described in prior chapters to calculate the mitigated sce-nario frequency. This includes calculations for the existing system or design(“as is”) and for the modified system or design after recommended changesare incorporated (“mitigated”). The calculations may be quantitative usingnumerical estimates or they may use lookup tables.

This chapter addresses Step 5 of the LOPA method described in Chapter2. The mitigated scenario frequency calculated in this chapter is used in deci-sion making in Chapter 8.

7.2. Quantitative Calculation of Risk and Frequency

General Calculation

The following is the general procedure for calculating the frequency for arelease scenario with a specific consequence endpoint. For this scenario, theinitiating event frequency from Chapter 5 is multiplied by the product of theIPL PFDs from Chapter 6.

f f

f

iC

i ij

j

J

i i i ij

= ×

= × × × ×

=

∏I

I

PFD

PFD PFD PFD

1

1 2 L (7-1)

115

where

fiC is the frequency for consequence C for initiating event i

fiI is the initiating event frequency for initiating event i

PFDij is the probability of failure on demand of the jth IPL that protectsagainst consequence C for initiating event i.

Equation (7-1) is applicable for low demand situations—that is, fiI is less

than twice the test frequency for the first IPL. The high demand calculation isdiscussed below. Equations (7-1) through (7-5) assume that all IPLs are trulyindependent—a basic premise of LOPA.

The result of Eq. (7-1) can be used as input for comparing calculated riskto scenario risk tolerance criteria for the decision-making methods in Section8.3 including matrix, numerical criteria, and number of IPL credits.

Calculating the Frequency of Additional Outcomes

Some companies calculate only the frequency of a release. As shown in Figure3.1, other outcomes of the release are also possible and companies may haverisk tolerance criteria for those outcomes. Thus, companies may choose toinclude the frequency of the other outcomes of the release:

• flammable effects such as fire or explosion,• toxic effects where applicable,• exposure to flammable or toxic effects,• injury or fatality.

To calculate the frequency of such outcomes, Eq. (7-1) is modified by mul-tiplying the frequency of the release scenario by the appropriate probabilitiesfor the outcome of interest. These include

• the probability of ignition (Pignition)—for flammable releases,• the probability that personnel are in the affected area (Pperson present )—a

precursor parameter for calculating exposures and injuries, and• the probability that injury occurs (Pinjury)— for injury or fatality.

Equation (7-2) determines the frequency of a fire for a single scenario for asingle system.

f f Pi i ij

j

Jfire I ignitionPFD= ×

×

=

∏1

(7-2)

Equation (7-3) determines the frequency of a person exposed to a fire.

f f P Pi i ij

j

Jfire exposure I ignitionPFD= ×

× ×

=

∏1

person present (7-3)

116 7. Determining the Frequency of Scenarios

Equation (7-4) determines the frequency of a person injured in a fire.

f f P Pi i ij

j

Jfire injury I ignition pePFD= ×

× ×

=

∏1

rson present injury×P (fire) (7-4)

Similar equations can be written for toxic effects by omitting the probabil-ity of ignition. Both the probability of a person being present and the proba-bility of injury may be different for flammable and toxic effects. For this case,Eq. (7-4) becomes

f f P Pi i ij

j

Jtoxic I person present inPFD= ×

× ×

=

∏1

jury (toxic) (7-5)

Note that the probability of ignition and the probability of a person pres-ent are frequently linked with the initiating event—the actions of the personmay be the ignition source. The initiating event, by its nature, may increaseone or both of these probabilities, as shown in Example 7.1. The LOPA analystshould take care to identify such links.

Example 7.1• If the initiating event for a release in the operating area is an operator

opening a bleed valve in the area, Pperson present is 1 because a person isalways present for the scenario to begin.

• If the initiating event for a flammable release is a crane dropping a heatexchanger on a tank, Pignition is higher than it would be for a controlled,electrically classified area; the collision of the heat exchanger into thetank provides the release and an ignition source. Also the crane itselfmay be an ignition source. Pignition is 1 in either case.

• For pool fires, Pinjury may be a moderate to low probability. However, forflash fire, the likelihood of injury is high if someone is present. For toxicvapor, Pinjury depends on the vapor concentration, the duration of expo-sure and the ability of the person to move out of the cloud. The ability tomove out of the cloud depends on whether the person detects thevapor, the speed that the vapor incapacitates the person, and the avail-ability of escape routes. Several analysts use 0.5 for most Pinjury situations,and 1.0 for situations in which it is difficult to detect the vapor, or thevapor acts quickly, or escape routes are difficult to use.

The probability of ignition depends on how the release disperses and onthe location of ignition sources. An example decision tree is shown in Figure7.1. Other flammable effects are possible and the probabilities for each branchof the tree may be different for different situations. For the purposes of LOPA,a conservative estimate of the probability of ignition may be used for typicalsituations. For example, an organization may use


• 1.0 for releases caused by collision,• 1.0 for large releases close to fired equipment,• 0.5 for releases in general process areas,• 0.1 for releases in remote process areas, like a tank farm.

The different values for general and remote process areas are based onactivities in those areas. There is typically more electrical equipment in thegeneral process area and more opportunity for the electrical classification tobe compromised (such as a missing cover plate). A company can choose aconservative approach to determine the probabilities of Pinjury, Pperson present,

Pignition, or it can establish criteria for different categories for these three proba-bilities.

Alternately, a company can use a method such as the Risk Matrix Conse-quence Categorization Method described in Chapter 3 (Method 1). The condi-tional probabilities are included in the consequence lookup table (Table 3.1)and the risk matrix (Table 8.1).

Calculating Risk

If a risk index is the desired outcome, the frequency of the outcome of interestis multiplied by a factor related to the magnitude of the consequences

R f CkC

kC

k= × (7-6)


FIGURE 7.1. Example decision tree for probability of ignition for flammable vapor.Starting on the left, each branch shows the probability of the outcome. (If the releaseoccurs, the probability of immediate ignition is 0.1.)

where

RkC is the risk index of incident outcome of interest k, expressed as a

magnitude of consequences per unit time. Specific units will varydepending on the risk being estimated. Some examples mightinclude risk of fatality per year, number of fatalities per year, dol-lars of economic loss per month, pounds of pollutant released perday,

f kC is the frequency of the incident outcome of interest k, in inverse

time units, e.g., year–1, hour–1, etc.,

Ck is a specific measurement of the consequences of the incident out-come of interest k . Some measures of the consequences might bean individual fatality, number of fatalities, dollars of economicloss, pounds of release of a pollutant, number of people exposed toa specific concentration of an air pollutant. Ck might be expressedas a category.

Note that the consequence of the undesired outcome of interest k must beexpressed as a single number measure in order to use Eq. (7-6). If there are avariety of potential consequences or outcomes, the risk calculations are muchmore complex, and the methods discussed in Chapter 4 of the Guidelines forChemical Process Quantitative Risk Analysis, Second Edition (CCPS 2000a)should be considered.

Equations (7-1) to (7-7) can be used to calculate any desired singlenumber risk index. Examples include process safety, environmental, busi-ness impact, quality, etc. Note that risk is a function of the frequency of thescenario and the consequence severity. This book uses a risk index expressedas frequency of an outcome category, thus, the consequence portion of theequation is defined as a constant. The risk index for a category is thenexpressed as the frequency of that outcome category, such as, releases peryear, fires per year, injuries per year, fatalities per year, or consequence cate-gory per year.

Summing Up Frequencies For Multiple Scenarios

Some companies have geographic risk or personal risk criteria (See AppendixE for examples). To use such risk criteria for risk decision making in Chapter8, it is necessary to sum up the frequencies (as the risk indices) from all thescenarios that affect the geographic area or the people under consideration:

• in the same geographic area,• in the same process unit (e.g., several reactor trains),• affecting the same location of interest,• in the same consequence severity category (e.g., same material haz-

ards).


Each scenario should be evaluated individually, using Eq. (7-1), sincedifferent IPLs may apply to different scenarios, even if both scenariosresult in the same consequence. The frequency of the consequence can thenbe approximated, if fi are small, using

f f

f f f

CiC

i

I

C CIC

=

= + + +=

∑1

1 2 L (7-7)

where fiC is the frequency of the Cth consequence for the ith initiating event.

Suppose it is desired to estimate the risk from several scenarios in thesame geographic area, as shown in Figure 7.2. Note that each of the three sce-narios has a different release: from the column, shown by a dashed line; fromthe reactor, shown by a solid line; and from the tank, shown by a dotted line.These scenarios are not concurrent—they may occur at different times. First,the risk to an exposed individual should be calculated individually for eachscenario. Since the individual could be exposed to all three releases, the fre-


FIGURE 7.2. Multiple releases in same geographic area.

quency can then be totaled for all the scenarios of interest and the risk evalu-ated.

The analyst may encounter processes where the same consequenceresults from two or more initiating events. Some companies sum the frequen-cies of all the scenarios that give the same consequence (see Section 11.3).Note: many companies do not sum the individual scenario frequencies for thesame consequence, but rather choose the highest scenario frequency for thatconsequence (high risk initiating event–consequence pair). The company’sLOPA rules should specify which approach to take; the approach must beconsistent with company’s risk tolerance criteria.

The calculations of Eqs. (7-1)–(7-7) can be used as input for comparingcalculated risk to risk tolerance criteria for the decision-making methods inSection 8.3 including matrix and numerical criteria.

Calculations for High Initiating Event Frequency(High Demand Mode) Scenarios

Equation (7-1) is applicable to calculate the frequency of the consequence forscenarios in which the initiating event frequency is less than twice the test fre-quency—also called “low demand mode.” The initiating event frequency ismultiplied by the IPL PFDs.

“High demand mode” occurs when the challenge frequency to an IPL ishigher than twice the test frequency for the IPL (IEC 61511, Part 1; IEC 2001).For example, the IPL is tested once a year and there are more than 2 demandsper year. Using Eq. (7-1) results in an unreasonably high frequency for theconsequence, as explained in Appendix F. Instead, the frequency of conse-quence or frequency of challenge to the next IPL is given by

2 × (IPL test frequency, per year) × (IPL PFD). (7-8)

In other words, in Eq. (7-1) the terms for the initiating event frequencyand the first IPL PFD are replaced by the expression above. This approachprovides more realistic frequency results.

Another approach to high demand is a rule-based lookup tablefor initiating event frequency (not shown in this book) that limits the initiat-ing event frequency such that Eq. (7-1) gives appropriate frequencies.


CALCULATE EACH SCENARIO INDIVIDUALLY

An analyst may attempt to combine several initiating events that lead to the

same consequence in one calculation step. This calculation assumes that the

IPLs apply to each of the initiating events. Such a practice is not LOPA. The

authors strongly recommend that each scenario (initiating event–consequence

pair) be evaluated separately with its respective IPLs.

7.3. Look-up Table Determination of Risk or Frequency

The scenario risk or frequency may be determined qualitatively using look-up tables. Typically, such matrices also include a target (or required) numberof IPLs for different risk categories. Some matrices may include the frequencyof the consequence. Categories on the matrix may include

• the initiating event frequency for the scenario,• the severity of the consequence for the scenario,• the required number of IPLs (or IPL credits) for a given risk category

(the risk category is given by the initiating event frequency and theconsequence severity for the scenario),

• the frequency of the consequence.

The calculations from the equations in this chapter and the risk tolerancecriteria are embedded in the look-up table. Table 8.2 is presented in Chapter 8as part of the risk decision making. As the method is usually practiced, a com-panion look-up table shows the IPL credits for typical IPLs (a sample IPLcredit table is shown in Table 7.1). During development of the method, theIPL credit is calculated from the PFD of the IPL (typical values are shown inTables 6.3, 6.4, and 6.5) using the relationship (consistent within this book):

1 IPL credit ≡ 1 × 10–2 PFD (7-9)

Two additional examples of this type of calculation are also given inGuidelines for Safe Automation of Chemical Processes (CCPS 1993b, page 313) andISA S84.01 Sections A.3.1 and A.3.2 (ISA 1996), specifically, for estimating theSIL (safety integrity level) for a SIF (safety instrument function) based on thenumber of other IPLs. Such matrices could be adapted for the general IPL cal-culation. Typically, the matrix and calibration for the categories are devel-oped for a corporation as discussed in Chapter 9.

An example based on the Safe Automation book is shown in Figure 7.3. Inthe experience of the authors, such tables are difficult to use and tedious to


HIGH DEMAND MODE

The challenge frequency to an IPL is higher than twice the test frequency for

the IPL.

The frequency of consequence or frequency of challenge to the next IPL is

• Failure frequency of the IPL, or

more simply, for the first IPL,

• 2 × (IPL test frequency, per year) × (IPL PFD)

7.3. Look-up Table Determination of Risk or Frequency 123

TABLE 7.1Sample IPL Credits Table

IPL

(subset ofTables 6.3, 6.4, 6.5) PFD

Number of IPLCredits

(for the methodillustrated in this

book)

Dike 1 × 10–2–1 × 10–3 1–1.5

Flame/detonation arrestors 1 × 10–2–1 × 10–3 1–1.5

Relief valve 1 × 10–1–1 × 10–5 0.5–2.5

Rupture disc 1 × 10–1–1 × 10–5 0.5–2.5

SIF SIL 1 1 × 10–1–1 × 10–2 0.5–1

SIF SIL 2 1 × 10–2–1 × 10–3 1–1.5

SIF SIL 3 1 × 10–3–1 × 10–4 1.5–2

Human action with 10 minutes response time 1.0–1 × 10–1 0–0.5

FIGURE 7.3. SIL for SIF [from Guidelines for Safe Automation of Chemical Processes(CCPS 1993b)].

document. We recommend using the other calculation and risk decision-making tools illustrated in this book.

7.4. Calculation of Risk or Frequency with IntegerLogarithms

As a first approximation, the scenario risk or frequency may be calculatedusing the absolute value of the logarithm of the initiating event frequency andthe IPL PFDs. An initiating event frequency of 1 × 10–2/yr becomes 2 and aPFD of 1 × 10–2 becomes 2.

Cautions:

• The number format must have the structure of a one-digit integerbefore the decimal, for example, 0.1 × 10–3 must be converted to 1 × 10–4.

• The maximum frequency that can be used in this method (as illustratedhere) is 1/yr , logarithm = 0.

The logarithm is rounded to the nearest integer, thus, 3 × 10–2/yr isexpressed as 2 and 4 × 10–2/yr is expressed as 1. For simplification, someorganizations take the conservative approach of rounding any coefficientlarger than 1 to the next order of magnitude, thus 2 × 10–2 becomes 1. Equation(7-1) would be expressed as

F F PiC

i ij

j

J

= + ′=

∑I

1

(7-10)

where

FiC is the frequency exponent for consequence C of scenario i,

FiI is the absolute value of the log of the frequency of initiating event i,

and

′Pij is the absolute value of the log of the PFD of the probability of fail-ure on demand of the jth IPL that protects against scenario i.

The greater the frequency exponent calculated by Eq. (7-10), the lower thefrequency. Therefore, a frequency exponent of Fi

C = 1 represents a frequencyof 1 × 10–1 /yr; a frequency exponent of Fi

C = 4 represents a frequency of 1 ×10–4 /yr.

Equations (7-2) and (7-3) can be expressed in a similar fashion. Thismethod offers simplicity of calculation with some loss of precision. The look-up tables discussed in Section 7.3 give the same order of conservatism as usedin the rounding of the integer logarithm method. This approach is similar tothat described in the CCPS Safe Automation book (CCPS 1993b).



In the continuing examples, consequence categories were determined as

• release, by the Risk Matrix Consequence Categorization Method(Method 1 from Chapter 3), or

• fire (business loss),• injury, where the severity is taken as fatality, by the Fatality Frequency

Criteria Method (Method 3 from Chapter 3).

Frequency of fire is calculated below.

Continuing Example 1: Hexane Surge Tank Overflow—Numerical Methods

Consider the hexane surge tank problem introduced in Chapter 2. We cannow calculate the frequencies of the mitigated scenarios with the existingIPLs in place, using Eq. (7-1). Note that consequence frequencies could be cal-culated for release, fire, exposure, and injury (in these examples, the severityof the injury is fatality).

Scenario 1a: Hexane Surge Tank Overflow—Spill Not Contained bythe DikeFrequency of consequences outside the dike due to LIC failure.

• Release [Risk Matrix Consequence Categorization Method (Method 1from Chapter 3)], from Eq. (7-1),

f f1 1arelease

aLIC fails

dikePFD= ×

f 1arelease = (1 × 10–1/yr) × (1 × 10–2) = 1 × 10–3/yr

• Fire, using Eq. (7-2):

f f P1 1afire

aLIC fails

dikeignitionPFD= × ×

f 1afire = (1 × 10–1/yr) × (1 × 10–2 ) × (1.0) = 1 × 10–3/yr

• Fatality due to fire [Fatality Frequency Criteria Method (Method 3from Chapter 3)], using Eq. (7-4),

f f P P1afire fatality

aLIC fails

dikeignition pPFD= × × ×1

erson fatality×P

f 1afire fatality

= (1 × 10–1/yr) × (1 × 10–2 ) × (1.0) × (0.5) × (0.5)

= 2.5 × 10–4/yr, rounded to 2 × 10–4/yr


Scenario 1b: Hexane Surge Tank Overflow—Spill Contained by theDikeFrequency of consequences inside the dike due to LIC failure:

• Release [Risk Matrix Consequence Categorization Method (Method 1from Chapter 3)]. For this case the dike is not considered as an IPL, sothe consequence frequency is equal to the initiating event frequency.

f 1brelease= (1 × 10–1/yr LIC fails) = 1 × 10–1/yr

• Fire, using Eq. (7-2),

f f P1 1bfire

bLIC fails ignition= ×

f 1bfire= (1 × 10–1/yr) × (0.1) = 1 × 10–2/yr

• Fatalitydue to fire [Fatality Frequency Criteria Method (Method 3 fromChapter 3)]. Equation (7-4) is used:

f f P P P1bfire fatality

bLIC fails ignition person f= × × ×1

atality

f 1bfire fatality

= (1 × 10–1/yr) × (0.1) × (0.1) × (0.5) = 5 × 10–4/yr

Chapter 8 will discuss decision making and adding additional protectionlayers.

Some companies would not perform the LOPA calculations for releaseleading to fatality from fire within the dike scenario. Their experience isthat the probability of ignition and the probability that a person is insidethe dike gives a risk that meets the risk tolerance criteria. Other companieswould do the calculations and compare against risk tolerance criteria inChapter 8.

Continuing Example 2: Hexane Storage Tank Overflow—Numerical Methods

For the hexane storage tank introduced in Chapter 2, the frequency of the con-sequences can be calculated with the existing IPLs in place, using Eq. (7-2).Note that consequence frequencies could be calculated for release, fire, expo-sure, and injury (in these examples, the severity of the injury is fatality).

Scenario 2a: Hexane Storage Tank Overflow—Spill Not Contained bythe DikeFrequency of several consequences outside the dike due to inventory controlfailure:


• Release [Risk Matrix Consequence Categorization Method (Method 1from Chapter 3)]. For this case there are two IPLs: the operator and thedike. Equation (7-1) is used:

f f2 2arelease

ainventory control fails

operatorPFD= × checks LI dikePFD×

f 2arelease = (1 /yr) × (1 × 10–1 ) × (1 × 10–2 ) = 1 × 10–3/yr

• Fire. Equation (7-2) is used:

f f2 2afire


operator chePFD= × cks LI dikeignitionPFD× ×P

f 2afire = (1 /yr) × (1 × 10–1 ) × (1 × 10–2 ) × (1.0) = 1 × 10–3/yr

• Fatality due to fire [Fatality Frequency Criteria Method (Method 3from Chapter 3)]. Equation (7-4) is used

f f2 2afire fatality


opePFD= × rator checks LI dike

ignition person fatalit

PFD×

× × ×P P P y

f 2afire fatality

= (1 /yr) × (1 × 10–1 ) × (1 × 10–2 ) × (1.0) × (0.5) × (0.5)

= 2.5 × 10–4/yr, rounded to 2 × 10–4/yr.

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

Frequency of several consequences inside the dike due to inventory con-trol failure:

• Release [Risk Matrix Consequence Categorization Method (Method 1from Chapter 3)]. Equation (7-1) is used:

f f2 2brelease

binventory control fails

operatorPFD= × checks LI

f 2 brelease = (1 /yr) × (1 × 10–1 ) = 1 × 10–1/yr

• Fire. Equation 7-2 is used:

f f2 2bfire


operator chePFD= × cks LIignition×P

f 2 bfire = (1 /yr) × (1 × 10–1 ) × (0.1) = 1 × 10–2/yr

• Fatality due to fire [Fatality Frequency Criteria Method (Method 3from Chapter 3)]. Equation (7-4) is used:

f f2 2bfire fatality


opePFD= × rator checks LI

ignition person fatality× × ×P P P

f 2 bfire fatality

= (1 /yr) × (1 × 10–1 ) × (0.1) × (0.1) × (0.5) = 5 × 10–4/yr


Continuing Example 1: Hexane Surge Tank Overflow—Numberof IPLs Credits Method

For the Number of IPLs Credits calculation method, the consequence severitywas classified by the Fatality Frequency Criteria Method (Method 3 fromChapter 3). Unlike other methods discussed in this chapter, the IPL PFDs arenot used in the calculations here. Instead, the adjusted initiating event fre-quency is used as input to the lookup Table 8.2.

Scenario 1a: Hexane Surge Tank Overflow—Spill Not Contained bythe DikeTo use the number of IPLs method, the initiating event frequency of 1 × 10–1/yris adjusted by the probability of ignition, the probability of a person present,and the probability of fatality for a fire outside the dike:

adjustedI ignition person present injury (7-11)

Adjusted Initiating Event Frequency = (1 × 10–1/yr) × (1.0) × (0.5) × (0.5)= 2.5 × 10–2 /yr, rounded to 2 × 10–2/yr

The adjusted initiating event frequency and the number of existing IPLsidentified in Chapter 6 will be used in the decision making for this example inSection 8.8. The IPL PFD calculations are embedded in Table 8.2.

Scenario 1b: Hexane Surge Tank Overflow—Spill Contained by theDikeSimilar adjustments are made to the initiating event frequency for a fireinside the dike and resultant fatality:

adjustedI ignition person present injury

f adjustedI = (1 × 10–1/yr) × (0.1) × (0.1) × (0.5) = 5 × 10–4 /yr


Continuing Example 1: Hexane Surge Tank Overflow—IntegerLogarithm Method

For the Integer Logarithm Method calculation method, the consequenceseverity was classified by the Risk Matrix Consequence CategorizationMethod (Method 1 from Chapter 3).


f =SSYMB O L F O R I N I T I A T I N G ×P ×P ×P

f ={sELE C T I O N ×P ×P ×Pf I

f I

Scenario 1a: Hexane Surge Tank Overflow—Spill Not Contained bythe DikeThe frequency of the initiating event is 1 × 10–1/yr that the LIC fails; the abso-lute value of the log is 1. The PFD of the dike is 1 × 10–2. The absolute value ofthe log of the PFD is 2. The frequency exponent of the mitigated consequenceis given by 1 + 2 = 3, equivalent to 1 × 10–3 /yr for release outside the dike.

Continuing Example 2: Hexane Storage Tank Overflow—Number of IPLs Credits Method

For the Number of IPLs calculation method, the consequence severity was clas-sified by the Fatality Frequency Criteria Method (Method 3 from Chapter 3).

Scenario 2a: Hexane Storage Tank Overflow—Spill Not Contained bythe DikeTo use the number of IPLs method, the initiating event frequency of 1/yr isadjusted by the probability of ignition, the probability of a person present,and the probability of fatality for a fire outside the dike:

f f P P PiadjustedI I ignition person present injury= × × ×

f adjustedI = (1/yr) × (1.0) × (0.5) × (0.5)

= 2.5 × 10–1/yr, rounded to 2 × 10–1/yr


Scenario 2b: Hexane Storage Tank Overflow—Spill Contained by theDikeSimilar adjustments are made to the initiating event frequency for a fireinside the dike:

f f P P PiadjustedI I ignition person present injury= × × ×

f adjustedI = (1/yr) × (0.1 ignition) × (0.1 person present ) × (0.5 injury) = 5 × 10–3 /yr

The adjusted initiating event frequency and the number of existing IPLsidentified in Chapter 6 will be used in the decision making for this example inSection 8.8. The calculations are embedded in Table 8.2.

Continuing Example 2: Hexane Storage Tank Overflow—IntegerLogarithm Method

For the Integer Logarithm Method calculation method, the consequenceseverity was classified by the Risk Matrix Consequence CategorizationMethod (Method 1 from Chapter 3).


Scenario 2a: Hexane Storage Tank Overflow—Spill Not Contained bythe DikeThe frequency of the initiating event is 1/yr that the inventory control fails;the log is 0. The PFD of the operator checking the LIs is 1 × 10–1 and the PFD ofthe dike is 1 × 10–2. The absolute value of the log for each PFD is 1 and 2,respectively. The frequency exponent of the mitigated consequence is givenby 0 + 1 + 2 = 3, equivalent to 1 × 10–3 /yr for release outside the dike.

7.6. Link Forward

The scenario frequencies or risks determined in Chapter 7 are used as a start-ing point for the decision-making process in Chapter 8.


8

Using LOPA to MakeRisk Decisions

8.1. Purpose

This chapter presents approaches for using the calculated results from Chap-ter 7 as input in making risk decisions. All of the methods described in thischapter can be used to make decisions for reaching risk levels that are “as lowas reasonably practicable” (ALARP), also defined as the risk level that is toler-able to the organization. Several methods are described using numerical cri-teria and one which employs expert judgment by an analyst (the lattermethod is not recommended by the authors, but has been used in industryand is presented for completeness). The methods are compared, and exam-ples are given. This chapter addresses Step 6 of the LOPA method describedin Chapter 2.

For all of the approaches, cost–benefit analysis may be an additional toolto help make the final risk-reduction decisions.

8.2. Introduction

Decision making takes place after the scenarios have been fully developedand the existing risk has been calculated, as described in previous chapters.At the end of any study, whether qualitative or quantitative, the decisionsregarding risk normally fall into one of three general categories:

1. Manage the residual risk—continue the management systems thatmaintain the risk at its current (presumably tolerable) level.

131

2. Modify (mitigate) the risk to make it tolerable.3. Abandon the risk (businesses, process, etc.) because it is too high.

Decisions to abandon operations are normally made as a result of otherstudies such as quantitative risk assessment (CPQRA). LOPA, on the otherhand, is usually applied to determine if a scenario is within the risk tolerancecriteria or if its risk must be reduced.

Three basic types of risk judgment are used in conjunction with LOPA:

1. The predominant method is to compare the calculated risk with a pre-determined risk tolerance criteria through use of various methods,which will be discussed below.

2. The second type is expert judgment by a qualified risk analyst, whichas noted above, is not recommended by the authors but is included forcompleteness.

3. The third type is relative comparison among competing alternativesfor risk reduction, using either of the methods described above.

Cost–benefit analysis is often also used to compare the value of compet-ing options. This technique supplements the basic risk judgment approaches.

Several methods for risk judgment are presented in this chapter. A briefdescription of each method is provided, with a discussion of the advantagesand disadvantages of each method. Examples are provided for each method.Three of the methods are applied to the ongoing example problems. It is alsopossible to combine features of the different methods in order to facilitate thedecision-making process.

An important factor in the use of any risk decision method is judgment.Use of judgment requires a good understanding of the process being ana-lyzed and the relative effectiveness of the various protective layers foundduring the analysis (IPL development). To make quality decisions usingjudgment, the organization should be aware of, and understand, the potentialresponses to chemical industry accidents from various groups. Consider-ations that may cause one to adjust previously defined criteria for specific sit-uations include:

• Community Response—The community may or may not be knowledge-able of the potential hazards or the consequences of accidents, or may beparticularly sensitive to certain kinds of events, such as chlorine ormethyl isocyanate releases. The community may or may not be properlyprepared with emergency plans and organizations to deal with a haz-ardous release if it occurs. These may vary widely from location to loca-tion, depending on history, community proximity, and other factors.

• Management Reaction—The site and business management should gen-erally be knowledgeable and aware of the hazards associated with the

132 8. Using LOPA to Make Risk Decisions

materials and processes at the site, but may not be intimately familiarwith process details.

• Regulatory Reaction—Some materials are high profile such as chlorine,methyl isocyanate, or hydrofluoric acid. Regulatory interest will behigh in the case of release of these materials.

• Consistency with Other Practices—Finally, the decision-making processshould be consistent with good engineering practices in the industry.

For further discussion of such factors, refer to the Chapter 9 discussion oncriteria development.

Examples of Criteria

Development of specific risk tolerance criteria will be discussed in Chapter 9.It is sufficient to note here that risk tolerance criteria fall into four basic cate-gories:

1. Criteria that place risk characterizations per scenario in matrices, withparameters of frequency and consequence as guides.

2. Criteria that specify a maximum allowable risk (e.g., fatality or dollarloss) per scenario.

3. Criteria that specify a minimum number of IPLs for any specific sce-nario.

4. Criteria that specify a maximum cumulative risk for a process or geo-graphic area (see Section 8.7).

Each of these will be discussed further in Sections 8.3–8.7.

8.3. Comparing Calculated Risk to Scenario RiskTolerance Criteria

For this type of risk decision making, the calculated risk from Chapter 7 iscompared to a risk criteria that relates to some measure of maximum risk perscenario that the company will tolerate—this is discussed further in Section9.6. This can take the form of a matrix, a maximum tolerable risk per scenario,or a requirement for a specific number of IPLs, given the frequency of the ini-tiating event and the severity of the consequences. If the calculated risk is less

8.3. Comparing Calculated Risk to Scenario Risk Tolerance Criteria 133

Many companies have found a benefit in the objective criteria for risk

categories when using LOPA for making risk decisions. The LOPA rules and well-

defined criteria reduce subjectivity in the decision-making process, leading to

faster, more defensible, and more consistent decisions.

than the risk criteria, the scenario is judged to have a sufficiently low risk orhave sufficient mitigation (or IPLs), that no further mitigation is needed. If,however, the calculated risk exceeds the risk criteria, the scenario is judged torequire additional (or stronger) mitigation (IPLs), or to require changes inthe design to make the process inherently safer, thus reducing scenariofrequency or consequence, or (preferably) eliminating the scenario. Addi-tional analysis, up to and including CPQRA, may be required when:

• “gray” areas exist in the risk criteria, or• the indicated mitigation or changes are highly complex or costly.

Matrix Methods

Risk matrices are a generalized method of visually showing the frequency tol-erable for a scenario based on the consequence severity (Chapter 3) and thescenario frequency (Chapter 7). An example is presented in Table 3.1 andTable 8.1. In this matrix, each cell is associated with the degree of risk reduc-tion required for a scenario which falls into that cell. For instance,

• the “very low” zone (cells on the lower left) may require no furtheraction (this may be the ALARP level noted earlier),

• the “low” zone (cells along the diagonal from upper left to lower right)may require management judgment to ascertain whether further miti-gation is needed (this is also the zone at which the risk is at the “toler-ated” level, but also requires analysis to identify any low cost or easilyimplemented reduction measures),

• the “moderate” zone (cells just above the diagonal) may require fur-ther mitigation at the next opportunity, and

• the “high” zone (cells in the upper right) may require immediate miti-gation or shutdown of the process.

It may be necessary to use a different matrix for different sites to recog-nize the proximity of the site boundary and off-site population. The embed-ded risk tolerance criteria may also include consideration of business risk aswell as injury and fatality. The matrix method may be the most widely usedapproach for making risk decisions with LOPA.

Numerical Criteria Method (Maximum Tolerable Riskper Scenario)

Some companies have developed risk criteria based on a maximum tolerablerisk per scenario, based on a variety of consequence categories. For instance,one organization may establish as its criteria a maximum frequency (per yearor per 1000 hours) of a single fatality. This may be derived from such criteria


13

5

TABLE 8.1 Risk Matrix with Individual Action Zones (see Table 3.1 for Consequence Category descriptions)

as maximum individual risk to employees (or to contractors or persons out-side the plant). Others may choose frequency of releases of hazardous materi-als, fires, or property damage dollar loss.

Number of IPL Credits

Some companies have embedded the tolerable risk criteria in tables whichspecify the number of IPL credits for scenarios of certain consequence levelsand frequency. Tolerable criteria are not shown explicitly. Typically, tabularvalues are provided for the number of IPLs required for ranges of initiatingevent frequency and for IPL credit values for various kinds of protectionlayers. See Table 8.2 for an example of the first type of table. As noted on thetable, the method typically assigns a value of 1 IPL credit to a layer of protec-tion with a PFD of 1 × 10–2, and so on. The values for these credits are nor-mally limited to multiples of whole and half credits, and can be derived fromthe IPL Tables 6.3, 6.4, and 6.5.

Table 8.2 applies to scenarios of a predefined consequence level. Forinstance, the potential consequence of interest for this table could be one fatal-ity or multiple lost-time injuries. Note also that for this method, adjustment fac-tors such as the probability of ignition and time at risk, among others, areincluded as well as calculation of the initiating event frequency. More severeconsequence categories (e.g., multiple fatalities, facility siting or off-siteimpact) might have similar tables with increased IPL requirements for each ini-tiating event frequency range. Also, similar tables can be developed for othertypes of consequences, such as production loss or environmental impact.


TABLE 8.2IPL Credit Requirements

Number of IPL Credits Required*

Adjusted Initiating Event Frequency**

ConsequenceCategory IV

One Fatality

ConsequenceCategory V

Multiple Fatalities

Frequency ≥ 1 × 10–2 2 2.5

1 × 10–2 > Frequency ≥1 × 10–3 1.5 2

1 × 10–3 > Frequency ≥1 × 10–4 1 1.5

1 × 10–4 > Frequency ≥1 × 10–6 0.5 1

1 × 10–6 > Frequency 0 0.5

*Adjusted Initiating Event Frequency includes adjustments to the initiating event frequency forPignition Pperson present and Pfatality

**An IPL Credit is defined as a reduction in event frequency of 1 × 10–2.

8.4. Expert Judgment

Expert judgment is needed when specific risk tolerance criteria are not avail-able or not easily established due to the type of process being analyzed or thehazards involved.

The PHA team may use LOPA techniques to determine the scenarios andIPLs, and make frequency calculations. However, decisions regarding the needfor additional IPLs, and the nature of such additional protection, will usuallybe based on the recommendations of a risk evaluation expert. The expertwould compare the IPLs and other features of the scenario to industry practice,similar processes, or other points of reference in his or her experience.

It should be noted that this should not be a “Lone Ranger” approach. Theexpert may be a member of a PHA team, which would include normal repre-sentation. As with any decision making involving process hazards, decisionsshould result from group consultations, not from one or two people operat-ing in isolation.

8.5. Using Cost–Benefit to Compare Alternatives

Cost–benefit analysis compares the cost of the avoided consequence at its fre-quency versus the cost of the IPL improvements to reduce the risk (Fryman,1996). Cost–benefit analyses can be applied in all of the decision-makingmethods. For example, it is common to identify more than one potential IPLto reduce the risk of a scenario. Cost–benefit analysis is generally the methodused to select the IPLs for risk reduction from among the candidate IPLs. Forfurther information see “Tools for Making Acute Risk Decisions with ChemicalProcess Safety Applications” (CCPS 1995c), and Handling Uncertainty: ManagingRisk (CCPS, 2001).

8.6. Comparison of Approaches, Pros and Cons

This section gives advantages and disadvantages for several methods of riskdecision making.

Matrix Method

The following are some advantages of the Matrix method for risk decisionmaking:

8.6. Comparison of Approaches, Pros and Cons 137

The authors do not recommend expert judgment alone for most risk decisions,

but it is included for completeness. It is preferred to make risk decisions with

established criteria.

• This method provides a clear delineation of the risk associated with ascenario. The risk reduction required can be demonstrated visuallyand numerically and various risk reduction decision areas are easilydescribed.

• The actual risk tolerance numerical values used by an organization canbe embedded in the matrix, for companies that prefer not to use explicitcriteria; disproportionately lower risk tolerance criteria for high conse-quence events can be included.

• The precision of many risk matrix methods (generally to an order ofmagnitude) makes them well suited for use with the LOPA methodwith its use of conservative and simplifying assumptions.

• It is easy to make decisions since only one scenario at a time is involvedin the risk decision.

The disadvantage of using a matrix method:

• The development of a useful matrix (see Table 8.1) with its associatedconsequence matrix (see Chapter 3) requires significant resources andtechnical expertise. In addition, the development of the criteria to beused to assess risk tolerance can be difficult for some organizations. Inusing this matrix, analysts must fully understand its assumptions andimplications.

Numerical Criteria Method

The advantages of the numerical criteria method:

• Per scenario criteria are easy to understand.• Per scenario criteria are consistent for a given material across a specific

site.• It is easy to make decisions since only one scenario at a time is involved

in the risk decision.

The disadvantages of the numerical criteria method:

• There may be a temptation to make too fine or too general a judgmentin estimating the ignition probability, the probability of injury, and theprobability of a person present, and to place too great a confidence inthat judgment. This is also the reason for establishing conservativeguidelines for such probabilities, to minimize this potential weakness.

• Adjusting frequencies for enabling conditions and the ignition proba-bility, the probability of injury, and the probability of a person presentadds complexity.


Number of IPL Credits Method

The advantages of the number of IPL credits method:

• As with the matrix method, the boundaries for frequency and severitycategories are easily identified.

• It is easy to use.• The risk tolerance criteria can be imbedded, for companies that prefer

not to use explicit criteria.• It is easy to make decisions since only one scenario at a time is involved

in the risk decision.

The disadvantages of the number of IPL credits method:

• The gross assumptions made for crediting the mitigation methods mayresult in requirements for more IPLs than another LOPA method orthan FTA.

• There may be a temptation to make too fine or too general a judgmentin estimating the ignition probability, the probability of injury, and theprobability of a person present, and to place too great a confidence inthat judgment.

8.7. Cumulative Risk Criteria versus Scenario Criteria

Some companies have developed risk criteria based on a maximum tolerablerisk per unit, per geographic area, or cumulative risk per person (i.e., risk to aspecific worker is less than x for the sum of all scenarios that could affect thatperson). Evaluating the total risk to a populated building against such acumulative risk criterion may be used in facility siting decisions.

As noted in Section 8.3, the criteria may arise from a single risk tolerancetarget, such as maximum individual risk to employees (or to contractors orpersons outside the plant). The criteria can also be based on a sliding scalethat represents less risk tolerance for multiple-impact events than for thosewhich might impact only a single individual. If there is a single risk tolerancecriterion for cumulative risk, then single scenario risk criteria can be derivedusing Equation 8-1:

C single scenario = (Risk Criteria)/(No. of Scenarios) (8-1)

If the risk tolerance criteria have a sliding scale for multiple impactevents, determination of single scenario risk criteria is more complex, andwill not be discussed here. Refer to Chapter 9 for further guidance.

When using cumulative risk tolerance criteria, it is sometimes more diffi-cult to assess each individual scenario, since more scenarios imply lower tol-erable risk for each scenario. The number of scenarios may not be known at

8.7. Cumulative Risk Criteria versus Scenario Criteria 139

the beginning of the assessment. Decision making may be more difficult sincetotal risk from many scenarios is involved in the risk decision.

Example 8.1

A site study found that 10 scenarios resulted in fatal consequences for the

unit control building. They added the mitigated event frequencies for the

10 scenarios and compared the total with the tolerable risk criteria for fatal-

ities to a single employee.

As noted above, another approach is to develop risk tolerance criteria forconsequences other than injuries. For instance, a company might use a crite-rion representing maximum allowable risk of a release of flammable or toxicmaterial above a certain threshold, one representing maximum allowable riskof a large fire, and yet another for injury or fatality to employees or personsoutside the plant. Typically, these will be in decreasing tolerable frequency inthe order listed above.


The continuing examples will demonstrate three of the risk decision processespracticed by the chemical industry. Each of the decision-making processes hasdifferent risk tolerance criteria, either stated explicitly as maximum tolerablefrequency for a consequence of a given severity, or implicitly included in therequired actions from the decision-making process. Thus, the actions maydiffer somewhat among the decision-making processes.

In the continuing example problem, four scenarios were identified, asdescribed in Chapter 7. Summary sheets for Scenarios 1a and 2a using thenumerical criteria method are shown as Tables 8.3 and 8.4. Summary sheetsfor all the scenarios and several risk decision-making methods are shown inAppendix A.

Continuing Example 1: Hexane Surge Tank Overflow—Matrix Method

For the Matrix Method calculation method, the consequence severities wereclassified by the Risk Matrix Consequence Categorization Method (Method 1from Chapter 3).

Scenario 1a: Hexane Surge Tank Overflow—Spill Not Contained bythe DikeThe tank LIC fails, the overflow is not contained by the dike, and the spillignites. As shown in Table 3.1, the release of 40,000 lb of a flammable liquid


below its boiling point is consequence Category 4. As shown in Chapter 7, theas-is frequency of release outside the dike is 1 × 10–3 /yr. Looking up the con-sequence Category 4 and frequency 1 × 10–3/yr on the risk matrix in Table 8.1,action to reduce risk is “optional” and “alternatives should be evaluated.”

Scenario 1b: Hexane Surge Tank Overflow—Spill Contained by theDikeThe tank LIC fails and the overflow is contained by the dike. As discussed inChapter 3, a release contained in the dike is not considered to be a conse-quence of interest in this particular matrix method.

Continuing Example 2: Hexane Storage Tank Overflow—MatrixMethod

For the Matrix Method calculation method, the consequence severities wereclassified by the Risk Matrix Consequence Categorization Method (Method 1from Chapter 3).

Scenario 2a: Hexane Storage Tank Overflow—Spill Not Contained bythe DikeFailure of the inventory control system results in storage tank overfill, thespill is not contained by the dike, and subsequently ignites. As shown inTable 3.1, the release of 40,000 lb of a flammable liquid below its boiling pointis Category 4. As shown in Chapter 7, the as-is frequency of release outsidethe dike is 1 × 10–3/yr. Looking up the consequence Category 4 and frequency1 × 10–3/yr on the risk matrix in Table 8.1, action to reduce risk is “optional”and “alternatives should be evaluated.”

Scenario 2b: Hexane Storage Tank Overflow—Spill Contained by theDikeInventory control failure results in storage tank overfill and the hexane is con-tained by the dike. As discussed in Chapter 3, a release contained in the dikeis not considered to be a consequence of interest here.

Decision Process

In each scenario above, the next step is to determine if risk reduction actionsare needed using the risk matrix. The comparison of the existing risk to thecompany’s risk tolerance criteria is implicit in the risk matrix. Scenarios 1band 2b require no action since a spill contained by the dike is not consideredto be a consequence of interest by this method. For Scenarios 1a and 2a therisk matrix says action is optional and alternatives should be evaluated. Theteam explores possible alternatives to reduce risk and decides to install an


independent SIF (safety instrumented function, or interlock) with PFD =1 × 10–2 to detect and prevent overflow for scenarios 1a and 2a. The selectionof the SIF is based on risk reduction, feasibility, and cost. For scenario 1a, theSIF reduces the frequency of release from 1 × 10–3 /yr to 1 × 10–5 /yr. For sce-nario 2a, the SIF also reduces the frequency of release from 1 × 10–3 /yr to1 × 10–5 /yr. The risk matrix of Table 8.1, for a Category 4 consequence releasefrequencies of 1 × 10–5 /yr, gives “No further action.” These frequencies forthis consequence severity meet the implicit tolerable risk criteria. (Note thatthe SIF will also reduce the frequency of the other two scenarios for releasecontained within the dike, but no decisions are required for those scenarios.)

Continuing Example 1: Hexane Surge Tank Overflow—Numerical Criteria

The consequence severities were classified using the Fatality Frequency Cri-teria Method (Method 3 from Chapter 3).

Scenario 1a: Hexane Surge Tank Overflow—Spill Not Contained bythe DikeThe tank LIC fails, the overflow is not contained by the dike, and the spillspreads and eventually ignites. As shown in Chapter 7, the as-is frequency offire outside the dike is 1 × 10–3 /yr, and the frequency at which this scenarioresults in a fatal injury is 2 × 10–4 /yr.

Scenario 1b: Hexane Surge Tank Overflow—Spill Contained by theDikeThe tank LIC fails, the overflow is contained by the dike, and the spill ignites.As shown in Chapter 7, the as-is frequency of fire inside the dike is 1 × 10–2/yr,and the frequency at which this scenario results in a fatal injury is 5 × 10–4/yr.

Continuing Example 2: Hexane Storage Tank Overflow—Numerical Criteria


Scenario 2a: Hexane Storage Tank Overflow—Spill Not Contained bythe DikeFailure of the inventory control system results in storage tank overflow, thespill is not contained by the dike, and subsequently ignites. As shown inChapter 7, the as-is frequency of fire outside the dike is 1 × 10–3 /yr, and thefrequency at which this scenario results in a fatal injury is 2 × 10–4 /yr.


Scenario 2b: Hexane Storage Tank Overflow—Spill Contained by theDikeInventory control failure results in storage tank overfill, the hexane is con-tained by the dike, and subsequently ignites. As shown in Chapter 7, the as-isfrequency of fire inside the dike is 1 × 10–2/yr, and the frequency at which thisscenario results in a fatal injury is 5 × 10–4/yr.

Decision Process

For each scenario above, the next step is to compare the existing risk to thecompany’s risk tolerance criteria. For the examples, the following have beenadopted

• Maximum tolerable risk of a serious fire = 1 × 10–4/yr• Maximum tolerable risk of a fatal injury = 1 × 10–5/yr

The team then compares the existing risk of the four scenarios to the risktolerance criteria. None of the scenarios meet the criteria for a fire, nor do anyof the scenarios meet the criteria for a fatal injury. Therefore, additional miti-gation is required for all four of the scenarios. Several options are available tothe team, including addition of one or more BPCS controls (see Approach B,Chapter 6 and Chapter 11), addition of administrative controls, and/or addi-tion of SIF (see Approach A, Chapter 6). Addition of a BPCS control with afailure rate of 1 × 10–1/yr results in scenario 2a meeting the risk tolerance cri-teria for a serious fire, but would also introduce an element of common causefailure, due to all of the BPCS instruments relying on a single logic solver. Theresult would also not meet the risk tolerance criteria for a fatal injury. Addi-tion of administrative controls would have similar effects, since an adminis-trative control typically has a PFD of about 1 × 10–1. This would also involvesome common cause considerations because of the limited number of person-nel available to carry out the administrative controls. To meet the criteria forfatality for scenarios 1a and 1b, the PFD of the added IPL would need to be 4 ×10–2 and 2 × 10–2, respectively. An SIF (interlock) design is available for PFD of1 × 10–2. Therefore, the team recommends installation of an independent SIFof PFD = 1 × 10–2 for mitigation of all four scenarios (see Figures 8.1 and 8.2).This results in mitigated final frequencies of:

1a. f 1afire = (1 × 10–3 /yr) × (1 × 10–2 SIF PFD) = 1 × 10–5/yr

f 1afatality

= (2 × 10–4 /yr) × (1 × 10–2 SIF PFD) = 2 × 10–6/yr

1b. f 1bfire = (1 × 10–2 /yr) × (1 × 10–2 SIF PFD) = 1 × 10–4/yr

f 1bfatality

= (5 × 10–4 /yr) × (1 × 10–2 SIF PFD) = 5 × 10–6/yr


2a. f 2afire = (1 × 10–3 /yr) × (1 × 10–2 SIF PFD) = 1 × 10–5/yr

f 2afatality

= (2 × 10–4/yr) × (1 × 10–2 SIF PFD) = 2 × 10–6/yr

2b. f 2 bfire = (1 × 10–2 /yr) × (1 × 10–2 SIF PFD) = 1 × 10–4/yr

f 2 bfatality

= (5 × 10–4 /yr) × (1 × 10–2 SIF PFD) = 5 × 10–6/yr

It should be noted that there are other possible mitigation methods thatwill reduce the scenarios to below the risk tolerance criteria, but most involvesome degree of common cause failure or additional cost. In other cases, it maybe appropriate to pursue such alternatives, particularly if they drive the sce-narios in the direction of inherent safety or consequence reduction.

Continuing Example 1: Hexane Surge Tank Overflow—Number of IPL Credits Method


Scenario 1a: Hexane Surge Tank Overflow—Spill Not Contained bythe DikeThe tank LIC fails, the overflow is not contained by the dike, and the spillignites. As shown in Chapter 7, multiplying the initiating event frequency ofthis scenario (1 × 10–1/yr) by the adjustment factors (probability of ignition,probability of occupancy and probability of fatality) results in an adjusted ini-tiating event frequency of 2 × 10–2/yr.

Scenario 1b: Hexane Surge Tank Overflow—Spill Contained by theDikeThe tank LIC fails, the overflow is contained by the dike, and the spill ignites.As shown in Chapter 7, multiplying the initiating event frequency of this sce-nario (1 × 10–1/yr) by the adjustment factors (probability of ignition, probabil-ity of occupancy and probability of fatality) results in an adjusted initiatingevent frequency of 5 × 10–4/yr.

Continuing Example 2: Hexane Storage Tank Overflow–Number of IPL Credits Method


Scenario 2a: Hexane Storage Tank Overflow—Spill Not Contained bythe DikeFailure of the inventory control system results in storage tank overflow, thespill is not contained by the dike, and subsequently ignites. As shown in


Chapter 7, multiplying the initiating event frequency of this scenario (1/yr)by the adjustment factors (probability of ignition, probability of occupancyand probability of fatality) results in an adjusted initiating event frequency of2 × 10–1/yr.

Scenario 2b: Hexane Storage Tank Overflow—Spill Contained by theDikeInventory control failure results in storage tank overflow, the hexane is con-tained by the dike, and subsequently ignites. As shown in Chapter 7, multi-plying the initiating event frequency of this scenario (1/yr) by the adjustmentfactors (probability of ignition, probability of occupancy and probability offatality) results in an adjusted initiating event frequency of 5 × 10–3/yr.

Decision Process

The next step is to compare the initiating event frequencies for each scenarioabove to the values in Table 8.2 to determine the number of IPL creditsrequired. This results in the following requirements:

Scenario 1a. Requires 2 IPL creditsScenario 1b. Requires 1 IPL creditScenario 2a. Requires 2 IPL creditsScenario 2b. Requires 1.5 IPL credits

In three of these scenarios, there are already IPLs in place

• dike wall in Scenario 1a and Scenario 2a with PFD of 1 × 10–2, or 1 IPLcredit;

• operator procedure in Scenario 2a and Scenario 2b with PFD of 1 × 10–1,or 0.5 IPL credit,

This results in additional IPL requirements of

Scenario 1a. 2 – 1 = 1 additional credit requiredScenario 1b. 1 – 0 = 1 additional credits requiredScenario 2a. 2 –1 .5 = 0.5 additional credit requiredScenario 2b. 1.5 – 0.5 = 1 additional credit required

Taking all these factors into consideration, the team might recommend aSIF (interlock) with PFD of 1 × 10–2 (on the boundary between SIL 1 and SIL 2)for scenarios 1 and 2. Possible solutions for Continuing Examples 1 and 2 areshown in Figures 8.1 and 8.2, respectively. These figures are compared to theoriginal configuration shown in Figures 2.12 and 2.13. In both cases an inde-pendent high level sensor is added that activates an independent block valve.

Note the recommendations from this method and the matrix methoddiffer slightly from those of the numerical criteria method, reflecting differentapproaches and/or different risk tolerance criteria for different companies.


TABLE 8.3Summary Sheet for Continuing Example 1—Scenario 1a: Numerical Criteria Method [Con-

sequence Severity Using Fatality Frequency Criteria Method (Method 3 of Chapter 3)]

ScenarioNumber

1a

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



Release of hexane outside the dike dueto tank overflow and failure of dikewith potential for ignition and fatality.

Risk ToleranceCriteria(Category orFrequency)

Maximum Tolerable Risk of a SeriousFire

Maximum Tolerable Risk of a FatalInjury

<1 × 10–4

<1 × 10–5


Loop failure of BPCS LIC. (PFD fromTable 5.1)

1 × 10–1



Probability of ignition 1

Probability of personnel in affected area 0.5

Probability of fatal injury 0.5

Others N/A

Frequency of Unmitigated Consequence 2.5 × 10–2


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

SIF (to be added—see Actions) 1 × 10–2


Human action not an IPL as it dependsupon BPCS generated alarms. Cannotbe used as BPCS failure is initiatingevent (Approach A in Ch. 6).

Frequency of Mitigated Consequence 2.5 × 10–6

Risk Tolerance Criteria Met? (Yes/No): Yes, with added SIF.

Actions Required toMeet Risk ToleranceCriteria:

Add SIF with PFD of 1 × 10–2.Responsible Group/Person: Plant Technical/ J. Doe June 2002Maintain dike as an IPL (Inspection, maintenance, etc.)

Notes Add action items to action tracking database



Total PFD for all IPLs 1 × 10-4

TABLE 8.4Summary Sheet for Continuing Example 2—Scenario 2a: Numerical Criteria Method

[Consequence Severity using 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.



Release of hexane outside the dike due totank overflow and failure of dike withpotential for ignition and fatality.


Maximum Tolerable Risk of a Serious Fire

Maximum Tolerable Risk of a Fatal Injury

<1 × 10–4

<1 × 10–5

Initiating Event(typically afrequency)

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

1


N/A





Others N/A



Operator checks level before unloading(PFD from Table 6.3)

1 × 10–1




BPCS level control and alarm is not an IPLas it is part of the BPCS system alreadycredited in LI read by operator.




Actions Required toMeet Risk ToleranceCriteria


Notes Human action at 1 × 10–1 as although actions simple and no time constraintsthe PFD of the level indication loop sets the overall PFD for this IPL.Add action items to action tracking database.



8.9. Cautions

Since LOPA uses simplifying assumptions and approximations (frequentlyto the nearest order of magnitude), LOPA is not intended to be either a com-plex or a high level of detail decision tool. LOPA is most effective for a generalapproximation of risk and the associated opportunities for mitigation ofthose risks. Using LOPA to justify significant reductions in protective layersor expenditures of significant amounts of capital is at times not appropriate,due to its approximate nature. For those decisions, it is often more appropri-ate to perform a more definitive analysis of the scenarios, using more rigor-ous methods such as FTA and CPQRA. The LOPA method—which includesthe frequency estimates in Chapter 5, the PFD estimates in Chapter 6, and thecalculations in Chapter 7—is a short cut method that is intended to be conser-vative. Conservative numbers will usually show a higher frequency or higherrisk than more rigorous methods such as fault tree analysis and quantitativerisk assessment. Conservative numbers could lead to spending extra moneyfor frequency reduction or to turning away business because of the perceivedrisk. On the other hand, doing risk studies with the more rigorous methods


FIGURE 8.1. Continuing Example 1: Hexane Surge Tank Overflow (with added IPL).

may require significant expenditures for the studies. More sophisticatedapplications of LOPA are shown in Chapter 11.

8.10. Link Forward

The techniques of LOPA can be extended to most any type of risk reductiondecision. There are many different types of risk faced by companies in thechemical industry including: environmental, health, safety and business (i.e.,property, reliability, and quality). We have discussed the application ofLOPA to process safety risk reduction for the purposes of reducing injury toemployees and the community. For other considerations, such as those notedabove, analyses must identify the multiple risk aspects for each scenario, anduse the consequence that represents the highest risk to the overall business.Alternatively, the consequence can be integrated for each scenario, and theresults used to calculate a composite risk for the scenario. For the latter


FIGURE 8.2. Continuing Example 2: Hexane Storage Tank Overflow (with added IPL).

option, a common value for consequences (such as dollars) must be used.Note that the consequences lookup Table 1 (Method 1, Chaper 3) and its com-panion risk matrix (Table 8.1) contain all the aspects of business risk and theycan be used to make a decision on the tolerance of the integrated risk, morerecently termed Enterprise Risk.

Chapter 9 discusses implementation of a LOPA system in an organiza-tion, including development of risk tolerance criteria.

Appendix C discusses documentation of the LOPA calculations and riskdecision making.


9

Implementing LOPA

9.1. Purpose

This chapter discusses how to effectively implement LOPA. To achieve themaximum benefit from LOPA, an organization must also implement risk tol-erance criteria. Implementation should be throughout an organization, andnot limited to a single site or single analyst.

Sections 9.2 through 9.7 discuss key questions an organization mustaddress and the background data required before implementing LOPA. Sec-tion 9.8 describes typical steps for implementing LOPA once the questionsand data needs have been addressed.

9.2. Is the Company Ready for LOPA?

A number of factors are part of this question. First, an examination of theoverall risk management philosophy within the corporation is needed.

• Are the organization’s values and beliefs compatible with an objectiverisk management strategy?

• Does the organization have an effective process safety managementsystem to help control risk?

• Are there policies and standards that support the reduction of risk toprotect assets, productive capacity, and public trust?

• Will the organization’s senior management and attorneys agree to awritten risk tolerance criteria?

• Are the objectives of the risk management staff aligned with those ofthe organization?

151

• Will the organization really try to reduce risk if judged excessive?• Does the risk management staff have the support of upper manage-

ment?• Does plant management support this initiative?

If the answer to each of these questions is yes, then the organization isprobably supportive to using any risk management tool that can be profitablyapplied to meet the organization’s objectives. If the answer is no to one or twoquestions, then those hurdles should be addressed aggressively before (orduring) implementation of LOPA. If most of the answers are no, then thecompany is probably not ready for LOPA, and resources would be better allo-cated to other initiatives. LOPA can be a valuable tool to control risk, but itcannot be effectively implemented if the organization is not suited for thisnew tool.

The second area to examine is the organization’s current risk manage-ment capability, considering the hazard analysis capability of the organiza-tion first.

• What analysis methods are currently being used?• Does the organization have a history of rigorous analysis?• Does the organization regularly analyze equipment, systems, proce-

dures, and processes?• At what level of sophistication are hazard analysis tools used?

If an organization rarely conducts formal hazard analyses on systems,and is driven primarily by law or regulation, then it is unlikely that such anorganization could use LOPA with much confidence or success. However, ifhazard analyses are a regular part of the engineering, design, procedure vali-dation, and daily management processes of an organization, then LOPA maywell provide another cost-effective hazard analysis tool that helps increasethe safety and integrity of its systems.

LOPA’s cornerstone is the organization’s policies and practices regard-ing risk management. Such policies and practices provide safety and reliabil-ity professionals the authority to influence and shape the design of processesand systems.

9.3. What Is the Current Foundation for Risk Assessment?

Before implementing LOPA, an organization must have certain capabilitiesand experience in place. A readiness assessment requires an analysis of thecurrent risk management policies, a review of the current hazard analysismethods used, an evaluation of the capabilities within the organization, andan assessment of institutional knowledge related to consequences and failurefrequencies (some of these aspects are addressed later in this chapter).

152 9. Implementing LOPA

If there are clearly articulated policies, are those policies backed up byinternal standards and guidelines that are a normal part of day-to-day busi-ness? The existence of standards requiring hazard analysis, safety reviews,reliability analysis, root cause/failure analyses, and design checks sets thestage for successful implementation of LOPA. For organizations that areaccustomed to performing hazard analyses, LOPA will be accepted asanother tool in the hazard review method toolbox. This is particularly truesince HAZOP and other qualitative methods are ideally suited for findingpotential accident scenarios.

The next step in evaluating the current status is to review the hazard anal-ysis methods in use. Determine if the organization is experienced using quali-tative and quantitative hazard analysis methods. Because LOPA bridges thegap between qualitative and quantitative methods, the more experience theorganization has with quantitative methods the better. Organizations whohave used only qualitative methods (e.g., checklist analysis, what-if analysis,or hazard and operability [HAZOP] analysis) are not likely to be experiencedwith failure rates or probabilities of failure on demand (PFD).

Organizations that implement LOPA usually find that it forces analystsand management to recognize where “uncertainty” in risk exists. In the past,individuals argued qualitatively that the risk is, or is not, tolerable. LOPAhelps build consensus because it uses quantitative (order of magnitude) esti-mates of risk components (initiating event frequency, independent protec-tion layers (IPLs), and consequence).

9.4. What Data Are Required?

While LOPA is a simplified risk assessment technique, it does require data.The data quantify (to a rough order of magnitude) how often equipment fails,how often people err, the consequences of errors and failures, and how likelythe safeguards will prevent the outcomes. These data will be used to developvalues for consequence severity, initiating event frequency, and PFDs forIPLs.

Consequences

Consequence categories must be developed for LOPA use. An organizationmust understand the ranges of severity of consequences, and for the chemicalindustry, these include the severity of chemical releases, runaway reactions,decompositions, fires, and explosions. Many “typical” release/event scenar-ios may need modeling to determine the potential severity of certain types ofscenarios. The organization may run their own models, contract others to runthe models, or use available look-up tables to establish the range of severity.

9.4. What Data Are Required? 153

Before implementing LOPA, an organization must have an understanding ofthe consequences of chemical releases, and should develop guidelines for theLOPA analyst to use when performing an analysis of a scenario. The conse-quence categorization guidelines should be developed such that the LOPAanalyst rarely needs to run a mathematical model. Chapter 3 provides exam-ples of typical consequence lookup tables.

Component Failure Data

Numerous databases exist that provide ranges of failure rates for almostevery conceivable device. This includes relief valves, control loops, and oper-ating procedures (Guidelines for Process Equipment Reliability Data, CCPS1989b; IEEE 1984; OREDA 1989, 1992, 1997; EuReData 1989). The order-of-magnitude values from these sources are often accurate enough for LOPA.The sources typically provide a range of failure rates that encompass mostfacilities. The values are best applied when a company

• understands the source(s) of the data and• knows how their specific processes compare to the data sources.

Some processes with standard designs, such as steam systems or propane stor-age facilities, can be characterized fairly accurately from existing databases.

When the process is unique, the likelihood of failure is highly dependenton the particulars of that process and the environment (including climate) inwhich it operates. The best source of failure rate data for these processes is theactual data from those systems (i.e., from operational-specific sources). Com-panies or organizations with well developed mechanical integrity and inci-dent investigation procedures, including the ability to collect and analyze thedata, are more capable of assigning credible failure rates which strengthensthe credibility of their LOPA method.

Most chemical companies have only recently developed reliability(mechanical integrity) databases and these databases are still being popu-lated. Therefore, most companies applying LOPA begin with data from exter-nal sources and then use subjective judgment to fit the data to their processes.

Note that organizational changes can influence the database as well. Forinstance, an increase in PSV maintenance staff along with a policy change totest and inspect PSVs each year instead of during turnarounds every 2 years,can improve the reliability of PSVs (assuming the test and inspection meth-ods can detect onset of failure).

Human Error Rates

Company or organization experience includes not only failure data for com-ponents in processes, but also softer factors such as knowledge and experi-


ence of operators, corporate culture, and behaviors. There are literaturesources (Swain and Guttmann, (1983), Guidelines for Preventing Human Errorin Process Safety, (CCPS, 1994b)) on human error data that can be used to esti-mate the likelihood of human errors. Internal company data on actual humanerror rates is either non-existent or anecdotal at best, therefore, most compa-nies rely on external sources (published data) for human error rates for use inLOPA.

Incident Data

Incident data from accidents and near misses is another excellent source ofdata for developing typical values for initiating events, IPLs, and conse-quences. The chemical industry is just beginning to report near misses(Bridges 2000b). The near miss data will greatly increase the number of datapoints, further assisting companies to select appropriate failure data, humanerror data, and consequences. Currently, most companies’ incident databasesdo not have sufficient data to allow determination of failure rates and PFDs.

Summary of Data

Ultimately, the organization will need to establish a succinct set of failure anderror data for use in LOPA. This should be a small set of choices, consistentwith the self-imposed limitations of LOPA. See Chapters 5 and 6 for examplesof LOPA frequency and PFD data.

9.5. Will the IPLs Remain in Place?

An organization must establish a system to periodically assess (audit) the ele-ments (components and human interventions) identified as IPLs to ensurethat the IPLs remain in service at the anticipated PFD. In some cases this willrequire functional testing of the devices (SIFs—interlocks, relief systems, etc.)or the human interventions. In other cases it could include inspections, suchas for passive protections like dikes, drainage systems, fire walls, etc. Forsome IPLs, replacement or preventive maintenance may be required at aspecified frequency.

In all cases, the organization must ensure that the testing, inspection, pre-ventive maintenance, procedure drills, etc., are accomplished at the appropri-ate frequency and with the appropriate amount of rigor. These assurancesteps are necessary to achieve the PFD assigned for the IPL. The results ofthese assurance steps (proof tests) must be recorded, including any correctiveactions taken. These records must be available to the LOPA analyst(s).

9.5. Will the IPLs Remain in Place? 155

9.6. How Are the Risk Tolerance Criteria Established?

Risk tolerance criteria can be explicit or implicit. Explicit criteria includevalues for tolerable risk and/or values for reducing risk to “as low as reason-ably practicable“ (ALARP). These values can be expressed as a single value oras a contour on a graph or risk matrix. Implicit criteria are typically hiddenwithin the procedure for selecting the number of IPLs needed for a given con-sequence. All organizations use a criteria of some means to make risk judg-ments, but some companies prefer not to document the risk tolerance criteria.

Frequently, organizations have values or slogans that say something like“all accidents can be prevented” or “nothing we do is worth risking injury.”However, words like “all” and “risk” may not have an organizational mean-ing. Ultimately, it is a question of what risk the organization is willing toaccept. An organization might be willing to accept a fairly frequent occur-rence if the consequences are small. For example, first-aid injury rates aregenerally accepted at a higher frequency than lost workday cases. It is, there-fore, a sliding scale. The worse the consequence, the lower the tolerance forthe incident.

Typically, when qualitative hazard analyses are done, potential risks arequalitatively identified. If the hazard analysis team judges the risk to be intol-erable, the team will generate a recommendation that is intended to reducethe risk. That recommendation, however, gives little indication of how muchan identified risk will be reduced, but the intent is typically to reduce the riskto a tolerable level.

If a similar analysis were done using quantitative methods, the organiza-tion might arrive at the same decision reached using the “qualitative” meth-ods—simply using CPQRA methods does not demand or imply that anorganization has predefined a tolerable risk criteria. A CPQRA analysis willestimate the risk reduction expected from installing the protective device, butit will not determine if the risk is tolerable. That is a decision the organizationmust make.

Without a risk tolerance (or risk acceptance) criteria, there is a tendencyto keep adding safeguards for each new idea for protection, under the falseassumption that safety is continually being improved. However, an organiza-tion will eventually add IPLs that are unnecessary and thereby reduce focuson the IPLs that are critical to achieving tolerable risk. Some organizationshave implemented risk tolerance criteria, coupled with LOPA, to help themfocus their limited resources on the most critical.


To achieve consistent results, the authors strongly advise that

organizations define risk tolerance criteria before implementing LOPA.

The development of risk tolerance criteria will impact many others in anorganization besides those involved in LOPA, because the criteria can andshould be used to reach risk-based decisions, regardless of the hazard analy-sis method used.

Each company must define tolerable risk levels. Upper managementmust buy into what is tolerable, particularly when the loss parameter ishuman suffering or fatality. This is a very difficult consideration. It is difficultfor people to quantify situations they find unthinkable. In the extreme case,no one wants to explain in a court of law that even one fatality is tolerable.However, every individual and every organization (regardless of whetherthe criteria are documented) uses criteria on risk tolerance related to humansuffering.

Example 9.1:

Has any regulator or community prohibited the use of extreme toxics (such

as chlorine)? No! The public (represented and protected by governments)

instead require that companies act responsibly to control the risk. And we

are still allowed to drive automobiles faster than 5 mph (miles per hour) (8

km/hr) on public roads, even though evidence indicates harm can occur

from impacts at speeds much over 5 mph. Again, we recognize the risk of

impact/collisions and administer equipment and administration-based safe-

guards to minimize the risk of these impacts. Similarly, we do not currently

require meteor shields over population centers. Such strikes could occur,

yet all agree that the likelihood is so remote that shields are not required; in

other words, there is agreement throughout our culture to tolerate the risk

of death to personnel caused by meteorite strikes. Other examples exist

that indicate there is a point at which we believe the risk is negligible (and

therefore tolerable).

There are benchmarks for establishing risk tolerance criteria. Appendix Eprovides a sampling of single-value criteria used by industry and regulatorsfor tolerating risk, and for judging that risk is ALARP. Company history canalso help define what is acceptable. Frequently an organization may findfrom a review of its own history that it is actually tolerating a level of uncom-fortable risk, but was not aware of this risk.

As discussed before, risk is a function of consequence and frequency. Therisk tolerance criterion could be simply a single value or it could be repre-sented by an F/N curve (see Chapter 11). This value could be expressedexplicitly in a number (value) or implied within a risk judgment tool such as arisk decision matrix.

Thus, a company can develop risk tolerance criteria using a variety ofdata sources and calculations of consequences and frequencies. Effectiveapplication of LOPA can help move the risk of each scenario into a tolerablerange. This is probably the most important feature of the entire LOPA pro-

9.6. How Are the Risk Tolerance Criteria Established? 157

cess. Without risk criteria, no one will know the risk target. Success will not bedefined, and it will be impossible for business leaders, LOPA team members,and team leaders to know when they have done what needs to be done.

9.7. When Is LOPA Used?

The procedures and practices governing the application of LOPA should out-line the process for deciding when to use LOPA.

LOPA should be applied in the gray area when the qualitative hazardanalysis reveals the need for reduction in risk, but the qualitative team is

• unsure of the frequency of the final consequences,• unsure of the consequences,• concerned that the processes or scenarios are too complex to address

qualitatively.

Here the LOPA method can help the decision-making process. Somecompanies decide when to use LOPA and when to use CPQRA based on the“risk” of a scenario, as estimated during a qualitative hazard evaluation.Other companies use only the “consequence” (or consequence category) todecide when to move beyond qualitative risk judgment. The flowchartshown in Figure 9.1 illustrates one organization’s approach for decidingwhen to use LOPA (and when to use CPQRA as well); this flowchart bases thedecision making on the consequences of the scenario and references the con-sequence categories defined in Table 3.1 in Chapter 3.

9.8. Typical Implementation Tasks

Once the frequency data and consequence data have been documented andthe risk matrix and tolerance criteria have been developed, an organization isready to implement the LOPA approach.

Documenting Risk Tolerance Criteria

The first step in implementation is to develop a document listing the stan-dards having a bearing on LOPA, including the risk tolerance criteria dis-cussed earlier in this chapter (Section 9.6) and in Chapter 8. This documentdefines the level of risk an organization is willing to assume in the course ofoperating its facilities, assuming that all basic standards and practices areapplied appropriately. Regardless of the specific risk assessment method orprocedure, the risk tolerance criteria must provide quantitative measures todetermine the acceptability of the risk associated with a scenario or a facility.


In some methods a range of risk is identified (such as between “tolerable”risk and “ALARP”) where a cost–benefit study may assist in decidingwhether to implement modifications. If this method is used then the basis forthe cost–benefit analysis should be defined. Sometimes a different approachis used when considering retrofits to an existing facility and the design of anew facility. The difference in approach must be clearly defined. In manycompanies the development and language of the risk tolerance criteria docu-ment requires input from the legal staff and approval of executive manage-ment.


FIGURE 9.1. Flowchart for deciding which risk analysis method to use (see Table 3.1 forconsequence definitions).

The LOPA Guidance Document

This is a high-level document that should define the general process and pre-requisites for applying LOPA within an organization. It should address thefollowing topics:

• The body or group within the organization responsible for the LOPAmethod. This includes responsibility for the basic assumptions, per-sonnel training, quality control, etc.

• The risk tolerance criteria (see Section 9.6).• Guidance on when to use LOPA (see Section 9.7).• Requirements for a LOPA team to proceed independently.• Required reviews for the risk results from LOPA by corporate experts

and/or local or corporate management.• Required reviews of LOPA recommendations by corporate experts

and/or local or corporate management.• Guidance on cost–benefit method and assumptions (if required).• Requirements for personnel to lead LOPA studies.• Guidelines on when a LOPA study may require a more rigorous analy-

sis (e.g., CPQRA) for all or part of a scenario (see Section 9.7).

Developing a Step-by-Step Procedure

A step-by-step procedure (protocol) is needed for reference by the user. Ear-lier chapters in this book contain the details on this procedure—these detailsshould be distilled into a set of rules and examples so that LOPA is appliedconsistently. Essential aspects include:

• Standardized initiating event frequencies for use throughout the com-pany.

• A standardized approach for including enabling events or conditions—if used by the LOPA method.

• Standardized PFD values for IPLs.• Guidance on establishing the independence, effectiveness and verifica-

tion of safeguards for consideration of a safeguard as an IPL. This shouldinclude specific guidance on whether to consider the BPCS logic solveravailable for other BPCS/IPLs when the failure of a BPCS loop is the ini-tiating event for a scenario, or what to do when a BPCS loop is alreadycredited as an IPL for the same scenario (see Chapters 6 and 11).

• Guidance on calculating the PFD for IPLs that have a high challengefrequency (see Chapter 7 and Appendix F)—if required by the LOPAmethod.

• Guidance on obtaining PFD values for IPLs not listed in the standardtables (calculation method or referenced personnel or group)—ifrequired by the LOPA method.


• Guidance on defining the consequence category.• Guidance on calculating the consequence frequency.• Guidance on including additional consequence factor probabilities

(e.g., probability of ignition) – if these are used in the method.• Guidance on evaluating risk against the risk tolerance criteria to deter-

mine if further action is warranted.• Steps to document (including sample forms) the LOPA scenarios, and

to communicate the findings for further action and archiving.• Steps to close the recommendations from LOPA.• Provisions for auditing the system to ensure compliance or to ensure

LOPA is used properly.

Conducting Pilot Tests

Each organization has recommendations from hazard evaluations or investi-gation teams that have not yet been resolved. Therefore, one good pilot test isto choose the recommendations with the most severe consequences (Category4 or 5), and see where the related accident scenarios fall on the risk matrix (suchas the risk matrix provided in Table 8.1) for mitigated consequences (takingappropriate credit for existing safeguards). If the residual risk is not tolerable,the proposed recommendation is applied to determine if the risk is moved tothe tolerable range. As the analyst(s) works through these in-house examples,he or she will begin to understand the value of this approach, and should alsosee where it may be necessary to modify the approach.

Alternatively, if the organization has existing engineering/safeguardingstandards or other established requirements, the LOPA process can be usedto evaluate the elements of those requirements. This can accomplish twoobjectives:

1. Calibration of the risk tolerance criteria against perceived “accept-able” levels of safeguards.

2. Identification of shortfalls (or excesses) in existing protection require-ments.

The results of the pilot tests mentioned above should be reviewed withexperienced risk analysts and design/process experts to ensure that the finalrisk judgments (and therefore, the LOPA approach and risk tolerance criteria)matches expert opinion.

Developing Training Courses and Training the Analysts

A short course (2-day, nominal) should be developed or contracted to trainanalysts on applying this technique. The training could also be done bycoaching rather than using classroom instruction. As a prerequisite, all atten-


dees of the LOPA course should have training and experience in performingqualitative hazard evaluations.

Developing Training for Personnel Who Support LOPA

In addition to training analysts, an organization may need to:

• train all hazard review leaders to identify scenarios that warrant LOPA,• train managers concerning their role in LOPA and risk judgment,• train maintenance and operations personnel on the care and mainte-

nance of IPLs.

Developing User Friendly Tools

The LOPA method can be implemented using manual or “paper” methods.Many users may desire to use other tools such as dedicated software orspreadsheets. Typically, these tools help the user

• select the appropriate initiating event frequency and appropriate IPLsand PFDs and

• perform the simple math and documentation required for this method.

Planned software will allow the analyst to convert data automaticallyfrom a qualitative hazard evaluation (such as HAZOP or FMEA tables) intothe starting point for a LOPA scenario, and then to complete the LOPA usingpulldown data selection. Other proprietary applications have been devel-oped to perform a LOPA for scenario data that are input by the analyst. Dedi-cated tools such as these can also present the results of a LOPA approach invarious formats, including showing the placement on the risk matrix. As ofFebruary 2001, to the authors’ knowledge, software with planned or includedLOPA features are HazardReview LEADER™ (ABS Consulting) andPROBE™ (exida.com); several companies have developed “in-house”spreadsheets or applications to aid in LOPA.



10

Using LOPA for OtherApplications

10.1. Purpose

LOPA is a tool used to perform risk assessments. Previous chapters describedits use in assessing the risk level of process hazards scenarios and in evaluat-ing whether adequate layers of protection exist.

The objective of this chapter is to identify and discuss other specific usesof LOPA. This chapter will describe how LOPA is used in:

• capital improvement planning• management of change• mechanical integrity programs or risk-based inspection/risk-based

maintenance• risk-based operator training• emergency response planning• determining a credible design basis for overpressure protection• evaluating facility siting risks• evaluating the need for emergency isolation valves• evaluating the removal of a safety system from service• incident investigations• determining SIL for SIF.

163

10.2. Using LOPA in Capital Improvement Planning

Costs are associated with risk mitigation measures. There are also benefitsderived from risk mitigation actions. Some companies are using cost–benefitanalyses to evaluate the relative merits of alternative risk-reducing costexpenditures. These results are used to prioritize projects.

At the completion of a LOPA, a risk level is determined and safeguards toreduce the risk are identified. These safeguards can reduce risk by loweringthe frequency of occurrence of a scenario (or, in some cases, by reducing theseverity of the consequence). A capital expenditure is usually required toobtain the desired risk reduction. A decision must be made on which safe-guard or set of safeguards to select. The LOPA method can be integrated witha cost–benefit method to assist with this decision.

Integrating LOPA with a cost–benefit analysis is a tool that

• Captures the economic benefit from reducing risk.• Enables decision makers to allocate resources to provide the greatest

benefit. This also helps the organization decide on which of severaloptions to pursue to achieve an acceptable risk level for a given project.

• Compares the economic attractiveness of different projects. This alsohelps the organization decide when to further reduce the risk level forseveral projects which are marginally acceptable versus tolerable riskcriteria.

The parameters and procedures of this cost–benefit analysis are organi-zation dependent, but the general principle is the same in all cases. Organiza-tions must assign a dollar value to both the unmitigated scenario andmitigated scenario and to the risk reduction effort. Most use a net presentvalue calculation where the time value of money is accounted for as a func-tion of time and interest rate. Tax consequences and inflation can be incorpo-rated into the models, or the models can be kept simple.

All of the scenarios evaluated with this procedure are equated to a finan-cial impact, which is defined in terms of what is important to the organiza-tion. Financial impact can be identified in many ways. Some of the categoriesused by companies are the cost of

• minor/major injuries/fatalities to employees,• minor/major injuries/fatalities to the off-site population,• equipment loss/replacement,• business loss due to production down time,• business loss due to undesirable publicity,• productivity loss due to employee morale,• legal action,• environmental cleanup,• regulatory agency fines.

164 10. Using LOPA for Other Applications

The benefit of the risk reduction is defined as the difference between thefinancial impact at the high-risk condition and the financial impact at the low-risk condition. This difference is divided by the cost of the risk reductioneffort and the result is called the benefit to cost ratio.

Most companies compare the alternatives on a relative basis rather thanexpecting the analysis to yield absolute cost savings. The method can be usedto compare competing or alternate projects which will reduce the same riskscenario, or can be used to help decide which projects to undertake among allrisk reduction projects. The important point is the establishment of the linkwith the LOPA technique and the use of the LOPA evaluation findings in thecost–benefit analysis.

10.3. Using LOPA in Management of Change

LOPA is well suited for use in the management of change (MOC) process toidentify the safety issues involved in the modification of a process, proce-dures, equipment, instrumentation, etc., and whether the modification willmeet corporate risk tolerance criteria. The LOPA summary sheet (see Appen-dices A and C) provides a concise means of documenting the results of theanalysis and can be included with the other MOC documentation. A suitablyqualified analyst must either perform the LOPA studies or review the results.All referenced documentation must be available to the analyst.

A typical procedure for using LOPA in the MOC process, if no previousLOPA analysis has been performed on the system, involves the followingsteps:

1. Specify the process, procedure, equipment, instrumentation, etc.,involved in the change.

2. Develop scenarios for the unmodified process, procedure, equipment,instrumentation, etc., to assess the current risk level using LOPA, anddocument the results. Effects that may propagate into other parts ofthe process must also be included in the analysis.

3. Repeat the LOPA analysis using the proposed modification(s) toassess the risk, and document the results.

4. Summarize the findings of the LOPA study and, if appropriate, docu-ment that the proposed change meets the corporate risk tolerance crite-ria. Attach this documentation with the complete MOC documentation.

If a LOPA analysis has already been completed, then only steps 3 and 4must be performed.

LOPA studies can help an organization focus on the important issuesinvolved in making a change. LOPA studies are self-documenting, and theMOC documentation should refer to the LOPA documentation.

10.3. Using LOPA in Management of Change 165

10.4. Using LOPA in Mechanical Integrity Programs or Risk-Based Inspection/Risk-Based Maintenance Programs

Safety critical equipment (SCE) are engineering controls that provide inde-pendent layers of protection to lower the risk category of a specific scenario orscenarios from “unacceptable” to “acceptable” as defined by the organiza-tional risk tolerance criteria. Chapter 6 contains several rules for determiningif an engineering control is an IPL. In particular, the engineering control mustbe independent of other engineering controls, must be specifically designedto prevent or mitigate the consequence of a potentially hazardous event, andmust be auditable. It is important to note that some IPLs may not be safetycritical equipment because they may simply lower the risk from “acceptable”to even more “acceptable.”

LOPA is an excellent way to identify safety critical equipment. Scenario2a in Section 6.7 identified the dike for the existing hexane storage tank, thetank’s existing BPCS LIC, and the proposed SIF as IPLs whose probabilities offailure on demand were 1 × 10–2, 1 × 10–1, and 1 × 10–2, respectively. If theapproach presented in this section is applied, these IPLs would be consideredSCEs. After claiming these PFDs, these SCEs must be maintained to insuretheir effectiveness. For example, they could be placed on a “safety criticalequipment list” to insure that they are inspected, tested, and maintained.

Many companies use risk-based decision-making tools like LOPA toidentify SCEs and to drive risk-based inspection and maintenance programs.For example, one company uses a frequency/consequence tool that is verysimilar to LOPA to prioritize its inspection and maintenance activities. Thiscompany recently reported the following benefits associated with their pro-gram (Leonard and Lodal, 1998):

• Significant opportunities for improving mechanical integrity of criticalsafety equipment.

• Major improvements in their overall process safety programs.• Improved business results due to higher utilization of existing equip-

ment, fewer unplanned shutdowns due to unexpected failures, andtargeting of scarce resources to the most risk-critical processes.

• Decreased production costs without adverse affects on the environ-ment, safety, or health.

10.5. Using LOPA in Risk-Based Operator Training

LOPA is an excellent tool to identify safety critical actions, such as adminis-trative or human actions that provide independent layers of protection tolower the risk category from “unacceptable” to “acceptable.” An example of asafety critical action is an operator response (e.g, closing a valve) to an alarm.


A second example is a procedure that ensures that blinds and caps on open-ended valves or connections are kept in place to prevent release of material ifthe valve is inadvertently opened. A third example is the wiring of the “ears”on quick-disconnect hose connection fittings to prevent the hose from discon-necting during loading or unloading operations.

The safety critical actions identified can be placed on a safety criticalaction list to insure that the operators receive more frequent and focusedtraining to insure operator knowledge and performance. The amount oftraining should be commensurate with the assumed PFD. This means that acompany can realize significant savings by targeting training resources to themost critical operations. LOPA can also be used to improve operating proce-dures by highlighting critical operations and consequences of exceedingestablished operating limits.

10.6. Using LOPA in Emergency Response Planning

As discussed in Chapter 4, two important inputs to the LOPA program for apotential accident scenario are the mitigated as is consequence and the miti-gated as is frequency of occurrence. A company using LOPA would be able todocument a substantial number of estimated mitigated as is offsite conse-quences. The following benefits would then be realized when this documen-tation is shared with local emergency planners:

• Planners would better understand the community risk.• Local emergency response planning would improve because planners

will be able to combine the more likely and significant accidentalrelease information with other local planning.

• Coordination would increase between emergency response plannersand facility personnel.

• Public confidence and acceptance of the emergency response planningprocess would increase.

• Emergency response planners would be able to conduct more effectivetable top and evacuation drills and develop more effective gas detec-tion monitoring systems to protect human health and the environment.

• The chemical industry’s involvement in community response planningwould be expanded.

10.7. Using LOPA to Determine a Credible Design Basisfor Overpressure Protection

In1995/1996, ASME approved Code Case 2211 (ASME, 1995). This allowspressure vessels to be protected by system design in lieu of mechanical reliefdevices subject to the following conditions (Windhorst, 1998):

10.7. Using LOPA for Overpressure Protection 167

1. The vessel is not exclusively in air, water or steam service.2. The decision to provide a vessel with overpressure protection by

system design is the responsibility of the user. The manufacturer isonly responsible for verifying that the user has specified overpressureprotection by system design, and for listing this Code Case on the datareport.

3. The user shall ensure that the MAWP (maximum allowable workingpressure) of the vessel is greater than or equal to the highest pressurethat can reasonably be expected to be achieved by the system. The usershall conduct a detailed analysis, which examines all credible scenar-ios that can result in an overpressure condition.

Some companies apply ASME Code Case 2211 to evaluate critically sce-narios that are considered in determining the worst credible relief systemdesign basis. In such evaluations LOPA can be used to determine the existingIPLs and their failure probabilities, and to help define the worst credibleevent design basis for sizing pressure relief devices. A credible event has beendefined in Guidelines for Pressure Relief and Effluent Handling Systems (CCPS,1998b) as “a scenario or event that has reasonable and sufficient likelihood ofoccurrence that it should be considered in selecting the design basis for anemergency relief system. This should be based on a risk analysis that includesa careful and thorough review of process characteristics, experience with sim-ilar systems, the hazardous nature of the materials handled, and the conse-quences of an incident.”

LOPA provides an organization with a risk assessment tool to helpensure that credible scenarios are determined in a uniform, consistentmanner throughout the corporation (see Chapter 4). An important aspect inthe selection of the design basis for relief systems is the ability to identify thenon-credible scenarios and to document why they were not selected as thedesign basis. The definition of a non-credible scenario is based on the com-pany’s risk tolerance criteria. LOPA is an effective tool in this type of screen-ing.

There are normally many scenarios resulting in overpressure that areconsidered during the design of emergency relief systems. These scenarios


CAUTION

This is a short summary of the results of ASME CODE CASE 2211. The reader is

advised to study the code in detail before proceeding with this practice.

IPLs used to reduce the frequency of a scenario to the extent that a mechanical

relief device is not required must be inspected, maintained, and tested to

ensure that the necessary PFDs are achieved.

include, but are not limited to, runaway reactions, fire exposure, a blockedoutlet pipe, utility failures and operational and equipment failures. The reliefdevices are sized to handle the most severe credible design case. For manyexothermic batch reaction systems, the runaway reaction scenario is often theworst case design basis. In many instances the relief device size required tosafely handle these exothermic runaway reactions would be so large that itwould be impractical/uneconomical to proceed with the required design.LOPA can be used as a screening tool to evaluate if additional layers of pro-tection could be added to reduce the likelihood of the runaway reaction-initi-ating event to a sufficiently low level so that it would not be considered acredible design basis scenario. In this example, if the likelihood of a runawayreaction is reduced to a noncredible level, then the fire exposure case or othercredible scenario would become the design basis.

When LOPA screening indicates a sufficiently low scenario frequency, aquantitative risk analysis should be performed to confirm the low occurrencefrequency of the undesired scenario. Typical factors that companies use todecide whether a full FTA (fault tree analysis) is required are

• the conservatism in the scenario development, and• the magnitude of the difference between the projected mitigated risk

level and the maximum tolerable risk level.

Under no circumstances should LOPA by itself be used to eliminate reliefdevices for a specific system.

10.8. Using LOPA in Evaluating Facility Siting Risks

LOPA is also a useful tool for evaluating facility siting risks within the com-pany’s fence line. This procedure is as follows:

1. Identify and develop credible fire, explosion, and/or toxicity scenar-ios which could impact occupants in buildings or affect buildingswhere people congregate or must go for emergency equipment.

2. Use LOPA to estimate the frequency of occurrence, consequence cate-gory, and the existing risk level within the existing layers of protec-tion.

10.7. Using LOPA for Overpressure Protection 169

CAUTION

When the results of a LOPA screening suggest a sufficiently low frequency of

a specific scenario, it is strongly recommended that this be verified by a CPQRA

study before removing the scenario from the basis for relief device sizing.

3. If the existing risk level is deemed “unacceptable” per the organiza-tion’s facility siting risk tolerance criteria, LOPA can be used to iden-tify opportunities to reduce these risks and screen out certainscenarios from facility siting consequence analysis by identifyingappropriate and additional IPLs.

Some companies have obtained significant dollar savings by applyingLOPA by avoiding the relocation of occupied buildings, installation of newblast walls, or implementation of other measures.

CCPS has issued a detailed eight-step procedure for identifying and reduc-ing facility siting risks. Several application examples are shown in Guidelines forEvaluating Process Plant Buildings for External Explosions and Fires (CCPS, 1996a).All of the CCPS examples use “quantitative” risk decision-making tools. LOPAcan be used as a screening tool within the eight-step protocol.

10.9. Using LOPA to Evaluate the Need for EmergencyIsolation Valves

Isolation valves are used to isolate a process unit if a leak occurs in a pipingsystem or if a fire threatens to cause such a leak. These valves are usuallylocated in a piping system so that, when closed, they prevent the sustainedrelease of a large volume of flammable, toxic, or environmentally detrimentalmaterial. Such a release could result in a large widespread fire or the genera-tion of a vapor cloud explosion. Examples include ethylene and propylenepipelines, propylene or LNG storage spheres and large liquid phase reactorsystems. Such valves are often designed to be “fire-safe” and can be actuatedfrom the control room or from local panels in the field. They may also have adedicated air cylinder to provide back-up to the plant air system. These sys-tems are expensive and are normally installed only in selected locations.

Another use of LOPA is for evaluating the need/justification for theseisolation systems. Once a company has decided which type of consequenceanalysis to use (see Chapter 3) and how to set its risk acceptance criteria (seeChapters 7 and 8) the method would involve, for each candidate system:

1. Determining the release size that could, as a minimum, produce theconsequence(s) of interest. This might be in terms of a given mass ofmaterial, a fatality, a certain estimated capital damage, lost produc-tion, etc. (see Chapter 3).

2. Creating scenarios that would result in the release of large quantitiesof toxic or flammable materials assuming no isolation valve is in place.These could include:

� An external fire that could cause another release by damagingpiping, pumps, instrument lines, etc.

� Piping or flange leaks


� Pump seal failures� Third party intervention

3. Calculating the frequency of these initiating events (see Chapter 5).For example, for piping leaks the calculation is done by multiplyingthe total length of pipe by the expected frequency (per unit length) ofthe type of leak that leads to the consequence of interest.

4. Determining the risk associated with the system without an isolationvalve in place. This could involve using a consequence/frequencymatrix, or fatality frequency, or some other method to judge whetherthe risk associated with the system without isolation valves is accept-able given the particular risk tolerance criteria used. Depending uponthe method employed, the frequency associated with each scenariocan be examined individually, or the total frequency for all scenariosassociated with the system can be calculated. If the risk is acceptablethen the installation of an isolation valve is not necessary (see Chapters6, 7 and 8).

5. Determining viable options if the risk is unacceptable (see Chapter 8):� Installing isolation valves� Examining the mechanical design of the system to make it less sus-

ceptible to failures. This might include using welded piping, using adifferent pipe size, changing the pump seal designs, etc.

� Examining the process design of the system to determine if theamount of material released could be reduced. This could involvechanging the pipe size, operating conditions, or materials. This is notnormally a viable option, especially for existing facilities.

10.10. Using LOPA to Evaluate Taking a Safety SystemOut of Service

LOPA can be used to determine whether a critical IPL safety system can bebypassed or taken out of service for a short, known time duration and to

10.10. Using LOPA to Evaluate Taking a Safety System Out of Service 171

CAUTION

The design and installation of isolation valve systems is complex and must be

considered carefully. If such a system is used to reduce risk it must meet the

requirements for an IPL and the appropriate PFD must be applied to assure that

the level of risk reduction gained by installing such a system is sufficient.

In addition, unless the isolation valves are activated immediately after the leak

occurs, they may not prevent a significant vapor cloud formation or a

significant toxic release. Therefore, a quick, reliable detection and actuation

system is essential.

determine what additional layers of protection would be required in theinterim. The procedure for doing this is as follows:

1. Identifying the accident scenarios where the IPL is critical.2. Identifying alternative safeguards that can take the place of the

bypassed IPL to maintain the same risk level. (There may be somecases where an option of increasing the risk level for a short time dura-tion is possible, as long as this new risk level is tolerable by the com-pany’s risk criteria standards.)

One example of this type of action is a simple temperature control systemthat is part of a basic process control system. If high temperature is detected ina reactor system, an automatic control valve in the emergency cooling waterline is opened and the emergency cooling water is used to bring the tempera-ture back to the desired level. If this system must be taken off-line for service,it may be acceptable to use an operator to monitor the temperature of thereactor—if the temperature begins to rise, the operator opens a manual valveto allow emergency cooling water flow to the reactor. LOPA performed onthis scenario would indicate whether this is acceptable for a given companyor whether additional layers of protection are required.

There are many other cases where LOPA can be used to evaluate the safe-guards utilized by a company when a primary safety system is bypassed.

10.11. Using LOPA during Incident Investigations

Several companies have found LOPA to be a useful analysis and communica-tion tool during incident investigations. For example, one company usedLOPA to show how additional IPLs could have prevented a recent gas firedspray dryer explosion incident at its chemical plant. LOPA has been used toidentify scenarios with a common IPL that was compromised in an incidentand to show how to add additional IPLs to reduce the frequency of occur-rence.

10.12. Using LOPA in the Determination of SIL for SIF

LOPA can be used to determine the required SIL (safety integrity level) forSIFs (safety instrumented functions). See the continuing example in Chapter8 for more details. In LOPA, the necessary PFD of a SIF is specified to meet therisk tolerance criteria. One form of LOPA for this purpose is referenced in IEC61511, Part 3 (IEC, 2001).



11

Advanced LOPA Topics

11.1. Purpose

The purpose of this chapter is to discuss more complex methods for using theLOPA technique. It is intended for analysts who are competent with applyingthe basic LOPA methods presented in Chapters 3 through 8 and with eventtree/fault tree techniques and methods. The approaches discussed in thischapter will enable an analyst to

• determine whether the conservative assumptions used in LOPA can berelaxed in certain cases (Section 11.2); and/or

• use LOPA to assist in more refined risk assessment studies (Sections11.3–11.7).

The continuing examples are analyzed using a less conservative approachthan employed in earlier chapters.

11.2. Counting Multiple Functions in One BPCS as IPLsin the Same Scenario

In this section the basic LOPA assumption of complete independence of IPLsfrom the initiating event and other IPLs credited in the same scenario is dis-cussed. Situations where it may be appropriate to relax this requirement arepresented. Important requirements and cautions are included which thereader is urged to read and understand before using this less conservativeapproach.

173

Note: Use of this approach could result in using a PFD for BPCS loop IPLsthat is less than the 1 × 10–1 limit required by IEC 61511 (IEC 2001). Such achange should only be made with adequate analysis and documentation.

Comparison of Methods

Chapter 6 briefly discussed the differences between the two approaches usedfor assessing the independence of IPLs involving BPCS loops to decide howmany IPLs exist for a particular scenario.

Approach A, which was presented in Example 6.2, assumes that a singleBPCS loop failure invalidates all other BPCS loops using the same logicsolver. It was used in Chapters 2–8 because its rules are clear and it is conser-vative. Approach B, also presented in Example 6.2, assumes that if a BPCSloop fails, it is more probable that the failed component is the sensor or thefinal control element, and that the BPCS logic solver remained functional.This approach may be used if the analyst is experienced and adequate dataare available on the design and actual performance of the BPCS logic solver.Another approach would be to divide the initiating event (BPCS failure) intothree scenarios where the initiating event is alternately the sensor, the logicsolver, or the final element.

Approach AIn order for a device or action to be fully credited as an IPL, it must be inde-pendent 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 failureinvalidates all other BPCS loops using the same logic solver. This approacheliminates many common mode failures (see Table 6.2) affecting the PFD forthe IPLs which are claimed. Approach A is straightforward to apply since itsrules are unambiguous and little judgment is left to the analyst or team.

Approach BThis approach assumes that if a BPCS loop fails, it is most probable that thefailed component is the sensor, the final control element, or another compo-nent other than the logic solver itself. The assumptions made in Approach Bare exactly the same as those made in Approach A except that Approach Bassumes the BPCS logic solver continues to function when the failing loopelement is the sensor or final element. Industry experience is that the failurerates of the detection devices and the final control elements are usually muchhigher than the failure rate of the BPCS logic solver in typical installations.

174 11. Advanced LOPA Topics

Approach B allows a limited number of additional elements of the BPCS toserve as IPLs for the same scenario.

Approach B BPCS Loop Failure Concepts

Failure Mode of BPCS LoopsFigure 11.1 shows the components of a simplified BPCS loop. The final con-trol element could be a valve, solenoid, etc., or it may be an alarm that initiateshuman intervention. The important point is that if any one of these compo-nents fails, then the entire loop is disabled and it will not fulfill its functionwhen 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 his-toric failure rate and its effective test rate. In general, for a shorter periodbetween testing, the PFD for a component is lower. The PFD for an entireBPCS loop is approximated by summing the PFDs of all its components.

One important point concerning BPCS systems is their susceptibility tohuman error. In many installations the BPCS is deliberately made accessibleto personnel who have the ability to change set-points, bypass alarms, etc.This openness, while providing operational benefits, does leave any BPCSIPLs open to compromise due to human error. The PFD limit stipulated for allIPLs in the BPCS in IEC 61511 does, in a general manner, take account of thisfactor. Therefore, any method that wishes to take a lower PFD for a BPCS IPLshould also consider whether the security of the existing BPCS can supportsuch a change. In some installations it might be necessary to impose greatercontrol over access to the BPCS to justify the use of a lower PFD, with appro-priate analysis, but this could impose unacceptable operational constraints.The security constraints for access to an SIS system are usually far moresevere than for a BPCS.

11.2. Counting Multiple Functions in One BPCS as IPLs in the Same Scenario 175

FIGURE 11.1. Simplified components of a BPCS loop.

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).

BPCS Logic Solver FailuresHistorical data from a number of companies suggests that, for typicalinstallations, the effective PFD for the BPCS logic solver is at least twoorders of magnitude lower than the sensor or final control element of aBPCS loop. When this is true, the probability that the failure of a BPCS loopinvolved a failure of the BPCS logic solver is no more than approximately 1in 100 (1 × 10–2). In other words, in at least 99 cases out of 100, when theBPCS loop fails, the BPCS logic solver remains fully operational. Any claimfor a lower PFD must be supported by internal data or certification by a rec-ognized independent third party—see below for important requirementsand cautions. As noted above, without adequate access and security con-trols the potential for human error may prevent additional BPCS function-ality being counted as an IPL, even if all the other conditions described inthis section are satisfied.

If, however, all the conditions are met, it may be justifiable to relax therule used in the basic LOPA method (Approach A) where the failure of anyBPCS loop requires all other BPCS loops using the same logic solver (or anyother common component) to be considered ineffective. This is the key differ-ence between Approach B and the basic LOPA method. For example, inFigure 11.2, there are two BPCS loops using the same BPCS logic solver. Ifboth of these loops meet the other requirements for an IPL for the same sce-nario, the basic, conservative, LOPA method (Approach A) would only allowone of these loops to be credited as an IPL for the same scenario. This is due tothe BPCS logic solver serving as a common element to both loops. ApproachB would allow both loops to be credited as IPLs for the same scenario, pro-vided the requirements discussed in the following sections are satisfied.


FIGURE 11.2. Typical BPCS logic solver with multiple loops for the same scenario.

Guidelines for Crediting Multiple Functions in One BPCS LogicSolver for the Same Scenario

The recommended guidelines for crediting multiple BPCS loops as IPLs forthe same scenario are as follows:

• Adequate Access and Security Procedures—These are required to provideassurance that the potential for human error in programming, modify-ing or operating the BPCS is reduced to an acceptable level.

• Sensor/Final Control Elements—The sensors and final control elementsusually have the highest PFD values of all the components in a BPCSloop and are the most likely to cause the failure of a loop.

The following general rules qualify multiple functions on a BPCS logicsolver as multiple IPLs:

• The sensor for an additional, different BPCS function must be inde-pendent of the sensor that is part of the initiating event of the scenario.

• The final element used in an additional, different BPCS function mustbe independent of the final element that is part of the initiating event ofthe scenario .

• The sensor for an additional, different BPCS function must be inde-pendent from any other sensor used in an IPL in the scenario.

• The final element for an additional, different BPCS function must beindependent from any other final element used in an IPL in the scenario.

Therefore, no credit can be taken for multiple loops where either thesensor, or the final control element (including action by the same alarm andoperator response) are common to loops that could otherwise be IPLs for agiven scenario or were part of the initiating or enabling events. This is identi-cal to the approach taken in the basic LOPA method. Thus, as shown inFigure 11.3 since the single sensor is used for both BPCS loops 1 and 2, only a


FIGURE 11.3. Effect of common sensors for the same scenario.

single BPCS loop can be claimed as an IPL for this scenario. Similarly, inFigure 11.4, the final control element (or the same alarm and operatorresponse) is common to both BPCS loops, and only a single BPCS loop can beclaimed as an IPL for this scenario.

Input Cards/Logic Solver/Output CardsThe input and output cards used for transferring information into and out ofthe logic solver are components that may fail at a higher rate than the logicsolver itself. It is recommended that no additional BPCS loops be counted asIPLs where an input or output card is common unless adequate performancecan be demonstrated. In Figure 11.5, A, B, C, D are sensors and 1, 2, 3, 4 arefinal control elements. Provided all other requirements for an IPL are satis-fied, credit would be allowed for a loop with a path of (Sensor A–Input Card1–Logic Solver–Output Card 1–Final Control Element 1) as an IPL. If thesecond control loop has a path of (Sensor D–Input Card 2–Logic


FIGURE 11.4. Effect of common final control elements (including alarms) for the samescenario.

FIGURE 11.5. Effect of common input/output cards for the same scenario.

Solver–Output Card 2–Final Control Element 4) then it could also be claimedas an IPL. This assumes that both loops meet all the other requirements for anIPL for the same scenario. However, if the second loop has a path of (SensorD–Input Card 2–Logic Solver–Output Card 1–Final Control Element 2), nocredit would be allowed for the second loop, as output Card 1 is common toboth loops. Similarly, no credit would be allowed for a second loop if the pathwas (Sensor D–Input Card 1–Logic Solver–Output Card 2–Final Control Ele-ment 2) as Input Card 1 is common to both.

Maximum Number and Type of IPLsApproach B makes the assumption that the failure of a BPCS loop will be dueto components other than the BPCS logic solver. Thus, we make the followingrecommendations:

• The total IPL PFD taken, including that which would be taken bystrictly applying the basic LOPA method, must be no less than twoorders of magnitude, unless the BPCS logic solver has been certified toa higher level of reliability. That is, the additional PFD credited for theBPCS IPL should be no less than 1 × 10–1. This would allow a best caseoverall failure probability of 1 × 10–2 for the BPCS [(1 × 10–1 as perApproach A) × (1 × 10–1)] if justified by additional analysis as describedin this section). Note: This would be outside of IEC 6511 requirementsfor the PFD for all BPCS IPLs.

• No more than a total of two BPCS loops should normally be credited asIPLs for the same scenario if the initiating event does not involve thefailure of a BPCS logic solver. Each of these loops must satisfy all of therequirements for an IPL discussed in Chapter 6 and also the rules andguidelines contained in this section. Thus, in Figure 11.6, if all four ofthe loops individually meet the requirements for an IPL for the samescenario, only two of them would normally be credited as IPLs using


FIGURE 11.6. Maximum number of BPCS loops credited for the same scenario.

this method (Approach B). Only one would be credited as an IPL usingthe 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 samescenario unless detailed analysis shows that complete independence can beachieved and both meet the requirements for human action as an IPL (seeChapter 6).

If the initiating or enabling event involves the failure of a BPCS loop, thenno more than one BPCS loop should normally be credited as an IPL for thesame scenario. If human failure is the initiating event then it is not recom-mended that a BPCS alarm starting human action be counted as an IPL,unless detailed analysis shows that complete independence can be achievedand the operation meets the requirements for human action as an IPL (seeChapter 6). If the initiating event is human error and the enabling event doesnot involve the BPCS, then two BPCS loops can be counted as separate IPLs.

Information/Expertise Required to Apply Credits for MultipleBPCS Loops

In order to count additional BPCS loops as IPLs, the information and exper-tise that are required include:

Data and AnalysisSince this method relies on the assumption that the BPCS logic solver has aPFD at least two orders of magnitude lower than the other components of theBPCS loop (sensor, final control element, etc.), data to support this assump-tion must be available and analyzed. These data could include

• historical performance data for the BPCS logic solver, input/outputcards, sensors, final control element, human response, etc.;

• data from the manufacturer of the system (such information must beexamined critically to ensure that it applies to situations similar to theparticular installation, the effective test periods are comparable, andany assumptions made are understood and are applicable to thesystem 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.


Analysis of these data could include

• calculation of effective failure rates for BPCS loop components for thefacility or system;

• comparison of PFD data for various components and, particularly, forthe BPCS logic solver;

• assessment of input/output card logic and associated loop independ-ence.

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 ExpertiseThis method should only be attempted if the analyst is fully experienced inthe basic LOPA method and has demonstrated expertise in understandingthe possible interrelationships among equipment, instrumentation, andhumans. Experience with event tree and fault tree techniques is highly desir-able, 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 andwhether they can be used for making the required calculations withadequate accuracy;

• understanding whether the design of the instrumentation and BPCSsystems provides the required independence;

• understanding the effects of the proposed IPLs on the process orsystem.

The analyst may be a single person or a number of people each contribut-ing to the complete analysis, but with no single person performing the wholeanalysis. For example a qualified independent third party may certify a BPCSlogic solver to have a low enough PFD that allows multiple BPCS loops to beused in the same scenario. A skilled instrument designer may analyze histori-cal performance data and maintenance records to establish standard designsthat meet the requirements of independence and reliability or establish thereliability of an existing BPCS loop. A process engineer working alone or in ateam environment may use a tool, such as LOPA, to determine the combina-tion of layers of protection that are needed to effectively control an undesir-able consequence. This analysis may indicate that multiple BPCS loops canwork independently to stop the undesired event. The process engineer, pro-cess control engineer, and instrument engineer gather all the informationregarding BPCS component reliability and process requirements, then collab-


orate to design and implement a system of multiple BPCS loops that meet therequirements of independence and reliability. The LOPA analyst must workwith all of these disciplines to arrive at a final result.

If analysts with these skill-sets are not available, then only the basicLOPA 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 usingit, an organization increases the potential for overlooking certain importantinteractions, in particular common cause failures. This issue is discussed inSection 6.3 and it can be a very subtle factor in increasing risk. The basicLOPA technique is conservative, but does provide a high level of protectionagainst common cause failures. If Approach B is used then the analyst mustbe especially vigilant in looking for such interactions. This will normallyrequire additional time and resources, which may be justified by the potentialfor eliminating the need for additional IPL systems.

Continuing Examples Using Approach B—Crediting MultipleBPCS Loops

Two scenarios from the continuing examples used in Chapter 2 through 8 areused to demonstrate the application of Approach B and the issues that canarise. It is assumed for the purposes of this discussion that adequate data andanalysis support the use of Approach B for this installation.

Scenario 1a: Hexane Surge Tank Overflow—Spill Not Contained bythe DikeIn this scenario the initiating event is the failure of the BPCS level controlloop, leading to a tank overflow which is not contained by the dike and result-


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 must be

more than 1 × 10–1, that is, the PFD for all the BPCS risk reduction functions is

not allowed to be lower than 1 × 10–1.

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

multiple BPCS IPLs.

ing in a consequence of a widespread hexane spill. Approach B allows the useof a single additional BPCS loop as an IPL for this scenario (one loop hasalready been accounted for in the initiating event), provided that this meetsall the other requirements for an IPL. Such a BPCS loop could be either

• an additional level sensor which would provide a method of stoppingflow to the tank (a new separate isolation valve or pump cut-off) or

• an additional level sensor that would sound an alarm in the controlroom and initiate operator action to stop flow to the tank before thetank overflowed.

In either case the requirements discussed in this section regarding sepa-rate sensors, input and output cards, and final control element apply.

If a separate level sensor loop is installed with an additional final controlelement to stop flow to the tank, the minimum PFD for this IPL would be 1 ×10–1 (see Table 6.4), unless another value was justified. The adequacy of thislevel of risk reduction would depend on

• the security and access controls for the BPCS providing adequate pro-tection against human error,

• the risk tolerance criteria used, and• the cost–benefit analysis based on the cost of installing the full SIS rec-

ommended in Chapter 8 versus the lower cost of installing only a newBPCS loop and its components and the lower total PFD. Thus, an orga-nization would need to determine whether the increased frequency ofthe event based on only an additional BPCS loop is justified by thelower cost.

A separate level sensor loop with an alarm and operator action to stopfilling the tank could be counted as an IPL. This is possible if the rate of feed tothe tank, the tank cross-sectional area, the normal level, the level at which thealarm sounded, and the dike volume allowed adequate time for the operatorsto respond before the tank overflowed (see Chapter 6). If this is the case, andthe requirements discussed in Section 6.5 for human action are satisfied, itmight be possible to use a PFD of 1 × 10–1 for one separate alarm loop. If twoseparate sensors and alarm annunciators are used, and the operators are welltrained and drilled in the action, a PFD of 1 × 10–2 might be possible. Again,whether this approach would be appropriate would depend upon the riskcriteria used and a cost–benefit decision.

Scenario 2a: Hexane Storage Tank Overflow—Spill Not Contained bythe DikeIn this scenario the initiating event is the failure of the inventory controlsystem due to a tank truck arriving at the storage tank with insufficient roomin the tank for the contents of the truck. This leads to an overflow of the tank.


If the inventory control system is part of the BPCS that also monitored thetank, Approach B allows the use of one additional BPCS loop as an IPL for thisscenario, provided that this meets all the other requirements for an IPL. If theinventory 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 thisscenario. Examples of additional BPCS loops include

• an additional level sensor and indicator which the operator would useas a check on the tank level prior to unloading or

• an additional level sensor providing a method to stop the flow to thetank (separate isolation valve or pump cutoff).

In either case, the requirements discussed in this section regarding sepa-rate 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 pro-tection 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 lowercost of installing only new BPCS loop(s) and components.

If a separate level sensor loop is installed with an additional final controlelement to stop flow to the tank, the minimum PFD for this IPL would be 1 ×10–1 (see Table 6.4), unless another value was justified. The adequacy of thislevel of risk reduction would depend on the risk criteria used and a cost–ben-efit decision.

If the BPCS is separate from the inventory control system both the pumpshutoff and operator alarm IPLs could be used, provided that the requirementsabove were met (e.g., separate sensors, input/output cards, final control ele-ment). This approach would require complete separation between the inven-tory control system and the BPCS system for the tank and no human factorinteractions in the facility for these systems. A maximum PFD of 1 × 10–2 for thetwo BPCS loops as IPLs could be claimed (see above).

11.3. Summation of Risk for Multiple Scenarios

In some methods the risk is assessed on a per scenario basis and this is com-pared with the organization’s risk tolerance criteria to determine whetheraction is required. In other methods, the risk associated with an entire plant oreven an entire complex is combined and compared with the risk tolerance cri-teria. Either approach can be used, but certain issues arise when calculatingthe risk associated with an entire plant or complex. These issues are discussedbelow.


For any facility there will be a range of scenarios which will occur at dif-ferent frequencies and have a range of outcomes from minor to catastrophic.This method makes an attempt to combine these to produce an overall assess-ment of the risk.

Applications

For this approach, the total risk for a facility is determined to the level of accu-racy of the method if all important scenarios have been identified. The totalrisk is then used to make decisions for each facility on whether it shouldremain in operation and to determine the priorities for applying resources (ifrequired) to reduce risk to meet the risk tolerance criteria for the facility.However, the additional work may not be justified, since working on theindividual scenarios should reveal the scenarios with the highest risk.

Method

The consequence categories used for this method must be appropriate forsumming between different scenarios. Methods that use a fatality frequencyas the risk measure can apply this technique directly by adding together all ofthe fatality frequencies calculated for a given facility. Methods using conse-quence categories can also apply this technique, but it is more cumbersome.

Example 11.1 shows how to estimate the frequency of a consequence thathas 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 (1 × 10–1/yr), and failure of the steam flow control

loop (1 × 10–1/yr). These two scenarios can be prevented by two IPLs, each

with a PFD of 1 × 10–2. Equation (7-1) is used to calculate the frequency for

the consequence of rupture due to no cooling,

f f fj

j

rupture no cooling no cooling no coolPFD= × ==

∏1

2ing

IPL1 IPL2PFD PFD× ×

[ ]f rupture no cooling yr) ( (= × × × × × =− − −( / ) )1 10 1 10 1 101 2 2 1 10 5× − /yr

Similarly, for rupture due to steam loop failure,

f f fj

j

rupture steam loop steam loop steam lPFD= × ==

∏1

2oop

IPL1 IPL2PFD PFD× ×

[ ]f steam loop yr) ( ( y= × × × × × = ×− − − −( / ) ) /1 10 1 10 1 10 1 101 2 2 5 r

11.3. Summation of Risk for Multiple Scenarios 185

Equation (7-7) is used to determine the consequence frequency for both

events,

f f f fC

i

rupture both rupture no cooling rupture= = +=

∑1

2steam loop

f rupture both yr yr yr= × + × = ×− − −( ) ( )1 10 1 10 2 105 5 5

In LOPA, correction for both events happening simultaneously is not nor-

mally 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 orga-nization’s tolerance for risk is linear (e.g., 1 fatality in 100 years is equivalentto 10 fatalities in 1000 years). This is questionable, as most governments thathave addressed this issue have produced criteria that are less accepting ofhigh consequence events compared to low consequence events. However, theadditive method is appropriate to combine risk of single fatality scenarios.

11.4. Using LOPA to Develop F/N Curves

An F/N curve plots the cumulative frequency (F) versus the number of fatali-ties (N) and is intended to incorporate a number of scenarios into a singlefigure (see Figure 11.7 for a typical F/N curve). LOPA may be used to gener-ate an F/N curve only when the consequence of each scenario is stated interms of fatalities or another consequence parameter (such as serious injury,business loss) consistent with the organization’s risk tolerance criteria. Thedata shown on an F/N curve is only as accurate as the method used. There-fore, 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 sce-nario or facility and to compare it to risk tolerance criteria that can be plottedon the same graph. The frequency intercept of the line at N = 1 and the shapeof the curve provides additional information. The frequency at which thenumber of fatalities is at least equal to 1 provides a baseline risk for the sce-nario or facility which can be compared directly. The shape of the curveallows the analyst to assess whether the risk is to a relatively small popula-tion, in which case the curve would fall steeply. Alternatively, if the risk wereto a large population, the curve would be expected to fall only gradually withincreasing values of N. As discussed in Chapter 8, most guidelines that have


been developed by governmental agencies and individual companies are lesstolerant of high consequence events than low consequence events. The F/Ncurve presents data in a form that allows the direct comparison with such cri-teria.

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 frequen-cies of all scenarios with that number of fatalities. This is the first, andextreme right hand point, on the curve.

5. For the next highest consequence, add the sum of the frequencies of allthe scenarios with that consequence to the frequency for the largestconsequence. This is the second point on the curve and is located to theleft of the point obtained in Step 4.

6. Continue adding the frequencies for each successively lower conse-quence, until the lowest consequence has been reached.

7. If the lowest consequence is not one fatality, add a point with a conse-quence of one fatality at the same frequency as that calculated in Step 6.

11.4. Using LOPA to Develop F/N Curves 187

FIGURE 11.7. Typical F/N curve.

11.5. Operator Response Issues

Human action as an IPL is discussed in Section 6.5. This section addressesmore advanced issues but, as noted previously, extreme care should be usedin examining human factors in assigning IPL credits.

Immediate versus Delayed Feedback of an ErroneousHuman Action

In certain cases an operator receives immediate feedback that an action was inerror. In other cases the results of an incorrect human action are not apparentfor 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 con-sidered an IPL?

If, for example, an operator opened a small quarter-turn valve expectingthe line to be depressurized, and material started issuing from the valve, theoperator would be immediately aware of the erroneous action. In most casesthe operator would immediately close the valve, and no harm would occur.However, the possibility exists that the operator might be disabled, or in apanic, and the valve would remain open. An analyst must consider whetherto credit human action as an IPL in such a case and, if it is decided that imme-diate 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 multipleoperators of a potentially unsafe condition independently (by using multiplesensors, multiple annunciators, etc.). This situation could be credited as mul-tiple IPLs (e.g., one for each separate notification loop); or as a single IPL witha lower PFD, particularly if the time available for action is substantial for all ofthe operators (see Table 6.5). If one operator has only a short period of time torespond, 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 acommon 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.


11.6. Normal Plant Operations as “Tests” ofIPL Components

Many of the components of safety systems, particularly those in BPCS loops,are used during the “normal” operation of the process. Under some condi-tions the successful performance of normal tasks can be used as an effectivetest of the device or system and, thereby, potentially decrease the PFD of thedevice, and possibly the system. Section 6.6 discusses the equations used tocalculate the PFD using the historical failure rate data and the effective testperiod. Generally, if the time between tests is decreased, the PFD for thedevice or system tested will also be decreased.

If, for example, a temperature sensor is monitored on a regular basis andis compared with other sensors (perhaps ones used in a SIS) then the periodbetween comparisons might be used as the effective test period. However,care must be taken with this approach (see below). Another example wouldbe a valve that is cycled regularly so that its shutoff can be confirmed. Thiscould 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 inter-val and the PFD of the valve thereby decreased (improved).

Such an analysis would normally be applied to the components with thehighest PFDs (sensors, valves, etc.), rather that the BPCS logic solver, in orderto 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.

11.7. Focused Fault Tree/Event Tree Analysisof IPL Components

In some cases uncertainty may exist as to the appropriate numeric valueassigned to a component of a scenario (initiating event frequency, enablingevent or condition probability, PFD for an IPL, consequence size or type).Alternatively, it may be desired to reduce the conservatism in the LOPA tech-nique by using numerical values that are more rigorously calculated, ratherthan the tabulated values used by a given organization. In such cases it maybe appropriate to perform a focused fault tree or event tree analysis. Such ananalysis can, when applied selectively, improve the confidence in the results

11.7. Focused Fault Tree/Event Tree Analysis of IPL Components 189

of the LOPA study and generate support for the conclusions. The Guidelinesfor 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 ini-tiating event frequency may depend upon one or more enabling events orconditions. For complex scenarios a fault tree may be appropriate.

Common Cause Issues

A fault tree can be valuable in clarifying interactions and resolving concernswhen 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 anIPL, or of the IPL itself, a fault tree can be used to demonstrate interactionsand provide a rigorous calculation of the appropriate PFD value.

In certain cases a fault tree is used to demonstrate that a particular IPL hasa PFD significantly higher, or lower, than that which would be assigned usingan organization’s standard reference tables. This approach is useful if anorganization is designing an IPL with a very low PFD to provide the requiredrisk reduction at lower cost or without making major modifications to a pro-cess 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.

APPENDIX A

LOPA Summary Sheets for theContinuing Examples

This appendix contains the completed LOPA sheets for the four continuingexamples used in this book using the three decision-making methods dis-cussed in Chapter 8 (risk matrix, fatality frequency, and required number ofIPLs). In addition the results of the analysis using the method of a majorchemical company are also shown. The solutions presented in this appendixare not necessarily consistent when one method is compared with another, asthe methods differ in their assumptions. Other approaches using the LOPAconcepts presented in this book or developed by a particular organization canalso be used. However, they must be internally consistent and the risk toler-ance criteria must be fully developed so that analysts and teams can deter-mine whether the risk associated with a scenario is acceptable for anindividual organization.

These LOPA sheets contain all the information necessary for understand-ing the scenario (initiating event, enabling event/condition, consequence,existing IPLs and proposed IPLs to meet the defined risk criteria). The formatof these sheets conforms to that discussed in Chapter 4 and in Appendix C(Documentation) for the three methods discussed in this book. The results ofthe fourth method are shown in the format used by the organization thatdeveloped it. Any format containing the required information is acceptable,but it must be adequately maintained and tracked.

The solutions contained in these sheets are the result of discussion amongindividuals from several companies which use different methods. As suchthere have been some adjustments in the data used for the sake of consis-tency. Each company participating in the development of this book wouldnot necessarily have reached the same conclusions as those shown in the

191

accompanying sheets. Therefore, the examples contained in this appendixmust not be considered definitive solutions to the problems discussed. Theyare, rather, illustrative of the concepts and approaches used. Each companymust consider all of the factors that are required to implement LOPA andapply them consistently within their own organization.

A comparison of the results of the analysis of these examples using thefour methods is shown in Table A.14.

List of Summary Sheets for the Continuing Examples

Table No.Continuing

ExampleConsequence Categorization

MethodRisk Decision

Making Method

Table A.1 1a Risk Matrix (Method 1 of Chapter 3) Risk Matrix

Table A.2 1b Risk Matrix (Method 1 of Chapter 3) Risk Matrix

Table A.3 2a Risk Matrix (Method 1 of Chapter 3) Risk Matrix

Table A.4 2b Risk Matrix (Method 1 of Chapter 3) Risk Matrix

Table A.5 1a Fatality Frequency (Method 3 of Chapter 3) Numerical Criteria

Table A.6 1b Fatality Frequency (Method 3 of Chapter 3) Numerical Criteria

Table A.7 2a Fatality Frequency (Method 3 of Chapter 3) Numerical Criteria

Table A.8 2b Fatality Frequency (Method 3 of Chapter 3) Numerical Criteria

Table A.9 1a Fatality Frequency (Method 3 of Chapter 3) Required Numberof IPLs

Table A.10 1b Fatality Frequency (Method 3 of Chapter 3) Required Numberof IPLs

Table A.11 2a Fatality Frequency (Method 3 of Chapter 3) Required Numberof IPLs

Table A.12 2b Fatality Frequency (Method 3 of Chapter 3) Required Numberof IPLs

Table A.13 Based on a Method from a Major Chemical Company(includes Continuing Example Scenarios 1a, 1b, 2a, 2b)

Table A.14 Comparison of Results—Required PFD for Added SIF

192 Appendix A. LOPA Summary Sheets for the Continuing Examples

Appendix A. LOPA Summary Sheets for the Continuing Examples 193

TABLE A.1Summary Sheet for Continuing Example 1a: Risk Matrix Consequence Categorization Method


ScenarioNumber1a

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



Release of hexane (1,000–10,000 lb)outside the dike due to tank overflowand failure of dikeSeverity Category 4


Action required

Tolerable

>1 × 10–3

<1 × 10–5



1 × 10–1


—

Conditional Modifiers(if applicable)




Others N/A


Independent ProtectionLayers



Safeguards(non-IPLs) Human action not an IPL as it dependsupon BPCS generated alarms. Cannot beused as BPCS failure is initiating event(Approach A)

Total PFD for all IPLs 1 × 10–4

Frequency of Mitigated Consequence 1 × 10–5




Notes Add action items to action tracking database.




TABLE A.2Summary Sheet for Continuing Example 1b: Risk Matrix Consequence Categorization Method


ScenarioNumber1b

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



Tank overflow and spill of hexane intodike. In this method a spill into the tankdike, with little potential for ignition andresulting damage or lost production, is nota consequence of interest.

No Consequence of Interest


Action required

Tolerable

N/A

N/A



1 × 10–1


N/A—





Others N/A

Frequency of Unmitigated Consequence N/A


None existing (as dike is not an IPL forrelease assumed to be contained in thisscenario)

N/A


Total PFD for all IPLs N/A

Frequency of Mitigated Consequence N/A

Risk Tolerance Criteria Met? (Yes/No): N/A


None. This is not a consequence of interest for this method.

See Notes below.

Notes The classification of “No consequence of interest” for this scenariodepends upon the organization accepting the release of this materialinto the dike. Other organizations may not accept this risk, or experiencemay dictate that this risk should be mitigated by the installation of addi-tional IPLs at low cost (see Approach B in Chapter 11)..




TABLE A.3Summary Sheet for Continuing Example 2a: Risk Matrix Consequence Categorization Method


ScenarioNumber2a

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



Release of hexane (1,000 – 10,000 lbs.) out-side the dike due to tank overflow andfailure of dike.Severity Category 4


Action required

Tolerable

>1 × 10–3

<1 × 10–5



1


N/A





Others N/A

Frequency of Unmitigated Consequence 1


Operator checks level before unloading(existing) (PFD from Table 6.5)

1 × 10–1



Safeguards(non-IPLs) BPCS level control and alarm is not an IPLas it is part of the BPCS system alreadycredited in LI read by operator.





Add SIF with PFD of 1 × 10–2.Responsible Group/Person: Plant Technical/ J. Doe June 2002Maintain emphasis on procedure to check level as a critical action.Maintain dike as an IPL (Inspection, maintenance, etc.)

Notes Human action at 1 × 10–1 since BPCS level indication is part of this IPLAdd action items to action tracking database.




TABLE A.4Summary Table for Continuing Example 2b: Risk Matrix Consequence Categorization Method


ScenarioNumber2b

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



Tank overflow and spill of hexane intodike. In this method a spill into the tankdike, with little potential for ignition andresulting damage or lost production, is nota consequence of interest.

No Consequence of Interest


Action required

Tolerable

N/A

N/A



1


N/A—





Others N/A

Frequency of Unmitigated Consequence N/A

Independent Protection Layers N/A


Total PFD for all IPLs N/A

Frequency of Mitigated Consequence N/A

Risk Tolerance Criteria Met? (Yes/No): N/A


None. This is not a consequence of interest for this method.

See Notes below.

Notes The classification of “No consequence of interest” for this scenariodepends upon the organization accepting the release of this materialinto the dike. Other organizations may not accept this risk, or experiencemay dictate that this risk should be mitigated by the installation of addi-tional IPLs at low cost (see Approach B in Chapter 11).




TABLE A.5Summary Sheet for Continuing Example 1a: Fatality Frequency Method


ScenarioNumber1a








<1 × 10–4

<1 × 10–5



1 × 10–1


—





Others N/A



Dike intended to contain spill (existing)(PFD from Table 6.3)

1 × 10–2












TABLE A.6Summary Sheet for Continuing Example 1b: Fatality Frequency Method


ScenarioNumber1b




Release of hexane inside the dike due totank overflow with potential for ignitionand fatality.




<1 × 10–4

<1 × 10–5



1 × 10–1


—


Probability of ignition 0.1



Others N/A














TABLE A.7Summary Sheet for Continuing Example 2a: Fatality Frequency Method


ScenarioNumber2a








<1 × 10–4

<1 × 10–5



1


N/A





Others N/A

Frequency of Unmitigated Consequence 0.25



1 × 10–1













TABLE A.8Summary Table for Continuing Example 2b: Fatality Frequency Method


ScenarioNumber2b








<1 × 10–4

<1 × 10–5



1


N/A





Others N/A




1 × 10–1







Add SIF with PFD of 1 × 10–2.Responsible Group/Person: Plant Technical/J. Doe June 2002Maintain emphasis on procedure to check level as a critical action.





TABLE A.9Summary Sheet for Continuing Example 1a: Required Number of IPLs Method

(Consequence severity classified by Fatality Frequency Method (Method 3 of Chapter 3)

ScenarioNumber1a






See Table 8.3



1 × 10–1


N/A





Others N/A



Dike intended to contain spill (existing)(PFD from Table 6.3)

1 × 10–2









As Frequency of Unmitigated Consequence is >(1 × 10–2 per year), 2 IPLcredits are required (i.e., a total PFD of at least 1 × 10–4 must be in placefor IPLs). See Table 8.2. This requirement controls the SIF requirementfor this example.




TABLE A.10Summary Table for Continuing Example 1b: Required Number of IPLs Method

(Consequence severity classified by Fatality Frequency Method (Method 3 of Chapter 3)

ScenarioNumber1b






See Table 8.3



1 × 10–1


N/A





Others N/A



SIF (to be added—see Actions)1 × 10–2






Add SIF with PFD of 1 × 10–2.Responsible Group/Person: Plant Technical/ J. Doe June 2002Maintain emphasis on procedure to check level as a critical action.

Notes As Frequency of Unmitigated Consequence is between 1 × 10–3 and 1 × 10 ,1 IPL credit is required (i.e., a total PFD of at least 1 × 10–2 must be in placefor IPLs). See Table 8.2

This requirement controls the SIF requirement for this example.



–2

TABLE A.11Summary Sheet for Continuing Example 2a: Required Number of IPLs Method (Consequence

severity classified by Fatality Frequency Method (Method 3 of Chapter 3)

ScenarioNumber2a




Release of hexane inside the dike due totank overflow and failure of dike withpotential for ignition and fatality.


See Table 8.2



1


N/A





Others N/A

Frequency of Unmitigated Consequence 0.25



1 × 10–1


SIF (to be added for scenario 2b) 1 × 10–2







Notes: Human action at 1 × 10–1 since BPCS level indication is part of this IPLAdd action items to action tracking database.As Frequency of Unmitigated Consequence is >(1 × 10–2 per year),2 IPL credits are required (i.e., a total PFD of at least 1 × 10–4 must beinstalled). See Table 8.2As 1 × 10–3 PFD in place only 1 × 10–1 needs to be added, but require-ment of Scenario 2b for this system controls the design for the SIF as onewith a PFD of 1 × 10–2



204

TABLE A.12Summary Sheet for Continuing Example 2b: Required Number of IPLs Method (Consequence

severity classified by Fatality Frequency Method (Method 3 of Chapter 3)

ScenarioNumber2b






See Table 8.2



1


N/A





Others N/A




1 × 10–1







Add SIF with PFD of 1 × 10–2.Responsible Group/Person: Plant Technical/ J. Doe June 2002Maintain emphasis on procedure to check level as a critical action.

Notes: Human action at 1 × 10–1 since BPCS level indication is part of this IPLAdd action items to action tracking database.As Frequency of Unmitigated Consequence is between 1 × 10–2 and1 × 10–3, 1.5 IPL credits are required (i.e., a total PFD of at least 1 × 10–3

must be in place for all of the IPLs). See Table 8.3As only 0.5 IPL credit exist, an SIF with a PFD of 1 × 10–2 must be added.This controls the design of the SIF system for this example.



Table A. 13Summary Sheet for Continuing Examples—Based on a Methodfrom a Major Chemical Company

The calculations shown on the pages that follow were performed by one com-pany’s proprietary software using the principles described in this book andthat company’s IPL PFD data and risk tolerance criteria. That informationand the decision-making rules are embedded in the software and may not beexplicitly shown in the table.


TABLE A.13SAFETY/ENVIRONMENTAL RISK ASSESSMENT

Location: CCPS Unit: Continuing Example Scenario Number: 1a

Description of PHA Scenario: Hexane surge tank overflow—spill not contained by the dike

List of Existing Safeguards Dike

Risk BeforeLikelihood: L Consequence: H Color: Yellow [denotes risk matrix grid]

Risk AfterLikelihood: LL Consequence: H Color: Blue [denotes risk matrix grid]

Description of Recommended Mitigation Option(s): Install an SIF

Mitigation Option(s) Accepted: SIF installation

Date of Analysis: Participants:

Interlock Tag Number: Drawing Number:

System Name:

SIF Overview:

Impact Event: Release of hexane (1,000–10,000 lb) outside the dike due to tankoverflow and failure of dike. Potentially life-threatening.Severity Category 4

Potential Consequence: H

Initiating Cause BPCS Loop Failure, LatentUse 10–5 dangerous failures per hour for an operational loop.

Enabling Conditions: Probability of operator being affected by scenario (i.e., in vicinityof spill) is assumed to be 0.5; further, probability of fatal injury isassumed to be 0.5 for affected operator. An ignition is assumed tooccur so probability of ignition = 1.

Probability of Enabling Conditions: 2.5000E-01 *If the value is 1.0, NO EnablingCondition is considered.

Unmitigated Likelihood: M-H 4.00E+01 Years

Protection Layers (Not Final Defense)Group Layer Credit PFDMitigation Systems Dikes—2 credits 2 1.00E-02

Protective Layer Descriptive Text: Human action not an IPL as it depends upon BPCSgenerated alarms. Cannot be used, as BPCS failure isinitiating event.

Total Credits 2

Intermediate Likelihood L 4.00E+03 Years

Description SIF Mitigating Actions:

SIF Mitigating Actions (Final Defense Instrumentation)

Minimum MinimumInput Output System

Safety, Proactive Credits PFD Redundancy Redundancy Design

Class IC 1.0 0.1 1oo1 1oo2 DTT

SIF Class: IC

SIL: 1

Final Mitigated Likelihood: LL 4.00E+04 Years


TABLE A.13 (continued)

Location: CCPS Unit: Continuing Example Scenario Number: 1b

Description of PHA Scenario: Hexane surge tank overflow—spill contained by the dike

List of Existing Safeguards: None




Mitigation Option(s) Accepted: SIF Installation



System Name:

SIF Overview:

Impact Event: Tank overflows and spill of hexane into dike. Spill into the tank dikeresults in less potential for ignition and the resultant potential personnelinjury. Potentially life-threatening. Severity Category 4


Initiating Cause: BPCS Loop Failure, LatentUse 10–5 dangerous failures per hour for an operational loop.

Enabling Conditions: Probability of operator in dike is assumed to be = 0.1;probability of ignition is assumed to be = 0.1;probability of fatal injury is assumed to be = 0.5


Unmitigated Likelihood L 2.00E+03 Years

Protection Layers (Not Final Defense)Group Layer Credit PFDN/A

Protective Layer Descriptive Text: None as dike is not an IPL for release within dike.It contains the spill which is specified in thescenario description.

Total Credits 0







SIF Class: IC

SIL: 1




Location: CCPS Unit: Continuing Example Scenario Number: 2a

Description of PHA Scenario: Hexane storage tank overflow—spill not contained by the dike

List of Existing Safeguards: LAHH and Operator check, dike







System Name:

SIF Overview:

Impact Event: Release of hexane (1,000 to 10,000 lbs) outside the dike due to tankoverflow and failure of dike. Potentially life-threatening.Severity Category 4


Initiating Cause: Insufficient room in tank, failure of inventory control system.Arrival of tank truck with insufficient room in the tank due to failure ofthe inventory control system. Frequency of 1 per year based on plant data.

Enabling Conditions: Probability of ignition is assumed to be = 1;probability of person in affected area is assumed to be = 0.5;probability of fatality given exposure is assumed to be = 0.5


Unmitigated Likelihood H 4.00E+00 Years

Protection Layers (Not Final Defense)Group Layer Credit PFDMitigation Systems Dike—2 credits 2 1.00E-02Instrumentation BPCS—Typical DCS 1 1.00E-01Safeguarding

Protective Layer Descriptive Text: BPCS level control and alarm is taken as one IPL whichincludes operator intervention based on the LAHH.

Total Credits: 3







SIF Class: IC

SIL: 1




Location: CCPS Unit: Continuing Example Scenario Number: 2b

Description of PHA Scenario: Hexane storage tank overflow—spill contained bythe dike

List of Existing Safeguards: LAHH and Operator intervention







System Name:

SIF Overview:

Impact Event: Potentially life-threatening. Severity Category 4


Initiating Cause: Overfill in dike, administrative failure.Arrival of tank truck with insufficient room in the tank due to failure ofthe inventory control system. Frequency of 1 per year based on plant data.

Enabling Conditions: Probability of ignition = 0.1;probability of person in affected area = 0.1;probability of fatality given exposure = 0.5


Unmitigated Likelihood L-M 2.00E+02 Years

Protection Layers (Not Final Defense)Group Layer Credit PFDInstrumentation BPCS—Typical DCS 1 1.00E-01Safeguarding

Protective Layer Descriptive Text: BPCS alarm is an IPL. Dike is not an IPL for releasewithin dike. It contains the spill, which is specified inthe scenario description.

Total Credits: 1







SIF Class: IC

SIL: 1



TABLE A.13 (continued)CUMULATIVE FREQUENCY—CONTINUING EXAMPLE

The summed frequency of the four mitigated scenarios is approximately once per 6700 yearsor an annual frequency of 1.5 × 10–4. This is achieved by the application of a SIFwith PFD of1 × 10–1 (SIL 1 in this company).

The summed frequency is equivalent to the Boolean OR operation on the frequencies of thefour scenarios. Although it is recognized that the OR function requires that the intersectionof the four frequencies be subtracted from the sum of the frequencies; the difference is verysmall for numerically small frequencies. Also ignoring the intersection of the frequenciesmakes the cumulative frequency conservative.

1st Pass Evaluation of Unit Risk Added SIFs with PFD of 1 × 10–1

Scenario Scenario MTBF, years Frequency, per year Unit MTBF, years

4.00E+04 2.50E-05

2.00E+04 5.00E-05

4.00E+04 2.50E-05

2.00E+04 5.00E-05

Unit 1.50E-04 6.67E+03 or 6,667

To meet a risk criteria of 1 × 10–4/yr Added SIFs with PFD of 1 × 10–2

Scenario Scenario MTBF, years Frequency, per year Unit MTBF, years

4.00E+05 2.50E-06

2.00E+05 5.00E-06

4.00E+05 2.50E-06

2.00E+05 5.00E-06

Unit 1.50E-05 6.67E+04 or 66,667

If the requirement is that the potentially life threatening scenarios occur with an annual fre-quency less than 1 × 10–4, then a SIFwith PFD of 1 x 10–2 (SIL 2 in this company). would berequired. The SIF would affect the summed frequency of the four scenarios (each equally)resulting in a mitigated frequency of approximately once every 67,000 years or an annualfrequency of 1.5 × 10–5.

TABLE A.14Comparison of Results—Required PFD for Added SIF

Risk MatrixFatality

Frequency

RequiredNumber of

IPLs

MajorChemicalCompany

Scenario 1a 1 × 10–2 1 × 10–2 1 × 10–2 1 × 10–1

Scenario 1b None—NoConsequence

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

Scenario 2a 1 × 10–2 1 × 10–2 1 × 10–2 1 × 10–1

Scenario 2b None – NoConsequence

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


APPENDIX B

Worked Examples from CCPS’sSafe Automation Book

B.1. Introduction

In Chapter 7 of Guidelines for the Safe Automation of Chemical Processes (CCPS,1993b), an example of a polymerization process was used to demonstratesome of the principles discussed in CCPS (1993b). This included a prototypeanalysis of the protection layers in place and proposed SIL levels for auto-mated protective systems. As stated in CCPS (1993b):

Because of the amount of detail that is required to achieve a high-integrity,safely automated design, the example used in this chapter necessarilyincludes a number of simplifications, but is presented to show the applica-tion and discussion of the principles described earlier. Further the specificdesign choices do not reflect practices that are part of a particular company’sstandards, but are representative of good practices. It certainly does not rep-resent a complete design for a polymerization process.

This example from CCPS (1993b) will be used to demonstrate the applica-tion of the LOPA rules presented in this book. In several instances these rulesmay indicate that a different design should be selected compared with thesolution contained in CCPS (1993b). This is not meant to imply that the designpresented in CCPS (1993b) is unsafe, or does not represent good engineeringpractice; it is only intended as a contrast in methods and risk tolerance end-points. The reader should judge whether the issues raised by the applicationof the LOPA method described in this book are appropriate for their ownorganization and processes, or whether modifications to the rules, assump-tions, and data should be made.

211

The major differences between the LOPA method and the risk analysisapproach used in CCPS (1993b) are

• the concept of an enabling event or condition that could modify the fre-quency of the initiating event;

• the concept and rules for identifying and crediting independent pro-tection layers (IPLs);

• the use of a numeric risk tolerance criterion.

Section B.2 describes the problem, Section B.3 discusses the application ofthe LOPA method to the example and Section B.4 discusses various modifica-tions to the design described in CCPS (1993b) and how these affect the PFDfor the various IPLs.

B.2. Problem Description

Figure B.1 shows the P&ID for the process used in CCPS (1993b) and formsthe basis for the analysis in this appendix. A detailed description of the chem-icals, reactions, and the batch process are also contained in CCPS (1993b). Insummary, the process is a batch polymerization of vinyl chloride monomer(VCM) to polyvinyl chloride (PVC). Water, liquid VCM, initiator, and addi-tives are charged through the same nozzle to the agitated, jacketed reactor.The charge nozzle is also connected to the emergency vent valves and therelief valves (PSVs). Shortstop can be added through the same nozzle.

Table B.1 lists the scenarios (denoted as “Events” in CCPS 1993b) thatwere examined in the original example and are reexamined in this appendix.Tables B.2 through B.9 contain the LOPA summary sheets for these scenarios.Additional scenarios could be generated for this problem, but the discussionwill be confined to the eight developed in CCPS (1993b).

B.3. Problem Discussion

To demonstrate the self-documenting ability of LOPA, no additional detailsof the process will be given except for the information contained in the LOPAsheets (Tables B.2–B.9) and the P&ID (Figure B.1). The discussion of the issuesfollows the LOPA scenario structure to illustrate differences between theapproaches. The risk matrix consequence categorization and risk tolerancecriteria are used (see Chapters 3 and 8) in analyzing the problem. The use ofone of the other methods discussed in these two chapters (fatality frequencyand required number of IPLs) would not affect the major findings of the com-parison.

212 Appendix B. Worked Examples from CCPS’s Safe Automation Book

21

3

FIGURE B.1. Simplified flowdiagram: the PVC process(from CCPS 1993b).

Consequence

The consequence assessment used in CCPS (1993b) is qualitative, but notinconsistent with the quantitative consequence matrix. For each method theconsequence of an exothermic runaway reaction inside the reactor is taken asthe most severe that can be assigned.

Risk Tolerance Criteria

The risk tolerance criterion used in CCPS (1993b) is qualitative and defines aspecific SIL (safety integrity level) that must be installed depending upon thefrequency at which the mitigated event will occur with the existing safeguardsthat are assessed. The SIL level required by the matrix is actually the requiredadditional PFD as the SILs are defined in terms of PFD in CCPS (1993b).

The risk tolerance matrix (Table 8.1) is more flexible in assessing theaction required. For Category 5 consequences an event frequency greaterthan 1 × 10–4 per year is unacceptable and action must be taken to correct thesituation. Event frequencies equal to or less than 1 × 10–6 per year are tolerableand no action is required. In the range between these two limits there is someflexibility allowed based upon cost, practicality, etc. (see Chapter 8). As a gen-eral philosophy the risk tolerance matrix method would require a new facilityto meet the most stringent risk tolerance criteria, while an existing unit wouldbe subjected to a cost–benefit analysis if the risk were in the “gray” area.


TABLE B.1Scenarios for Safe Automation Example

Scenario 1:

Scenario 2:

Scenario 3:

Scenario 4:

Scenario 5:

Scenario 6:

Scenario 7:

Scenario 8:

Cooling water failure with runaway reaction and potential for reactoroverpressure, leakage, rupture, injuries, and fatalities

Agitator motor drive failure with potential for runaway reaction, reactoroverpressure, leakage, rupture, injuries and fatalities

Loss of electric power (area wide) with potential for runaway reaction, reactoroverpressure, leakage, rupture, injuries and fatalities

Cooling water pump failure (electric power loss) with potential for runawayreaction, reactor overpressure, leakage, rupture, injuries and fatalities

Human error—Double charge of catalyst with potential for runaway reaction,reactor overpressure, leakage, rupture, injuries and fatalities

BPCS level control failure leading to overfill of reactor with potential for reac-tor overpressure, leakage, rupture, injuries and fatalities

BPCS temperature control failure during heat-up step leading to overheatingof the batch with potential for runaway reaction, reactor overpressure, leak-age, rupture, injuries and fatalities

Agitator seal fails with potential for leakage of VCM with potential for fire,explosion, injuries, and fatalities

Other approaches to defining risk tolerance criteria can be used (seeChapter 8) and individual organizations must decide which approach bestsuits their needs.

Initiating Event

The identification of the initiating event and the assumed initiating event fre-quencies are similar for both approaches.

Enabling Event or Condition

The method presented in CCPS (1993b) does not directly modify the initiatingevent frequencies (loss of cooling, loss of power, etc.) by the probability thatthe batch reactor is both

• in service and• in a condition which, if the initiating event occurred, would result in

the consequence (usually exothermic runaway reaction with overpres-sure for the scenarios examined).

In the solution using the LOPA method it is assumed that the probabilityof both of these conditions existing together is 0.5, which is probably conser-vative for most batch reactor systems.

Similarly, the frequency of a double charge of catalyst being added isequal to the number of batch cycles per year times the probability that anerror will occur in this procedure.

If we assume a value of 0.01 for the probability that an error will occur inthis procedure, then the frequency of a double charge is given by

(365 days/yr) × (1 batch/3 days) × (0.01) = 1.21/yr

This assumes that only one catalyst addition occurs per batch and onebatch is run every three days.

Note: The scenario involving this event sets the required PFD for the SIFdepressurizing system if the assumed values for catalyst loading and humanerror are used. In such a situation an organization may elect to examine theseassumptions in more detail to determine if they are overly conservative.

In some cases neglecting enabling event or condition probabilities cansignificantly affect the results of risk assessment studies. This issue is dis-cussed in detail in Chapters 4 and 5.

Conditional Modifiers

In some methods that use the frequency of fires or fatalities as risk tolerancecriteria, conditional modifiers are used to obtain these frequencies from the

Appendix B. Worked Examples from CCPS’s Safe Automation Book 215

initiating event frequency (see Chapter 7). Neither the method used in CCPS(1993b), nor the risk matrix classification method used in this Appendix, usesthese modifiers.


The method used in CCPS (1993b) does not show this value. This is usefulinformation as it is the baseline risk associated with the scenario and indicateshow much reliance an organization is placing on IPLs to meet the risk toler-ance criteria.

IPLs

The assessment of what is, and is not, an IPL is the biggest difference betweenthe method used in CCPS (1993b) and the LOPA method described in thisbook. LOPA (see Chapter 6) requires that an IPL be

• effective in preventing the consequence (Section 6.3).• independent of the initiating event and the components of any other

IPL already claimed for the same scenario. This is the rule recom-mended for normal LOPA. Under some circumstances it may be per-missible to assume that the BPCS logic solver will not have failed whena BPCS loop failure occurs. This issue is discussed in greater detail inSection 6.3 and Chapter 11.

• auditable, that is, the assumed effectiveness in terms of consequenceprevention and PFD must be capable of verification in some manner(e.g., by documentation, review, testing, etc.). See Section 6.3 andAppendix C.

These requirements will now be discussed in relation to the designshown in Figure B.1 and the IPLs claimed in CCPS (1993b). In some casesmore than one of these requirements raises the same issues regardingwhether a safeguard is an IPL. The argument is developed for each issue todemonstrate the various paths that can be used to examine whether a safe-guard is truly an IPL. Tables B.2 through B.9 contain the detailed LOPA anal-ysis of the system with detailed recommendations. The recommendations aresummarized and discussed in Section B.4.

EffectivenessThe addition of a depressurizing system SIF controlled by an SIS is indicatedfor most of the scenarios. Figure B.1 shows the proposed arrangement inCCPS (1993b). The nozzle used for the depressurizing valves and for the PSVsis the same nozzle used for adding initiator, water and additives to the reactorand, more importantly, shortstop material. This raises the question as to


whether any one of these streams would, or could, be flowing into the vesselthrough this nozzle at the same time that the SIF opens the vent valves or thePSV valves open. For some of these streams it might be acceptable to assumethat it would be unlikely—although careful study of the runaway VLE andreaction kinetics would be required. However, shortstop addition is an IPLcredited for many of the same scenarios where the depressurizing system andPSV are also IPLs. Thus, it might be questionable whether it could beassumed that the addition of shortstop and the venting of the system throughthe same nozzle would not occur simultaneously. Therefore, a team or ana-lyst using the LOPA method would question the effectiveness of the ventsystem PSV and shortstop addition systems as configured in Figure B.1 andwhether they should all be considered as IPLs with the proposed pipingdesign. A fault tree analysis might be considered for these safeguards withcommon components (see Chapter 11).

Other questions that could be asked are whether two-phase flow wouldoccur during venting of the reactor (using either the PSVs or the vent valves)in the piping and valves. If this were possible, DIERS, or similar technology,should be used to account for this appropriately in regards to sizing, mechan-ical strength, disposal issues, etc.

In CCPS (1993b) for Scenario 4 the operator is credited with taking twoactions (turning on the steam driven cooling water pump and adding short-stop). In the LOPA method presented in this book, if the operator is ineffec-tive in performing one of these tasks in response to an alarm, then it isconsidered unlikely that the second task will be performed correctly. So, inLOPA, only one of these actions would be considered as an effective IPL.

In Scenario 8 an IPL is claimed for the process design of a spot ventilationsystem to protect against the release of VCM due to the failure of the agitatorshaft seal. The design of the seal is claimed to limit the maximum amount ofVCM that could be released so that the ventilation system is adequate.Whether the design basis for the evacuation system is appropriate dependsupon the level of analysis performed on the seal and what historic failure rateis justifiable for the vent system fan, etc. For the purposes of the LOPA analy-sis shown in Table B.9 it is assumed to be an IPL with a PFD of 1 × 10–1,although a note on the sheet requires further analysis of this IPL. In additionin CCPS (1993b), low occupancy in the reactor area is claimed as an IPL forScenario 8. This is a qualitative judgment that can be challenged. For example,if a seal is experiencing problems it is likely that personnel would be in thevicinity, either observing and discussing the seal, or actually working on theseal. If a rupture then occurred there could actually be a greater number ofpeople in the area than normal. (Note: At least one major incident resulted inmultiple fatalities due to people being in the vicinity of an explosion whileinvestigating equipment problems.) So it might not be appropriate to claimlow occupancy rates as an IPL. In the LOPA analysis shown in Table B.9, low


occupancy rate is not considered as an IPL as it cannot be considered effectiveor independent of the initiating event for the reasons described above; addi-tionally quantification of its PFD is difficult.

The effectiveness of human action (see Chapter 6) can also be consideredin assessing whether an IPL is present. In some scenarios in CCPS (1993b)where the agitator was not operational, credit was taken for the operatoradding shortstop and then mixing the contents by “burping” the reactor bymanual action. Whether this combination of actions meets the requirementthat human action IPLs have adequate time to analyze and respond to alarmsand for the action required to be simple is questionable. In the LOPA tablesthis action is not considered to be an IPL.

Effectiveness can also include consideration of the PFD claimed for theIPL. An example of this is a comparison of the credit taken for the PSVs (PFD= 1 × 10–2) and the vent valve SIF (PFD = 1 × 10–3). The PFD for the PSVs is rela-tively high for such a device—probably because of concern over the block-age/freezing of the valves or piping due to deposition of polymer or withpolymeric material during the venting process. While the SIF will, if designedcorrectly, detect the condition and send the signal to open the vent valves at aPFD of 1 × 10–3, it would seem unlikely that the valves and piping would beany less susceptible to blockage than the PSVs. If this is correct then it is prob-able that a PFD of 1 × 10–2 should be assumed for both the PSVs and the ventvalves with the design shown in Figure B.1. This is particularly true as, inaddition to the common nozzle, the two PSVs share a common inlet line andthe two vent valves also share a common inlet line. See Section B.4 for possi-ble modifications to the existing design.

IndependenceA different path to highlight similar issues as those discussed above would beto consider the independence of the IPLs. Thus, the independence of theshortstop addition system, the vent system SIF and the PSVs would be ques-tioned once the use of a common nozzle and piping is identified. This wouldresult in a discussion of whether they should all be considered as IPLs withthe design shown in Figure B.1 (due to a potential lack of independence), orwhether a different design is required.

Another issue in considering independence is whether there is any link-age between the initiating event and a potential IPL, or between an IPL thathas already been claimed and another potential IPL for the same scenario.This issue is not addressed directly in CCPS (1993b). Examples of this are:

• Scenario 4 where a single low cooling water flow alarm is creditedwith initiating two operator actions (starting steam driven coolingwater pump and the addition of shortstop) which are both credited asIPLs in CCPS (1993b). In LOPA this is not allowed as:


� If the single low flow alarm fails then both actions could be ineffec-tive because the operator might not be aware of the lack of coolingwater. This is an example of a lack of independence via a commonsensor.

� If the operator fails to perform one of these tasks successfully itwould be unlikely that the second action would be performed cor-rectly. This is an example of a lack of independence via the final con-trol element (operator action).

� If the BPCS fails then it would disable both IPL actions in the basicLOPA method. Under certain circumstances, with specific require-ments for the BPCS design and performance, this issue can beassessed less conservatively (see Chapter 11).

• Scenario 6 where the initiating event is the failure of the level controlloop in the BPCS leading to the overfilling of the reactor. In CCPS(1993b) the level and weigh cell alarms are considered to be an IPL forthis scenario, as they will initiate an alarm to allow the operator to takeaction. In LOPA this is not allowed since, if the control system failure isthe initiating event, it is not permitted to assume that the BPCS willremain capable of detecting, processing and taking action (initiating analarm) to allow the operator to take action. Chapter 11 discusses cir-cumstances when this requirement could be relaxed.

• Scenario 7 where the initiating event is the failure of the temperaturecontrol loop in the BPCS. In CCPS (1993b) it is assumed that the BPCS isstill able to detect this situation and alarm the operator to take action,which is credited as an IPL. This approach is not allowed in LOPA; thefailure of one part of the BPCS (the initiating event) cannot be assumedto leave another part of the same BPCS in a condition where it can takeeffective action to detect, process and send information. Thus the initi-ating event and the corrective action are not independent and theaction cannot be considered to be an IPL. Again, Chapter 11 discusseswhen this requirement might be relaxed.

AuditableThe detailed design of the protection systems is not addressed directly inCCPS (1993b), or in Tables B.2 through B.9. However, verification and audit-ing might include

• the summary sheets for the PSVs showing the design basis, methods ofpipe sizing (i.e., DIERS), hydraulic and mechanical calculations (or ref-erences to them) (CCPS 1998b);

• process design basis demonstrating why the design cases for the sce-narios have been selected with the required modeling, VLE, reactionkinetics, etc. (attached or referenced) to support the conclusions;

• details of the design of the BPCS and SIS.


• details of the design of SIF to demonstrate that the claimed PFD valuesare appropriate.

• details of the required inspection, testing and maintenance procedures.• documentation of the frequency and results of inspection, testing and

maintenance.

Safeguards

Safeguards are described and documented in LOPA to explain why protectiondevices or systems that might, on the surface, appear to be effective, are notconsidered to be IPLs. This is useful for documenting the thought process andproviding an understanding of how much protection might also be availablefor which partial credit may be taken qualitatively, particularly if the LOPAanalysis results in risks that are close to a boundary point. This could alterwhether the risk is tolerated or mitigated by the addition of additional IPLs.

Frequency of Mitigated Consequences

This shows the calculated frequency at which the consequence will occur forthe scenario with all of the IPLs credited.

Risk Tolerance Criteria Met?

This section indicates whether the risk criteria are met by the present or pro-posed design. In many cases the proposed modifications are included todemonstrate that the new design will meet requirements. If this approach isused then the recommendations and notes must make clear what action isrequired, by whom and by what date.

Actions Required to Meet Risk Tolerance Criteria

This section defines the actions required to meet the risk tolerance criteria.

Notes

This section includes any clarifications, etc.

B.4. Design Modifications for Consideration

In this section modifications to the design shown in Figure B.1 are suggestedwith the effect these changes would have upon the number of IPLs and their


TABLE B.2

ScenarioNumber1

EquipmentNumber

Scenario Title: Cooling water failure with runaway reaction and poten-tial for reactor overpressure, leakage, rupture, injuries and fatalities.Agitation assumed.



Runaway reaction and potential for reactoroverpressure, leakage, rupture, injuries, andfatalitiesCategory 5

Risk Tolerance Criteria(category or frequency)

Unacceptable (Greater than)

Tolerable (Less than or equal to)

1 × 10–4

1 × 10–6


Loss of cooling water1 × 10–1


Probability that reactor in condition where run-away reaction can occur on loss of cooling(annual basis)

0.5(per reactor)





Others N/A



BPCS alarm andHuman Action

Shortstop addition on BPCS loop high reactortemperature alarm

1 × 10–1

Pressure Relief Valves With required modifications to system (seeActions) (PFD may be conservative if modifica-tions added)

1 × 10–2

SIF(Req’d PFD = 1 × 10–3)(Part of SIS for all 3reactors)

SIF to open vent valves (see Actions for designdetails)Required PFD set by Scenario 5TO BE ADDED—see Actions/Notes

1 × 10–3

Safeguards (non-IPLs) Operator action. Other operator actions not independent of the sameoperator already credited.

Emergency Cooling System (Steam Turbine). Not credited as an IPL astoo many common elements (piping, valves, jacket, etc) that could haveinitiated initial CW failure.



Risk Tolerance Criteria Met? (Yes/No): Yes with added SIF


Add SIS for all 3 reactors. Install SIF with minimum PFD = 1 × 10–3 foropening vent valves on high temperature. Separate nozzles and piping foreach vent valve. Install separate nozzle and vent lines for each PSV tominimize blockage and common cause.Consider N2 purges under all vent valves/PSVs.Responsible Group/Person/Date: Plant Technical/J. Doe/ January 20xx

Notes Ensure operator response to high temperature meets requirements for IPLEnsure RV design, installation, maintenance meet requirements for PFD1 × 10–2 as a minimum. If determined to be better consider PFD for VentValve SIF PFD


TABLE B.3

ScenarioNumber2

EquipmentNumber

Scenario Title: Agitator motor drive failure with potential for runawayreaction, reactor overpressure, leakage, rupture, injuries and fatalities







1 × 10–4

1 × 10–6


Agitator motor drive failure1 × 10–1



0.5(per reactor)





Others N/A




1 × 10–2



1 × 10–3

Safeguards (non-IPLs) Emergency Cooling System. Not credited as an IPL as no agitation ren-ders it ineffectiveOperator intervention. Reactor “burping” and inhibitor injection overlycomplex








TABLE B.4

ScenarioNumber3

EquipmentNumber

Scenario Title: Loss of electric power (area wide) with potential for run-away reaction, reactor overpressure, leakage, rupture, injuries, and fatali-ties







1 × 10–4

1 × 10–6


Loss of electric power (area wide)1 × 10–1



0.5(per reactor)





Others N/A




1 × 10–2



1 × 10–3

Safeguards (non-IPLs) Emergency Cooling System. Not credited as an IPL as no agitation ren-ders it ineffectiveOperator intervention. Reactor “burping” and inhibitor injection overlycomplex for an IPL







TABLE B.5

ScenarioNumber4

EquipmentNumber

Scenario Title: Cooling water pump electric power failure with runawayreaction and potential for reactor overpressure, leakage, rupture, injuriesand fatalities. Agitation assumed.







1 × 10–4

1 × 10–6


Loss of cooling water pump (electric)1 × 10–1



0.5(per reactor)





Others N/A



BPCS alarm andHuman Action

Inhibitor addition on BPCS high reactor tem-perature/pressure OR starting of CW steamturbine-drive pump on low cooling water flow.

1 × 10–1


1 × 10–2



1 × 10–3

Safeguards (non-IPLs) Operator Intervention. Only one of the two operator actions is an IPLdue to common operator, alarms, sensors, etc.








TABLE B.6

ScenarioNumber5

EquipmentNumber

Scenario Title: Human error—Double charge of catalyst with potentialfor runaway reaction, reactor overpressure, leakage, rupture, injuries andfatalities







1 × 10–4

1 × 10–6


Loading of catalyst (once every three days—121times per year)

121


Probability that operator(s) double charge thereactor with catalyst (per opportunity)

1 × 10–2





Others N/A



BPCS alarm and Inhibitor addition on BPCS high reactor tem-perature/pressure

1 × 10–1


1 × 10–2



1 × 10–3

Safeguards (non-IPLs) Operator Intervention Not independent of BPCS sensors, alarms, FCE.Operator error is initiating event.


Frequency of Mitigated Consequence 1.21X10-6





Human Action

1.21X10-6

TABLE B.7

ScenarioNumber6

EquipmentNumber

Scenario Title: BPCS level control failure leading to overfill of reactorwith potential for reactor overpressure, leakage, rupture, injuries andfatalities



Overfill of reactor with potential for reactoroverpressure, leakage from flanges, connections(10,000–100,000 lb flammable above atmo-spheric BP), with injuries and fatalities.Complete rupture not considered feasible.Category 5




1 × 10–4

1 × 10–6


BPCS failure1 × 10–1



0.5(per reactor)





Others N/A




1 × 10–2



1 × 10–3

Safeguards (non-IPLs) BPCS level/weigh cells. Not independent of BPCS involved in initiatingevent.

Operator Intervention. Not independent of BPCS sensors, alarms, FCE.







TABLE B.8

ScenarioNumber7

EquipmentNumber

Scenario Title: BPCS temperature control failure during heat-up stepleading to overheating of the batch with potential for runaway reaction,reactor overpressure, leakage, rupture, injuries and fatalities







1 × 10–4

1 × 10–6


BPCS temperature control loop1 × 10–1



0.5(per reactor)





Others N/A




1 × 10–2


SIF to open vent valves (see Actions for designdetails)Required PFD set by Scenario 5SIF to add emergency cooling waterTO BE ADDED—see Actions/Notes

1 × 10–3

1 × 10–1

Safeguards (non-IPLs) BPCS add inhibitor and emergency cooling loops. Not independent ofinitiating event

Operator Intervention Not independent of BPCS sensors, alarms, FCE








TABLE B.9

ScenarioNumber8

EquipmentNumber

Scenario Title: Agitator seal fails with potential for leakage of VCM withpotential for fire, explosion, injuries and fatalities



Leakage from agitator seal (100–1000 lb flam-mable above atmospheric BP), with possibleinjuries and fatalities

Category 3




1 × 10–1

1 × 10–4


Seal failure1 × 10–1






Others N/A



Spot ventilation system at agitator shaft seal 1 × 10–1



1 × 10–3

Safeguards (non-IPLs) Operator Intervention Not independent of action that would be taken bySIS to de-pressure reactor.

Fume detection around seal Post event scenario and effectiveness notquantifiable





Add SIS for all 3 reactors. Install SIF with minimum PFD = 1 × 10–3 foropening vent valves on high temperature. Separate nozzles and piping foreach vent valve. Install separate nozzle and vent lines for each PSV tominimize blockage and common cause.Confirm spot ventilation at agitator shaft seal will be effective in remov-ing all leaking materials to prevent fireConsider N2 purges under all vent valves/PSVs.Responsible Group/Person/Date: Plant Technical/J. Doe/ January 20xx

Notes

PFD. These are based upon the LOPA analyses shown in Tables B.2 throughB.9. As stated earlier, these design modifications are intended for illustrativepurposes only and do not imply that the design shown in CCPS (1993b) isunsafe. Other design options could be considered.

Modification of the PSV system

It is proposed to modify the piping system so that each of the PSVs is connectedto the reactor by its own nozzle and piping system. This will ensure the inde-pendence of the PSVs and the shortstop injection system. It will also eliminatethe potential for the blockage of a single nozzle by polymer during normaloperation, or during a relief event, rendering both PSVs ineffective. Consider-ation should also be given to adding nitrogen purges under the PSVs to mini-mize the potential for polymer deposition/freezing in the piping or at the inletto the valves. If not already considered, DIERS technology should be used todetermine if two-phase flow could occur in the piping and valves during arelease. If this is feasible the piping and valves should be designed appropri-ately (Guidelines for Pressure Relief and Effluent Handling Systems, CCPS, 1998b).

These changes will allow both the PSVs and the shortstop system to beconsidered as IPLs. The PFD for the PSV system will probably be improvedsignificantly by the proposed piping changes and the addition of a nitrogenpurge—if appropriate and practical. On the other hand, it can be argued thatcharging the reactants through the common nozzle for the PSVs, the short-stop system, and the vent valve SIF increases the probability that the nozzlewill be open to those devices when needed. Chapter 11 offers guidance forfault tree analysis of protection layers that have common components.

However, in accordance with the recommendations contained in Chap-ter 6, a PFD of 1 × 10–2 will be used in the analysis shown in Tables B.2 throughB.9. This will affect the required PFD for the SIF to open the vent valves inorder to meet the risk tolerance criteria. In a company practicing this technol-ogy, testing and data might be available to use a lower PFD for the PSVsystem. This issue demonstrates that while LOPA is a powerful method, itrelies upon good engineering judgment and reliable data in order to makeappropriate risk judgments.

Modification of the Vent Valve SIF System

The same modifications for the design of the PSV system are also applicablefor the vent valve SIF system. Thus, two more new nozzles are required at thetop of the reactor. The same design issues regarding two-phase flow, poly-merization, etc., must also be addressed. As before, these changes allow boththe vent valve SIF system and the shortstop addition system to be consideredas IPLs. The assumed PFD of the PSVs (see above) and the risk tolerance crite-


ria set the PFD for the SIF system. The final design of the system (number ofsensors, final control elements, type of processor, frequency and type of test-ing, etc.) would be determined by the required PFD for this IPL. As an exam-ple, if the complete vent valve IPL (from signal detection to opening of thevent valves) was tested between each batch, the test period would be shortand the PFD, for a given design, would be improved, compared to the samedesign that was only tested every year. The practicality, cost, and manpowerrequired to perform such frequent testing would be balanced against thelower cost of a simpler system.

Human Action IPLs

Only one human action per scenario should be used as an IPL unless the anal-ysis shows there is independence of sensor, alarm, and operator. Adequatetraining, testing and procedures must be in-place for any human action to beconsidered as an IPL.


APPENDIX C

Documentation for aLOPA Study

C.1. Documentation to be Developed during LOPA

The documentation of the study should be complete and accurate to fullycapture the knowledge gained during the evolution of the scenario. It isimportant to document the full series of events required for the undesiredconsequence to occur. This allows for a review by a team, or other analysts, toassess the assumptions made and whether other protection layers may beavailable to interrupt the chain of events and reduce the risk associated with ascenario if it does not meet the corporate risk tolerance guidelines. The docu-mentation of components of a scenario can be presented in any way that anorganization prefers. The standardized values for initiating event frequency,PFD for IPLs, etc., specified by an organization should be used unless there issufficient reason to deviate from them. Any change from these specifiedvalues must be documented and approved by the personnel/group responsi-ble for LOPA quality control within an organization. The following guide-lines summarize the minimum amount of information that should beincluded. The LOPA summary sheet used throughout this book (see TableC.1) is used as the basis for this discussion, although any such form is accept-able, provided it contains the required information.

Consequence

The consequence should be documented in two ways. First, there should be adescription of the final consequence. For example, all of the following might

231

232 Appendix C. Documentation for a LOPA Study

TABLE C.1Summary Sheet for LOPA Method

Scenario Number Equipment Number Scenario Title:










Others








Notes:



be valid descriptions of the consequences of a scenario involving loss of cool-ing on a column or reactor:

• “Pressure greater than MAWP resulting in leakage from flange joints,”or

• “Pressure greater than MAWP resulting in vessel rupture,” or• “Pressure greater than MAWP resulting in release of 12,000 lb of pro-

pylene,” or• “Pressure greater than MAWP resulting in an explosion with injuries

and fatalities.”

However, these are very different from one another. It is important to bevery clear as to what consequence is being examined. If this is not done, con-fusion will arise during the analysis. For the examples noted above, therecould be significant differences in how the scenario would be developed andexamined.

Second, the consequence should be stated in terms specific to the riskassessment method being applied by the organization. This could be in termsof the amount of material released and a resulting consequence categorization,or in terms of the potential for injuries or fatalities.

Any assumptions should be stated. For example, if an overpressure wereto occur, is the consequence a catastrophic rupture, a large leak, or a smallleak from a flange? If consequence categorization is employed the release sizecould be assumed based on the contents of the system, or it could be calcu-lated by modeling. Supporting documentation should be attached or refer-enced.

Risk Tolerance Criteria

The risk tolerance criteria for the method being used should be clearly statedto provide a reference point to judge the status of the scenario. Dependingupon the method, the risk criteria may be stated in terms of a frequencyrange, or a maximum frequency acceptable for the consequence type used ina particular method.

Initiating Event

The initiating event for the scenario must be unambiguously described. Thefrequency of the initiating event must also be stated, together with the basisfor this value (standard figure, plant experience, calculation, etc.). Any otherrelevant information or assumptions should also be noted. Supporting docu-mentation, such as calculations, communications, standards, etc., should beattached or referenced to enable a review of the assumptions or calculations.

C.1. Documentation to be Developed during LOPA 233

Enabling Event or Condition

If an enabling event or condition is required in order for the initiating event toproceed, this should be described. Since these situations can be complex, it isrecommended that additional documentation explaining how the initiatingevent and enabling condition interact be attached or referenced. An event treemight be a useful form of documentation. The basis for the probabilityassumed for the enabling event or condition should be attached or refer-enced, together with any assumptions and other relevant information.

Conditional Modifiers

If the consequence basis is fatality frequency, then additional assumptionsmay be required to assess the probability that the scenario will result in afatality. This can involve consequence modeling using probabilities for

• ignition,• personnel being in affected area, and• fatal injury given exposure occurs.

The basis for these assumed values should be referenced. Any modifica-tions to standard values must be justified and documented.


This is the product of the frequency of the initiating event and the probabilityof any enabling event or condition, plus any conditional modifiers, if used. Itis a measure of the baseline risk associated with this scenario. This result isimportant, since it provides a basis from which the importance of the IPLsassociated with a particular scenario can be assessed.


The existing or proposed IPLs should be stated, together with the assumedPFD for each IPL. Supporting documentation should be attached or refer-enced. If the PFD is different from the standard value normally used withinan organization, the justification should be stated. If additional IPLs are to beinstalled, this should be cross-referenced to the “Actions Required to MeetRisk Tolerance Criteria” section (see below). If the less conservativeApproach B is used when crediting BPCS loops as IPLs, it is particularlyimportant to justify the basis for this approach (see Chapter 11).

Safeguards

If an existing safeguard is not claimed as an IPL, the justification should bestated (e.g., it is not independent of an IPL already claimed) so that the basis


for the analysis is fully understood. It is important for the team or analyst todocument all safeguards considered, to allow for review and to assist otherpersonnel in understanding LOPA concepts and conclusions.

Frequency of Mitigated Consequences

This is the frequency that the consequence is expected to occur with the IPLs inplace and with each IPL having the stated PFD value. It may be appropriate tostate two figures. The first is the mitigated event frequency with existing IPLs,and the second the mitigated event frequency with any additional IPLs added.

Risk Tolerance Criteria Met?

If the risk tolerance of the organization is met, the documentation shouldstate the actual risk and the risk tolerance criteria. The IPLs needed to meetthe risk tolerance criteria should be marked in the IPL documentation dis-cussed above.

On the other hand, if the result of the analysis is that the current systemdoes not meet the risk tolerance criteria this must be stated. Documentationshould be attached or referenced stating the acceptable risk for this scenario,so that the difference between the actual and required risk is clearly delin-eated and the necessity for remedial action is documented and tracked.

Actions Required to Meet Risk Tolerance Criteria

This section should clearly define what actions are required. The specificactions required should be defined together with the responsible person orgroup and the date when this must be completed. For example: “Add addi-tional independent BPCS loop to trip pump P-311 on Hi-Hi level (14 feet) intank T-302. Responsibility T. Jones/Operations Supervisor Tank Farm. Com-pletion Date: June 2001.” If a cost–benefit analysis, or similar documentation,has been performed or published to justify accepting a higher risk than speci-fied by the risk tolerance criteria of an organization, this must be attached orreferenced. A senior manager may be required to sign-off on such an excep-tion and, in such a case, this must be attached to the documentation. It is alsopossible that at some stage of a LOPA study, additional information may berequired to perform the calculations. All actions must be put into a trackingsystem that will report any failure to achieve the required actions. All suchdocumentation must be maintained.

Notes

This section should contain any background information, or reference suchinformation, relevant to the scenario or the required actions.

C.1. Documentation to be Developed during LOPA 235

References

Any relevant process flow diagrams, P&IDs, SIF (interlock) drawings, instru-ment tags, equipment numbers, operating procedures, test procedures, revi-sion numbers, etc. should be attached or referenced as required, toadequately document the basis for the analysis and to assist in the review orimplementation of the study. Revisions to the documents should be recordedon the sheet on a line-by-line basis.

LOPA Analyst and Team Members

Names and roles should be listed.

LOPA Documentation and Action Tracking

Once this documentation is completed it must be

• maintained so that it is available for review. This includes a policy ofapproving and tracking revisions to the documentation.

• tracked so that the recommendations and actions from the study areaddressed: either implemented or rejected with adequate documenta-tion of the reasons for their rejection.

C.2. Uses of LOPA Documentation

Once the LOPA documentation is complete it can be used for numerous pur-poses, given its concise format and rigorous basis. Some of these uses are dis-cussed in Chapter 10, but others may include

• documentation for meeting OSHA and EPA requirements,• training of engineers and operations staff,• providing a consistent approach to risk management within an organi-

zation,• other uses as developed by the organization.


APPENDIX D

Linkage with Other Publications

CCPS has published several books dealing with process safety issues in thechemical industry. LOPA can be usefully applied in several areas to providean alternate method or to address particular concerns in an objective, cost-effective manner. Relevant publications are described below.

Guidelines for Technical Management of Chemical Process Safety (CCPS,1989c) is an expansion of the 12 elements of the CCPS model and provides theframework and detailed components of the CCPS Chemical Process SafetyManagement System. This book discusses various alternatives for the imple-mentation of each of the elements and components of the CCPS model. LOPAshould be viewed as one additional tool that can be employed by manage-ment to manage process safety. Its simplified assumptions and calculationmethods coupled with the use of objective risk tolerance criteria and self-doc-umentation make it a powerful tool for such a purpose. Chapter 9 outlines theissues that should be addressed by an organization before it decides to useLOPA as part of its process safety management system.

Guidelines for Process Safety Documentation (CCPS, 1995b) providesdetailed guidance on establishing the type and amount of information to berecorded, various alternatives for developing record management systemsand record retention and retrieval programs to ensure a viable corporatememory for PSM relevant information. LOPA is a self-documenting processsince the scenario definition, initiating event frequency, number of IPLs, etc.provides a direct documentation trail. The only function not provided by theLOPA method is the closeout of recommendations—these must be effectivelymanaged by the existing process safety management system.

237

Guidelines for Safe Automation of Chemical Processes (CCPS, 1993b) exam-ines the direct or indirect applications of instrumentation and control devicesthat can prevent and/or mitigate identified unacceptable process conditions.LOPA can be used directly to determine the required safety integrity level (interms of the probability of failure on demand (PFD)) of such systems. LOPAcannot be used to determine whether a particular device or system will actu-ally achieve the specified PFD—this requires another tool. LOPA is asemiquantitative technique and its results may be less accurate than a moresophisticated technique, such as fault tree analysis. However, several compa-nies have demonstrated its effectiveness in classifying the required SIL forindividual safety functions within an SIS.

Guidelines for Hazard Evaluation Procedures, Second Edition with WorkedExamples (CCPS, 1992a) describes methods used to identify and assess the sig-nificance of hazardous situations found in process operations or activitiesinvolving hazardous chemicals. These approaches are not limited in theirapplication to the chemical manufacturing industry; they are also appropri-ate in any industry where activities create situations that have the potential toharm workers or the pubic; damage equipment, facilities or quality; orthreaten the environment through chemical releases, fires or explosions.LOPA should be considered an addition to this book as it provides a consis-tent, objective, semiquantitative method for addressing the issues covered.Generally LOPA will use scenarios developed by other methods—usuallyqualitative (HAZOP, What-If, etc.). However, companies have found thatLOPA will often uncover scenarios overlooked by other methods because ofthe rigor in applying the concept of IPLs to the scenario.

Guidelines for Chemical Process Quantitative Risk Analysis (CCPS, 1989a);Second Edition (CCPS, 2000a) show how to use the information obtained bythe hazard evaluation procedures of CCPS (1992a) to make quantitative riskestimates for the hazards identified by the techniques described in thatvolume. LOPA should be considered a simplification of the quantitative riskanalysis methods described in the CCPS CPQRA book (2000a). The simplifi-cation involves making assumptions concerning the numerical values for thecomponents of the scenario (initiating event frequency, enabling event/con-dition, number of IPLs, numeric PFD for an IPL) and in the calculation tech-niques employed. The simplifications are intended to be conservative so that,if a study were to be performed using a full quantitative analysis (event tree,fault tree, etc.), the results would show less risk associated with the scenariowhen compared to the results of a LOPA analysis. For this to be true an ana-lyst must have an understanding of the issues involved when performing afull quantitative risk analysis and what issues are important. Thus, it is highlyrecommended that this volume be read in conjunction with CCPS (2000a) andthat an analyst review the LOPA method developed by an individual organi-zation to ensure that the conservatism intended for the LOPA process is

238 Appendix D. Linkage with Other Publications

maintained. As described in Chapter 11, there are situations when a focusedquantitative study can be usefully performed on one component of a LOPAscenario to provide additional confidence in the numerical value used.

Guidelines for Engineering Design for Process Safety (CCPS, 1993a) discussesthe impact of various engineering design choices on the risk of a catastrophicaccident, starting with the initial selection of the process and continuingthrough its final design. This book is concerned with engineering design forprocess safety and addresses the need to design safety into the initial design.The book also addresses reducing risk through the use of passive and activedevices to prevent and mitigate catastrophic events. LOPA is a useful tool foruse in these areas and an understanding of its techniques would be valuableto all engineers involved in design work.

Inherently Safer Chemical Processes. A Life Cycle Approach (CCPS, 1996b)develops the concept of a safer initial design discussed in the CCPS Engi-neering Design book (CCPS, 1993a) and expands the subject. LOPA is an idealtool to assist in developing designs that have an inherently lower risk associ-ated with them, or which require the minimum number of IPLs to achieve atolerable risk. Using scenarios and the simplified assumptions and calcula-tion methods allows rapid comparisons to be made between alternativedesigns and safety philosophies.

Tools for Making Acute Risk Decisions with Chemical Process Safety Applica-tions (CCPS, 1995c) discuses methods used for decision making where riskshave been assessed. In addition to chemical process risk, other factors, includ-ing financial cost, corporate image, employment of workers, etc., may beinvolved in a decision. This book provides a collection of decision aids toassist a company. LOPA should be considered an alternate method formaking such decisions as it employs objective, quantified risk tolerance crite-ria. Some of the more qualitative factors (company image, morale, etc.)cannot be directly included, but that is also the case for all other objectivemethods. Some LOPA risk tolerance criteria include a range where acost–benefit study—or another type of judgment—is required to help decidewhether a risk should be tolerated or mitigated. Analysts using LOPA shouldbe familiar with the techniques discussed in this book.

Guidelines for Chemical Transportation Risk Analysis (CCPS, 1995a) dis-cusses quantitative assessment of transportation risks. LOPA is ideally suitedto such studies provided that the risk tolerance criteria can be specified in amanner consistent with the LOPA technique employed by the company.

Guidelines for Pressure Relief and Effluent Handling Systems (CCPS, 1998b)presents background information on pressure relief technology along withguidance for selecting relief devices and effluent handling equipment. Thisbook should be viewed as supporting the application of LOPA particularlywhen considering the appropriate PFD for relief devices (see Chapter 6).Relief devices in clean, non-fouling, non-corrosive services can have low PFD

Appendix D. Linkage with Other Publications 239

values. Conversely, those in fouling, polymeric, corrosive services can have ahigh PFD and provide a very limited degree of protection as IPLs. Practitio-ners of LOPA should be familiar with the issues discussed in this book.

Guidelines for Evaluating Process Plant Buildings for External Explosions andFires (CCPS, 1996a) provides a practical approach to identify, evaluate andmanage the process safety considerations associated with process plantbuilding design and siting. This book specifically addresses the explosionand fire impacts to process plant buildings, occupants and function. LOPA isan excellent tool for screening the risk associated with these events, providedthe risk tolerance criteria used are stated appropriately.

Guidelines for Evaluating the Characteristics of Vapor Cloud Explosions, FlashFires, and BLEVEs (CCPS, 1994a) provides an overview of the methods forestimating the characteristics of vapor cloud explosions, flash fires, and boil-ing liquid expanding vapor explosions (BLEVEs). The volume summarizesand evaluates all the current information, identifies areas where informationis lacking, and describes current and planned research in this area. This bookshould be viewed as supporting the application of LOPA by assisting indefining the consequences of a release. Analysts using LOPA should be famil-iar with the topics and methods discussed in this book.

LOPA can be used to assist in implementing the requirements of the USProcess Safety Management (PSM) of Highly Hazardous Chemicals (OSHA PSM1910.119). The rule was developed for “preventing or minimizing the conse-quences of catastrophic releases of toxic, flammable or explosive chemicals”(OSHA, 1992). The PSM regulation specifies a comprehensive safety manage-ment program that integrates technologies, procedures and managementpractices. The rule addresses process hazard assessment, specification of riskcontrol measures, evaluation of failures of these controls, documentation ofengineering controls, and scheduled maintenance to assure the on-goingintegrity of the protective equipment.

LOPA can be applied to meet the requirements of OSHA PSM 1910.119 inthe following ways:

• Process Safety Information (Section d) can be directly included or refer-enced on the LOPA sheet for each scenario to justify the values or con-sequences. Such information could include� hazards of the chemicals,� the technology of the process (particularly in the evaluation of the

consequences of deviations),� information pertaining to the equipment in the process (particularly

in relation to the relief system design and design basis, safety sys-tems, SIF (interlock), detection and suppression systems, etc.).

• Process hazard analysis (Section e) to identify, evaluate and control thehazards of the process by addressing

240 Appendix D. Linkage with Other Publications

� the hazards of the process,� engineering and administrative controls applicable to the hazards,� consequences of failure of engineering and administrative controls,� facility siting,� human factors.

• Operating procedures (Section f) by addressing� emergency shutdown procedures,� emergency operations,� operating limits (consequences of deviation and the steps required to

avoid deviation),� safety and health considerations (precautions necessary to prevent

exposure including engineering controls and administrative con-trols),

� safety systems and their functions.

• Mechanical integrity (Section j) by addressing� emergency shutdown systems,� controls (including monitoring devices, sensors, alarms and SIFs),� written procedures,� training,� inspection and testing,� quality assurance.

• Management of change (Section l) by addressing� the technical basis for the proposed change,� impact of change on safety and health,� modifications to existing equipment,� notification and documentation of change,� updating of process safety information,� updating of procedures and practices.

All of these functions can be achieved using the LOPA method with docu-mentation similar to that illustrated in this book.

Appendix D. Linkage with Other Publications 241

APPENDIX E

Industry Risk Tolerance CriteriaData

CAUTION: The risk tolerance criteria in this appendix are not exhaustiveand may be out-of-date. The data were extracted from several sources, eachpublished in different years, and hence individual quoted values may differ.It is provided to show the similarity among risk tolerance criteria around theworld. The data shown here are to be used only to provide a benchmark per-spective of a range of risk tolerance criteria. These data should not be used forregulatory compliance; contact the appropriate regulatory authority for theapplicable current criteria.

The sources were BLS (1998), Greenwood (1997), Renshaw (1990), andVROM (1995), and other industry literature sources.

243

TYPICAL DATA RELATED TO RISK TOLERANCE CRITERIA

(all values have units of probability of death per year for an individual)

Generalized USAIndustry Data

Risk for workforce from allscenarios

Risk for public from allscenarios

High risk (e.g., mining,heavy construction)

10–3 10–3 to 10–5

Low risk (e.g., engineer-ing, services)

10–5 10–5 to 10–5

General Industry (chemi-cal, manufacturing, rail,trucking)

10–4 10–4 to 10–5

Statistical Data from USA

Risk for workforce from allscenarios; derived by

dividing applicable fatalitiesby the affected population

Risk for public from allscenarios; derived by

dividing applicable fatalitiesby the affected population

Driving accidents 10–4 10–4

Airline accidents 5 × 10–7 4 × 10–6

Work-related accidents inUS industry

1.9 × 10–5 NA

All accidents in US (workand nonwork); sometimescalled “background” risk

3.5 × 10–4 3.5 × 10–4

Some regulators andmajor companies thathave set risk tolerance

criteria

Maximumtolerable riskfor workforce

from allscenarios

Negligiblerisk for

workforcefrom all

scenarios

Maximumtolerable risk

for publicfrom all

scenarios

Negligiblerisk for

public fromall scenarios

Health & Safety Executive,UK (existing industry)

10–3 10–6 10–4 10–6

VROM, The Netherlands(existing industry)

NA NA 10–5 NA

VROM, The Netherlands(new industry)

NA NA 10–6 NA

Hong Kong Government(new industry)

NA NA 10–5 NA

Santa Barbara County,CA, USA (new industry)

NA NA 10–5 10–7

Shell (onshore and off-shore; approx.)

10–3 10–6 Note 1 Note 2

BP (onshore and offshore) 10–3 10–6 Note 1 Note 2

244 Appendix E. Industry Risk Tolerance Criteria Data

Some regulators andmajor companies thathave set risk tolerance

criteria


from allscenarios

Negligiblerisk for

workforcefrom all

scenarios


for publicfrom all

scenarios

Negligiblerisk for

public fromall scenarios

ICI (onshore) 3.3 × 10–5 NA 1 × 10–4 NA

Rohm and Haas Company 2.5 × 10–5

Personal riskto specificemployee

NA 1 × 10–5 1 × 10–7

Typical criteria used withLOPA

(Note 3)


Negligiblerisk for

workforce


for public

Negligiblerisk forpublic

For ALL scenariosaffecting an individual

10–3 10–5 10–3 10–5

For any ONE scenarioaffecting an individual(most useful for LOPA)

10–4 10–6 10–4 10–6

Note 1: Not available, but typically industry uses a value that is an order of magnitude lower thanworkplace risk

Note 2: Not available, but typically industry uses the same value used for workplace risk, since thevalue is already in the region where risk calculations become meaningless

Note 3: Many company criteria require that scenarios capable of causing multiple fatalities or causinggreater than US$10 million damage/harm must be evaluated using QRA

NA: Means either not available or not applicable.

Appendix E. Industry Risk Tolerance Criteria Data 245

APPENDIX F

High Initiating Event FrequencyScenarios

Calculations for High Initiating Event Frequency Scenarios

Equation (7-1) is applicable to calculate the frequency of the consequence forscenarios in which the initiating event frequency is less than twice the testfrequency—also called “low demand mode.” The initiating event frequencyis multiplied by the IPL PFDs. “High demand mode” occurs when the chal-lenge frequency to an IPL is higher than twice the test frequency for the IPL(IEC 61511, Part 1; IEC 2001). For example, the IPL is tested once a year andthere are more than two demands per year.

For high demand mode, a different equation is needed, shown in Equa-tion (F-1) for a scenario with one IPL:

f fiC

ii= IPL 1 (F-1)

where


fiiIPL 1 is the failure frequency for the one IPL that protects against conse-

quence C for initiating event i.

If there are multiple IPLs, the failure frequency for the first IPL should becompared to the test frequency of the second IPL. If it is low demand mode,then Eq. (7-1) can be used, substituting the first IPL failure frequency in placeof the initiating event frequency, and omitting the PFD for first IPL.

The CCPS CPQRA book (CCPS, 2000a) and Kumamoto and Henley(1996) provide guidance to calculate the IPL failure rate and the IPL PFD.However, for LOPA, the IPL PFD may be known but the IPL failure rate may

247

not be readily available. A simple approach is to use Eq. (7-1) and to set theinitiating event frequency to twice the IPL test frequency. The basis for thisapproach will be illustrated in Example F.1 and Figure F.1, and is discussedbelow.

Example F.1

A small tank is filled from a large tank 1400 times per year. In the past, the

operator watched a local level gauge and closed a manual valve at the right

amount. After an overflow incident, a level sensor, logic solver and auto-

matic valve were added as an IPL to detect high level and stop the fill. The

IPL is tested annually and has a PFD of 1 × 10–2. It was intended that the

operator would continue to monitor the local level gauge and close the

manual valve. The demand on the IPL would be 1400 fills/yr × 0.001 proba-

bility of operator error/fill = 1.4 demands/yr. Thus the IPL is in low demand

mode and the frequency of overflow would be 1.4 demands/yr × 1 × 10–2

PFD = 1.4 × 10–2/yr.

Human nature being what it is, the operator found other tasks to do while

the tank was filling and relied on the IPL to stop the flow. Now the IPL was

in high demand mode with 1400 demands per year. Using the low demand

equation (7-1) with the apparent initiating event frequency gives too high a

number:

1,400 charges/yr × (IPL PFD 1 × 10–2) = 14

overflows per year per tank (unreasonable)! Actual experience is much

less.

Instead, the high demand equation (7-8) should be used. The operator

starts the flow, and if the IPL fails, the tank will overflow. This IPL has a fail-

ure rate (to danger) of 2 × 10–2/yr. Using Eq. (7-8) and setting the LOPA initi-

ating cause frequency to the failure rate of the IPL gives 2 × 10–2

overflows/yr. If there are 100 tanks like this in the organization, an overflow

would be expected about twice a year.

Alternatively, using Eq. (7-1) with the initiating event frequency set to twice

the test frequency gives:

2/yr × (IPL PFD 1 × 10–2) = 2 × 10–2 /yr

The unmodified Eq. (7-1) is not applicable for high demand because thehigh number of demands on the IPL will detect a failure in the IPL well beforethe regular test of the IPL. Kletz (1985) provides additional examples, includ-ing the source for Example F.2.

Example F.2

Consider the brakes on a car. The consequence is that the car does not stop.

Kletz (1985) suggests a guessed demand rate (initiating event frequency) of

1 × 104 /yr. The failure rate for the brakes is typically 0.1/yr. The PFD for the

248 Appendix F. High Initiating Event Frequency Scenarios

brakes would be about 2.6 × 10–2. Annual inspection and test of the brakes

is required in some locations. Using the low demand equation (7-1) with

the apparent initiating event frequency gives 1 x 104 /yr × 2.6 × 10–2 PFD =

2.6 × 102 /yr, or 260/yr! Actually, the frequency of the car not stopping is

0.1/yr, or once in 10 years.

Kletz presents a formula for the frequency of consequence for both lowand high demand:

f f eiC

iDTi= − −IPL 1 1 2( ) (F-2)

where


fiiIPL 1 is the failure frequency for the one IPL that protects against conse-

quence C for initiating event i.

D is the demand rate at which the IPL is required to act (yr–1); for ascenario with one IPL, this is the initiating event frequency.

T is the test interval for the IPL (year)

Appendix F. High Initiating Event Frequency Scenarios 249

FIGURE F.1. Calculations for high demand mode. Test frequency of IPL = 1/yr.Note that the low demand equation (7-1) gives the same frequency of consequenceas the high demand equation (F-1) when the demand frequency equals twice the testinterval.

Figure F.1 shows a graph of Eq. (7-1) (low demand), Eq. (F-1) (highdemand), and Eq. (F-2) for the scenario in Example F.1. The transition fromthe low demand equation to the high demand equation occurs at 2 demandsper year, or a demand frequency equal to twice the test frequency. This transi-tion illustrates the concept of setting a high demand initiating event to a fre-quency of twice the IPL test frequency. While Eq. (F-2) can be used for bothhigh and low demand, it underpredicts the consequence frequency near thetransition between high and low demand. For some applications of LOPA,this approximation may be close enough.

250 Appendix F. High Initiating Event Frequency Scenarios

HIGH DEMAND MODE

The challenge frequency to an IPL is higher than twice the test frequency for

the IPL.

The frequency of consequence or frequency of challenge to next IPL is

• Failure frequency of the IPL, or

more simply, for the first IPL,

• 2 × (IPL test frequency, per yr) × (IPL PFD)

APPENDIX G

Additional Reading

G.1. General Risk

Bernstein, Peter L. (1998), Against the Gods: The Remarkable Story of Risk, New York:

John Wiley and Sons, Inc.

Philley, J. O. (1992), “Acceptable Risk—An Overview,” Plant/Operations Progress, 11, 4.

Stickles, P. (1998), “How Much Safety Is Enough?,” Hydrocarbon Processing, October.

G.2. Target Risk

Alder, W. A. T., and Ashurst, J. A. S. (1992), “The Development of Risk Criteria for

Application to New Industries,” International Conference on Hazard Identification

and Risk Analysis, Human Factors and Human Reliability in Process Safety, Orlando,

FL, January, New York: American Institute of Chemical Engineers.

Summers, A. (1997), “Techniques for Assigning a Target Safety Integrity Level,” ISA

TECH/EXPO, Anaheim, California, October 7–9.

G.3. General Interest

Bhimavarapu, K. R., Stavrianidis, P. (2000), “Safety Integrity Level Analysis for Pro-

cesses—Issues and Methodologies,” Process Safety Progress, 19, 1.

Cheddie, H., and J. A. Cusimano (1997), “Applying a SIS to Fired Heater,” ISA


Gibson, S. B. (1992), “A Comprehensive Review of Alarm and Interlock Testing,”

International Conference on Hazard Identification and Risk Analysis, Human Factors

251

and Human Reliability in Process Safety, Orlando, FL, January, New York: American

Institute of Chemical Engineers.

Gruhn, P. (1999), “Accidents Lead to Modern Safety Instrumented Systems,” InTech,

46, 1, January.

Hill, R. (1991), “The Role of Instrumentation and Process Controls in Minimizing Acci-

dental Releases,” Plant/Operations Progress, 10, 3, July.

Langford, C. (1997), “The Control Valve as the Safety Interlock Valve,” ISA


G.4. Instruments and Safety Instrumented Systems(Interlocks) Design

Beckman, L. V. (1995), “Match Redundant System Architectures with Safety Require-

ments,” Chemical Engineering Progress, Dec.

Beckman, L. (1997), “Determining the Required Safety Integrity Level for Your Pro-

cess,” ISA TECH/EXPO, Anaheim, California, October 7–9.

Dowell, A. M., III, and D. L Green, (1998), “Formulate Emergency Shutdown Systems

by Cookbook,” Chemical Engineering Progress, April.

Drake, E. M., and C. W. Thurston, (1993), “A Safety Evaluation Frame Work for Pro-

cess Hazards Management in Chemical Facilities with PES-based Controls,” Pro-

cess Safety Progress, 12, 2.

Gray, J. (1994), “A Design Process for Safety Interlock Systems,” International Sympo-

sium and Workshop on Safe Chemical Process Automation, Houston, Texas, Septem-

ber. New York: American Institute of Chemical Engineers.

Huff, A. N. and R. L. Montgomery (1997), “A Risk Assessment Methodology for Eval-

uating the Effectiveness of Safeguards and Determining Safety Instrumented

System Requirements,” International Conference and Workshop on Risk Analysis in

Process Safety, October 21–24, 1997, Atlanta, GA, pp. 61–74. New York: American


Moosemiller, M., and W. H. Brown (1997), “Finding an Appropriate Level of Safety

Guards,” International Conference and Workshop on Risk Analysis in Process Safety,

Atlanta, October. New York: American Institute of Chemical Engineers.

Stanrianidis, P., and K. Bhimavarapu, (1998), “Safety Instrumented Functions and

Safety Integrity Levels (SIL),” ISA Transactions, 37, pp. 337–351.

Thurston, C. W. (1994), “Automation in Chemical Plant Safety: A Design Philosophy,”

International Symposium and Workshop on Safe Chemical Process Automation, Hous-

ton, Texas, September. New York: American Institute of Chemical Engineers.

G.5. International Topics

Ale, B. J. M. (1992), “The Implementation of an External Safety Policy in the Nether-

lands,” International Conference on Hazard Identification and Risk Analysis, Human

252 Appendix G. Additional Reading

Factors and Human Reliability in Process Safety, Orlando, Florida, January. New

York: American Institute of Chemical Engineers.

Bell, R. (1994), “Safety in Chemical Process Automation: HAS Approach (4),” Interna-

tional Symposium and Workshop on Safe Chemical Process Automation, Houston,

Texas, September. New York: American Institute of Chemical Engineers.

G.6. SIS Design as Part of the PHA Process

Gardner, R. J. and M. R. Reyne (1994), “Selection of Safety Interlock Integrity Levels as

Part of Design Process Hazard Reviews,” International Symposium and Workshop

on Safe Chemical Process Automation, Houston, Texas. September. New York:

American Institute of Chemical Engineers.

Powell, R. L. (1994) “Process Safety and Control Systems Integrity Levels as Part of

Design Process Hazard Reviews,” International Symposium and Workshop on Safe

Chemical Process Automation, Houston, Texas. September. New York: American


G.7. Cost–Benefit Analysis—Solution Prioritization

Garcia, A. A., and D. E. Lewis (1998), “Safety Instrumented System Design Using

Risk—Benefit Evaluation,” International Conference and Workshop on Reliability and

Risk Management, San Antonio, TX, September. New York: American Institute of

Chemical Engineers.

Stevens, G. and R. P. Stickles (1992), “Prioritization of Safety-Related Plant Modifica-

tions Using Cost-Risk Benefit Analysis,” International Conference on Hazard Identi-

fication and Risk Analysis, Human Factors and Human Reliability in Process Safety,

Orlando, Florida, January. New York: American Institute of Chemical Engineers.

Appendix G. Additional Reading 253

References

American Chemistry Council (2000), “Responsible Care® Process Safety Code of

Management Practices,” Washington, DC: American Chemistry Council.

ASME (1995),“Pressure Vessels with Overpressure Protection by System Design,”

Section VIII, Divisions 1 and 2, ASME Code Case 2211, The 1995 Boiler Pressure Vessel

Code. New York: American Society of Mechanical Engineers.

Bridges, William G., and Tom R. Williams (1997), “Risk Acceptance Criteria and Risk

Judgment Tools Applied Worldwide within a Chemical Company,” International

Conference and Workshop on Risk Analysis in Process Safety, October 21–24, 1997,

Atlanta, GA, pp. 13–28. New York: American Institute of Chemical Engineers.

Bridges, William G. (2000a), Course 209, Layer of Protection Analysis. Knoxville, TN:

Risk Consulting Division, ABS Consulting.

Bridges, William G. (2000b), “Getting Near Misses Reported,” Process Industry Inci-

dents: Investigation Protocols, Case Histories, Lessons Learned, October 3–6, 2000,

Orlando, FL, pp. 379–399. New York: American Institute of Chemical Engineers.

BLS (1998), Toscano, Guy, and Janice Windau, “Profiles of Fatal Work Injuries in 1996”

Washington, DC: Bureau of Labor Statistics.

CCPS (1989a), Guidelines for Chemical Process Quantitative Risk Analysis, New York:

American Institute of Chemical Engineers, Center for Chemical Process Safety.

CCPS (1989b), Guidelines for Process Equipment Reliability Data, New York: American

Institute of Chemical Engineers, Center for Chemical Process Safety.

CCPS (1989c), Guidelines for Technical Management of Chemical Process Safety, New York:


CCPS (1992a), Guidelines for Hazard Evaluation Procedures, Second Edition with Worked

Examples, New York: American Institute of Chemical Engineers, Center for

Chemical Process Safety.

255

CCPS (1992b), Guidelines for Investigating Chemical Process Incidents, New York: Ameri-

can Institute of Chemical Engineers, Center for Chemical Process Safety.

CCPS (1993a), Guidelines for Engineering Design for Process Safety, New York: American

Institute of Chemical Engineers, Center for Chemical Process Safety.

CCPS (1993b), Guidelines for Safe Automation of Chemical Processes, New York: Ameri-


CCPS (1994a), Guidelines for Evaluating the Characteristics of Vapor Cloud Explosions,

Flash Fires and BLEVEs, New York: American Institute of Chemical Engineers,

Center for Chemical Process Safety.

CCPS (1994b), Guidelines for Preventing Human Error in Process Safety, New York:


CCPS (1995a), Guidelines for Chemical Transportation Risk Analysis, New York: Ameri-


CCPS (1995b), Guidelines for Process Safety Documentation, New York: American Insti-

tute of Chemical Engineers, Center for Chemical Process Safety.

CCPS (1995c), Tools for Making Acute Risk Decisions with Chemical Process Safety Applica-

tions, New York: American Institute of Chemical Engineers, Center for Chemical

Process Safety.

CCPS (1996a), Guidelines for Evaluating Process Plant Buildings for External Explosions

and Fires, New York: American Institute of Chemical Engineers, Center for Chem-

ical Process Safety.

CCPS (1996b), Inherently Safer Chemical Processes: A Life Cycle Approach, New York:


CCPS (1998a), Guidelines for Design Solutions for Process Equipment Failures, New York:


CCPS (1998b), Guidelines for Pressure Relief and Effluent Handling Systems, New York:


CCPS (1999), Guidelines for Consequence Analysis of Chemical Releases, New York: Amer-

ican Institute of Chemical Engineers, Center for Chemical Process Safety.

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

New York: American Institute of Chemical Engineers, Center for Chemical Pro-

cess Safety.

CCPS (2000b), Evaluating Process Safety in the Chemical Industry: A User’s Guide to Quan-

titative Risk Analysis. New York: American Institute of Chemical Engineers,

Center for Chemical Process Safety.

CCPS (2000c), “Workshop: S84, Related Standards, and Layers of Protection Analy-

sis,” January 11, Tampa, FL. New York: American Institute of Chemical Engi-

neers, Center for Chemical Process Safety.

CCPS (2001), Handling Uncertainty: Managing Risk, New York: American Institute of

Chemical Engineers, Center for Chemical Process Safety, in preparation.

Dowell, A. M., III (1997), “Layer of Protection Analysis: A New PHA Tool, After

Hazop, Before Fault Tree,” International Conference and Workshop on Risk Analysis

256 References

in Process Safety, October 21–24, 1997, Atlanta, GA, pp. 13–28. New York: Ameri-

can Institute of Chemical Engineers.

Dowell, A. M., III, (1998), “Layer of Protection Analysis for Determining Safety Integ-

rity Level,” ISA Transactions 37, pp. 155–166.

Dowell, A. M., III (1999a), “Layer of Protection Analysis—A Worked Distillation

Example,” ISA Tech/1999 Philadelphia, PA. Research Triangle Park, NC: Instru-

ment Society of America.

Dowell, A. M., III (1999b), “Layer of Protection Analysis and Inherently Safer Pro-

cesses,” Process Safety Progress, 18, 4, 214–220.

EuReData (1989), Reliability Data Collection and Use in Risk and Availability Assessment,

Proceedings of the 5th EuReData Conference, Heidelberg, Germany April 9–11,

1986. Edited by H. J. Wingender. Berlin: Springer-Verlag.

Ewbank, Rodger M., and Gary S. York (1997), “Rhône-Poulenc Inc. Process Hazard

Analysis and Risk Assessment Methodology,” International Conference and Work-

shop on Risk Analysis in Process Safety, October 21–24, 1997, Atlanta, GA, pp. 61–74.

New York: American Institute of Chemical Engineers.

Fryman, C. (1996), “Managing HAZOP Recommendations Using an Action Classifica-

tion Scheme,” AIChE Spring National Meeting, New Orleans, February 25–29, 1996.

New York: American Institute of Chemical Engineers.

Fuller, Brad, and Edward M. Marszal (1999), “Quantitative Consequence Analysis for

Safety Integrity Level Selection,” ISA Tech/1999 Philadelphia, PA. Research Trian-

gle Park, NC: Instrument Society of America.

Greenwood, Brian, et al (1997), “Risk Criteria for Use in Quantitative Risk Analysis,”

International Conference and Workshop on Risk Analysis in Process Safety, October

21–24, 1997, Atlanta, GA, pp. 29–40. New York: American Institute of Chemical

Engineers.

Huff, Andrew M., and Randal L. Montgomery (1997), “A Risk Assessment Methodol-

ogy for Evaluating the Effectiveness of Safeguards and Determining Safety

Instrumented System Requirements,” International Conference and Workshop on

Risk Analysis in Process Safety, October 21–24, 1997, Atlanta, GA, pp. 111–126. New

York: American Institute of Chemical Engineers.

IEC (1998), IEC 61508, Functional Safety of Electrical / Electronic / Programmable Electronic

Safety-related Systems, Parts 1–7, Geneva: International Electrotechnical Commission.

IEC (2001), IEC 61511, Functional Safety Instrumented Systems for the Process Industry

Sector, Parts 1–3. (Draft in Progress), Geneva: International Electrotechnical Com-

mission.

IEEE (1984), ANSI/IEEE Standard 500-1994: Guide to the Collection and Presentation of

Electrical, Electronic, and Sensing Component Reliability Data For Nuclear-Power Gen-

erating Stations. IEEE Standards Association, Piscataway, NJ: Institute of Electri-

cal and Electronic Engineers.

ISA (1995), ANSI/ISA-91.01-1995: Identification of Emergency Shutdown Systems and Con-

trols that are Critical to Maintaining Safety in Process Industries, Research Triangle

Park, NC: Instrument Society of America.

References 257

ISA (1996), ANSI/ISA-84.01-1996: Application of Safety Instrumented Systems for the Pro-

cess Industries, Research Triangle Park, NC: Instrument Society of America.

ISA (2001), ISA TR84.0.02, draft. Safety Instrumented Systems (SIS)—Safety Integrity

Level (SIL) Evaluation Techniques, Research Triangle Park, NC: Instrument Society

of America. (Projected 2001.)

Kletz, Trevor (1985), “Eliminating Potential Process Hazards,” Chemical Engineering,

New York: Chemical Week Publishing, 1985.

Kumamoto, Hiromitsu, and Ernest J. Henley (1996), Probabilistic Risk Assessment and

Management for Scientists and Engineers, Second Edition, New York: The Institute of

Electrical and Electronic Engineers, Inc, 1996.

Leonard, C. Ronald, and Peter N. Lodal (1998) “Using Reliability Based Inspection

(RBI) as a Means for Safety Data Collection,” CCPS International Conference and

Workshop on Reliability and Risk Management, September, 1998, San Antonio, TX,

pp. 47–62. New York: American Institute of Chemical Engineers.

Lorenzo, Donald M., and William G. Bridges (1997), “Playing the Killer Slot Machine

(A Tutorial on Risk),” International Conference and Workshop on Risk Analysis in Pro-

cess Safety, October 21–24, 1997, Atlanta, GA, pp. 53–60. New York: American

Institute of Chemical Engineers, New York, 1997.

OREDA (1989), Offshore Reliability Data Handbook, 1st ed., OREDA Participants, Høvik,

Norway: Pennwell Books.

OREDA (1992), Offshore Reliability Data Handbook, 2nd ed., OREDA Participants, Høvik,

Norway: Det Norske Veritas.

OREDA (1997), Offshore Reliability Data Handbook, 3rd ed., OREDA Participants, Høvik,

Norway: Det Norske Veritas.

OSHA (1992), “29 CFR Part 1910: Process Safety Management of Highly Hazardous

Chemicals; Explosives; Blasting Agents; Final Rule.” Federal Register 57, 36 (Feb-

ruary 24) 6356–6417.

Renshaw, F. M. (1990), “A Major Accident Prevention Program,” Plant/Operations

Progress, 9 (3), 194–197.

Swain, A. D., and H. E. Guttman (1983), Handbook of Human Reliability Analysis with

Emphasis on Nuclear Power Plant Applications. NUREG/CR-1278. Washington, DC:

United States Nuclear Regulatory Commission.

VROM (1995), Pikan. M. J., and M. A. Seaman “A Review of Risk Control,” Zoetmeer,

The Netherlands: Ministerie VROM Directie SVS. Report Number SVS 1994/27.

Windhorst, Jan C.A. (1998), “Over-pressure Protection by Means of a Designed

System Rather Than Pressure Relief Devices,” CCPS International Conference and

Workshop on Risk Analysis in Process Safety, October 21–24, 1997, Atlanta, GA, pp.

191–204. New York: American Institute of Chemical Engineers.

258 References

Glossary of Terms

BPCS Basic Process Control System (BPCS): A system thatresponds to input signals from the process and/or froman operator, and generates output signals, causing theprocess to operate in the desired manner. The BPCS con-sists of a combination of sensors, logic solvers, processcontrollers, and final control elements which automati-cally regulate the process within normal productionlimits. Includes a HMI (human machine interface). Alsoreferred to as process control system.

Note 1: BPCS logic solvers execute state control func-tions (i.e., On–Off) such as alarms and automaticinterlocks.

Note 2: BPCS process controllers execute continuouscontrol functions such as pressure and flow regula-tion at a setpoint value.

Per IEC 61511, Part 1, (IEC, 2001) the BPCS does not per-form any safety instrumented functions with a claimedSIL 1.

ChemicalProcessQuantitativeRisk Assessment

The systematic development of numerical estimates ofthe expected risk from potential scenarios in a chemicalprocessing facility, including the distribution network,using engineering evaluation and mathematical tech-niques. The risk assessment may be used to make deci-sions, particularly when mitigation of risk is considered.Abbreviated as QRA or CPQRA.

259

Common Causeor CommonMode Failure

Failure, which is the result of one or more events, caus-ing coincident failures in multiple systems or on two ormore separate channels in a multiple channel system,leading to system failure. The source of the commoncause failure may be either internal or external to the sys-tems affected. Common cause failure can involve the ini-tiating event and one or more safeguards, or theinteraction of several safeguards.

Consequences A measure of the expected effects of an event.

Enabling Event An event that makes possible another event.

Event An occurrence involving the process caused by equip-ment performance or human action, or by an occurrence

external to the risk control system.

Final ControlElement

A device that manipulates a process variable to achievecontrol. Examples are:1. control valve;2. emergency block valve (EBV);3. motor starter of a pump.

Frequency Number of occurrences of an event per unit time.

HazardEvaluation

The analysis of the significance of hazardous situationsassociated with a process or activity. Uses qualitativetechniques to pinpoint weaknesses in the design andoperation of facilities that could lead to accidents, and tojudge risk qualitatively.

Impact The ultimate potential result of a hazardous event.Impact may be expressed in terms of numbers of injuriesor fatalities, environmental or property damage, or busi-ness interruption.

IndependentProtection Layer(IPL)

A device, system, or action that is capable of preventinga scenario from proceeding to the undesired conse-quence regardless of the initiating event or the action ofany other protection layer associated with the scenario.Independent means the performance of the protectionlayer is not affected by the initiating event and is notaffected by failures of other protection layers. The effec-tiveness and independence of an IPL should be auditable.

Initiating Event The event that initiates the scenario leading to the unde-sired consequence.

260 Glossary of Terms

LOPA Layer of Protection Analysis: A process (method,system) of evaluating the effectiveness of independentprotection layer(s) in reducing the likelihood or severityof an undesirable event.

Logic Solver The portion of the BPCS or SIS (Safety InstrumentedSystem) that performs state control, i.e., executes logicfunctions. Logic solvers in the SIS are typically fault-tol-erant PLCs (programmable logic controllers); a singlecentral processing unit in the BPCS may perform bothcontinuous process control and state control functions.

Mitigation The act of causing a consequence to be less severe.

PFD Probability of failure on demand. The probability that asystem will fail to perform a specified function on demand.

PHA Process hazard analysis. A hazard evaluation of broadscope that identifies and qualitatively analyzes the sig-nificance of hazardous situations associated with a pro-cess or activity.

Prevention The act of causing an event not to happen.

Probability The expression for the likelihood of occurrence of anevent or an event sequence during an interval of time orthe likelihood of the success or failure of an event on testor on demand. Probability is expressed as a dimen-sionless number ranging from 0 to 1.

Protection Layer A device, system, or action that is capable of preventing ascenario from proceeding to the undesired consequence.

Risk A measure of potential economic loss, human injury orenvironmental insult in terms of the frequency of theloss or injury occurring and the magnitude of the loss orinjury if it occurs.

Risk Analysis The development of a quantitative estimate of risk basedon engineering evaluation and mathematical techniquesfor combining estimates of initiating event frequencyand independent protection layers and consequences.(CCPS 2000a)

Risk Assessment The process by which the results of an analysis are usedto make decisions, either through relative ranking of riskreduction strategies or through comparison with risktargets.


Root Cause An underlying system-related (the most basic) reasonwhy an incident occurred.

Safeguard Any device, system or action that either would likelyinterrupt the chain of events following an initiatingevent or that would mitigate the consequences.Note: A safeguard may not meet the requirements of anIPL.

Safety CriticalActions

Specific steps humans take that provide layers of protec-tion to lower the risk category of a specific scenario orscenarios from “unacceptable” to “acceptable” asdefined by organizational risk tolerance criteria. Some-times called “administrative control.” Such steps thatfurther reduce the risk below “acceptable” might not bedesignated as safety critical actions.

Safety CriticalEquipment

Engineering controls that provide layers of protection tolower the risk category of a specific scenario or scenariosfrom “unacceptable” to “acceptable” as defined by orga-nizational risk tolerance criteria. Engineering controlsthat further reduce the risk below “acceptable” mightnot be designated as safety critical equipment.

Scenario An event or sequence of events that results in undesir-able consequences.

Sensor Field measurement system (instrumentation) capable ofdetecting the condition of a process. For example,

• pressure transmitter;• level transmitter;• toxic gas detectors.

SIF Safety instrumented function. A combination of sensors,logic solver and final elements with a specified safetyintegrity level that detects an out-of-limit (abnormal)condition and brings the process to a functionally safestate without human intervention, or by initiating atrained operator response to an alarm. The SIF

• protects against a specific hazard,• performs a specific safety function,• has a defined range of probability of failure on

demand (PFD) related to a specific SIL,• is independent from other protection or mitiga-

tion systems.

262 Glossary of Terms

SIL Safety integrity level. A performance criterion for a SIFdefining the probability of the SIF failing to perform itsfunction on demand.

SafetyIntegrity LevelDemand Modeof Operation

AverageProbability of

Failure on Demand Risk Reduction

4 ≥10–5 to 10–4 >10,000 to ≤100,000

3 ≥10–4 to 10–3 >1,000 to ≤10,000

2 ≥10–3 to 10–2 >100 to ≤1,000

1 ≥10–2 to 10–1 >10 to ≤100

See IEC 61511, Part 1 (IEC 6511) for SILs for ContinuousMode of Operation

SIS Safety instrumented system. A combination of sensors,logic solver and final elements that performs one ormore safety instrumented functions.

Validation The activity of demonstrating that the safety instru-mented system under consideration, after installation,meets in all respects the safety requirements specifica-tion for that safety instrumented system.

Verification The activity of demonstrating by analysis and/or test,that, for the specific inputs, the deliverables meet, in allrespects, the objectives and requirements set forth by thefunctional specification.


Index

AAction tracking, documentation, 236Active independent protection layer (IPL),

94–95, 96. See also Independentprotection layer (IPL)

Additional outcomes, scenario frequencydetermination, 116–118

Adjustments, frequency rates, 72Advanced topics, 173–190

basic process control system, IPLs and,173–184

exampleshexane storage tank overflow, 183–184hexane surge tank overflow, 182–183

F/N curve plots, 186–187focused fault tree/event tree analysis,

189–190multiple risk summation, 184–186normal operations as “tests,” 189operator response issues, 188

Alarms, independent protection layer (IPL),77

Alternative uses, 163–172capital improvement planning, 164–165change management, 165emergency isolation valve needs, 170–171emergency response planning, 167incident investigation, 172mechanical integrity program/risk-based

inspection/risk-based maintenanceprograms, 166

overpressure protection, design basis for,167–169

risk-based operator training, 166–167safety system bypass or removal, 171–172

SIL for SIF determination, 172siting risks evaluation, 169–170

American Institute of Chemical Engineers(AIChE), xi

Assessment, independent protection layer(IPL), 88–90

Auditabilityindependent protection layer (IPL) rules,

88worked examples, 219–220

BBasic process control system (BPCS)

advanced topics, 173–184independent protection layer (IPL), 77, 95,

97Blast walls, independent protection layer

(IPL), 78

CCalculated risk, scenario risk tolerance

compared, risk decision making,133–136

Capital improvement planning, alternativeuses, 164–165

Category approach, without human harm,consequence evaluation approaches,33–36

Cause-consequence pair, LOPA function,12–13

Center for Chemical Process Safety (CCPS),activities of, xi–xii

Change management, alternative uses, 165Chemical process quantitative risk

assessment (CPQRA)

265

LOPA function, 13, 15LOPA limitations, 25

Community emergency responseindependent protection layer (IPL), 78–79risk decision making, 132

Component failure data, LOPAimplementation, 154

Conditional modifiersdocumentation, 234worked examples, 215–216

Consequence and severity estimation, 31–42consequence endpoints, 31–32consequence evaluation approaches, 32–40

category approach without human harm,33–36

qualitative estimates with human harm,36

qualitative estimates with human harmwith adjustments for postreleaseprobabilities, 36, 38

quantitative estimates with humanharm, 38–40

examples, 40–42hexane storage tank overflow, 41–42hexane surge tank overflow, 40–41

Consequence datadocumentation, 231–233LOPA implementation, 153–154

Consequence endpoints, consequence andseverity estimation, 31–32

Consequence evaluation approaches, 32–40category approach without human harm,

33–36qualitative estimates with human harm, 36qualitative estimates with human harm

with adjustments for postreleaseprobabilities, 36, 38

quantitative estimates with human harm,38–40

Cost-benefit analysis, risk decision making,132, 137

Cumulative risk criteria, scenario risk criteriacompared, risk decision making,139–140

Current practices, LOPA implementation,152–153

DData requirements, LOPA implementation,

153–155Decision making. See Risk decision makingDeluges, independent protection layer (IPL),

101Design modifications, worked examples,

229–230Dikes, independent protection layer (IPL), 78Documentation

action tracking and, 236

conditional modifiers, 234enabling events/conditions, 234independent protection layer (IPL), 234LOPA steps, 16–24LOPA study, 231–236

consequence, 231–233initiating event, 233risk tolerance, 233

mitigated consequence frequency, 235risk tolerance criteria, 235safeguard, 234–235scenario development, 49–52unmitigated consequence frequency, 234uses of, 236

EEffectiveness

independent protection layer (IPL) rules,80–81

worked examples, 216–218Emergency isolation valve needs, alternative

uses, 170–171Emergency response

community, 78–79planning for, alternative uses, 167plant, 78

Enabling events/conditionsdocumentation, 234initiating event identification, 67–68worked examples, 215

Equipment-related initiating event,identification of, 64–65

Event tree/focused fault tree analysis,advanced topics, 189–190

Expert judgment, risk decision making, 137External initiating event, identification of, 64

FFacility siting risks evaluation, alternative

uses, 169–170Failure rate data

initiating events derived from, frequencyestimation, 70

selection of, frequency estimation, 69–70sources of, frequency estimation, 68–69

Failure rate expression, initiating eventidentification, 73

Firefighting systems, independent protectionlayer (IPL), 101

F/N curve plots, advanced topics, 186–187Foam systems, independent protection layer

(IPL), 101Focused fault tree/event tree analysis,

advanced topics, 189–190Frequency estimation (initiating event

identification), 68–73. See alsoScenario frequency determination

adjustments, 72

266 Index

failure rate data sources, 68–69failure rate selection, 69–70high demand mode, 73initiating events derived from failure data,

70LOPA use, 70, 71time at risk, 70, 72

HHazard and operability study (HAZOP)

LOPA implementation, 24, 153LOPA limitations, 25scenario development, 52–59scenario identification, 47–48

Hazard evaluations, scenario identification,47–48

Hexane storage tank overflow (continuingexample)

advanced topics, 183–184consequence and severity estimation, 41–42example introduced, 28–30independent protection layer (IPL), 111–113

summary sheets, 106–109initiating event identification, 74risk decision making, 141–147scenario development, 61–62

HAZOP, 52–59scenario frequency determination, 126–127,

129–130summary sheets for, 191–210

Hexane surge tank overflow (continuingexample)

advanced topics, 182–183consequence and severity estimation, 40–41example introduced, 27–28independent protection layer (IPL), 109–111

summary sheets, 106–109initiating event identification, 73risk decision making, 140–141, 142, 144scenario development, 59–60

HAZOP, 52–59scenario frequency determination, 125–126,

128–129summary sheets for, 191–210

High demand modecalculations for, 247–250frequency estimation, 73scenario frequency determination, 121–122

Human error rates, LOPA implementation,154–155

Human failure-related initiating event,identification of, 65

Human harmqualitative estimates with

adjusted for postrelease probabilities,consequence evaluation approaches,36, 38

consequence evaluation approaches, 36

quantitative estimates with, consequenceevaluation approaches, 38–40

Human interventionalarms and, independent protection layer

(IPL), 77design modification, worked examples,

230independent protection layer (IPL),

103–104operator response issues, advanced topics,

188

IImplementation, 151–162

current practices, 152–153data requirements, 153–155

component failure data, 154consequence data, 153–154human error rates, 154–155incident data, 155

hazard and operability study (HAZOP),24

IPL audits, 155readiness evaluation, 151–152risk tolerance criteria, 156–158tasks in, 158–162

LOPA guidance document, 160pilot tests, 161risk tolerance criteria documentation,

158–159software, 162step-by-step procedure, 160–161training requirements, 162

timing in use of, 158Incident data, LOPA implementation, 155Incident investigation, alternative uses, 172Independence

independent protection layer (IPL) rules,81–88

worked examples, 218–219Independent protection layer (IPL)

advanced topics, basic process controlsystem, IPLs and, 173–184

alarms and intervention, 77assessment, 88–90

PFD value, 89–90safeguard/IPL, 88–89

audits of, LOPA implementation, 156credit requirements, calculated

risk/scenario risk tolerancecompared, 136, 139, 144–147

defined, 75documentation, 234effectiveness of, 76emergency response

community, 78–79plant, 78

examples, 90–104

Index 267

active, 94–95, 96basic process control system (BPCS), 95,

97human intervention, 103–104instrumented systems, 95mitigating systems, 101passive, 91–94pressure relief devices, 101–102safety instrumented system (SIS), 98–100vendor installed safeguards, 101

examples (continuing), 106–113hexane storage tank overflow, 111–113hexane surge tank overflow, 109–111summary sheets, 106–109

LOPA, 6, 12physical protection, 78postrelease protection, 78preventive/mitigation IPLs compared,

104–106process control systems, 77process design, 76–77rules, 80–88

auditability, 88effectiveness, 80–81independence, 81–88

safety instrumented function (SIF), 78scenario components, 44, 45, 46scenario development, 49worked examples, 216–220

Initiating event, documentation, 233Initiating event identification, 63–74

examples, 73–74hexane storage tank overflow, 74hexane surge tank overflow, 73

expression of events, 63failure rate expression, 73frequency estimation, 68–73

adjustments, 72failure rate data sources, 68–69failure rate selection, 69–70high demand mode, 73initiating events derived from failure

data, 70LOPA use, 70, 72time at risk, 70, 72

limitations, 74types of events, 63–68

enabling events/conditions, 67–68equipment-related, 64–65external, 64human failure-related, 65verification, 66–67

worked examples, 215Instrumented independent protection layer

(IPL), 95. See also Independentprotection layer (IPL)

Integer logarithms, scenario frequencydetermination, 124, 128–130

Interlock. See Safety instrumented function(SIF)

JJudgment, risk decision making, 137

LLayer of protection analysis (LOPA)

advanced topics, 173–190 (See alsoAdvanced topics)

alternative uses of, 163–172 (See alsoAlternative uses)

benefits of, 26–27consequence and severity estimation,

31–42 (See also Consequence andseverity estimation)

defined, 1, 11–12examples

hexane storage tank overflow, 28–30hexane surge tank overflow, 27–28

function of, 12–14historical perspective on, 2–5implementation of, 24, 151–162 (See also

Implementation)initiating event identification, 63–74 (See

also Initiating event identification)limitations of, 24–25professionals interested in, 1–2related literature, 7–8, 237–241risk decision making, 131–150 (See also

Risk decision making)scenario development, 43–62 (See also

Scenario development)steps and documentation for, 16–24study documentation, 231–236 (See also

Documentation)timing of use, 14–16use in process life cycle, 5–6worked examples, 211–230 (See also

Worked examples)Look-up table, scenario frequency

determination, 122–124Loop failure concepts, basic process control

system, IPLs and, 175–176

MManagement, risk decision making, 132–133Management of change, alternative uses, 165Matrix method, calculated risk/scenario risk

tolerance compared, 134, 135,137–138, 140–142

Mechanical integrity program, alternativeuses, 166

Mitigated consequence frequencydocumentation, 235worked examples, 220

Mitigating systems, independent protectionlayer (IPL), 101

268 Index

Mitigation independent protection layer(IPL), preventive IPL compared,104–106. See also Independentprotection layer (IPL)

Multiple risk summation, advanced topics,184–186

Multiple scenarios, scenario frequencydetermination, 119–121

NNumerical criteria method, calculated

risk/scenario risk tolerance compared,134, 136, 138, 142–144

OOperator response issues, advanced topics,

188Overpressure protection, design basis for,

alternative uses, 167–169

PPassive independent protection layer (IPL),

91–94. See also Independent protectionlayer (IPL)

Physical protection, independent protectionlayer (IPL), 78

Pilot tests, LOPA implementation, 161Plant emergency response, independent

protection layer (IPL), 78Postrelease protection, independent

protection layer (IPL), 78Pressure relief devices

design modification, worked examples, 229independent protection layer (IPL), 101–102

Preventive independent protection layer(IPL), mitigation IPL compared,104–106. See also Independentprotection layer (IPL)

Probability of failure on demand (PFD)IPL assessment, 89–90LOPA, 3

Process control systems, independentprotection layer (IPL), 77

Process design, independent protection layer(IPL), 76–77

Process hazard analysis (PHAs), LOPA use, 6Process life cycle, LOPA use in, 5–6

QQualitative estimates

with human harm, consequence evaluationapproaches, 36

with human harm with adjustments forpostrelease probabilities, consequenceevaluation approaches, 36, 38

Quantitative calculations, scenario frequencydetermination, 115–122. See alsoScenario frequency determination

Quantitative estimates, with human harm,consequence evaluation approaches,38–40

RReadiness evaluation, implementation,

151–152Regulatory compliance, LOPA, 2Relief valves, independent protection layer

(IPL), 78Risk-based inspection/risk-based

maintenance programs, alternativeuses, 166

Risk-based operator training, alternativeuses, 166–167

Risk calculation, scenario frequencydetermination, 118–119

Risk decision making, 131–150calculated risk/scenario risk tolerance

compared, 133–136IPL credits, 136matrix method, 134, 135numerical criteria method, 134, 136

cost-benefit analysis, 137criteria in, 131–133cumulative risk criteria/scenario risk

criteria compared, 139–140examples, 140–147

hexane storage tank overflow, 141–147hexane surge tank overflow, 140–141,

142, 144expert judgment, 137limitations, 148–149methods compared, 137–139

Risk/frequency calculation. See Scenariofrequency determination

Risk tolerance criteriadata on, 243–245documentation, 233, 235

LOPA implementation, 158–159LOPA implementation, 156–158worked examples, 214–215, 220

Root cause, defined, 63–64Rupture discs, independent protection layer

(IPL), 78

SSafeguards

documentation, 234–235independent protection layer (IPL)

contrasted, 75–76IPL assessment, 88–89vendor installed, independent protection

layer (IPL), 101worked examples, 220

Safety instrumented function (SIF)design modification, worked examples,

229–230

Index 269

independent protection layer (IPL), 78LOPA, 2, 3, 172

Safety instrumented system (SIS),independent protection layer (IPL),98–100

Safety integrity level (SIL), LOPA use, 6, 172Safety system bypass or removal, alternative

uses, 171–172Scenario development, 43–62

components of, 43–46examples, 52–62

HAZOP, 52–59hexane storage tank overflow, 61–62hexane surge tank overflow, 59–60

identification of scenario, 47–48steps in, 49–52

Scenario frequency determination, 115–130examples, 125–130

hexane storage tank overflow, 126–127,129–130

hexane surge tank overflow, 125–126,128–129

integer logarithms, 124look-up table, 122–124quantitative calculations, 115–122

additional outcomes, 116–118general calculation, 115–116high initiating event frequency, 121–122multiple scenarios, 119–121risk calculation, 118–119

Scenario risk criteria, cumulative risk criteriacompared, risk decision making,139–140

Scenario risk tolerance, calculated riskcompared, risk decision making,133–136

Siting risks evaluation, alternative uses,169–170

Software, LOPA implementation, 162Sprays, independent protection layer (IPL),

101

TTime at risk, frequency estimation, 70, 72Training

LOPA implementation, 162risk-based operator training, alternative

uses, 166–167

UUnmitigated consequence frequency

documentation, 234worked examples, 216

VVendor installed safeguards, independent

protection layer (IPL), 101Vent valve SIF system, design modification,

worked examples, 229–230Verification, initiating event identification,

66–67

WWhat-If review

LOPA implementation, 24LOPA limitations, 25

Worked examples, 211–230design modifications, 229–230independent protection layer (IPL),

216–220mitigated consequence frequency, 220problem description, 212problem discussion, 212–228

conditional modifiers, 215–216consequence, 214enabling event, 215initiating event, 215risk tolerance criteria, 214–215unmitigated consequence frequency,

216risk tolerance criteria, 220safeguards, 220tables, 221–228

270 Index

[Center for chemical_process_safety_(ccps)]_layer_(book_fi.org)

Engineering

Transcript of [Center for chemical_process_safety_(ccps)]_layer_(book_fi.org)