Layer of Protection Analysis: Simplified Process Risk Assessment (A CCPS Concept Book)

Layer of Protection Analysis SIMPLIFIED PROCESS RISK ASSESSMENT Center for Chemical Process Safety of the American Ins...

Author: Center for Chemical Process Safety (CCPS)

476 downloads 3424 Views 3MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
Report copyright / DMCA form

DOWNLOAD PDF

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 © 2001 American Institute of Chemical Engineers 3 Park Avenue New 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 any means, electronic, mechanical, photocopying, recording, or otherwise without the prior permission of the copyright owner. Library of Congress Cataloging-in-Publication Data CIP 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 purpose, 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 Chemical Process Safety express their gratitude to all the members of the Layer of Protection Analysis Subcommittee for their generous efforts and technical contributions in the preparation of this Concept Series book. Layer of Protection Analysis: Simplified Process Risk Assessment was written by the Center for Chemical Process Safety Layer of Protection Analysis Subcommittee. Chair: Arthur M. Dowell, III, P.E.

Rohm and Haas Company

The primary authors were William G. Bridges ABS Consulting (includes former JBF Associates) Arthur M. Dowell, III, P.E. Rohm and Haas Company Martin Gollin Consultant, formerly of ARCO Chemical Warren A. Greenfield International Specialty Products John M. Poulson now retired from Union Carbide Corporation William Turetsky International Specialty Products Providing support and valuable contributions throughout the project were John T. Marshall The Dow Chemical Company Stanley A. Urbanik E. I. Du Pont de Nemours and Company Providing important guidance in the conceptual phases of the book were Rodger M. Ewbank Rhodia Inc. Robert J. Gardner now retired from E. I. Du Pont de Nemours and Company Kumar Bhimavarapu Factory Mutual Research John A. McIntosh The Proctor & Gamble Company xiii

xiv

Acknowledgments

R. Peter Stickles A. D. Little Arthur W. Woltman Equilon Enterprises LLC, formerly Shell CCPS Staff Consultant Robert E. Bollinger Center for Chemical Process Safety Editor Dr. Daniel A. Crowl

Michigan Technological University

The Subcommittee acknowledges the support and contributions of their employer organizations in completing this book. Dr. Jack Weaver and Mr. Les Wittenberg of CCPS sponsored and supported this project and provided access to the resources of CCPS and its sponsoring organizations. The authors thank the following for their contributions in creation of figures and tables, setting up committee meetings and teleconferences and other administrative functions that were essential to the completion of this book: Ms. Jill Johnson and Mr. Paul M. Olsen, ABS Consulting; Ms. Sandy Baswell, Ms. Marge Killmeier, Ms. Angella Lewis and Ms. Jackie Rico’t, Rohm and Haas Company. Before publication, all CCPS books are subjected to a thorough peer review process. CCPS also gratefully acknowledges the thoughtful comments and suggestions of the peer reviewers. Their work enhanced the accuracy 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 Company Dennis Blowers, C.S.P. Solvay Polymers, Inc. Michael P. Broadribb BP Amoco Company David Campbell Concord Associates Bill Carter CCPS Staff Consultant Curtis Clements E. I. Du Pont de Nemours and Company Kimberly F. Dejmek Wilfred Baker Engineering Richard R. Dunn E. I. Du Pont de Nemours and Company Jim Evans Union Carbide Corporation Rodger M. Ewbank Rhodia Inc. Dave Fontaine Chevron Corporation Raymond A. Freeman ABS Consulting Raymond W. French Exxon Mobil Corporation Dallas L. Green Rohm and Haas Company Dennis C. Hendershot Rohm and Haas Company William H. Johnson E. I. Du Pont de Nemours and Company Peter N. Lodal, P.E. Eastman Chemical Company Donald M. Lorenzo ABS Consulting (includes former JBF Associates)

Acknowledgments

Vic Maggioli Feltronics Corporation Rick Mann Union Carbide Corporation Peter McGrath Olin Corporation Norman McLeod ATOFINA Chemicals, Inc. Steve Metzler Primatech Inc. Dr. Hans Pasman TNO Jack Philley, C.S.P. Det Norske Veritas (DNV) Michael E. G. Schmidt, P.E. Industrial Risk Insurers Art Schwartz Bayer Corporation Adrian Sepeda Occidental Chemical Corporation Bastiaan Schupp Delft University of Technology Robert Stankovich Eli Lilly and Company Peter Stickles A. D. Little Dr. Angela E. Summers, P.E. SIS-Tech Solutions, LLC Clark Thurston Union Carbide Corporation Anthony Torres Eastman Kodak Jan Windhorst NOVA Chemicals

xv

Acronyms and Abbreviations

AIChE ALARP ANSI API ASME BI BLEVE B.P. BPCS C CCF CCPS CEI CPQRA CW D DCS DIERS DOT xvi

American Institute of Chemical Engineers As Low as Reasonably Practicable American National Standards Institute American Petroleum Institute American Society of Mechanical Engineers Business Interruption Boiling Liquid Expanding Vapor Explosion Boiling Point Basic Process Control System Consequence factor, related to magnitude of severity Common Cause Failure Center for Chemical Process Safety, American Institute of Chemical Engineers Dow Chemical Exposure Index Chemical Process Quantitative Risk Assessment Cooling Water Number of times a component or system is challenged (hr–1 or year–1) Distributed Control System Design Institute for Emergency Relief Systems, American Institute of Chemical Engineers Department of Transportation


EBV ERPG EuReData F f F&EI F/N FCE FMEA FTA HAZOP HE HRA IEC IEEE IPL ISA LAH LI LIC LFL LNG LOPA LOTO LT MAWP MOC N2 OSBL OREDA OSHA P fatality P ignition P person present P P&ID

Emergency Block Valve Emergency Response Planning Guideline European Reliability Data (series of conferences) Failure Rate (hr-1 or year-1) Frequency (hr-1 or year-1) Dow Fire and Explosion Index Fatality Frequency versus Cumulative Number Final Control Element Failure Modes and Effect Analysis Fault Tree Analysis Hazard and Operability Study Hazard Evaluation Human Reliability Analysis International Electrotechnical Commission Institute of Electrical and Electronic Engineers Independent Protection Layer The Instrumentation, Systems, and Automation Society (formerly, Instrument Society of America) Level Alarm—High Level Indicator Level Indicator—Control Lower Flammability Limit Liquefied Natural Gas Layer of Protection Analysis Lock-Out Tag-Out Level Transmitter Maximum Allowable Working Pressure Management of Change Nitrogen Outside Battery Limits The Offshore Reliability Data project Occupational Safety and Health Administration (U.S.) Probability of Fatality Probability of Ignition Probability of Person Present Probability Piping and Instrumentation Diagram

xvii

xviii

PFD PHA PI PL PM PSM PSV R RV SCE SIF SIL SIS T VCE VLE XV


Probability of Failure on Demand Process Hazard Analysis Pressure Indicator Protection Layer Preventive Maintenance Process Safety Management Pressure Safety Valve (Relief Valve) Risk Relief Valve Safety Critical Equipment Safety Instrumented Function Safety Integrity Level Safety Instrumented System Test Interval for the Component or System (hours or years) Vapor Cloud Explosion Vapor Liquid Equilibrium Remote Activated/Controlled Valve

Preface

For over 40 years the American Institute of Chemical Engineers (AIChE) has been involved with process safety and loss control in the chemical, petrochemical, hydrocarbon process and related industries and facilities. The AIChE publications are information resources for the chemical engineering and other professions on the causes of process incidents and the means of preventing their occurrences and mitigating their consequences. The Center for Chemical Process Safety (CCPS), a Directorate of the AIChE, was established in 1985 to develop and disseminate information for use in promoting the safe operation of chemical processes and facilities and the prevention of chemical process incidents. With the support and direction of its advisory and management boards, CCPS established a multifaceted program to address the need for process safety technology and management systems to reduce potential exposures to the public, the environment, personnel and facilities. This program entails the development, publication and dissemination of Guidelines relating to specific areas of process safety; organizing, convening and conducting seminars, symposia, training programs, and meetings on process safety-related matters; and cooperating with other organizations and institutions, internationally and domestically to promote process safety. Within the past several years CCPS extended its publication program to include a “Concept Series” of books. These books are focused on more specific topics than the longer, more comprehensive Guidelines series and are intended to complement them. With the issuance of this book, CCPS has published 65 books. CCPS activities are supported by the funding and technical expertise of over 80 corporations. Several government agencies and nonprofit and academic institutions participate in CCPS endeavors. xi

xii

Preface

In 1989 CCPS published the landmark Guidelines for the Technical Management of Chemical Process Safety. This book presents a model for process safety management 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 a technical management program have been assembled in one document. We believe the Guidelines provide the umbrella under which all other CCPS Technical Guidelines will be promulgated.

This Concept Series book supports several of the twelve elements of process safety enunciated in the landmark Guidelines for the Technical Management of Chemical Process Safety including Process Risk Management, Incident Investigation, Process Knowledge and Documentation, and Enhancement of Process Safety Knowledge. The purpose of this book is to assist designers and operators of chemical facilities to use Layer of Protection Analysis (LOPA) to evaluate risk and to make rational decisions to manage risk with a simplified methodology.

Contents

Preface

xi

Acknowledgments

xiii


xvi

1

Introduction 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

2

Overview 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

vi

Contents

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

3

Estimating 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

4

Developing Scenarios 4.1. Purpose

43

4.2. LOPA Scenarios and Components

43

4.3. Identifying and Developing Candidate Scenarios

47


52

4.5. Link Forward

61

5

Identifying Initiating Event Frequency 5.1. Purpose

63

5.2. Initiating Events

63

5.3. Frequency Estimation

68

5.4. Expression of Failure Rates

73


73

5.6. Limitations (Cautions)

74

5.7. Link Forward

74

vii

6

Identifying 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


106

6.8. Link Forward

113

7

Determining 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


125

7.6. Link Forward

130

8

Using 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


140

8.9. Cautions

148

8.10. Link Forward

149

viii

Contents

9

Implementing 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

10

Using 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-Based Inspection/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 Basis for Overpressure Protection

167

10.8. Using LOPA in Evaluating Facility Siting Risks

169

10.9. Using LOPA to Evaluate the Need for Emergency Isolation 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

11

Advanced LOPA Topics 11.1. Purpose

173

11.2. Counting Multiple Functions in One BPCS as IPLs in the Same Scenario

173

Contents

ix

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

1 Introduction

Layer of protection analysis (LOPA) is a semiquantitative tool for analyzing and assessing risk. This book • describes the LOPA process, • discusses the strengths and limitations of LOPA, • describes the requirements for implementing LOPA in an organization, 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 for managing 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 9 discusses the questions that an organization must answer when deciding whether to use LOPA and the required steps to implement the pro1

1. Introduction

2

cess effectively. Chapter 10 describes other processes (such as management of change, identification of safety critical equipment, etc.) which can be enhanced by LOPA. The appendices contain summary forms and worked examples that demonstrate the LOPA product. • Safety specialists who are familiar with existing methods (such as HAZOP, fault tree analysis, event tree analysis, etc.) or who may already have some experience with LOPA (analysts, participants, reviewers, auditors, etc.). For this audience, Chapters 3, 4, 5, 6, 7, 8 discuss the steps of the LOPA process in detail, with several continuing examples used to demonstrate the method. The appendices contain additional worked examples and other supporting documentation. • Process and process control engineers, chemists, operations and maintenance personnel, and others who may participate in LOPA reviews or who may be affected by LOPA recommendations. This includes those who implement the recommendations and those who receive the outcomes from LOPA. Chapters 1, 2, and 6 may be helpful for this audience. • Persons around the world who are responsible for compliance with process safety regulations—including the US Process Safety Management rule (OSHA, 1992), Seveso II Regulations in EU member countries—and related standards—including ISA S84.01 (ISA, 1996), IEC 61508 (IEC, 1998) and IEC 61511 (IEC, 2001).

1.2. History of LOPA In a typical chemical process, various protection layers are in place to lower the frequency of undesired consequences: the process design (including inherently safer concepts); the basic process control system; safety instrumented systems; passive devices (such as dikes and blast walls); active devices (such as relief valves); human intervention; etc. There has been much discussion among project teams, hazard analysts, and management about the number of and strength of protection layers (see text box below). Decisions were sometimes made using subjective arguments, emotional appeals, and occasionally simply by the loudness or persistence of an individual. LOPA has its origins in the desire to answer these key questions using a rational, objective, risk-based approach. In LOPA, the individual protection KEY QUESTIONS FOR PROTECTION LAYERS • How safe is safe enough? • How many protection layers are needed? • How much risk reduction should each layer provide?

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.

layers proposed or provided are analyzed for their effectiveness. The combined effects of the protection layers are then compared against risk tolerance criteria. Characteristics of the answers provided by LOPA are listed in the text box above. The genesis of this method was suggested in two publications: 1. In the late 1980s, the then Chemical Manufacturers Association published the Responsible Care® Process Safety Code of Management Practices which included “sufficient layers of protection” as one of the recommended components of an effective process safety management system (American Chemistry Council, 2000). The Chemical Manufacturers Association is now the American Chemistry Council. 2. In 1993, CCPS published its Guidelines for Safe Automation of Chemical Processes (CCPS, 1993b). Although it was called the risk-based SIS integrity level method, LOPA was suggested as one method to determine the integrity level for safety instrumented functions (SIFs). (See Table 7.4 in Safe Automation; CCPS, 1993b.) “Interlock” is an older, imprecise term for SIF. The method used was not as fully developed as the LOPA technique described in this book. However, it did indicate a path forward, which was pursued by several companies independently. 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 requiring a full (chemical process) quantitative risk assessment (CPQRA), • develop a tool that would identify “safety critical” equipment and systems to focus limited resources, • develop a semiquantitative tool to make consistent risk based judgments within an organization, • harmonize terminology and methodology with recently developed and developing international process sector standards, and • facilitate communication (e.g., SIS, SIF, SIL, IPL) between the hazard and risk analysis community and the process control community (e.g., integrators, manufacturers, instrument and electrical engineers, plant personnel).

4

1. Introduction

The initial development of LOPA was done internally within individual companies, in some cases focusing on existing processes, e.g., converting a control system to DCS. However, once a method had been developed and refined, several companies published papers describing the driving forces behind their efforts to develop the method, their experience with LOPA, and examples 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 discussion among the attendees at the CCPS International Conference and Workshop on Risk Analysis in Process Safety in Atlanta in October 1997 brought agreement that a book describing the LOPA method should be developed. In parallel with these efforts, discussions took place on the requirements for the design of safety instrumented functions (SIF) to provide the required PFDs (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. Informative sections of the ISA and IEC standards suggested methods to determine the required SIL (safety integrity level), but LOPA was not mentioned until the draft of IEC 61511, Part 3 appeared in late 1999. These issues were summarized 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 Consulting (includes former JBF Associates), International Specialty Products, Proctor and Gamble (P&G), Rhodia, Rohm and Haas, Shell (Equilon), and Union Carbide to tabulate and present industry practice for LOPA in this book. This book extends the method outlined in Safe Automation of Chemical Processes (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 independent 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 share the following common features: • a consequence classification method that can be applied throughout the organization; • numerical risk tolerance criteria. Individual companies use different criteria which include:

1.3. Use of LOPA in the Process Life Cycle

5

frequency of fatalities, frequency of fires, G required number of independent protection layers (IPLs), and G 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 it does not, how this is resolved and documented. G G

• • • • •

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 a facility (see Figure 1.1), but it is most frequently used during: • the design stage when the process flow diagram and the P&IDs are essentially complete. LOPA is used to examine scenarios, often generated 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 design study on a system to classify the various process alternatives and to select the best method; • modifications to an existing process or its control or safety systems (i.e., management of change).

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

6

1. Introduction

However, LOPA can also be used in all phases of the process life cycle: • LOPA can be used during the initial conceptual process design to examine basic design alternatives and provide guidance to select a design that has lower initiating event frequencies, or a lower consequence, or for which the number and type of IPLs are “better” than alternatives. Ideally, LOPA could be used to design a process that is “inherently safer” by providing an objective method to compare alternative 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 companies has shown that its scenario-focused methodology can reveal additional safety issues in fully mature processes that have previously undergone numerous PHAs. In addition, its objective risk criteria have proven effective in resolving disagreements on PHA findings. • LOPA can readily determine if the risk is tolerable for a process. If an SIF is required, LOPA can determine the required SIL. LOPA can examine alternatives to a SIF (modifying the process, adding other IPLs, etc.). Note that IEC 61508 (IEC, 1998) and IEC 61511 (IEC, 2001) define a safety system life cycle that covers all the activities associated with safety instrumented functions. LOPA can be a valuable tool in that safety system life cycle. • LOPA can be used to identify equipment that, as part of an IPL, is relied upon to maintain the process within the tolerable risk criteria of an organization. Such equipment may be denoted as “safety critical” (ISA S91.01, 1995) and is subjected to specified testing, inspection and maintenance. At least one company has found that LOPA has significantly decreased the number of safety critical equipment items. (The amount of safety critical equipment had erroneously grown over time by adding equipment on a qualitative “better safe than sorry” basis.) • LOPA can be used to identify operator actions and responses that are critical to the safety of the process. This will allow focused training and testing to be performed during the life of the process and for the operating manuals to reflect the importance of a limited number of process variables, alarms and actions. LOPA can also be used for other risk assessment studies within an organization, including transportation studies (road, rail, pipeline), terminal operations, toll conversion operations, auditing of third parties, loss prevention and insurance issues, etc. In some companies LOPA is now used for a wide variety of purposes beyond the initial use for which it was developed (see Chapter 10).

1.4. Linkage to Other CCPS Publications

7

1.4. Linkage to Other CCPS Publications CCPS has published many books dealing with process safety issues in the chemical industry. LOPA depends on techniques described in the following CCPS 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 Examples (CCPS, 1992a) describes methods used to identify and assess the significance of hazardous situations found in process operations or activities involving hazardous chemicals. Generally, LOPA uses scenarios developed by hazard identification methods—usually qualitative (HAZOP, what-if, etc). However, companies have found that LOPA will often uncover scenarios overlooked by other methods because of the rigor in applying the concept of IPLs to the scenario. LOPA should be considered an extension to the Guidelines 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 simplification of the quantitative risk analysis methods described in Guidelines for Chemical Process 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 identified by the techniques described in the Guidelines for Hazard Evaluation book. LOPA adds simplifying assumptions concerning the numerical values for the components of the scenario (initiating event frequency, enabling event/condition, number of IPLs, numerical value for an IPL) and in the calculation techniques 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 scenario when compared to the results of an LOPA analysis. In order to ensure this, an analyst must understand the issues involved in performing a full quantitative risk analysis and what issues are important. Chapter 11 describes situations where a focused quantitative study can be performed on one component of a LOPA scenario to provide useful additional confidence in the numerical values used. Evaluating Process Safety in the Chemical Industry: A User’s Guide to Quantitative Risk Analysis CCPS (2000b) is a brief and relatively inexpensive introduction to the concepts of CPQRA. These concepts also apply for using LOPA. The LOPA book is a direct extension to concepts briefly described in Guidelines for Safe Automation of Chemical Processes (CCPS, 1993b). The LOPA book shows how to determine the required safety integrity level (in terms of the

8

1. Introduction

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 for Making Acute Risk Decisions with Chemical Process Safety Applications (CCPS, 1995c). CCPS (1995c) discusses methods used for decision making where risks have been assessed. In addition to chemical process risk, other factors, including financial cost, corporate image, employment of workers, etc., may be 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 decision. LOPA should be considered an alternate method for making such decisions as it employs objective, quantified risk tolerance criteria. Some of the more qualitative factors (company image, morale, etc.) cannot be directly included, but that is the case for all other objective methodologies. Some LOPA risk tolerance criteria include a range where a cost–benefit study—or another type of judgment—is required to assist in making the decision on whether a risk should be tolerated or mitigated. Analysts using LOPA should be familiar with the techniques in the Making Acute Risk Decisions book (CCPS, 1995c). More detailed links to other CCPS books and other publications are shown 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, discusses concepts and definitions unique to LOPA, and introduces the continuing examples used throughout the book. Chapter 3 (Estimating Consequences and Severity) describes the concept of consequence, and its definition, in the LOPA process and provides examples of consequence categories used by some companies. Chapter 4 (Developing Scenarios) discusses the concept of a scenario as used in LOPA, including the components that comprise a scenario. A format for presenting the results of LOPA studies is presented. Chapter 5 (Identifying Initiating Event Frequency) discusses various initiating and enabling events and summarizes typical frequency data. The importance of using consistent initiating event frequencies for LOPA studies within an organization is emphasized. Chapter 6 (Identifying Independent Protection Layers) discusses independent protection layers (IPLs). The requirements for a device, system, or action to be considered an IPL are defined and the concept of the probability of failure

1.5. Annotated Outline of the LOPA book

9

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 calculations for the continuing example problems using several methods. These show how different organizations would combine the individual components of a scenario to calculate the frequency of the consequence type specific to their method. Chapter 8 (Using LOPA to Make Risk Decisions) discusses how the results of calculations are used to make decisions on whether the frequency of the consequence for a given scenario meets the risk tolerance criteria for a particular organization. Methods from various companies are used to demonstrate the concepts. Chapter 9 (Implementing LOPA) discusses the implementation of LOPA within 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, apart from 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 in LOPA may be modified are reviewed. The use of LOPA for other risk assessment applications is discussed. Appendix A (LOPA Summary Sheets for the Continuing Examples) contains the complete LOPA sheets for all of the scenarios in the continuing examples using all of the methodologies discussed in the book. Appendix B (Worked Examples from CCPS’s Safe Automation Book) provides an analysis of the problem discussed in Chapter 7 of CCPS (1993b). Important issues regarding the application of the rules for an IPL are discussed. Appendix C (Documentation for a LOPA Study) summarizes the minimum documentation requirements for a LOPA study and discusses why such information is required, the appropriate level of detail, and other uses of the documentation. Appendix D (Linkage with Other Publications) discusses other publications. Included are the use of LOPA to address regulatory or other process safety issues, and how other publications can assist in the implementation of LOPA. Appendix E (Industry Risk Tolerance Criteria Data) lists typical data related to risk tolerance criteria.

10

1. Introduction

Appendix F (High Initiating Event Frequency Scenarios) describes LOPA calculations when the initiating event frequency is high compared to the test frequency of the independent protection layer. Appendix G (Additional Reading) is a list of other books and articles that may be of interest to the reader.

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 it works, and how it is implemented. The limitations and benefits of LOPA are also discussed. This chapter also introduces two example problems used throughout 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 of magnitude categories for initiating event frequency, consequence severity, and the likelihood of failure of independent protection layers (IPLs) to approximate the risk of a scenario. LOPA is an analysis tool that typically builds on the information developed during a qualitative hazard evaluation, such as a process hazard analysis (PHA). LOPA is implemented using a set of rules. Like many other hazard analysis methods, the primary purpose of LOPA is to determine if there are sufficient layers of protection against an accident scenario (can the risk be tolerated?). As illustrated in Figure 2.1, many types of protective layers are possible. A scenario may require one or many protection layers depending on the process complexity and potential severity of a consequence. Note that for a given scenario, only one layer must work successfully for the consequence to be prevented. However, since no layer is perfectly effective, sufficient protection layers must be provided to render the risk of the accident tolerable. 11

12

2 . Overview of LOPA

FIGURE 2.1. Layers of defense against a possible accident.

LOPA provides a consistent basis for judging whether there are sufficient IPLs to control the risk of an accident for a given scenario. If the estimated risk of a scenario is not acceptable, additional IPLs may be added. Alternatives encompassing inherently safer design can be evaluated as well. LOPA does not suggest which IPLs to add or which design to choose, but it assists in judging between alternatives for risk mitigation. LOPA is not a fully quantitative risk assessment approach, but is rather a simplified method for assessing 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 risk of selected accident scenarios. A scenario is typically identified during a qualitative hazard evaluation (HE), such as a PHA, management of change evaluation, or design review. LOPA is applied after an unacceptable consequence, and a credible cause for it, is selected. It then provides an order of magnitude approximation of the risk of a scenario. LOPA is limited to evaluating a single cause–consequence pair as a scenario.

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

2.3. What LOPA Does

13

of the scenario. The results can then be extended to make risk judgments and to help the analyst decide how much additional risk reduction may be required to reach a tolerable risk level. Other scenarios or other issues may be revealed while performing LOPA on a scenario. Another way to understand LOPA is to view it relative to quantitative risk assessment (CPQRA). In this context, a LOPA scenario represents one path (typically we choose the path to the worst consequence) through an event tree. Figure 2.2 shows an event tree for a given initiating event. An event tree shows all the possible outcomes (consequences) of an initiating event. A comprehensive treatment of the use of event trees and other quantitative risk assessment methods is provided by the CCPS CPQRA books Guidelines for Chemical Process Quantitative Risk Analysis and Guidelines for Chemical Process Quantitative Risk Analysis, Second Edition (CCPS, 1989a, 2000a) and Guidelines for Hazard Evaluation Procedures, Second Edition with Worked Examples (CCPS, 1992a). For LOPA, the analyst (or team) must limit each analysis to a single consequence, paired to a single cause (initiating event). In many applications of LOPA, the goal of the analyst is to identify all cause–consequence pairs that can exceed the organization’s tolerance for risk.

FIGURE 2.2. Comparison of LOPA and event tree analysis.

14


In others, the analyst chooses the cause–consequence pair that likely represents the highest risk scenario from many scenarios that may be similar to the one chosen. The approach taken depends upon the analyst’s experience with LOPA and with the process under consideration - this is not always straightforward. In practice, the analyst who will apply LOPA will not have the benefit of picking a scenario from a fully developed event tree. Instead, LOPA typically begins with scenarios identified by a qualitative hazard review team. As mentioned earlier, LOPA is a method that falls between qualitative and quantitative methods and is applied when the analyst decides it is the best tool for judging risk. The goal is to choose scenarios that the analyst believes represent 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. However, “typically” means just that—LOPA can also be used to analyze scenarios that originate from any source, including design option analysis and incident investigations. LOPA can also be applied when a hazard evaluation team (or other entity) • believes a scenario is too complex for the team to make a reasonable risk judgment using purely qualitative judgment, or • the consequences are too severe to rely solely on qualitative risk judgment. The hazard evaluation team may judge the “scenario as too complex” if they • 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 quantitative risk assessment (CPQRA) method. When used as a screening tool, each scenario above a specified consequence or risk level will first go through LOPA analysis, and then certain scenarios will be targeted for a higher level of risk assessment. The decision to proceed to CPQRA is typically based on the risk level determined by LOPA or based on the opinion of the LOPA analyst (i.e., the scenario is too critical or complex to rely on LOPA for risk assessment). Figure 2.3 depicts the spectrum of risk assessment tools: from purely qualitative to rigorous application of quantitative methods. At the far left are qualitative tools; these are typically used to identify scenarios and qualita-

2.4. When to Use LOPA

15

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

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 provide an order-of-magnitude estimate of risk. Finally at the far right are quantitative tools; these allow analysis of more complex scenarios and provide risk estimates for comparison and risk judgment. The percentages shown in Figure 2.3 are for illustration purposes only. Typically all scenarios are identified and evaluated qualitatively, and some that are too onerous or complex proceed to semiquantitative risk assessment, and a few scenarios may need more rigorous evaulation than is than possible with LOPA. Thus, LOPA can be applied to evaluate scenarios that are too complex or consequential for only qualitative review and LOPA can screen which scenarios need more quantitative scrutiny (which need to go beyond LOPA to CPQRA). Later chapters provide examples of how companies have incorporated LOPA into their risk assessment approaches. In general, the writers believe that if the analyst or team can make a reasonable risk decision using only qualitative methods, then LOPA may be overkill. However, LOPA can be much more efficient than qualitative methods for judging the sufficiency of IPLs; in a qualitative hazard review these decisions can quickly digress into shouting matches. LOPA should not be used as a replacement for quantita-

16


tive analysis. If complex human behavior models or equipment failure models are required to understand the risk of a scenario, then quantitative analysis 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 outlined in Figure 2.4 and summarized below. Figure 2.4 also identifies the relevant chapter for each step. The steps below refer to Figures 2.5 through 2.11 and show how the results are selected from the figures. These figures are discussed in detail in later chapters. Step 1: Identify the consequence to screen the scenarios. Since LOPA typically evaluates scenarios that have been developed in a prior study, a first step by the LOPA analyst(s) is to screen these scenarios, and the most

FIGURE 2.4. How LOPA works.

2.5. How LOPA Works

17

common screening method is based on consequence. The consequence is typically identified during a qualitative hazard review (such as a HAZOP study) (see Figure 2.5). Next the analyst evaluates the consequence (including the impact) and estimates its magnitude. Some companies stop at the magnitude of a release (of material or energy), which implies, but does not explicitly state, the impact to people, the environment, and the production system (see Figure 2.6). Other companies will model the release (see Figure 2.7) and more explicitly estimate the risk to people, the environment, and production by accounting for the likelihood of harm resulting from a specific scenario, for instance by also accounting for the probability of operators being in harm’s way during a release scenario. Chapter 3 describes the methods used for consequence 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), but the scenario describes a single cause–consequence pair (see Figure 2.5). Chapter 4 provides rules and examples for identifying scenarios. Step 3: Identify the initiating event of the scenario and determine the initiating event frequency (events per year). The initiating event must lead to the consequence (given failure of all of the safeguards). The frequency must account for background aspects of the scenario, such as the frequency of the mode of operation for which the scenario is valid. Most companies provide guidance on estimating the frequency to achieve consistency in LOPA results (see Figure 2.8). Chapter 5 provides guidance on selecting an appropriate initiating event and in determining a reasonable frequency in the context of the accident scenario being analyzed. Step 4: Identify the IPLs and estimate the probability of failure on demand of each IPL. Recall that LOPA is short for “layer of protection analysis.” Some accident scenarios will require only one IPL, while other accident scenarios may require many IPLs, or IPLs of very low probability of failure on demand, to achieve a tolerable risk for the scenario. Recognizing the existing safeguards that meet the requirements of IPLs for a given scenario is the heart of LOPA. Most companies provide a predetermined set of IPL values for use by the analyst, so the analyst may pick the values that best fits the scenario being analyzed (see Figure 2.9). Chapter 6 provides the rules (requirements) that are applied to select existing IPLs and also describes how various companies estimate the effectiveness of existing and proposed IPLs. Step 5: Estimate the risk of the scenario by mathematically combining the consequence, initiating event, and IPL data. Other factors may be included during the calculation, depending on the definition of consequence (impact

18


FIGURE 2.5. Choosing the scenario.

19 FIGURE 2.6. Determining the consequence and its severity.

20


Click for high resolution graphic

FIGURE 2.7. Mathematical modeling of consequence. From

FIGURE 2.8. Choosing initiating event frequency.

From

21 FIGURE 2.9. Choosing IPL values.

22


From

FIGURE 2.10. LOPA documentation.

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

23 FIGURE 2.11. Estimating the risk and required action.

24


Step 6: Evaluate the risk to reach a decision concerning the scenario. Chapter 8 describes how to make risk decisions with LOPA. This includes comparing the risk of a scenario to a company’s tolerable risk criteria and/or related targets (see Figure 2.11). Chapter 10 describes other uses of LOPA results. Chapters 8 and 10 also describe how the results can be used to prioritize risk management activities, such as identifying which equipment components to focus on within a mechanical integrity program.

2.6. How to Implement LOPA LOPA is most effective when an organization adopts a consistent approach to LOPA and sets criteria for when to use LOPA and who is qualified to use it. Chapter 9 provides general guidance for effective implementation of LOPA and includes lessons learned from several international companies. Training of personnel in LOPA is a key implementation task. Chapter 11 describes advanced LOPA topics. LOPA can be applied in a team setting, such as during or immediately following a HAZOP- or What-If–based review (e.g., PHA) used to identify accident 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 by a hazard evaluation team). Note that a single analyst rarely works in a vacuum and will almost inevitably need to clarify issues with others in the organization. Many companies practice LOPA with a subteam composed of the analyst and a process engineer or production specialist (someone intimately familiar with the process); a larger team or an independent LOPA analyst may review their work.

2.7. Limitations of LOPA LOPA is just another risk analysis tool that must be applied correctly. The limitations imposed on LOPA result in a work process that is much less complex than quantitative risk analysis, while generating useful, somewhat conservative, 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 comparisons are based on the same risk tolerance criteria or to the risk of other scenarios determined by LOPA. The numbers generated by a LOPA calculation are not precise values of the risk of a scenario. This is also a limitation of quantitative risk analysis.

2.7. Limitations of LOPA

25

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:

• LOPA is a simplified approach and should not be applied to all scenarios. The amount of effort required to implement LOPA may be excessive for some risk-based decisions and is overly simplistic for other decisions. • LOPA requires more time to reach a risk-based decision than qualitative methods such as HAZOP and What-if. This extra time is offset by the improved risk decision compared to using only qualitative methods for moderately complex scenarios. For simple decisions, the value of LOPA is minimal. For more complex scenarios and decisions, LOPA may actually save time compared to using only qualitative methods, because LOPA brings focus to the decision making. Since LOPA provides quantitative results, LOPA is better than HAZOP. The two are different techniques with different goals and cannot be compared directly. MYTH:

REALITY:

• HAZOP is ideally suited for brainstorming or uncovering what could go wrong and at identifying potential accident scenarios; a HAZOP team can also qualitatively 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.

• LOPA is not intended to be a hazard identification tool. LOPA depends on the methods used (including qualitative hazard review methods) to identify the hazardous events and to identify a starting list of causes and safeguards. The more rigorous procedure of LOPA frequently clarifies ill-defined scenarios from qualitative hazard reviews. • Differences in risk tolerance criteria and in LOPA implementation between organizations means the results cannot normally be compared directly from one organization to another. This is true of CPQRA techniques as well.

26


2.8. Benefits of LOPA LOPA has many benefits that justify investment by company management and risk analysts. As with most new tools, however, the benefits often cannot be fully appreciated until LOPA is applied to everyday problems. Some general benefits of LOPA include: • LOPA requires less time than quantitative risk analysis. This benefit applies particularly to scenarios that are too complex for qualitative assessment of risk. • LOPA helps resolve conflicts in decision making by providing a consistent, simplified framework for estimating the risk of a scenario and provides a common language for discussing risk. LOPA provides a better risk decision basis compared to subjective or emotional arguments based on “the risk is tolerable to me.” This is particularly beneficial for organizations making the transition from qualitative to more quantitative risk methods. • LOPA can improve the efficiency of hazard evaluation meetings by providing a tool to help reach risk judgments quicker. • LOPA facilitates the determination of more precise cause–consequence pairs, and therefore improves scenario identification. • LOPA provides a means of comparing risk from unit to unit or plant to plant, if the same approach is used throughout the company. • LOPA provides more defensible comparative risk judgments than qualitative methods due to the more rigorous documentation and the specific values assigned to frequency and consequence aspects of the scenario. • LOPA can be used to help an organization decide if the risk is “as low as reasonably practicable” (ALARP), which may also serve to meet specific regulatory requirements. • LOPA helps identify operations and practices that were previously thought to have sufficient safeguards, but on more detailed analysis (facilitated by LOPA), the safeguards do not mitigate the risk to a tolerable level. • LOPA helps provide the basis for a clear, functional specification for an IPL [ISA S84.01 (ISA, 1996) and IEC 61508 and IEC 61511 (IEC, 1998; 2001)]. • Information from LOPA helps an organization decide which safeguards to focus on during operation, maintenance, and related training. For instance, many companies decide to focus their inspection, test, and preventive maintenance activities on the IPLs identified during LOPA; these companies often decide to run the remaining safeguards (those not identified as IPLs) to failure or subject them to less rigorous test and maintenance schedules. Therefore, LOPA is a tool for


27

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

2.9. Introduction of Continuing Examples The following two examples will be used to illustrate the concepts of LOPA throughout this book. Note that LOPA methods vary throughout the industry. Each example shows only one of the many approaches. Variations will be shown or discussed in the following chapters and appendices. The solution steps for each example will be shown in each chapter. For each of these examples: • Chapter 3 discusses how to identify consequences and classify them for 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 the probability of failure on demand (PFD) for the applicable IPLs. • Chapter 7 shows how to calculate the frequency of the scenario with the IPLs in place. • Chapter 8 describes how to use LOPA to evaluate risk and make decisions.

Continuing Example 1: Hexane Surge Tank Overflow The following process, shown in Figure 2.12, will be used as a continuing example to illustrate the concepts of LOPA throughout this book. Design Hexane flows from another process unit (not shown) into a hexane surge tank. The hexane supply pipeline is always under pressure. The surge tank level is controlled by a level control loop (LIC-90) that senses the level in the tank and throttles a level valve (LV-90) to control the level. Hexane is used by a downstream process (also not shown). The LIC loop includes a high level alarm (LAH-90) to alert the operator. The tank normally operates half full; the total tank capacity is 80,000 lb of hexane. The tank is located in a dike that can contain up to 120,000 lb of hexane. The designs in the examples are for illustrative purposes only. The designs are not necessarily endorsed by the authors. Readers are cautioned to use designs appropriate for their applications.

28


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

Scope This example provides a limited illustration of LOPA for a process safety decision based on the use of a safety instrumented function (SIF) as an independent protection layer (IPL). During the process hazard analysis (PHA), the team discussed the need for a high level SIF to help prevent overfilling accidents. They decided to use LOPA to help structure this process safety decision. The PHA team identified other scenarios that would lead to releases of hexane from the surge tank and related process equipment, but these other scenarios are not modeled here. Hazard Information The hazard information was prepared as part of the PHA, prior to conducting the 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 of flammable 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 continuing example to illustrate the concepts of LOPA throughout this book.


29

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

Design Hexane is unloaded from a tank truck (50,000 lb) via pump 3-40 into makeup storage tank T-301, which has a capacity of 80,000 lb. The surrounding dike is designed to contain 120,000 lb of hexane. The truck is unloaded once every 4 days or about 90 times per year. The makeup storage tank is equipped with a level indicator (LI-80) and a high level alarm (LAH-80) that annunciates in the control room. Two operators are typically involved in this operation; one in the field who initiates the transfer with the delivery truck driver and one in the control room who monitors and operates various process functions from a computer interface. The driver is required to supervise the transfer. Scope This example provides a limited illustration of LOPA for a process safety decision on the use of a safety instrumented function (SIF), as an independent protection layer (IPL). During the process hazard analysis (PHA), the team discussed the need for a high level SIF to trip the feed pump and close an inlet valve (to be installed) to help prevent overfilling accidents. They decided to use LOPA to help structure this process safety decision. The overflow scenario of concern is initiated by arrival of a truck when there is insufficient

30


room in tank T-301 for the truck contents. This could be due to a number of situations, including an error in ordering, or the unit was shut down after the truck was ordered. The PHA team identified other scenarios that would lead to releases of hexane from the surge tank and related process equipment, but these other scenarios are not analyzed here. Hazard Information The hazard information was prepared as part of the qualitative PHA, prior to conducting the LOPA. This included identification of the hazards, scenario, consequences, safeguards, and subsequent recommendations. The consequences are overflow of the tank; possible overflow of the dike; and subsequent dispersion of flammable hexane vapors, which if ignited, will result in a pool fire. Click here to go to Chapter 3

3 Estimating Consequences and Severity

3.1. Purpose One component of the risk of any accident scenario is its consequence. In LOPA, the consequences are estimated to an order of magnitude of severity, which requires much less effort than mathematical modeling, and yet still facilitates comparison of risk from different scenarios. This chapter describes the various types of consequence analysis used in LOPA. The continuing examples illustrate consequence analysis using the principles outlined in this chapter. This is Step 1 of the LOPA method.

3.2. Consequences of Interest Consequences are the undesirable outcomes of accident scenarios. One of the first decisions an organization must make when choosing to implement LOPA is how to define the consequence endpoint. Some companies stop at loss of containment; others estimate the final impact in terms of harm or damage. The most common scenario of interest for LOPA in the chemical process industry is loss of containment of hazardous material or energy. Loss of containment can occur by a variety of mechanisms such as a leak from a vessel, rupture of a pipeline, and lifting of a relief valve. The typical sequence of consequences of a release of flammable/toxic material is shown in Figure 3.1 and explained below. 31

32

3. Estimating Consequences and Severity

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

The material released may be in a liquid, gas, or solid form, or a combination of these. If the released material is flammable, ignition may result in an explosion and/or fire. In case of immediate ignition of a pressurized gas or two-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 flash fire or explosion. Liquid spills may burn as pool fires if ignited. If the released material is toxic, plant personnel or the public may be exposed to unhealthy concentrations. The radiation flux from fires, overpressures from explosions, and toxic concentrations from toxic releases are called physical effects. The physical effects have “impact” on personnel, environment and property, and may result in losses such as injuries, fatalities, environmental harm, and property damage. In addition to these initial effects, there could be follow-on losses due to business interruption, loss of quality of product, demolition requirements, and loss of credibility with the public, regulators, customers, and stockholders. The range of consequence endpoints for a loss of containment scenario include the release of the hazardous material, the dispersion of the hazardous material, physical effects from fires, explosions and toxic releases; and the losses from the impact of physical effects. All of these consequence endpoints are quantifiable by some estimation method. For example, a release can be measured in terms of the released quantity; the dispersion in terms of dispersion distance/area (for specific concentrations); and the losses in terms of number of injuries and fatalities, property damage, financial losses or indirect losses.


33

3.3. Consequence Evaluation Approaches for LOPA Consequence evaluation is an integral part of any risk assessment methodology. What consequences should be evaluated, and how rigorously the consequences are evaluated depend on several factors, including the risk associated with the accident scenarios, and the risk assessment methodology adopted by the organization, and the resources the organization is willing to expend to refine the estimate. These implementation issues are discussed in greater 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 are discussed in the following sections. The method used for consequence categorization should be consistent with the company’s risk tolerance criteria. Any organization implementing LOPA should carefully consider the level of detail for consequence analysis, as this choice can significantly affect the level of effort and training required. Figure 3.1 shows a generic release event and possible outcomes. Some companies choose to stop the analysis at identifying and quantifying the type and size of the release. Their risk tolerance criteria assume that releases of certain magnitudes have a certain likelihood of harming the environment, people, or production/assets. In these companies, the primary risk tolerance criterion is matched to the fact that the consequence categorization stops at the “release.” Other companies choose to explicitly account for the likelihood of some impact event (e.g., employee injury), and therefore their consequence categories are also more explicit in the degree of harm done. It should be noted that either approach can (and typically does) provide comparable risk decisions.

Method 1: Category Approach without Direct Reference to Human Harm This method typically uses matrices to differentiate consequences into various categories. It avoids estimating the number of potential injuries or fatalities, 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 people who 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-

34


quences, ranging from a slight bruise to a fatality. Or, a toxic release can result in one or more fatalities or no harm at all, depending on the proximity of people to the release point and the time and capability they have to escape. Table 3.1 is an example that includes a simple approach to categorize the consequences from a chemical release. Each consequence is assigned a numerical category from 1 to 5, with 5 being the most severe. Table 3.1 includes three matrices: • The upper matrix relates release size and the physical and toxicological properties to consequence categories (this avoids the need for quantitative calculations of dispersion, etc.). • The middle matrix relates plant type and type of damage or production loss to consequence categories. • The lower matrix relates equivalent cost factors to consequence categories. 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 in severity if dispersion modeling (quantitative analysis) is performed and shows that a lower impact category is warranted.] Once the release category has 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 tolerable (see Chapter 8). The advantages of this method: • The method is simple and easy to use because the size and properties of the release are relatively easy to assess. No case-by-case modeling is required. A release of a certain size is assigned a certain consequence value independent of the eventual effect (fire, explosion, toxic release, injury, fatality, etc.). The criteria for loss of production are similarly simple to assess. • When combined with a matrix showing the organization’s risk tolerance criteria, the method allows visual assessment of where a given risk lies in relation to the organization’s guidelines. The disadvantages of this method: • It requires either the acceptance of the consequence categorization matrix or the development of such a matrix by baseline modeling. The

TABLE 3.1 Example Consequence Categorization Size of Release (beyond a dike)

Release Characteristic

1- to 10pound release

100- to 1,000pound release

10- to 100pound release

1,000- to 10,000pound release

10,000- to 100,000pound release

>100,000pound release

Extremely toxic above BP*

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

Extremely toxic below BP or highly toxic above BP


Highly toxic below BP or flammable above BP


Flammable below BP


Combustible liquid


*BP = atmospheric boiling point

Magnitude of Loss

Consequence Characteristic

Spared or nonessential equipment

Plant outage 3 months 100–300 psi

Vessel rupture >10,000 gal >300 psi

Mechanical damage to large main product plant


Mechanical damage to small by-product plant


Consequence cost (U.S. dollars) Consequence Characteristic Overall cost of event

$0–$10,000

$10,000– $100,000

$100,000– $1,000,000

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

>$10,000,000

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 categorize consequences. CCPS does not endorse one method over another.

35

36


baseline modeling is time consuming and requires a good basic understanding of modeling techniques and physical processes. • The endpoints are not presented in terms of specific injury/fatality/cost figures, which can cause interpretation problems in some organizations.

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, using past experience, previously generated look-up tables, or knowledge of prior detailed release modeling of similar releases. Table 3.2 shows the consequence categorization resulting from this method. The resulting risk of an injury/fatality can be compared directly to a fatality risk tolerance criterion (see Chapter 8) for an individual event, or all of the events associated with a process or plant can be summed and then compared to process/plant risk tolerance criteria. The advantages of this method are: • Simplicity of understanding: Many people tend to better understand consequence in terms of harm rather than expressing risk in terms of release size. • Direct comparison with corporate guidelines: Many companies already have established guidelines for risk of a fatality/injury, or for risk of a certain monetary loss. The disadvantages of this method are: • Implicit assumptions for the probability of ignition for flammable releases, for the probability of injury, and the probability that a person is 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 different analysts, unless some guidance is provided across the company.

Method 3: Qualitative Estimates with Human Harm with Adjustments for Postrelease Probabilities Alternatively, the LOPA analyst can initially estimate the magnitude of a release “qualitatively” similar to Method 2 (but not as subjective as a look-up table similar to Table 3.2), and then later (as described in Chapter 7) adjust the event frequency by the probability that:


37

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 and with 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 and with 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 to cause immediate or long-term health effects

Facility

Major or total destruction of process area(s) at an estimated cost greater than $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 categorize consequences. CCPS does not endorse one method over another.

38


• • • •

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.

The advantages of this method: • Simplicity of understanding: People tend to better understand consequence in terms of harm rather than expressing risk in terms of release size. • Direct comparison with corporate guidelines: Many companies already have established guidelines for risk of a fatality or injury. • Frequency adjustments: The frequency adjustments may give a better estimate of the risk of human harm. The disadvantages of this method: • The simplifications made in assessing the probabilities of the events subsequent to the release. The results of real-world events have proven to be both significantly less and significantly greater than those calculated by analysts. However, if consistent approaches are used, it is reasonable to expect that this method will highlight scenarios with relatively higher risk. • Extra parameters for the probability of reaching the stated impact or outcome must be included in the risk calculation (described in Chapter 7), and these may change over time (e.g., the number of people or their location changes). • The estimation of the consequence severity may vary between different analysts, unless some guidance is provided across the company. • This method would need to be augmented to address business impact or 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 release and its effects upon individuals and equipment. This method involves the use of mathematical models (typically complex computerized models) to simulate the release itself (also called “source term” modeling), the subsequent dispersion, and the toxic or blast/thermal effect. Figure 3.2 illustrates the typical 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.


39

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

The advantages of this method: • A greater degree of certainty concerning the predicted consequences. • Direct comparison with corporate guidelines. The disadvantages of this method: • Although the modeling programs are much more sophisticated than the estimation methods, the results of real-world events have been both significantly less and significantly greater than those calculated by analysts. Modeling results are strongly affected by the exact release conditions (e.g., is the pipe severed or cracked? is the break near the tank or mid-run? is the release oriented up or down?), atmospheric stability, wind direction, time to ignition, etc. There are thousands of possible permutations to consider. Inevitably only a few “representative” cases can be chosen. • The level of sophistication required for modeling the consequence of a scenario is disproportionate to that used to estimate the order of magnitude frequency of the scenario with LOPA. • The training, experience and effort required to perform the modeling can be prohibitive, and such analysis is usually only applied to scenarios that have already been judged to have potentially fatal results.

40


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

3.4. Continuing Examples In this section, consequences are assessed for the scenarios described in the continuing examples. We will use two methods in this chapter to categorize the consequences to illustrate the concepts used for LOPA. The first (Method 1) will use a category, look-up method, using Table 3.1 as the reference table. For this approach, only the boiling point, flammability data, and total quantity of the material are required. The second (Method 3) will qualitatively estimate the scenario consequences using prior experience of the authors. Method 3 is further addressed in 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 a detailed dispersion calculation and flammable effects model (Method 4), but the 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.

Continuing Example 1: Hexane Surge Tank Overflow Scenario 1a: Hexane Surge Tank Overflow—Spill Not Contained by the Dike For this case, we will assume that the total overflow can be as large as 40,000 lb of hexane, and that the dike is present as an IPL (addressed in detail in Chapter 6). The dike has a probability of failure with the release spreading beyond the dike. METHOD 1

Using this method, the consequence category from Table 3.1 for a release of 40,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 a large pool fire. In view of the low volatility of hexane, a flammable cloud is


41

not expected beyond the pool. A flash fire is considered unlikely, based on the flash point of hexane at process temperatures. The fire has the capacity to injure personnel in the immediate area of the spill, which now includes an area beyond the dike. This qualitative interim 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 1b: Hexane Surge Tank Overflow—Spill Contained by the Dike Given the flow rate into the vessel, the frequency of operator rounds, and the many other upstream limitations and safeguards, the plant engineers estimate that the maximum overflow (after completely filling the vessel) is 40,000 lb of hexane. Scenario 1b assumes that the dike will work perfectly to contain the spill. METHOD 1

Using this method, there is no consequence since the release is completely contained 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 could result in a contained 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 the flash point of hexane at process temperatures. The fire has the capacity to injure personnel in the immediate area. This qualitative interim 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.

Continuing Example 2: Hexane Storage Tank Overflow Scenario 2a: Hexane Storage Tank Overflow—Spill Not Contained by the Dike For this case, we will assume that the total overflow can be as large as 40,000 lb of hexane, and that the dike is present as an IPL (addressed in detail in Chapter 6). The dike has a probability of failure with the release spreading beyond the dike. METHOD 1

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

42


METHOD 3

For this method up to 40,000 lb of hexane are released which could result in a large pool fire. Again, in view of the low volatility of the hexane, a flammable cloud 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 the capacity to injure personnel in the immediate area of the spill, which now includes an area beyond the dike. This qualitative interim 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 2b: Hexane Storage Tank Overflow—Spill Contained by the Dike For this case, we will assume that the total overflow can be as large as 40,000 lb of hexane, and that the dike will not fail. METHOD 1

Using this method, there is no consequence since the release is completely contained 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 which could result in a contained pool fire. Again, in view of the low volatility of the hexane, a flammable cloud 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 the capacity to injure personnel in the immediate area. of the spill. This qualitative interim result (a release of 40,000 lb of hexane into the dike) 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.

3.5. Link Forward Chapter 4 will explain how scenarios are selected and developed for purposes of LOPA. As mentioned earlier, categorizing the consequences is often the screening criteria for selecting the scenarios for LOPA. Other criteria can also be used. Chapters 5 and 6 will complete the data collection and scenario development efforts for a LOPA scenario.

4 Developing Scenarios

4.1. Purpose Scenario development is the LOPA step in which the team or analyst constructs a series of events, including initiating events and the failure of IPLs (independent protection layers), that lead to an undesired consequence. The purpose of this chapter is to describe the components of a scenario and give examples of how scenarios can be developed from hazard evaluations and other 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 an undesirable consequence. Each scenario consists of at least two elements (see Figure 4.1): • an initiating event (e.g., loss of cooling) that starts the chain of events and • a consequence (the potential for overpressuring the system, release of toxic or flammable material to the atmosphere, fatality, etc.) that results if 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

44

4. Developing Scenarios

FIGURE 4.1. Minimum requirements for a scenario

example, if a process is modified to significantly reduce the inventory of a toxic material that could be released, the consequence, and thus the risk, associated with a vessel rupture can be significantly reduced. Again, if a vessel is designed to resist an internal explosion, or the shut-off head of a pump, or a relief flow is passed to a flare rather than directly to the atmosphere, the risk associated with scenarios with these consequences may be reduced or eliminated. How inherently safer concepts can be incorporated into LOPA is discussed in more detail in Chapter 6. Each scenario must have a unique initiating event/consequence pair. If the same initiating event can result in different consequences, additional scenarios should be developed. In some cases many scenarios may spring from a common initiating event (e.g., loss of a utility to a facility) and separate scenarios should be developed for individual sections of the plant. In addition to the initiating event and consequence, a scenario may also include • enabling events or conditions that have to occur or be present before the 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 Chapter 6.) Methods that use consequence end-points of fatalities, or harm to business 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 vapor release), • the probability of a person being present in the area affected by the event,

FIGURE 4.2. Coincident initiating and enabling events.

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.

• the probability that a fatal injury will result from exposure to the effects of the fire, explosion, or toxic release—includes evacuation or protective action, or • the probability that an estimated financial loss to the facility of a certain magnitude 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 considered an IPL for the purposes of LOPA. If this IPL operates as intended, it will break the chain of events and prevent the undesired consequence from occurring (see Figure 4.4 and Chapter 6).

46


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 evaluation 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) designed

to detect high temperature/pressure and take action to prevent the runaway exothermic reaction; and • a correctly sized and maintained relief valve to prevent the overpressure of the system following an exotherm.

Figure 4.5 shows the scenario for Example 4.2 for loss of cooling leading to overpressure of the reactor: 1. Loss of cooling (Initiating Event) AND 2. Reactor in a condition where exotherm can occur if cooling is lost (Enabling Condition) AND 3. BPCS fails to act correctly (Failure of IPL) AND 4. 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 hazardous material and potential for fatalities, injuries, or property or environmental damage). As discussed in Chapter 3, the LOPA method used by a particular organization will affect how the consequences of each scenario are developed and completed. The effectiveness of the LOPA method relies heavily on the thoroughness of the detail presented in the scenario. Each scenario must be adequately documented (see Section 4.3 and Appendix C).

FIGURE 4.5. Scenario path for reactor Example 4.2.


47

4.3. Identifying and Developing Candidate Scenarios This section examines methods for identifying and developing scenarios to the level of detail required for LOPA.

Identifying Candidate Scenarios The most common source of information for identifying scenarios are hazard evaluations (HE) developed and documented for existing processes and performed during the design of new and modified processes. The purpose of an HE is to identify, assess and document the hazards associated with the process (see Guidelines for Hazard Evaluation Procedures, Second Edition with Worked Examples; CCPS, 1992a). Most HE methods are qualitative and do not enable an analyst or team to quantify whether the risk associated with a documented hazard is acceptable (so their judgment may be inconsistent). The HE may have already identified the initiating event for a given scenario, but enabling events and safeguards are often neglected, not included appropriately, or are not fully understood or documented. Figure 4.6 shows how information from a HAZOP type review could be used in developing a scenario for LOPA. HAZOP reports usually contain adequate information to describe the components of a scenario. LOPA can take HAZOP information and assign numeric values for initiating event frequency, failure frequency and 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 identified in the HAZOP are used to specify the initiating event and the LOPA method will assign a frequency to this event. Similarly, if the HAZOP identifies 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 estimates to make judgments of risk. Other sources for identifying candidate scenarios for LOPA are • issues related to plant operation. This could involve unexpected behavior, or operating conditions outside normal ranges, etc.; • incidents in the process, or from other processes, which reveal an initiating event or scenario not previously considered or which was not considered credible; • the requirement to change the process, which could involve new or modified scenarios; • interlock reviews to assess whether the safety instrumented function (SIF)—interlock—is required and, if so, the type of SIF required to meet the corporate risk guidelines.

48


FIGURE 4.6. HAZOP Information and LOPA.


49

Scenario Development Once a scenario has been identified, it must be developed and documented to the level where a basic understanding of the events and safeguards is achieved. The scenario may not be initially understood completely and may undergo revisions. New scenarios may also be revealed that must be analyzed separately. Table 4.1 shows one method for presenting the information required for full development of a scenario. Table 4.1 is discussed in more detail in Appendix C. Any format is acceptable, provided that it is comprehensive and applied consistently within an organization. Include All Steps of the Scenario A scenario requires identification and documentation of all the important steps required for an event to progress from the initiating event to the consequence. Any factor that could affect the numeric calculation of the consequence frequency or consequence size or type should be included and documented (see Appendix C). It is critically important to maintain the link between 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 temperature trip (a candidate IPL) might protect against the first and third scenarios, but might provide no protection against external fire in the second scenario. 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 analyst must determine whether any enabling events or conditions are required for the initiating event to lead to the consequence. Again, an understanding of how events could unfold is required. Chapter 5 deals with these issues in greater detail. The next step is to confirm that the consequence is stated using the same criteria as the LOPA method (see Chapter 3). If the LOPA method being applied 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 the method uses fatality frequency (Methods 3 and 4, Chapter 3), then appropriate probabilities must be assigned before the calculation for the scenario can be completed (see Chapter 7).

50

4. Developing Scenarios TABLE 4.1 Example of Summary Sheet for LOPA Scenario Documentation and Calculations

Scenario Number

Equipment Number

Date:

Scenario Title

Description

Consequence Description/Category Risk Tolerance Criteria (Category or Frequency) Initiating Event (typically a frequency) Enabling Event or Condition 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):

Frequency Probability (per year)


51

The next step in developing the scenario is to identify the safeguards that are in place, which, if they operate as intended, may prevent the scenario from proceeding to the consequence. It is best to list all of the safeguards for a particular scenario before deciding which are truly IPLs. This practice documents the issues considered and enables subsequent reviewers to understand why some safeguards were or were not considered to be IPLs. Chapter 6 describes the requirements for a safeguard to be considered as an IPL in LOPA. Care must be taken in applying these guidelines to ensure that a particular safeguard meets the requirements of an IPL. Example 4.4 demonstrates the development of a scenario for the reactor exotherm discussed in Examples 4.1 and 4.2. Example 4.4

Consider a typical hazard evaluation of the reactor runaway exotherm scenario presented in Examples 4.1 and 4.2:

• The HE team would almost certainly have identified the potential for a runaway exotherm on loss of cooling. However, a qualitative HE might not have documented: G That the potential for a runaway exotherm is only present during a specific portion of the batch cycle; and G 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, intermediates and products, etc. • The consequence described by the HE team may not match the classification used within an organization for making risk based judgments. The LOPA analyst must state the consequence in a manner consistent with the method being applied. • The HE team may have listed multiple safeguards against overpressuring the system, but may not have considered whether these safeguards were fully effective and independent of the initiating event and other protection layers. These safeguards might include operator action, alarms, multiple BPCS loops, SIF loops, relief devices, etc. The LOPA analyst should review the list of safeguards generated by the HE to identify those considered as true IPLs in LOPA.

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

52


tion becomes available as the analysis progresses and questions are often asked concerning the assumptions made earlier. This new information may demonstrate that the consequence is less serious than initially thought, that there are more IPLs than originally included in the analysis, or that the initiating frequency is lower, etc. In other cases the analysis may show that the risk is greater than first thought, due to safeguards not being truly independent or effective, or due to the initiating event frequency or consequence being greater than originally assumed. In some cases this analysis can lead to development of new scenarios as a greater understanding of the system is gained. This new understanding may also affect how similar scenarios are viewed in other processes. This is one of the side benefits of the LOPA process. A documentation and tracking system should be used to ensure that the scenario and associated issues, recommendations, references, assumptions, etc. are fully documented and recommendations are resolved (see Appendix C).

4.4. Continuing Examples Tables 4.2 and 4.3 present the results of a HAZOP for the continuing examples used in this book. Chapter 2 provided the basic problem descriptions together with the P&IDs and other relevant information. Chapter 3 identified the undesired consequences. In some LOPA methods the spill itself is the consequence end-point (the event itself must be prevented and the probabilities of ignition of the flammable material and the presence of personnel are viewed as irrelevant). Other approaches use the fatality frequency due to ignition of the spill inside or outside of the dike, including the various probabilities discussed in Examples 4.1 and 4.2 of Section 4.2. The HAZOP method and results shown in Tables 4.2 and 4.3 are for illustration and use a generic approach with key words for the deviation (low flow or no flow, high temperature, etc.) used to initiate discussion. The HAZOP tables then show whether a cause, or causes, for this deviation are present in the system and what consequences could result. Any safeguards are then listed against the cause leading to the deviation. Finally, any recommendations that are considered appropriate are listed, using a qualitative ranking approach. The results of the HAZOP for both installations indicate that loss of containment from the tank is a significant concern. There are several scenarios relating to loss of containment in Tables 4.2 and 4.3, but the scenarios selected for demonstrating the LOPA methodology in this book involve high liquid level leading to an overflow. Table 4.4 shows Scenario 1a of Example 1 developed using a matrix method for consequence and risk assessment (Method 1 from Chapter 3). In Table 4.5, Scenario 2a of Example 2 is developed using the fatality frequency method for consequence and risk assessment (Method 3 from Chapter 3). These tables only contain information on the consequence

53

4.4. Continuing Examples TABLE 4.2 HAZOP for Hexane Surge Tank Section 1— Line from the “prior process” to Hexane Surge Tank T-401 Drawing: P&ID for Continuing Example 1 Figure 2.12 Item

Deviation

Causes

1.1

High flow

Flow control valve High level—Hexane transfers or fails Surge Tank T-401 open (see 2.1)

1.2

Low flow or no flow

Blocked flow (e.g., plugged line) Downstream manual block valve inadvertently closed or gate falls

Low pressure (see 1.7)

Consequences

Low level—Hexane Surge Tank T-401 (see 2.2)

Potential overheating and failure of upstream pump seal outside battery limit (OSBL) of study

1.3

Reverse flow

Low pressure (see 1.7)

1.4

High temperature

No credible causes identified

1.5

Low temperature

No consequences of interest

1.6

High pressure


1.7

Low pressure

1.8

High concentration of contaminants

1.9

Loss of containment

Upstream pump (OSBL) fails off

Safeguards

Possible loss of containment (see 1.9)

Check valve

Low flow or no flow Local pressure (see 1.2) gauge at discharge of Reverse flow (see upstream 1.3) pump (OSBL) No consequence of interest—contamination downstream, possibly resulting in unit upset

Corrosion/ erosion

External fire

External impact

Gasket, packing, or seal failure Hydraulic hammer (continued on next page)

Release of hexane; fire hazard affecting a large area (consequence category 4 or 5)

Operation/ maintenance response as required, including isolation if needed Capability to manually isolate the line (continued on next page)

Recommendations

54 Item

4. Developing Scenarios Deviation

1.9 Loss of cont. containment

Causes

Consequences

Improper maintenance

Instrument or instrument line failure

Corrosion probes

Thermal expansion with equipment blocked in

Periodic nondestructive inspection

Reverse flow (see 1.3) High level

Recommendations

Check valve to prevent a large back-flow through a line breach

Material defect

2.1

Safeguards

High flow—Line from the “prior process” to Hexane Surge Tank T-401 (see 1.1)

High pressure (see 2.5)

No safety consequences—Potential process interruption if not refilled before downstream feed tank is empty

Level indication with high level alarm (audible in control room) Unit operating procedures

2.2

Low level

Low flow or no flow—Line from the “prior process” to Hexane Surge Tank T-401 (see 1.2)

2.3

High temperature


2.4

Low temperature

Low ambient temperature while there is water contamination in the tank (see 2.7)

2.5

High pressure

High level (see 2.1) Release of hexane through the relief valve into the tank’s dike; fire hazard affecting a large area if not contained by the dike (consequence category 4 or 5)

Possible freezing of accumulated water in the heel of the tank or in the tank’s drain line or instrument lines, resulting in fracture of the drain line and loss of containment (see 2.8)

Loss of containment (if the overpressure cause exceeds the tank pressure rating) (see 2.8)

Consider installing an SIS to shut off inlet flow on highhigh level in T-401

55

4.4. Continuing Examples Item

Deviation

Causes

Consequences

2.6

Low pressure

Tank blocked in before cool-down, following steamout

Equipment damage resulting from collapse of the tank under vacuum

2.7


Water not completely drained following a steamout or washout

Possible freezing of accumulated water in the tank during a period of low ambient temperature (see 2.4)

2.8

Loss of containment

Corrosion/erosion Release of hexane; fire hazard affecting External fire a large area, particuExternal impact larly if the capacity Gasket, packing, of the dike is or seal failure exceeded (conseImproper mainte- quence category 4 or 5) nance Instrument or instrument line failure Material defect Sample station valve leaking Vent or drain valve leaking

Low temperature (see 2.4)

High pressure (if the overpressure cause exceeds the equipment pressure rating) (see 2.5)

Safeguards

Recommendations

Standard procedures and checklist for steam-out of vessels

Operation/ maintenance response as required, including isolation if needed

Capability to manually isolate the tank Periodic nondestructive inspection per API recommended practices and ASME code

Relief valve that discharges to the tank’s dike Dike sized for 120,000 lb of hexane (1.5 times capacity of tank) Emergency response procedures

and the initiating event; the remaining fields in the tables, including numeric data, will be completed as the continuing example problems are discussed in the other chapters of this book. Appendix A contains the completed LOPA summary tables for all continuing examples using the risk matrix, fatality frequency, and required number of IPL methods, which are discussed in Chapter 8.

TABLE 4.3A HAZOP for Hexane Storage Tank Section 1—Line from the Tank Truck to Hexane Storage Tank T-301 Through Hexane Unloading Pump 3-40 Drawing: P&ID for Continuing Example 2 Figure 2.13 Item

Deviation

Causes

Consequences

Safeguards

3.1

High flow


3.2

Low flow or Blocked flow (e.g., no flow plugged line) Downstream manual block valve inadvertently closed or gate falls Low pressure (see 3.7)

Potential overheating and failure of pump seal (see 3.9) Low level—Hexane Storage Tank T-301 (see 4.2)

3.3

Reverse flow

Drain valve inadverPossible loss of contently left open while tainment (see 3.9) unloading pump is off Low pressure (see 3.7)

3.4

High temperature


3.5

Low temperature


3.6

High pressure


3.7

Low pressure

Unloading pump fails Lowflow or no flow off (see 3.2) Reverse flow (see 3.3)

Local pressure gauge

3.8


Contamination (organic, moisture, or debris) in flexible unloading lines Contamination in the tank truck Receiving or spotting the wrong tank truck

High concentration of contaminants— Hexane Storage Tank T-301 (see 4.7)

Hexane unloading procedures Caps for flexible unloading line Material testing procedure prior to unloading

3.9

Loss of Corrosion/erosion containment External fire External impact Gasket, packing, or seal failure Hydraulic hammer Improper maintenance Instrument or instrument line failure Material defect Thermal expansion with equipment blocked in Low flow or no flow (see 3.2) Reverse flow (see 3.3)

Release of hexane; fire hazard affecting a large area (consequence category 4 or 5)

Operation/maintenance response as required, including isolation if needed Capability to manually isolate the line Check valve to prevent a large backflow through a line breach Corrosion probes Periodic nondestructive inspection

Check valve

TABLE 4.3B HAZOP for Hexane Storage Tank—Hexane Storage Tank T-301 Drawing: P&ID for Continuing Example 2 Figure 2.13 Item

Deviation

Causes

Consequences

4.1

High level

High pressure (see Flow from tank truck not discon- 4.5) tinued before tank capacity has been reached Inventory control error—Truck arrives before needed

4.2

Low level

No safety consequences— Potential process interruption if not refilled before downstream feed tank is empty

4.3

High temperature

Inventory control error—Truck arrives too late Lowflow or no flow—Line from the Tank Truck to Hexane Storage Tank T-301 Through Hexane Unloading Pump 3-40 (see 3.2)

Low ambient temperature while there is water contamination in the tank (see 4.7)

Possible freezing of accumulated water in the heel of the tank or in the tank’s drain line or instrument lines, resulting in fracture of the drain line and loss of containment (see 4.8)

4.4

4.5

Low temperature

High pressure


High level (see 4.1)

Safeguards Level indication with high level alarm (audible in control room) Hexane unloading procedures with checklist that includes checking field reading of tank level before unloading

Recommendations Consider installing an SIS to shut off inlet flow on highhigh level in T-301

Release of hexane through the relief valve into the tank’s dike; fire hazard affecting a large area if not contained by the dike (consequence category 4 or 5) Loss of containment (if the overpressure cause exceeds the tank pressure rating) (see 4.8)

Continued on next page

58 Item

4. Developing Scenarios Deviation

Causes

Consequences

Safeguards Standard procedures and checklist for steam-out of vessels

4.6

Low pressure

Tank blocked in before cooldown, following steam-out

Equipment damage resulting from collapse of the tank under vacuum

4.7


Water not completely drained following a steam-out or washout

Possible freezing of accumulated water in the tank during a period of low ambient temperature (see 4.4)

Corrosion/ erosion

Release of hexane; fire hazard affecting a large area, particularly if the capacity of the dike is exceeded (consequence category 4 or 5)

High concentration of contaminants—Line from the Tank Truck to Hexane Storage Tank T-301 Through Hexane Unloading Pump 3-40 (see 3.8) 4.8

Loss of containment

External fire

External impact

Gasket, packing, or seal failure Improper maintenance

Instrument or instrument line failure Material defect Sample station valve leaking Vent or drain valve leaking

Low temperature (see 4.4)

High pressure (if the overpressure cause exceeds the equipment pressure rating) (see 4.5)

Operation/ maintenance response as required, including isolation if needed Capability to manually isolate the tank Periodic nondestructive inspection per API recommended practices and ASME code

Relief valve that discharges to the tank’s dike Dike sized for 120,000 lb of hexane (1.5 times capacity of tank) Emergency response procedures

Recommendations


59

To complete the analysis for this system, the LOPA team or analyst would also consider other scenarios (such as rupture of the flexible filling hose, pump seal failure, etc.), develop quantitative values for the various components of the scenario, and determine whether the existing risk meets the relevant criteria. Chapters 5–8 demonstrate this procedure for the continuing examples.

Continuing Example 1: Hexane Surge Tank Overflow As this is a continuous process, the control of the liquid level in the tank is a dynamic process that relies upon instrumentation to take action. The dike has adequate capacity to contain the overflow for a period of time sufficient for the operator to detect the spill for the normal flow rate into the tank. The initiating event for this example is failure of the LIC (a BPCS loop), which includes instrumentation failures and operator errors if the level control is set to manual or is bypassed. This could lead to overfilling of the tank and a spill into the dike surrounding the tank. The size or type of consequence depends on whether this dike contains the spill. The two separate scenarios developed for this case follow. Scenario 1a: Hexane Surge Tank Overflow—Spill Not Contained by the Dike The initiating event is failure of the level loop leading to tank overflow and release outside the dike due to the dike failure. The consequence (depending upon the method adopted) is a release, or fire outside the dike with possible injuries or fatalities. Existing safeguards, which are candidate IPLs for this scenario, include human intervention (operator response to alarms via the BPCS, and procedures), and the dike. The safeguards will be tested in Chapter 6 to determine if they are IPLs. The LOPA summary sheet for this scenario using the risk matrix method is shown in Table 4.4. Summary sheets for the other methods are shown in Appendix A. Scenario 1b: Hexane Surge Tank Overflow—Spill Contained by the Dike The initiating event is failure of the level loop leading to tank overflow with the spill contained by the dike. The consequence (depending upon the method) may be the spill itself or a fire in the dike with possible injuries or fatalities. Existing safeguards, which are candidate IPLs for this scenario, include human intervention (operator response to alarms via the BPCS, and procedures) and the dike. 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 are shown in Appendix A. The risk matrix method would not consider this a scenario, since the consequence of a spill inside the dike would not be considered a significant event (see Chapter 3).

TABLE 4.4 Summary Sheet for Continuing Example Scenario 1a—Risk Matrix Consequence Categorization Method (Method 1 of Chapter 3) Scenario Number

Equipment Number

1a

Scenario Title: Hexane Surge Tank Overflow. Spill not contained by dike

Date:

Description

Consequence Description/Category

Release of hexane outside the dike due to tank overflow and spill of hexane Severity Category 4


Risk Tolerance Criteria (Category or Frequency) Initiating Event (typically a frequency)

Loop failure of BPCS LIC.

Enabling Event or Condition Conditional Modifiers (if applicable) Probability of ignition

N/A

Probability of personnel in affected area N/A Probability of fatal injury

N/A

Others

N/A

Frequency of Unmitigated Consequence Independent Protection Layers None identified at this stage of the analysis. See Notes (below) for candidate IPLs Safeguards(non-IPLs) See Notes (below)

Total PFD for all IPLs Frequency of Mitigated Consequence Risk Tolerance Criteria Met? (Yes/No): Actions Required to Meet Risk Tolerance Criteria: Notes

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

References (links to originating hazard review, PFD, P&ID, etc.): LOPA analyst (and team members, if applicable): 60

4.5 Link Forward

61

Continuing Example 2: Hexane Storage Tank Overflow The potential exists for liquid overflow of the tank if the truck arrives for unloading with insufficient room in the tank. This would result in a spill into the dike. The scenarios developed for this case follow. Scenario 2a: Hexane Storage Tank Overflow— Spill Not Contained by the Dike The initiating event is failure of the inventory control system, allowing the tank truck to arrive with insufficient room in the tank. The result is liquid overflow of the tank with spillage outside the dike. The consequence is a release outside the dike with the potential for fire and/or injury. A candidate IPL is the dike. Other existing safeguards, which are candidate IPLs for this scenario, include human intervention (operator response to alarms via the BPCS, and procedures). The LOPA summary sheet for this scenario using the fatality frequency methodology is shown in Table 4.5. Summary sheets for the other methodologies are shown in Appendix A. Scenario 2b: Hexane Storage Tank Overflow— Spill Contained by the Dike The initiating event is failure of the inventory control system, allowing the tank truck to arrive with insufficient room in the tank. The result is liquid overflow of the tank with spillage inside the dike. The consequence is a release inside the dike with the potential for fire and/or injury. Other existing safeguards, which are candidate IPLs for this scenario, include human intervention (operator response to alarms via the BPCS, and procedures) and the dike. 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, are shown in Appendix A. The risk matrix method would not consider this as a scenario, since the consequence of a spill inside the dike would not be considered a significant event (see Chapter 3). An issue arising from these scenarios is that some organizations would not evaluate scenarios 1b and 2b for release within the dike, based on their experience of the severity of the consequence. This judgment is dependent upon the material released and the conditions of the release (temperature, pressure, location, etc.). This applies to flammables, but not to materials that could 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 and how to estimate these values accurately.

TABLE 4.5 Summary 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 Overflow. Spill not contained by the dike

Date:

Description

Consequence Description/Category

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


Risk Tolerance Criteria (Category or Frequency) Initiating Event (typically a frequency)

Arrival of tank truck with insufficient room in the tank due to failure of the inventory control system. Frequency based upon plant data.

Enabling Event or Condition 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 None identified at this stage of the analysis. See Notes (below) Safeguards(non-IPLs)

See Notes (below)

Total PFD for all IPLs Frequency of Mitigated Consequence Risk Tolerance Criteria Met? (Yes/No): Actions Required to Meet Risk Tolerance Criteria: Notes:

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

References (links to originating hazard review, PFD, P&ID, etc.): LOPA analyst (and team members, if applicable): 62

5 Identifying Initiating Event Frequency

5.1. Purpose The purpose of this chapter is twofold. First, it provides guidance on identifying true initiating causes (called initiating events in LOPA) of incident scenarios, and second, it provides guidance on estimating the frequency of initiating events. This chapter addresses Step 3 of the LOPA methodology described in Chapter 2.

5.2. Initiating Events Expression of Initiating Events For LOPA, each scenario has a single initiating event. The frequency of the initiating event is normally expressed in events per year. Some sources use other units, such as events per 106 hours.

Types of Initiating Events Initiating events are grouped into three general types: external events, equipment failures, and human failures (also called inappropriate actions). These are 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 Process Incidents; CCPS, 1992b). Initiating events can be the result of various underly63

64

5. Identifying Initiating Event Frequency

FIGURE 5.1. Types of initiating events.

ing root causes such as external events, equipment failures, or human failures, 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 identifying initiating events. Root causes can, however, contribute to determining the frequency of occurrence of the initiating event. Therefore, it may be appropriate to consider some root causes (e.g., inadequate procedures and/or training) when estimating the frequency of the initiating events as described in Section 5.3 of this chapter. External Initiating Events As depicted in Figure 5.1, external events include natural phenomena such as earthquakes, tornadoes, or floods, “knock-on” events from fires or explosions in adjacent facilities; and third party intervention such as mechanical impact on equipment or supports by motor vehicles, or construction equipment. Sabotage and terrorism are initiating events that require special treatment, because a true saboteur may defeat, or attempt to defeat, IPLs as well. It may be impossible to protect against sabotage and terrorism. Equipment-Related Initiating Events As depicted in Figure 5.1, equipment-related initiating events can be further classified into control system failures and mechanical failures. Control system failures include, but are not limited to:


65

• 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 manufacturing/fabrication defects; • vessel or piping failure caused by overpressure (e.g., thermal expansion, pigging/blowing) or underpressure (vacuum collapse); • vibration-induced failures (e.g., in rotating equipment); • failures caused by inadequate maintenance/repair, including substitution 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., autorefrigeration, 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 Events As depicted in Figure 5.1, causes related to human failures are either errors of omission or errors of commission, and include but are not limited to • failure to execute the steps of a task properly, in the proper sequence or omitting steps (something not done) and • failure to observe or respond appropriately to conditions or other prompts by the system or process (something done wrongly). Management systems are not normally listed as potential initiating events, although ineffective management systems are quite often a root cause of human error. For the purposes of LOPA, a cause-identification methodology stopping at a specific human error as the initiating event is sufficient. The analyst should avoid carrying the initiating event analysis too far into root causes of human error, at least at this stage. However, further analysis may be appropriate at the end of the LOPA, when appropriate means of safeguarding are being considered. For a more comprehensive discussion of human error and procedural causes, refer to Guidelines for Preventing Human Error in Process Safety (CCPS, 1994b), or other public domain sources.

66


Verification of Initiating Events Prior to assigning frequencies to initiating events, all causes from the scenario development step should be reviewed and verified as valid initiating events for the consequence identified (i.e., there must be a unique cause–consequence relationship). Any causes that are incorrect or inappropriate should be either discarded or developed into valid initiating events. Examples of inappropriate initiating events include • Inadequate operator training/certification: This is a possible underlying cause of an initiating event (site- or company-specific levels of training and certification are assumed in assigning failure rates). • Inadequate test and inspection: This is a possible underlying cause of an initiating event (site- or company-specific normal levels of test and inspection 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 device is challenged). The analyst should also verify that all the potential initiating events were determined by viewing the process from a system perspective, and ensuring that any causes normally generic to this process or similar processes have not inadvertently been excluded. In addition, the analyst should reduce each cause into discrete failure events. For example, the cause “loss of cooling” could be the result of a coolant pump failure, power failure, or control loop failure. Listing these separately is useful, because the existing (and new) potential layers of protection (described in Chapter 6) may be different for each initiating event. In addition, the analyst should ensure that initiating events in all modes of operation (e.g., normal operation, startup, shutdown, utility outages) and equipment states (e.g., standby, under maintenance) have been identified/examined. Any of these may involve discrete failures that could cause loss of cooling and in turn result in the consequence of interest. A spurious trip of a safety instrumented function (SIF), which is an independent protection layer for an accident scenario, is only considered an initiating 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 this section, where failure of a relief device to operate on demand is not a valid initiating event of an “overpressure leads to vessel failure” scenario. However, there are circumstances under which spurious trips of protective systems can affect frequencies of initiating events and result in challenges to other protective 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


67

involving a possible firebox explosion and its attendant hazards by increasing the frequency of startups (restarts).

Enabling Events/Conditions In some scenarios, the initiating event may not be obvious. As the PHA or LOPA team identifies scenarios that lead to safety consequences, some will be developed where the initiating or triggering event is not clear. In such complex scenarios, there may be other factors that are neither failures nor protection layers. These factors are called enabling events or conditions, and consist of operations or conditions that do not directly cause the scenario, but which must be present or active in order for the scenario to proceed. Enabling events are expressed as probabilities, and can include such things as the mode of operation (startup or shutdown) or the operation being in a specific phase or step. In such cases, the initiating event may be the combination of an enabling event (probability) and a subsequent failure or inappropriate action (frequency). This is shown in Examples 5.2 and 5.3 below. Some companies use enabling events/conditions to modify initiating event frequencies. Some do not because of the resulting complexity and potential for underestimation of 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 possibly 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 systems 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 important for the LOPA team to understand that this initiating event is a combination 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 releasing phosgene. Solution: Two approaches are possible for this example. In the first, the initiating event is dropping the uncapped phosgene cylinder during movement; note that the initiating event has two parts, moving the uncapped cylinders and dropping one. Thus, the frequency of the initiating event is

68


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 hazardous event 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 the operation 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 any skill improvements as a result of performing the task more frequently may be more than offset by the sheer number of opportunities for error. Therefore, some LOPA analysts use only a few discrete values for human error, rather than adjusting for enabling event frequency. This avoids the underestimation of the likelihood for human error for tasks done only a few times per year. Furthermore, estimation of the error probability for a complex task is often very difficult, and probably outside the scope of LOPA. The organization must develop 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 appropriate to a specific LOPA evaluation, then perhaps the analyst should consider performing a quantitative risk analysis for that case.

5.3. Frequency Estimation Failure Rate Data Sources A number of sources of failure rate data are available for assigning consistent values to the initiating event frequency. These include • industry data such as the Guidelines for Chemical Process Quantitative Risk Analysis (CCPS, 1989a) and the Second Edition (CCPS, 2000a), Guidelines for Process Equipment Reliability Data (CCPS, 1989b), and other public domain sources such as IEEE (1984), EuReData (1989), and OREDA (1989, 1992, 1997). CCPS also has a project underway for sharing failure rate data among participating companies. • company experience (including hazard analysis team experience), where enough historical data are available to be statistically significant. (Note: Operator experience is often a better source for specific events, whereas generic industry failure rate data are often better for overall equipment failures, because many companies do not have a good internal database for failure data.)

5.3. Frequency Estimation

69

• vendor data, which are typically optimistic, since the data are developed in clean, well-maintained settings, or may be based on components returned to the vendor—many failed components are thrown away, rather than returned. When a cause may have multiple component failures, use of simplified fault trees or event trees may be appropriate to derive the combined failure frequency (e.g., primary control loop failure). In general, such techniques should only be used selectively to prevent the LOPA process from becoming overly complex. Remember, LOPA is a methodology that falls between simple qualitative and more elaborate quantitative analysis techniques. Selection of Failure Rates Failure rates should be selected with a number of issues in mind: • Failure rates should be consistent with the basic design of the facility and be consistent with the company method for making risk-based decisions. • All the failure rates used should be from the same location in the data range (e.g., upper bound, lower bound, or midpoint), providing a consistent degree of conservatism for the entire process. • The failure rate data selected should be representative of the industry or operation under consideration. If historical data are available, they should be used only if sufficient data are available over an adequate period of time to be statistically significant. If general industry data are used, they should be adjusted (usually by consideration of limited plant data and expert opinion) to reflect local conditions and situations. Where such data may not be directly available, judgment must be used in deciding which data from outside sources are most applicable to the situation (e.g., use of US Department of Transportation pipeline failure data for in-plant piping systems). Many failure rate databases contain data presented with two or more significant places. This is much more precision than required for LOPA (and also often much more precise than the data warrants!). LOPA only requires orderof-magnitude approximation, and such data should be rounded up to the nearest whole order of magnitude. As noted earlier, caution should also be used in applying vendor-supplied data, as such data are often developed from best-achievable or laboratory performance. Underlying assumptions are always involved in selection of failure rate data. These normally include, among others, assumptions on the range of operating parameters, the specific chemicals processed, basic testing and inspection frequency, operator and maintenance training programs, and equipment design quality. It is therefore important to ensure that the failure rate data used for a process is consistent with the basic assumptions inherent

70


with the data. (For instance, it would be inappropriate to apply OREDA data developed by the petroleum industry for North Sea off-shore oil rigs directly to chemical operations in Kansas.) These assumptions should be documented so that future data selections are made consistently. The LOPA method also assumes that the failure rate is constant. This is not always true, since equipment failure rates are typically higher when the equipment is new (“infant mortality”) and when it ages (“old age”). However, for most equipment the longest period of operation involves a constant failure rate. For the purposes of LOPA, a constant failure rate is adequate. Failure Rates in LOPA Typically, for LOPA, a company should lump discrete initiating event frequencies into a representative set of initiating event categories. This improves the consistency of risk estimates across an organization. Typical initiating event frequencies used by LOPA analysts in the chemical industry are shown in Table 5.1. For control system failures, the overall loop failure rate typically includes failure of any of several components (transmitter, air supply, DCS, valve, sensor, etc.) and can include other factors such as improper set points, miscalibration, operation on manual or off-cascade. Derivation of Initiating Event Frequency from Failure Data Failure 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 be derived. This involves estimating the number of times per year (or times per 106 hours) that a demand is placed on the system (or person). This may be as straightforward as counting the number of times the operation is carried out per year and multiplying by the probability of failure on demand (assuming the two values are not interdependent). Or, it may be as complex as using fault tree techniques to estimate the number of challenges per year to which the system is subjected. LOPA is a simplified approach, and the analyst should move on to more rigorous techniques if the scenario is overly complex or more precision is desired. Time at Risk For systems/operations that are not continuously operated (loading/ unloading, batch processes, etc.) failure rate data must be adjusted to reflect the ‘time at risk’ for the component or operation under consideration. Since

71

5.3. Frequency Estimation TABLE 5.1 Typical Frequency Values, fI, Assigned to Initiating Events Frequency Range Initiating Event

from Literature (per year)

Example of a Value Chosen by a Company for Use 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 casing breach

10–3 to 10–4

1 × 10–4

Third party intervention (external impact by backhoe, 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 61511 limit 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 per opportunity

1 × 10–3 per opportunity

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

10–1 to 10–3 per opportunity

1 × 10–2 per opportunity

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

72


most failure rate data are expressed with units of “per year” (yr–1), it is necessary to adjust the data to reflect that the component or operation is not subject to failure during the entire year, but only that fraction of the year when it is operating or ”at risk.” This is normally done by multiplying the base failure rate 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 hazardous 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 the year 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 Rates Some LOPA methodologies adjust the unmitigated consequence frequency to reflect such factors as probability of personnel being exposed to a hazard, probability of ignition, and probability of injury or fatality should an exposure occur. This adjustment may be made either in the determination of the initiating event frequency, or in the calculation of the final scenario frequency, as described in Chapter 7. Generally, analysts do not go to this level of detail, since LOPA is a simplified technique. If this level of accuracy is necessary, fault trees or event trees may be necessary, and the scenario should be analyzed using those more rigorous methods. Users of LOPA have noted that higher levels of scrutiny do not always provide a better risk decision.

73


High Demand Mode When the initiating event frequency is more than twice the first IPL test frequency, it is called high demand mode. Section 7.2 and Appendix F discuss how to select the initiating event frequency for LOPA calculations for high demand mode.

5.4. Expression of Failure Rates There are several ways of expressing failure rates used in LOPA. The method used should be consistent with the basic criteria and design of the LOPA methodology. 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. TABLE 5.2 Various 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.

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 where more definitive failure rates are not available.

5.5. Continuing Examples Continuing Example 1: Hexane Surge Tank Overflow For the tank overflow scenario resulting from instrument failure, the obvious initiating event is failure of the tank level indicator/controller (LIC). Its initiating event frequency is, from Table 5.1 f I = 1 × 10–1/yr loop failure rate

74


Continuing Example 2: Hexane Storage Tank Overflow For this example, the overflow of the hexane storage tank is initially caused by an inventory control error. This results in inadequate room for unloading the truck. The initiating event frequency will be the number of times per year that the inventory control system fails. This has been determined by the PHA team 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 a function of the lead time for ordering hexane, the frequency of inventory verification, and the plant shutdown frequency (which would lead to reduction in usage and slower than normal depletion of the hexane inventory).

5.6. Limitations (Cautions) The LOPA method is a simplified (semiquantitative) method, and is not exhaustive (see the risk decision tools spectrum, Figure 2.3). If a more detailed analysis is required, a method such as fault tree or event tree analysis may be more appropriate. Also, LOPA may be inappropriate for very high consequence events since the risk tolerance is significantly lower for these events. It may be necessary to proceed to risk assessment techniques nearer to CPQRA in such cases. One trap to avoid is incorporating an IPL failure into the initiating event frequency. Referring to the phosgene cylinder in Example 5.3, the two approaches treat the probability of the cap being missing differently and must not be intermingled. Either approach works, provided it is applied consistently. The existence, or lack, of a procedure to check that a cylinder is capped before it is moved could affect the probability that a cylinder is uncapped when it is moved. Alternatively, it could affect the PFD for a human 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) and their application in the next step in LOPA. The reader will see how various forms of IPLs are applied and their subsequent reduction of the scenario frequency to the final risk value.

6 Identifying Independent Protection Layers

6.1. Purpose The purpose of this chapter is to discuss the concept of an independent protection layer (IPL) and its use in layer of protection analysis (LOPA). This is Step 4 of the LOPA process. Several examples are used throughout the chapter 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 scenario from proceeding to its undesired consequence independent of the initiating event or the action of any other layer of protection associated with the scenario. 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 IPL has the opportunity to act. If it operates as intended the undesired consequence is prevented. If all of the IPLs in a scenario fail to perform their functions then the undesired consequence will occur following the initiating event. The distinction between an IPL and a safeguard is important. A safeguard is any device, system, or action that would likely interrupt the chain of events following an initiating event. However, the effectiveness of some safeguards cannot be quantified due to lack of data, uncertainty as to independence or effectiveness, or other factors. 75

76

6. Identifying Independent Protection Layers

FIGURE 6.1. Event tree showing effect of IPL success or failure when demanded. See Figure 2.2 for the effect of multiple IPLs.

All IPLs are safeguards, but not all safeguards are IPLs.

The effectiveness of an IPL is quantified in terms of its probability of failure on demand (PFD) which is defined as the probability that a system (in this case the IPL) will fail to perform a specified function on demand. The PFD is a dimensionless number between 0 and 1. The smaller the value of the PFD, the larger the reduction in frequency of the consequence for a given initiating event frequency. The “reduction in frequency” achieved by an IPL is sometimes termed the “risk reduction factor.” Figure 2.1 shows the layers of safeguards that can be employed to prevent 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 in reducing the frequency or consequence of an initiating event. The characteristics of these layers, and whether they should be credited as IPLs in the LOPA method, are discussed below.

Process Design In many companies, it is assumed that some scenarios cannot occur because of the inherently safer design of the process equipment. For example, the equipment might be designed to withstand the maximum pressure for a particular scenario, batch size might be limited, inventory lowered, chemistry modified, etc.; i.e., scenarios are eliminated by the inherently safer design.


77

Inherently safer process design features are encouraged to eliminate possible scenarios

—Inherently Safer Chemical Processes: A Life Cycle Approach (CCPS, 1996b).

In other companies, some inherently safer process design features are considered to have a nonzero PFD—that is, they do have possible failure modes that have been observed in industry. These companies consider such inherently safer process design features as IPLs. The design of the IPL is intended to prevent the consequence from occurring. For example, a pump may have an impeller that is too small to generate high pressure in a downstream vessel. The latter approach allows a company to compare the risk between plants designed using different equipment standards; the analysis can result in different failure rates for similar pieces of equipment which in turn might require additional IPLs for the equipment with higher failure rates. The LOPA analyst should be aware that inherently safer process design features may have a PFD and appropriate inspection and maintenance (auditing) might be required (e.g., a small impeller may be replaced with a larger impeller during repair or maintenance, batch size may be changed, etc.). Whether process design should be credited as an IPL, or considered as a method of eliminating a scenario, depends upon the method employed within a particular organization (see also Sections 6.4 and 6.5, and Example 6.5). Either approach can be used, but must be applied consistently within an organization.

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 designed to maintain the process in the safe operating region. The normal operation of a BPCS control loop may be credited as an IPL if it meets the appropriate criteria (see Section 6.5). As discussed in Chapter 5, the failure of the BPCS can be an initiating event. When considering using the BPCS as an IPL, the analyst must evaluate the effectiveness of the access control and security systems as human error can degrade the performance of the BPCS.

Critical Alarms and Human Intervention These systems are the second level of protection during normal operation and should be activated by the BPCS. Operator action, initiated by alarms or observation, can be credited as an IPL when various criteria are satisfied to assure the effectiveness of the action (e.g., independence—see Section 6.5). Company procedures and training may improve the performance of humans in the system, but procedures themselves are not an IPL.

78


Safety Instrumented Function (SIF) A SIF is a combination of sensors, logic solver, and final elements with a specified safety integrity level that detects an out-of-limit (abnormal) condition and brings the process to a functionally safe state. A SIF is functionally independent of the BPCS. A SIF is normally considered to be an IPL and the design of the system, the level of redundancy, and the amount and type of testing 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 IPLs which can provide a high degree of protection against overpressure in clean services. However, their effectiveness can be impaired in fouling or corrosive services, if block valves are installed under the relief valves, or if the inspection and maintenance activities are of poor quality. If the flow from the relief valves is discharged to the atmosphere, additional consequences may occur which will require examination (see Section 6.5). This could involve the examination 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 if designed and maintained correctly. Although their failure rates are low, possibility of failure should be included in the scenarios. Also, if automatic deluge systems, foam systems, or gas detection systems, etc., meet the requirements of IPLs (see Section 6.5), then some credit can be taken for these devices 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 initial release and there are too many variables (e.g., time delays) affecting their overall 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 initial release and there are too many variables affecting their effectiveness in mitigating a scenario. They provide no protection for plant personnel.

79


Table 6.1 is a summary of safeguards that are not normally considered to be IPLs. TABLE 6.1 Examples of Safeguards Not Usually Considered IPLs Safeguards not Usually Considered IPLs

Comments

Training and Certification

These factors may be considered in assessing the PFD for operator action, but are not—of themselves—IPLs.

Procedures

These factors may be considered in assessing the PFD for operator action, but are not—of themselves—IPLs.

Normal Testing and Inspection

These activities are assumed to be in place for all hazard evaluations and form the basis for judgment to determine PFD. Normal testing and inspection affects the PFD of certain IPLs. Lengthening the testing and inspection intervals may increase the PFD of an IPL.

Maintenance

This activity is assumed to be in place for all hazard evaluations and forms the basis for judgment to determine PFD. Maintenance affects the PFD of certain IPLs.

Communications

It is a basic assumption that adequate communications exist in a facility. 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 post event for most scenarios and its availability and effectiveness may be affected by the fire/explosion which it is intended to contain. However, if a company can demonstrate that it meets the requirements of an IPL for a given scenario it may be used (e.g., if an activating system such as plastic piping or frangible switches are used). Note: Fire protection is a mitigation IPL as it attempts to prevent a larger consequence subsequent to an event that has already occurred.

Fireproof insulation can be used as an IPL for some scenarios provided that it meets the requirements of API and corporate standards. Requirement that Information is Available and Understood

This is a basic requirement.

Note: Poor performance in the areas discussed in this table may affect the process safety of the whole plant and thus may affect many assumptions made in the LOPA process.

80


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 prevention and PFD must be capable of validation in some manner (by documentation, review, testing, etc.). (See also Appendix C, Documentation for a LOPA Study.)

Effectiveness If a device, system or action is credited as an IPL it must be effective in preventing the undesired consequence associated with the scenario. To determine whether a safeguard is an IPL, the following questions are used to guide the team or analyst in making the appropriate judgment. Additional discussion of these issues is provided in Section 6.5. • Can the safeguard detect the condition that requires it to act? This may be a process variable, or an alarm, etc. If the safeguard cannot always detect the condition, and generate a specific action, it is not an IPL. • Can the safeguard detect the condition in time to take corrective action that will prevent the undesired consequence? The time required must include G the time to detect the condition, G the time to process the information and make the decision, G the time to take the required action, and G the time for the action to take effect. • Does the IPL have adequate capacity for it to take the required action in the time available? If a specific size (e.g., relief valve orifice, dike volume, etc.) is required, does the installed safeguard meet these requirements? Is the strength of the IPL adequate for the required action? The strength of an IPL might consist of G physical strength (e.g., a blast wall or dike); G the ability of a valve to close under the conditions that would be present for a particular scenario (i.e., strength of valve spring, actuator, or components); G human strength (i.e., is the required task within the physical capabilities 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 consequence is quantified using its PFD. Determining, or specifying, the appropri-

6.3. IPL Rules

81

ate value for the PFD of an IPL is an important part of the LOPA process. An IPL is expected to operate as intended, but any system can fail. The lower the value of the PFD for an IPL the greater the confidence that it will operate correctly and interrupt a chain of events. Since LOPA is a simplified method, the values of the PFDs are usually quoted to the nearest order of magnitude. PFD values 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. The LOPA team or analyst must determine whether a safeguard is an IPL, and then assess the appropriate value of the PFD for the IPL. Caution is required when assigning the PFD for IPLs in scenarios where the initiating event frequency is high, i.e., where the initiating event frequency for a scenario is greater than, or close to, the effective functional test interval for the IPL (see Section 7.2 and Appendix F).

Independence The LOPA method uses independence to assure that the effects of the initiating event, or of other IPLs, do not interact with a specific IPL and thereby degrade its ability to perform its function. Independence requires that an IPL’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 be claimed as an IPL in LOPA. Example 6.1 shows a safeguard that is an IPL for one scenario, but not for another scenario. Example 6.1 In Figure 6.2, Initiating Event 1 shows a safeguard (high reactor temperature triggers addition of quench) that is an IPL. Initiating Event 2 illustrates 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 failure may also be considered as a common-cause failure for both the initiating event and the potential safeguard.

82


FIGURE 6.2. Example of IPL not independent of initiating event.

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.

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 arrangement is not an IPL because the sensor and the BPCS are common to both the initiating event and the high level trip functions.

6.3. IPL Rules

83

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

Two approaches are used in assessing the independence of IPLs involving BPCS loops or functions to decide how many IPLs exist for a particular scenario. Approach A is generally recommended because its rules are clear and it is conservative. Approach B may be used if the analyst is experienced and adequate data is available on the design and actual performance of the BPCS logic solver. Approach A In order for a device or action to be credited as an IPL, it must be independent of both • the initiating event and any enabling event and • any other device, system, or action that is already being credited as an IPL for the same scenario. Approach A is conservative, since it allows only one IPL in a single BPCS and requires that IPL to be independent of the initiating event. This approach eliminates many common cause failures (see Table 6.2) affecting the PFD for

84


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 using Approach A.

TABLE 6.2 Causes of Dependent Failure in Systems (Including Systematic Failure)* Engineering Design Functional Deficiencies

Realization Faults

Operation Construction Installation and Commissioning

Maintenance and Testing

Operation

Imperfect repair

Operator errors

Temperature

Fire

Imperfect testing

Inadequate procedures

Pressure

Flood

Imperfect calibration

Inadequate supervision

Humidity

Weather

Vibration

Earthquake

Imperfect procedures

Communication errors

Acceleration

Explosion

Stress

Missiles

Corrosion

Electric Power

Channel dependency

Inadequate quality control

Inadequate quality control

Inadequate instrumentation

Common operation and protection components

Inadequate standards

Inadequate standards

Inadequate inspection

Inadequate inspection

Inadequate testing

Inadequate testing and commissioning

Operational deficiencies Inadequate components

Environmental

Manufacture

Hazard undetectable

Inadequate control

Procedural

Inadequate supervision

Normal Extremes

Energetic Events

Contamination

Radiation

Design errors

Interference

Design limitations

Radiation

Chemical sources

*From Guidelines for Chemical Process Quantitative Risk Analysis, Second Edition (CCPS 2000a).

Static charge

85

86


the IPLs which are claimed. Approach A is more straightforward to apply as its rules are unambiguous and little judgment is left to the analyst or team. Approach A is used for the continuing examples discussed in Chapters 2 through 8. Approach B This approach allows more than one IPL to be in the same BPCS or it allows a BPCS IPL with a BPCS initiating event (with independence required for certain components). This approach is based on the assumption that if a BPCS function fails, it is probable the component that induced the failure is the detection device or the final control element, and that failures of the IPL due to a fault in the logic solver are much less frequent. Industrial experience indicates that the failure rates of the detection devices and the final control elements are usually much higher than the failure rate of the BPCS logic solver. Approach B allows a limited number of other elements of the BPCS to serve as an IPL for the scenario. Details of this approach are discussed in Chapter 11 together with application to the continuing examples. Approach B is less straightforward 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 B when deciding to claim an IPL. 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.

Example 6.3

Consider a situation where the failure of a specific BPCS loop is the initiating event. The operator response that could mitigate the situation relies upon obtaining information from another loop in the same BPCS in which

6.3. IPL Rules

87

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. Therefore, 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, provided 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 components (with the exception of the central processing unit) involved in the initiating 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 and cannot be credited as an IPL for either approach if either of the following are true: • Operator error is the initiating event and the candidate IPL assumes that the same operator must act to mitigate the situation. Human error is equivalent to the failure of a system and once a human has committed an error it is not reasonable to expect the same operator to act correctly later in the sequence of events. This approach is justified because the error may be due to illness, incapacity (drugs or alcohol), distraction, work overload, inexperience, faulty operating instructions, lack of knowledge, etc., that are still present later when the action is required. • Loss of a utility (electricity, air, cooling water, nitrogen, etc.) is the initiating 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 considered. This is particularly important if Approach B is employed. This type of failure can be subtle and requires vigilance in identifying opportunities for its occurrence.

88


Other examples where the IPL is not independent include • multiple flow meters, analyzers, etc., with a calibration error due to human error, faulty calibration instruments, etc.; • multiple units or SIF systems with a single source of power or a common circuit breaker unless it can be determined that fail safe action will always be initiated in the event of power loss—this is true for any other utility required for an IPL to reach a safe state; • functional deficiency in a type of valve, sensor, etc. used in multiple systems; • assuming that the same operator acts correctly after operator error initiated the event. Additional examples are provided in Table 6.2 for common mode issues for 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 it meets the risk mitigation requirements of a LOPA IPL. The audit process must confirm that the IPL is effective in preventing the consequence if it functions as designed. The audit should also confirm that the IPL design, installation, functional testing, and maintenance systems are in place to achieve the specified PFD for the IPL. Functional testing must confirm that all the components of an IPL (sensors , logic solver, final elements, etc.) are operational and meet the requirements for LOPA to be applied. The audit process should document the condition of the IPL as found, any modifications made since the last audit, and track to resolution any corrective actions that are required. Chapter 9 (Implementing LOPA) discusses additional information required 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 an IPL are determined by several methods. The simplest is to use a written

6.4. LOPA IPL Assessment

89

design basis, or IPL summary sheet, which must be available for review by the LOPA team or analyst (see Table 4.1). This should include the initiating event considered, the action taken by the system or device, and the effects of these actions. Any assumptions, clarifications or calculations required to support the analysis must be attached or referenced. If this information is not available, or if its validity is questionable, then it must be developed for each scenario and each safeguard reviewed. This will require experts in the process design of the system, the design and installation of the instrumentation and the controls and operation 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 for SIF systems, certification that the system meets the requirements for a specified type of SIF would be acceptable. If a pressure relief device is being considered as an IPL, the documentation 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 lifting at the set pressure.

Where human action is credited as an IPL, the following factors should be defined 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 perform the required task. Failure to perform could be caused by • a component of an IPL being in a failed or unsafe state when the initiating event occurs; or

90


• 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 the required task on demand.) Thus, it is a simplified concept and must be applied with caution. In particular, the PFD for a BPCS function includes factors such as human error in programming, bypassing interlocks, and the typical 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 organization must satisfy itself that the PFD values used for its method are appropriate. The analyst should evaluate the design of the candidate IPL against the conditions of the scenario to estimate the appropriate PFD for the IPL. The credit taken for an IPL in risk reduction is discussed in detail in Section 6.5. Documentation should be developed to justify or substantiate the PFD claimed for IPLs. This should reference corporate standards or industry norms, or include appropriate calculations. For relief valves claimed as IPLs, justification for the PFD claimed, particularly for polymeric, fouling or corrosive services, is particularly important (see the discussion on Active IPLs in Section 6.5). 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).

6.5. Examples of IPLs This section describes various types of IPLs, together with information on the PFD values used by various companies. The PFD is the probability that, when challenged, the IPL will fail to perform its required function and, therefore, the scenario will continue toward the undesired consequence despite the presence of that IPL (see Chapter 4). Factors that may influence the selection of PFD values for IPLs are also discussed briefly in this section. Due to different approaches and different operating environments, a range of PFD values is provided in the summary tables 6.3, 6.4, and 6.5. The


91

PFD values used within an organization should be applied consistently, although variations between different facilities are appropriate if justified by differences in design, construction, installation, inspection or maintenance. The PFD values should also be consistent with the failure rates used to develop initiating event frequencies and risk tolerance criteria. Individual companies or methods may use a different list of IPLs, but these must meet the requirements defined in Section 6.3. When the demand frequency for an IPL is similar to the IPL test or proof test frequency, particular care must be taken in assigning the appropriate PFD (see Section 7.2 and Appendix F). Some companies may use a lower value for an IPL than the typical PFDs in Tables 6.3 to 6.5, but this requires a detailed analysis of the IPL (using fault tree, FMEA, etc.) performed by a qualified analyst. The use of such advanced techniques in IPL analysis is discussed in Chapter 11. The PFD of an IPL is usually related to its test frequency. The longer the period between testing, the higher the PFD. Kletz (1985) and the CCPS CPQRA books (CCPS 1989a, 2000a) discuss this issue. The assumed PFD of an IPL must be consistent with the actual test frequency. 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.

Passive IPLs A passive IPL is not required to take an action in order for it to achieve its function in reducing risk. Table 6.3 contains examples of IPLs that achieve risk reduction using passive means to reduce the frequency of high consequence events. Table 6.3 also includes a typical range of PFD values for each type of IPL, together with a PFD value used in one method. These IPLs achieve the intended function if their process or mechanical design is correct and if constructed, installed, and maintained correctly. Examples are tank dikes, blast walls or bunkers, fireproofing, flame or detonation arrestors, etc. These devices are intended to prevent the undesired consequence (widespread leakage, blast damage to protected equipment and buildings, failure due to fire exposure to vessels or piping, fire or a detonation wave passing through a piping system, etc.). If designed adequately, such passive systems

92


can be credited as IPLs with a high level of confidence and will significantly reduce the frequency of events with potentially major consequences. However, 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 boilTABLE 6.3 Examples of Passive IPLs Comments

PFD Used in This Book

Assuming an adequate design basis and adequate inspection and maintenance procedures

PFD from Literature and Industry

(For screening)

Will reduce the frequency of large consequences (widespread spill) of a tank overfill/rupture/spill/ etc.

1 × 10–2 – 1 × 10–3

1 × 10–2

Underground Drainage System

Will reduce the frequency of large consequences (widespread spill) of a tank overfill/rupture/spill/ etc.

1 × 10–2 – 1 × 10–3

1 × 10–2

Open Vent (no valve)

Will prevent over pressure

1 × 10–2 – 1 × 10–3

1 × 10–2

Fireproofing

Will reduce rate of heat input and provide additional time for depressurizing/firefighting/etc.

1 × 10–2 – 1 × 10–3

1 × 10–2

Blast-wall/ Bunker

Will reduce the frequency of large consequences of an explosion by confining blast and protecting equipment/buildings/etc.

1 × 10–2 – 1 × 10–3

1 × 10–3

“Inherently Safe” If properly implemented can significantly reduce the frequency of Design consequences associated with a scenario. Note: the LOPA rules for some companies allow inherently 1 × 10–1 – 1 × 10–6 safe design features to eliminate certain scenarios (e.g., vessel design pressure exceeds all possible high pressure challenges).

1 × 10–2

IPL Dike

Flame/Detonation Arrestors

If properly designed, installed and maintained these should eliminate the potential for flashback through a piping system or into a vessel or tank.

1 × 10–1 – 1 × 10–3

1 × 10–2


93

ing liquid, expanding vapor explosion (BLEVE), or for preventing an exothermic runaway reaction due to external heat input). This could mitigate the size of a release or provide additional time to respond to the situation by depressurizing the system, fire fighting, etc. If fireproofing is considered as an IPL it must be shown to be effective in preventing the consequence (a BLEVE, etc.) or provide sufficient time for other action. It should also meet the requirements that the fireproofing remain intact when exposed directly to a fire and that it will not be displaced by the impact of a jet of water from a monitor or hose. Other passive IPLs, such as flame or detonation arrestors, while employing simple physical principles, are susceptible to fouling, plugging, corrosion, unexpected conditions, potential maintenance mistakes, etc. These must be considered when assigning a PFD to such devices. Passive IPLs, such as dikes or blast walls, where the equipment design prevents the consequence can have low PFD values for LOPA purposes, but care must be taken to assess accurately the PFD to be applied. In some companies, process design features (such as special materials and inspection) are considered as IPLs if they can prevent the consequence from occurring. This approach allows an organization to evaluate risk differences between plants that are designed using different equipment standards. With this approach inherently safer process design features also have assigned 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 design features eliminate scenarios rather than mitigate the consequences of a scenario. For example, if equipment is designed to withstand an internal deflagration then all the scenarios that lead to a rupture of a vessel due to an internal explosion have thereby been eliminated. Using this approach, process design is not considered to be an IPL as there are no scenarios or consequences to be considered and, therefore, no IPL is required. However, appropriate inspection and maintenance (auditing) is required to insure that process changes do not change the effectiveness of the inherently safer design feature. 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 companies 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

94


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 pressure 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 catastrophic 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 initiating event.

A company must determine the approach to select to achieve consensus and consistent results within its organization. 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.

Active IPLs Active IPLs are required to move from one state to another in response to a change in a measurable process property (e.g., temperature or pressure), or a signal from another source (such as a push-button or a switch). An active IPL generally 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 discussed later in this section.

95


FIGURE 6.5. Basic components of active IPL.

Instrumented Systems These systems are a combination of sensors, logic solvers, process controllers, and final elements that work together, either to automatically regulate plant operation, or to prevent the occurrence of a specific event within a chemical manufacturing process. Two types of instrumented systems are considered in the basic LOPA method. Each has its own purposes and characteristics. One, the continuous controller (e.g., the process controller that regulates flow, temperature, or pressure at an operator supplied set-point value) generally provides continuous feedback to the operator that it is functioning normally (although unannounced malfunctions can occur). The second, the state controller (the logic solver which takes process measurements and executes on–off changes to alarm indicators and to process valves) monitors the plant conditions and only takes control actions when predefined trip points are reached. State control actions may be referred to as process interlocks and alarms, such as a reactor high-temperature trip that closes the steam valve. Faults in a state controller (logic solver and the associated field devices) may not 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. The BPCS 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 the process in day-to-day plant operation. The BPCS may provide three different types of safety functions that can be IPLs: • continuous control action, which keeps the process at set point values within the normal operating envelope and thus attempts to prevent the progression of an abnormal scenario following an initiating event. • state controllers (logic solver or alarm trip units), which identify process excursions beyond normal boundaries and provide this information (typically, as alarm messages) to the operator, who is expected to take a specific corrective action (control the process or shut down). • state controllers (logic solver or control relays), which are intended to take automatic action to trip the process, rather than attempt to return

96

6. Identifying Independent Protection Layers TABLE 6.4 Examples of Active IPLs Comments IPL

Assuming an adequate design basis and inspection/maintenance procedures

PFD Used in This Book

PFD from Literature and Industry

(For screening)

Relief valve

Prevents system exceeding specified overpressure. Effectiveness of this device is sensitive to service and experience.

1 × 10–1 – 1 × 10–5

1 × 10–2

Rupture disc

Prevents system exceeding specified overpressure. Effectiveness can be very sensitive to service and experience

1 × 10–1 – 1 × 10–5

1 × 10–2

Basic Process Control System

Can be credited as an IPL if not asso- 1 × 10–1 – 1 × 10–2 ciated with the initiating event being (>1 × 10–1 allowed considered (see also Chapter 11). (See by IEC) IEC 61508 (IEC, 1998) and IEC 61511 (IEC, 2001) for additional discussion.)

Safety Instrumented Functions (Interlocks)

See IEC 61508 (IEC, 1998) and IEC 61511 (IEC, 2001) for life cycle requirements and additional discussion

SIL 1

Typically consists of:

Single sensor (redundant for fault tolerance )

1 × 10–1

≥1 × 10–2–

Layer of Protection Analysis: Simplified Process Risk Assessment (A CCPS Concept Book)

Layer Of Protection Analysis

Evaluating Process Safety in the Chemical Industry: A User's Guide to Quantitative Risk Analysis (A CCPS Concept Book)

Risk Assessment

Risk Assessment

Risk Assessment

Risk Assessment

Risk Assessment

Risk Assessment

Risk Assessment

Risk Assessment

Risk Assessment

Risk Assessment

Risk Assessment

Hydrosystems Engineering Reliability Assessment And Risk Analysis

Radiological Risk Assessment and Environmental Analysis

Radiological Risk Assessment and Environmental Analysis

Risk Assessment and Risk Management

Boundary Layer Analysis

Forensic Assessment of Violence Risk: A Guide for Risk Assessment and Risk Management

Microbiological Risk Assessment of Food

Handbook of Chemical Risk Assessment

Technical Analysis Simplified

Human Factors Methods for Improving Performance in the Process Industries (CCPS Concept Books)

Landslide risk assessment

Country risk assessment

Torchwood Risk Assessment

Cancer Risk Assessment

Immunotoxicology and Risk Assessment

Reliabilty and Risk Assessment

Layer of Protection Analysis: Simplified Process Risk Assessment (A CCPS Concept Book)