sis engineering handbook - kenexsis

8/13/2019 SIS Engineering Handbook - Kenexsis

1/128

Kenexis

Safety Instrumented SystemsEngineering Handbook

Kenexis Consulting Corporation Columbus, OH


2/128


3/128

iii

About Kenexis

Kenexis is a global engineering consulting company that isfocused on the implementation of engineered safeguards inprocess plants. Engineered safeguards are physical devicesthat can detect that an unwanted or out-of-control situation isoccurring in the process plant and take remedial action to movethe process to a safe state. Some typical examples ofengineered safeguards employed in the process industries areshown below.

Safety Instrumented Systems

Fire and Gas Detection and Suppression Systems

Emergency Isolation Valve Systems

Alarm Systems

Pressure Relief Systems

Cyber Security Systems (Intrusion Detection andPrevention)

Machine Safeguarding Systems

Kenexis helps our clients to deploy these systems by workingas an independent expert third-party advisor who assists in thedevelopment of the design basis of these systems andvalidation that these systems are implemented in accordancewith the design basis over their entire lifecycle. Since Kenexisdoes not sell or recommend any hardware or perform anydetailed engineering services, Kenexis is uniquely positioned toact as an independent advisor with no conflicts of interest that

might sway the direction of decisions in the development of thedesign basis.


4/128

iv Kenexis SIS Engineering Handbook

Kenexis applies a risk-based approach in assisting our clients todetermine their engineered safeguard needs. The risks that areposed by the processes that our clients operate can bedetermined and developed through Process Hazards Analyses(PHA) that Kenexis can both facilitate and actively participatein. Once the needs for engineered safeguards are identified,the design basis for those safeguards is further developed byconsidering the codes and standards that apply to the design ofeach specific safeguard along with the level of risk reductionthat those safeguards are required to provide. Consideringthese two factors Kenexis prepares design basis documentationthat defines the requirements in sufficient detail to allowequipment to be selected and purchased, but general enough toensure that any technology or equipment vendor that iscapable of meeting the technical requirements can provide anappropriate solution. Kenexis design basis documents areunique in their ability to allow end users to comparealternatives from multiple vendors and select the solution thatbest suits their requirements.

After the design basis is complete, our clients work withequipment vendors, systems integrators, and engineeringcompanies to physically implement the solution. After thesafeguards are implemented, Kenexis helps our clients byperforming validation services and ongoing support services toensure that the safeguards were selected, designed, and

installed in accordance with the design basis documentation,and that the system design and design basis documentation aremaintained in an evergreen fashion.


5/128

v

About the Authors

Kevin J. Mitchell

Mr. Kevin J. Mitchell has unparallel experience in the riskmanagement and process safety fields. Mr. Mitchell has beeninvolved in hundreds of projects covering such diverseoperations as oil & gas production, refining, petrochemical,specialty chemical and general manufacturing. Specializes instate-of-the-art assessment of the risk of toxic, flammable, andexplosive materials on people, property, the environment, and,ultimately, the business. Uses risk assessment and Cost-BenefitAnalysis to assist in making engineering and business decisions.

Peter Herea

Mr. Herea has extensive experience in the design andinstallation of control systems and the implementation of safetyinstrumented systems for the process industries. He hasworked on numerous projects related to oil & gas production,refining, petrochemical and chemical manufacturing. His

experience includes software design, control system andinstrument field verification, and startup support for projectsworldwide. He has assisted clients in nearly every aspect of thesafety lifecycle, from HAZOP facilitation, through SIL selectionand verification, and development of Safety RequirementsSpecifications and functional test plans.

Todd M. Longendelpher

Mr. Longendelpher has experience in design of safetyinstrumented systems and risk analysis methods. He is


6/128

vi Kenexis SIS Engineering Handbook

responsible for the development of SIL requirements andverification of SIL requirements for safety instrumentedsystems. He utilizes risk analysis techniques to assess existingSIS design versus potential hazards resulting in consequences.He has conducted LOPA / SIL Selection and SIL Verificationactivities for customers in petroleum refining, petrochemicals,and upstream oil and gas production in US and internationallocations. He currently oversees the implementation of SISdesign at multiple upstream oil and gas production platforms inthe Gulf of Mexico.

Matthew C. Kuhn

Mr. Kuhn is a lead engineer at Kenexis and has significantexperience in safety instrumented systems design andconsequence / hazards analysis projects. Mr. Kuhn has been

responsible for several SIS design basis projects that involvedentire oil and gas production fields, from wellhead all the waythrough processing facilities, and finally to loading and shippingof products. These projects included a full range of SIS safetylifecycle activities including the development of SIL targetsthrough layer of protection analysis (both implicit and explicittechniques), verification of existing and proposed conceptualdesigns using SIL verification calculation techniques,

development of SIS design basis gap reports, and thepreparation of recommendations to address any issuesidentified in the studies. In these studies Mr. Kuhn performedon-site meeting facilitation along with detailed calculation in thedevelopment of the final work products.


7/128

vii

Preface

Safety instrumented systems (SIS) form some of the mostwidely used and difficult to design engineered safeguards in theprocess industries. Prior to the release of risk-based standardsfor the design of SIS, designs were traditionally implementedusing rules of thumb which were quite effective, but notentirely satisfactory. After the implementation of risk-based

analysis, users of SIS realized that these engineeredsafeguards alone had the design flexibility to allow widelydiverse designs with widely diverse risk reduction capabilities.Only SIS can be designed in a good, better, and best fashion,limiting the amount of risk reduction provided to match theamount of risk reduction needed.

The downside of the flexibility that risk-based decision making

provides is the large amount of complexity that subsequently isintroduced to the design process. In order to make risk-baseddecisions, one needs to understand the risk of the chemicalprocess, which is no small feat and typically out of the comfortzone of SIS designers, and also to understand the details ofreliability engineering as applied to SIS design.

In the years following the release of the performance-basedstandards that define SIS engineering, many books, standards,technical reports, and papers have been written about the SISEngineering process (including books and papers by the authorsof this book). The authors of this book determined that itwould be very valuable to distill this information down into ahandbook format that will allow everyday practitioners to havea quick reference to the most salient points of the designprocess.

This book provides a very practical discussion of the SIS safetylifecycle and presents it in a fashion that leans towardassistance in execution of the tasks without belaboring the


8/128

viii Kenexis SIS Engineering Handbook

theoretical underpinnings of the equations and data that arepresented in other books and technical reports. In addition,this book reflects the most proven and accepted methodologiesfor performing tasks, especially in areas where the standardsallow great flexibility to the users to select from many optionsfor complying with the standard.

For instance, the task of selecting safety integrity levels can beperformed utilizing a wide variety of methods including riskgraphs and layer of protection analysis. But since the vastpreponderance of industry has elected to use layer of protectionanalysis, only this methodology will be explored in great detail.

Also, this book focuses on the SIS engineering aspects of thesafety lifecycle while leaving important tasks that are out of therealm of instrumentation and control engineering to others. Forinstance, a good process hazards analysis is important toidentifying where instrumented safeguards such as SIS are

required, but execution of a PHA is typically not theresponsibility of instrumentation and control engineers, and isthus discussed, but not developed in detail.

The authors of this book hope you enjoy the contents and findthe information educational and useful on a day-to-day basis.


9/128

ix

Table of Contents

About the Authors ............................................................. v

Kevin J. Mitchell ............................................................ v

Peter Herea ................................................................ v

Todd M. Longendelpher .................................................. v Matthew C. Kuhn .......................................................... vi

Preface ........................................................................... vii

Table of Contents............................................................. ix

Introduction ..................................................................... 1

Why do I need an SIS? ................................................... 1

What is an SIS? ............................................................ 2

Legislation and Regulation .............................................. 4

Why develop SIS standards? ........................................... 5

What does the standard require? ..................................... 7

The Safety Lifecycle ....................................................... 9

Conceptual Process Design ............................................... 13

Process Hazards Analysis ................................................. 14

SIF Definition ................................................................. 18

Safety Integrity Level Selection ........................................ 22


10/128

x Kenexis SIS Engineering Handbook

Defining SIL ................................................................ 22

SIL Selection Process ................................................... 24

Representing Tolerable Risk for SIL Selection .................. 26

Layer of Protection Analysis .......................................... 30

Conceptual Design / SIL Verification .................................. 35

Component Selection ................................................... 37

Fault Tolerance ........................................................... 38

Functional Test Interval ................................................ 40

Common Cause Failures ............................................... 40

Diagnostic Coverage .................................................... 41

PFD Calculation ........................................................... 41

Simplified Equations .................................................... 42

Safety Requirements Specifications ................................... 44

Detailed Design and Specifications .................................... 49 Procedure Development ................................................... 50

Construction, Installation, and Commissioning .................... 53

Pre-Startup Acceptance Testing ........................................ 54

Operations and Maintenance ............................................ 56

Management of Change ................................................... 57


11/128

xi

Conclusions ................................................................... 59

Appendix A Acronyms ................................................... 61

Appendix B Definitions .................................................. 63

Appendix C Typical Initiating Event Frequencies ............... 71

Appendix D Typical Protection Layers .............................. 73

Appendix E PFDavg and Spurious Trip Rate SimplifiedEquations ...................................................................... 82

Appendix F Minimum Fault Tolerance Tables .................... 97

Appendix G SIS Component Failure Data ......................... 102

Sensor Data .............................................................. 103

Logic Solver Data ....................................................... 104

Final Element Interface Data ........................................ 105

Final Element Data ..................................................... 105

Appendix H Example Risk Criteria .................................. 106

Appendix I References ................................................. 115


12/128


13/128

1

Introduction

Safety instrumented systems (SIS) are the most flexible andone of the most common engineered safeguards used inprocess plants today. The design of SIS, in accordance withcurrent practice, is a risk based process where the selectedequipment and associated maintenance and testing proceduresare tailored to specific requirements of an application. This

risk-based approach yields superior designs that provide therequired risk reduction while minimizing cost.

SIS design has become a more complex process due to theneed to understand more than traditional instrumentation andcontrol engineering. In addition to basic concepts, SIS designrequires expertise in analyzing the risks of the process undercontrol (which necessarily requires an understanding of the

process) in order to establish design targets, and also expertisein reliability engineering to ensure that the selected targetshave been met.

The purpose of this book is to provide a brief overview of theSafety Lifecycle that is used to design SIS, along with generalinformation to assist in performing the tasks that are defined inthe safety lifecycle. This includes tables of data, lists ofdefinitions and acronyms, equations, and explanations for usingthese resources.

Why do I need an SIS?

Process plants create value by converting raw materials intovaluable products. The processes utilized to perform thisconversion often create hazardous conditions that could resultin significant consequences if the processes are not adequatelycontrolled. These conditions include:


14/128

2 Kenexis SIS Engineering Handbook

Flammable Materials

Toxic Materials

High Pressures

High Temperatures

Control of the risks posed by process plants is performed by acombination of:

Administrative Controls

Engineered Safeguards

A Safety Instrumented System (SIS) is one of the safeguardsused in modern petroleum and chemical processing to reducerisk to a tolerable level. It is an engineered control, and fits in

with engineering safeguards, as well as administrative controls,to achieve an overall balance of safeguards that reduce risk toa tolerable level.

Common Safety Instrumented System applications includeemergency shutdown systems, burner management systemsfor boilers and other fired devices; high integrity pressureprotection systems (HIPPS) in petroleum or chemical

processing facilities, as well as other industry specificapplications.

What is an SIS?

The Safety Instrumented System is an instrumentation andcontrol system that detects out-of-control process conditions,and automatically returns the process to a safe state. It is thelast line - or near last line - of defense against a chemicalprocess hazard, and it is not part of the Basic Process Control


15/128

3

System. The last line of defense is what differentiates a SafetyInstrumented System from the Basic Process Control System,which is used for normal regulatory process control.

Figure 1 demonstrates how Safety Instrumented Systems aredifferent from Basic Process Control Systems, or the BPCS. Inthis example, pressure is a potential hazard. Pressure isnormally controlled by a regulatory control loop, shown as theBasic Process Control System, which modulates a pressurecontrol valve. An independent high-pressure shutdown functionis implemented in a Safety Instrumented System. It isindependent in as much as the components used in the BPCSand the SIS are separate, physically and functionally. Thisincludes the sensor components, the logic solver, as well as thefinal control elements. SIS are generally independent, bothphysically and functionally, from the BPCS in order to ensurethat any condition, which might result in an out-of-controlprocess parameter in the BPCS, is safeguarded by the SIS,regardless of the function of the BPCS.

Fi g u r e 1 S I S v e r s u s B P CS

The SIS will include three types of components including sensorcomponents, a logic solver component, and final control


16/128


elements. Together these components make up the SafetyInstrumented System, which detects out-of-control processconditions, and automatically returns the process to a safecondition, regardless of the functioning of the Basic ProcessControl System. In this case, the SIS could include aprogrammable system, or a non-programmable system.

Legislation and Regulation

Legal requirements for Safety Instruments Systems in theUnited States are derived from a variety of process safetymanagement regulations, as well as the legislation that serveas the foundation of those regulations. While the discussion inthis handbook focuses on the US, a similar framework is utilizedin most regions of the world.

Regulations require compliance with recognized and generallyaccepted good engineering practices for safety critical controls,including SIS. These regulations require recognized andgenerally accepted good engineering practices to ensure thatindustry complies with the norms of operation that have beendefined for that industry. Regulations and standards that applyto Safety Instrumented Systems originated in the late 1980swhen industry regulators, including the U.S. Occupational

Safety and Health Administration (OSHA), as well as the U.S.Environmental Protection Agency (EPA), concluded thatindustrys performance with respect to prevention of majorhazards was inadequate. This originated Process SafetyManagement Standards by OSHA, which were propagated in1992 under 29 CFR 1910.119. In 1996, the EPA propagated itsAccidental Release Prevention Program, or 40 CFR Part 68,which is also called Risk Management Program. This regulatory

standard was substantially similar in the requirements toOSHAs Process Safety Management Standard. Largely inresponse to these regulations, the International Society forAutomation (ISA) as well as the International Electrotechnical


17/128

5

Commission, or IEC, developed industry standards for safetycritical control systems to provide additional information on howto comply with OSHA and EPA process safety managementregulations.

Why develop SIS standards?

As was previously noted, regulations regarding process safety

came about due to a perception of inadequate policies andprocedures regarding safety in the process industries. Many ofthe lessons that have been learned from major accidentinvestigations point to the lack of functional safety as a keycause in loss of life, as well as other property damage, and lostproduction incidence in the petroleum and chemical industries.Upon review of the accident history of the process industrieswith respect to scenarios where SIS failure contributed, several

common themes developed.

Often, no SIS was installed when it could be argued thatwas necessary for safety to be automated. In fact, in manyof these cases no study to assess the risks posed by theprocess was performed at all.

In some instances, a poor decision making process was

used to determine when safety should be automated versusleft to another system. This included deciding if operatorintervention or the basic process control was adequate inlieu of a separate instrumented system that is dedicated tosafety.

Incident histories also point to questionable equipmentselection as another cause for lack of functional safety thatresulted in major accidents and losses.

Lack of redundancy and diagnostic features of SIS wasanother frequent cause.


18/128


Poor testing methods and poor determination of thefrequencies for functional testing was also a cause in manyof the losses that were seen related to lack of functionalsafety, as well as improper bypassing and equipmentselection techniques.

Together, these causes point to the need for improvedpractices for ensuring functional safety management isachieved. The implications of the accident data on SafetyInstrumented System engineering are listed below, andincorporated into the IEC 61511 (ISA 84.00.01) standardfor SIS design and implementation.

We should select criteria for when to use alarms andoperator judgment verses an automatic shutdown, using aSIS, when predefined safe operating limits have beenviolated and the risk is significant enough that manualmeans are insufficient.

It is also important to recognize that in order to preventmajor hazards, a defense in depth strategy involvingmultiple, independent layers of protection or safeguards isnecessary to prevent major accidents. We recognize thisbecause in some cases, safeguards can fail resulting indemands on SIS.

We also recognize that inadequate specification of SIS isoften a fundamental cause of accidents where functionalsafety was inadequate. This includes specification ofcomponents, system architecture, diagnostic testing, as wellas functional proof tests.

In many cases, accident data shows that bypass and defeatof safety critical systems was also a significant contributor

to accident case histories.

In response to these factors, as well as other drivers in theindustry, the ISA and IEC developed a Standard for SIS that


19/128

7

addresses many of these causes. It provides a Safety Lifecycleas the foundation to address functional safety. The SafetyLifecycle includes identification, design, testing, maintenance,and management of change. Its a Cradle-to-Grave approachto safety that addresses fundamental problems that could occurat any step during the design, operation, maintenance, andchange of a Safety Instrumented System.

In the U.S., OSHA requires industrial facilities that are coveredby the Process Safety Management regulation to comply withrecognized and generally accepted good engineering practices.ISA posed the question to OSHA as to whether their standard,ISA 84.00.01 for Safety Instrumented Systems, complies withOSHAs requirements for Process Safety Management. OSHA,in response to this question, agreed that the ISA standardwould be one example of compliance with the mechanicalintegrity requirements for safety critical controls and shutdownsystems. OSHA also indicated that this was only one example -it was not the only way - that a company could comply with theProcess Safety Management standard requirements formechanical integrity, as well as process safety information.Since that time most process industry operating companieshave come to agree that the safety lifecycle contained in IEC61511 (ISA 84.00.01) is the optimal methodology for managingsafety instrumented system design and implementation.

What does the standard require?

Unlike other standards and practices in use prior to the releaseof IEC 61511 (ISA 84.00.01), this standard does not provide aset of rules that define, in details, how a system should bedesigned. Instead it lays out a framework for allowing each

individual user to determine what is appropriate for theirspecific situation. Its a performance-based approach to SISrather than a prescriptive approach. In other words, thestandard does not take the position of prescribing: what types


20/128


of components, what types of architecture, what types ofdiagnostic testing, how often, and what functionally tests aSafety Instrumented System? Rather, the standard establishesa performance or goal-setting approach. In other words, usersshould select an appropriate performance target for a SafetyInstrumented System function, and design the systemaccordingly to achieve that level of performance.

The standard defines a Safety Lifecycle with multiple steps thatshould be taken to achieve functional safety in a Cradle-to-Grave approach for functional safety management. Thestandard requires the selection and achievement of a targetperformance level. That key performance level is the SafetyIntegrity Level (SIL), which is selected for each SafetyInstrumented Function within a SIS using risk-basedapproaches. The SIL is the fundamental metric for allsubsequent decision making about the design of the SIS.

The standards bodies (IEC and ISA) and government regulators(e.g., OSHA in the U.S.) generally agree on the differentapproach to existing equipment versus new engineering design.Good engineering practice for new design would includecompliance with recognized and generally accepted engineeringstandards, including IEC 61511. However, existing equipmentcould be treated slightly differently, depending on how eachcompany decides to handle an approach to grandfathering of

existing equipment. Grandfathering of existing equipment isallowed in the U.S. under OSHAs Process Safety ManagementStandard, and is also allowed under the ISA 84.00.01 version ofthe IEC 61511 version of the SIS standard. The standard says,

For existing systems, designed and constructed in accordancewith codes, standards, or practices prior to the issue of thisstandard, the owner/operator shall determine, and if anyequipment is designed, maintained, inspected, tested, and

operated in a safe manner. In other words, it does notprescribe that old equipment designed to previous engineeringstandards needs to be up to the current SIS standard; rather asystem should be in place to verify that equipment is operated,


21/128

9

tested, inspected, maintained, and designed according to safestandards of the time. The acceptability of grandfatheringmay vary depending on the location in which a SIS isemployed.

The Safety Lifecycle

Figure 2 presents the SIS Safety Lifecycle as prescribed in IEC

61511 (ISA 84.00.01). The Safety Lifecycle includes a numberof specific steps from design through operation, maintenance,testing, and even decommissioning, to address safetythroughout the lifetime of a Safety Instrumented System in thepetroleum or chemical process.

F i g u r e 2 I EC 6 1 5 1 1 S a f e t y L i f e c y c l e

The first step in the Safety Lifecycle is Hazard and RiskAssessment. The premise of this step is that to adequatelydesign a Safety Instrumented System, we must fullyunderstand the hazards against which that system is intended


22/128


to safeguard. If we dont have an adequate understanding ofthose hazards, the system might be improperly designed withrespect to the types of components that are used, the type ofredundancy or architecture that is selected, and other factorsthat are pertinent to SIS engineering design.

The next step, Allocation of Safety Functions, involvesassigning certain levels of integrity to each of the safeguardsthat are used in the process, including Safety InstrumentedFunctions, as well as non-instrumented functions to achieve anoverall level of safety that is acceptable to the company that isoperating that process.

The third step in the Safety Lifecycle is Safety RequirementSpecifications. This is an important step to achieve overallfunctional safety. In the conceptual design of a process, wemust make sure that the safety requirements are adequatelyspecified prior to proceeding to other steps in the engineering

design lifecycle, including detailed design, construction,installation, and commissioning. This step is where theobjectives and means for achieving those objectives aredefined. Once completed, the Safety RequirementsSpecifications (SRS) form the basis for all subsequent designand validation activities.

The steps after SRS (which are often performed in parallel by

different groups) are Detail Design and Engineering and Design and Development of other non-safety instrumentedsystem safeguards. This stage is where the information in theSRS is expanded into more detailed documentation that is usedfor purchase of equipment, equipment configuration, andinstallation. This includes tasks such as creating equipmentlists, cabinet layout diagrams, internal wiring diagrams,interconnecting wiring diagrams, and PLC programs.

After the detailed design of the SIS is complete the followingstep is Installation, Commissioning, and Validation of theSafety Instrumented System itself. This stage involves factory


23/128

11

acceptance testing (FAT), physical installation of the SIS logicsolver and all of the field instrumentation, commissioning ofthose devices, and a validation step that will include siteacceptance testing (SAT) and pre-startup acceptance testing(PSAT).

Once the SIS is installed and operational, a different phase ofthe lifecycle begins where the design team passes responsibilityfor the equipment to the operations and maintenance team ofthe operating company. The Operation and Maintenanceinvolves the routine day-to-day interaction with a functioningsystem. During this phase, operations staff will respond toovert system alarms utilizing procedures written for thatpurpose. In addition, maintenance will repair the system inresponse to overt faults and also perform periodic functiontesting to ensure the systems proper operation.

The Decommissioning and Modification steps are very

similar in nature. If changes to the SIS or to the process undercontrol occur, measures must be taken so that the SIS is notcompromised in its ability to provide the required amount ofrisk reduction. During this phase Management of Change(MOC) requirements apply to ensure that when changes aremade to the process that are outside the SRS, those changesare adequately analyzed for potential hazards prior toimplementing the change. Decommissioning is a special form

of modification where analysis of the removed equipment mustbe analyzed with respect to its impact on the equipment thatwill stay in service.

There are three other steps of the Safety Lifecycle that occurover the entire length of an SIS lifetime. These steps are

Management of Functional Safety and Functional SafetyAssessment and Auditing, Safety Lifecycle Structure and

Planning, and Verification. In order to execute a functionalsafety project effectively, management of the entire process isimportant. Management tasks such as assigning tasks toqualified resources can have a bearing on the project, and thus


24/128


standard requirements were set. Each step along the way, thestandard requires that we verify that the outputs of each stepin the Safety Lifecycle have been achieved, and are consistentwith the inputs to that step of the Safety Lifecycle.

Kenexis has prepared a typical SIS design lifecycle in a slightlydifferent representation that more closely associates itself withthe actual steps that are taken during the design of a SIS. Thislifecycle is shown in Figure 3 .

F i g u r e 3 K e n e x i s S a f e t y L i f e c y c l e

The steps in the Kenexis Safety Lifecycle are more granular

than what is shown in the standard, and thus functions moreeffectively as a flowchart of an SIS project than does thelifecycle in IEC 61511.


25/128

13

Conceptual Process Design

Conceptual Process Design is the starting point of the SafetyLifecycle. Although it is listed as a step in IEC 61511, it istypically considered out-of-scope for Safety Instrumented

Systems. This step is included in the safety lifecycle as areference for the task that leads into the standard, andprovides inputs for the first safety lifecycle task, but thestandard places no requirements on the conceptual processdesign.

Conceptual process designs are either developed by theoperating company itself, or are licensed from a company that

specializes in developing processes. The conceptual designprocess will result in design documents that will form the basisfor subsequent engineering, and also form the basis of theProcess Safety Information (PSI) that will be used as an inputto the process hazards analysis. PSI includes information suchas piping and instrumentation diagrams (P&IDs), heat andmass balances, block flow diagrams, and safe operating limits.


26/128


Process Hazards Analysis

Process Hazards Analysis (PHA) is a qualitative analysis ofprocess hazards by a multi-disciplinary team. It is not a newconcept. PHA has been implemented within industry for morethan 15 years now. The OSHA process safety managementregulation put into place in 1992 caused PHA to become much

more prevalent, but most PHA methodologies were developedand implemented far earlier.

The inputs to this step of the Safety Lifecycle include ProcessSafety Information, such as proposed Process Flow Diagrams(PFD), Piping and Instrumentation Diagrams (P&ID), and otherdocumentation that would be required to analyze potentialdeviations from normal intention of process operation. PHA

involves analyzing those deviations from design intent anddetermining if they could result in a credible hazard. If so, theconsequences of those hazards are identified, and thesafeguards in place to prevent those hazards are identified. A


27/128

15

qualitative assessment of risk is made by the PHA team, oftenusing risk guidelines from the operating company, such as arisk matrix. If safeguards are not considered adequate, thenthe PHA team makes recommendations for reducing oreliminating the hazards or adding to the safeguards. The resultof this step is a Process Hazards Analysis report that identifiesthe process hazards. The PHA report can then be used in thenext step in the SIS engineering lifecycle.

With respect to SIS engineering, the primary purpose of thePHA step is to identify safeguards that are required in order toreduce risk of the process and understand what hazards thosesafeguards protect against. PHA is typically considered to be asingle formal study such as a Hazards and Operability Study(HAZOP) whose results are documented in a single report.However, in reality PHA should be considered as a series ofstudies and engineering tasks that result in recommendationsfor potential safeguards. These tasks should include thefollowing:

Development of Design Packages from Process TechnologyLicensors and Engineering Companies

Review of Design Standards, Codes, and Good EngineeringPractice Guidelines for Specific Equipment Items

Initial Preliminary Hazard Assessment studies, such asHAZID

Relief System Design Basis Studies

Alarm Rationalization Studies

Chemical Reactivity Testing and Analysis

Formal Process Hazards Analysis


28/128


A preliminary process design is rarely performed starting from ablank slate. Often, process design is based on proventechnologies used for years. There are often process designtemplates from process licensors that contain importantinformation about hazards and key safeguards. These licensorpackages identify Safety Instrumented Functions that havebeen included by process licensors based on past experiencewith design and operation of the process technology.Furthermore, most process plants include a large number ofcommon pieces of process equipment that require safeguardingthrough SIS. These include pumps, compressors, and firedequipment. Often, this equipment is designed and safeguardedin accordance with equipment specific standards such as theNational Fire Protection Association (NFPA) standards for firedequipment including boilers, as well as the American PetroleumInstitutes (API) recommended practices for designs for firedequipment, compressors, and other rotating equipment.

Other engineered safeguard design basis studies may also yieldrequirements for safety instrumented systems. Studies such asrelief system design basis, alarm management study, orchemical reactivity study often result in recommendations forSIS especially when other means of safeguarding aredetermined to be inappropriate or less effective than use ofSIS.

The tasks that are traditionally considered PHA are essentially structured brainstorming techniques where a trainedfacilitator generates discussion among a group of experts withregards to the hazards potentially posed by a process byleading the discussion with cues that are designed to stimulatethought. For instance, in a HAZOP the cues are deviations fromdesign intent for a specific process section such as less flow ormore level. Formal PHA studies are typically performed at

several stages in the lifecycle of a process plant. In manycases the first studies are carried out using simpler techniques(e.g., checklists, HAZID) and later studies using more detailedmethods such as HAZOP. At the point in time that a final PHA


29/128

17

is performed, the great preponderance of engineeredsafeguards have already been documented in the plants designand the PHA simply acts as a final check on a good design.

With respect to the SIS safety lifecycle, it is important for theselection of a SIL target to be consistent with other PHA studiesperformed for the process plant. In addition, the informationprovided in these studies can provide valuable assistance andinsight during the SIL selection effort.

Fi g u r e 4 T y p i c a l H A Z O P- S t y l e P H A O u t p u t

Figure 4 presents a typical HAZOP-Style PHA. This type ofreport can be dissected in order to develop information that willassist in the determination of a SIL target. For instance,hazard scenarios that are listed are typically assignedconsequence categories, the causes can often be used asinitiating events, and the safeguards can be considered asindependent protection layers. Also, recommendations fromthe PHA might identify the need for additional SIF that were notidentified by other prior analysis.

In summary, this step in the safety lifecycle should not beconsidered as conducting a traditional PHA, but acomprehensive series of activities to identify and understandthe hazards that require safeguarding by the SIS.


30/128


SIF Definition

The definition of safety instrumented functions (SIF) is a criticalstep in the SIS safety lifecycle, and the source of many errorsin SIS design as a result of common misconceptions about whatconstitutes a SIF. SIF Definition requires an adequateunderstanding of hazards associated with a chemical process,and the specific instruments that are utilized to protect against

those hazards. Safety Instrumented Functions are intended toprotect against specific and identifiable hazards instead ofgeneral hazards, such as fire and gas explosion.

The result of SIF definition is that Safety Instrumented FunctionList, or SIF list. A SIF list is a compilation of the functionswhich must be implemented in an overall Safety InstrumentedSystem which could include multiple Safety InstrumentedFunctions within the same logic solver, and using similar oridentical components such as sensors and final elements.Some components might be employed in multiple SIF, asdemonstrated in Figure 5 .


31/128

19

Fi g u r e 5 S I F v e r s u s S I S

The purpose of SIF definition is to create a list of all thefunctions that need to be analyzed in the remaining steps of theSafety Lifecycle including SIL selection, Safety RequirementSpecification, Functional Test Procedure development, and soon. Safety Instrumented Functions are identified on a hazard-by-hazard basis, as opposed to strictly considering thefunctionality executed by the SIF. Therefore, it is imperative

that this step is done adequately, with sufficient thought as tothe hazards that are involved in the process, and theequipment or components that could be used to detect andtake corrective action once those hazards are identified.

Identification of Safety Instrumented Functions is performedconsidering a range of design documentation including Causeand Effect Diagrams, and Piping and Instrumentation Diagrams.The SIF List is a list of all functions that needs to be analyzed.Each SIF is assigned its own Safety Integrity Level, individually,in order to represent the risk reduction required to mitigate thespecific hazard associated with that function. The integrity


32/128


level requires or defines the performance for that function interms of its ability to achieve a tolerable risk target that isestablished by the company operating the process.

Figure 6 presents a typical SIF list, as contained in the KenexisSIS Design Basis Toolkit. As shown, this list completelydefines the extents of the SIF.

Fi g u r e 6 T y p i c a l S I F L i s t

For each SIF, a description is provided that defines theintention of the function and the action that is required to movethe process to a safe state. All of the safety critical inputs arelisted, specifically all of the sensors that can detect the hazardbeing prevented. The safety critical outputs are listed, and by

this what is meant is all of the outputs that are necessary andsufficient to move the process to a safe state. This is a verydifferent concept than listing all of the outputs that areactivated as per the units cause and effect diagram. Also, thelocation of the SIF is listed, designating the logic solver that isutilized to implement the SIF. In addition to listing theequipment items information concerning the votingarrangements of the equipment necessary to prevent the

defined hazard is also provided.

The SIF List should define each SIF completely, including:


33/128

21

Tag names for input devices

Description of SIF intention

Input voting

Tag names for output devices

Output voting

Location of SIF logic

Additional information such as interlock numbers, P&ID drawingnumbers and general notes may also be included for completedocumentation purposes.


34/128


Safety Integrity Level Selection

Once all of the functions that are in the scope of analysis havebeen defined in the SIF list, Safety Integrity Level (SIL)Selection is performed. At this stage, the SIFs are analyzedsequentially looking at the hazards, identifying the appropriateperimeters that affect the risk of those hazards, and selectingan appropriate SIL to achieve a desired risk tolerance

threshold. It is important to remember that the purpose of SILSelection is to define performance criteria for the system. It isnot to define the SIF, but rather prescribe how much riskreduction is required of each of those SIF.

Defining SIL

As per their definition in IEC 61511 (ISA 84.00.01) SIL areorder of magnitude bands of average probability of failure ondemand (PFDavg). This PFDavg also represents the amount of


35/128

23

risk reduction of a preventive safety instrumented function canprovide. The ranges for each of the four SIL levels defined inthe standard are presented in Figure 7 . This figure not onlypresents SIL in terms of PFDavg, but also Safety Availabilityand Risk Reduction Factor (RRF). Safety Availability is thecomplement of PFDavg (i.e., 1-PFDavg), and the RRF is theinverse of PFDavg (i.e., 1/PFDavg). All of these metrics arecommonly used in industry.

F i g u r e 7 S a f e t y I n t e g r i t y L e v e l M e t r i c s

SIL 1 is the lowest level of Safety Integrity that is defined bysafety availability by at least 90% up to 99%, essentiallyproviding one order of magnitude of risk reduction. SIL 2 is anorder of magnitude safer than SIL 1 in terms of its safetyavailability. The safety availability of a SIL 2 function would beat least at least 99% and up to 99.9% safety available. SIL 3is an order of magnitude on top of SIL 2 in terms of safetyavailability, and SIL 4 follows accordingly. SIL 4 is rarely - ifever - seen in the process industries, and is often reserved forapplication to other non-process related industries that could becovered by international standards for Safety InstrumentedSystem design. If a SIL selection process results in arequirement for SIL 4 the user should proceed with care andobtain the assistance of experts.


36/128


SIL Selection Process

Since SIL is a measure of the amount of risk reduction providedby a Safety Instrumented Function, SIL selection is an exercisein analyzing the risk of the hazard and determining how muchrisk reduction is required to achieve a tolerable level of risk.Reducing the risk can be graphically represented by thisdiagram contained in Figure 8 , where at least two perimetersthat affect risk are considered. Specifically, those parametersare consequence and likelihood.

Consequence

Lik

elihoo

d Tolerable RiskRegion

ALARPRisk Region

UnacceptableRisk Region

Consequence Reduction,e.g., material reduc tion,containment d ikes,phys ical protection

Inherent Riskof the Process

Increasing Risk

SIL 1

SIL 2

SIL 3

Non SIS RiskReduct ion, e.g.Pressure ReliefValves

SIS RiskReduction

Fi g u r e 8 G r a p h i ca l S I L S e l e c t i o n R e p r e s e n t a t i o n

The consequence is the potential severity of an accidenthazard. The likelihood is a representation of how often theaccident is expected to occur. If one considers a single hazardwithin a process, it will have an inherent process risk, which isa function of its inherent consequence severity, and an inherent


37/128

25

likelihood of that hazard occurring in absence of any othersafeguards. In this diagram, increasing risk is up and to theright. This means that increasing consequence or increasinglikelihood would result in an increasing risk. The risk diagram,in this case, is divided into three regions shown below:

1. An unacceptable risk region, shown in red, where risk isintolerable and must be reduced.

2. A tolerable risk region, shown in green, where risks aredeemed generally tolerable without further risk reduction.

3. A region in-between the unacceptable and the tolerable riskregion, shown in yellow, which is called the ALARP, or aslow as reasonably possible risk region.

In order to achieve a level of risk that is broadly acceptable, theuser is required to show that risk is in the green area of this

diagram.

The inherent risk can be reduced by Non-SIS risk reduction. Inorder to assess the risk one, is required to know and evaluatethe effectiveness of all Non-SIS risk reduction measures toensure that the risk is reduced to as low as possible before weapply the additional benefit of a SIS. Or in fact, addresswhether or not we need a SIS to further reduce the risk.

Non-SIS risk reduction could include consequence reductionmeasures, as well as likelihood reduction measures.

Consequence Reduction could take the form of containmentdikes, or physical protections such as blast walls, or blast-resistant control buildings. Likelihood Reduction could takethe form of operators responding to safety critical alarms, orpressure relief provided by conventional over-pressure

protection.

In the example shown in Figure 8 , the benefit of all these Non-SIS layers of protection, or safeguards, is not sufficient to


38/128


achieve tolerable risk. Therefore, additional risk reduction isrequired, and in this example, a SIL 1 level of risk reduction, aSIL 1 performance, is adequate to achieve a tolerable risk. Inthis example, we would specify a SIL 1 level of performance toachieve tolerable risk for a Safety Instrumented Function thatprotects against this hazard. Each SIL level provides a oneorder of magnitude decrease in the frequency of the event.

Representing Tolerable Risk for SIL Selection

For the purposes of performing SIL selection, companies often,represent their risk tolerance in terms of either risk matrices orTolerable Maximum Event Likelihood (TMEL) Tables. Figure 9 shows an example risk matrix and Figure 10 contains aconsequence categorization table that includes TMEL figures foreach consequence category. These risk tools are utilized for

day-to-day risk engineering tasks, and are calibrated againstcorporations tolerable risk guidelines. Calibration details forthese example risk tools are contained in Appendix H .


39/128

27

0

0

0

0

0

0

3

2

1

0

0

0

4

3

2

1

0

0

5

4

3

2

1

0

6

5

4

3

2

0

7

6

5

4

3

0

0 1 2 3 4 5

5

4

3

2

1

0

LIKELIHOOD

S E V E R I T Y -

S A F E T Y

Fi g u r e 9 Ca l i b r a t e d R i s k M a t r i x


40/128


S Category Safety Environment Commercial TMEL

0 None No significantsafetyconsequence

None None N/A

1 Very Low Minor injury -first aid

Small release with minimalclean up requirements

$50,000 1E-02

2 Low Lost time injurynot requiring

extendedhospitalization

Moderate release limited toonsite damage with

moderate clean up effort

$500,000 1E-03

3 Moderate Severe injury(extendedhospitalization,dismemberment)

Large release with limitedoffsite impact requiressignificant onsite clean up

$5 Million 1E-04

4 High Single fatality Large release offsite onextensive clean up anddamage to sensitive areas

$50 Million 1E-05

5 VeryHigh

Multiple fatalities Very large release off sitewith extensive clean of andpermanent damage toseveral sensitive areas

$500 Million 1E-06

Fi g u r e 1 0 Co n s e q u e n c e Ca t e g o r y T a b l e w i t h T M E L

Figure 11 shows an example likelihood category table whichwould be used in combination with the consequence table whenusing the Risk Matrix approach.


41/128

29

Likelihood Description RecurrencePeriod

0 None N/A

1 Very Unlikely 1,000 years

2 Unlikely 100 years

3 Occasional 10 years

4 Frequent 1 year

5 Very Frequent 0.1 year

Fi g u r e 1 1 L ik e l i h o o d Ca t e g o r y T a b l e

While a wide variety of techniques can be used to select therequired SIL, Layer of Protection Analysis (LOPA) is by far themost common method due to its ease of use and effectiveness.LOPA can employ either the Risk Matrix or TMEL table approach

to represent risk. When a risk matrix is used, the analysisstrictly employs orders of magnitude (i.e., the exponents) andis referred to as Implicit LOPA, whereas then the TMEL tableis used, risk figures are calculated using the actual frequencyand probability figures and is referred to as Explicit LOPA.

When performing an Implicit LOPA, the category of theconsequence is selected, and the category of the initiating

event is selected. It is important to remember that theselected likelihood needs to reflect the frequency of theinitiating event, not the ultimate consequence. This is differentthan how risk is ranked in other PHA studies such as HAZOPwhere the frequency of ultimate consequence is ranked. Theintersection of the consequence and the likelihood categories onthe risk matrix contains the number of orders of magnitude ofrisk reduction that are required to make the risk of a particularhazard tolerable.

When using the TMEL table approach, only the consequencecategory needs to be determined. Each category of


42/128


consequence is associated with a TMEL. This TMEL is thefrequency at which a consequence of that magnitude istolerable. When using Explicit LOPA, initiating events arequantified based on their frequencies. Appendix C contains alist of typical initiating event frequencies.

Layer of Protection Analysis

The benefit of layers of protection can be accounted for in aseparate Layer of Protection analysis, where we look at thepotential effectiveness of each of these protection layers.

Fi g u r e 1 2 L a y e r s o f P r o t e c t i o n

Figure 12 presents a graphical depiction of the concept of layerof protection analysis, where each concentric sphere contains


43/128

31

the process risk with it. In order for a process hazard to escapeit will need to go through all of the layers.

The process industries utilize a number of independentprotection layers as part of typical plant designs. Somecommon protection layers, along with probabilities of failure ofthose layers can be found in Appendix D . Figure 13 displayssome protection layers that are common in the processindustries. This most common protection layer is operatorresponse based on alarms indicating a process has been movedfrom its normal window of operation to a potentially unsafestate. Safety instrumented systems are the layer of protectionfor which we would want to establish a SIL.

Pressure relief devices, or simple mechanical devices, to reducethe risk of hazards such as over-pressure are also common. Inaddition, other safeguards that are in this case not related toprevention of an accident, but rather mitigation of the potential

consequences of an accident, including plant emergencyresponse, are also often available.


44/128


Fi g u r e 1 3 L a y e r s o f P r o t e c t i o n

The philosophy of layers of protection acknowledges that one ormore of these layers could fail when a demand condition isplaced upon it. And as such, some accidents with potentiallyhigh consequence severities, as well as high likelihoods, couldrequire more than one robust SIS design, or other layers ofprotection to reduce the risk to a tolerable level. We account forthe protection layers in a separate Layer of Protection analysiswhere we verify that each of the protection layers isindependent of all other protection layers, is specificallydesigned to prevent the hazard that has been identified, and iseffective. In other words, its equivalent to at least 1 order ofmagnitude reduction in risk, or no more than 10% probabilityof failure when a demand is placed upon it.

Explicit and implicit varieties of LOPA handle the effectivenessof protection layers in a slightly different way, which aremathematically equivalent. When using TMEL targets as the


45/128

33

basis for tolerable risk, the frequency of the unwanted accidentmust be calculated and compared against the target. Thisfrequency calculation is done by multiplying the initiating eventfrequency by the probability of failure on demand of all of theindependent protection layers that act against that specificinitiating event. If multiple initiating events are present, thenthe resultant frequencies should be summed. The selectedperformance target for the SIF is then calculated as themaximum probability of failure that the SIF would be allowed toyet still to achieve the TMEL.

When using a risk matrix to contain tolerable risk, the requirednumber of orders of magnitude of risk reduction is taken fromthe matrix. Each credit for an independent protection layerreduces the risk by 1 order of magnitude. Mathematicallyspeaking, this means that each credit is equivalent to a PFD of1x10 -1 . Thus the SIL target selected for the SIF is the requirednumber of orders of magnitude of risk reduction minus thenumber of protection layer credits. The subtraction ofprotection layers is equivalent to multiplication of probabilitiesbecause multiplying numbers or adding their exponents yieldsthe same result.

The equations that are used to determine the required SIL(additionally the required RRF when TMEL is used) are shownbelow:

Implicit (Risk Matrix) LOPA

Credit IPL LS RRSIL ,

Where,

SIL= The selected safety integrity level

RR(S,L) is the required amount of risk reduction (in termsof required orders of magnitude of risk reduction, obtained fromthe calibrated risk graph


46/128


(IPLCredit) is the sum of all of the credits for all of the validindependent protection layers

IPL Credit to PFD Conversion:CreditsPFD 1.0

(1 credit = PFD = 0.1 ; 2 credit = PFD = 0.01 ; 3 credit = PFD= 0.001)

Explicit (TMEL) LOPA

TMELSIS Noevent F

SIL ),(

i j

iji IPLPFD IE SIS Noevent F )*(),(

Where,

SIL= The selected safety integrity level

TMEL (Total Mitigated Event Likelihood) is the frequency atwhich the event is tolerable, obtained from the calibrated riskmatrix and is based on the severity of the event.

F(event, No SIS) is the frequency of the event occurring

without a Safety Instrumented System installed to protectagainst it.

IE is the frequency of the initiating event.

(IPLPFD) is the Product of the probability of failure ondemands for all of the valid independent protection layers foreach Initiating Event.


47/128

35

Conceptual Design / SIL Verification

After Safety Integrity Levels have been selected for each of theindentified Safety Instrumented Functions, the next tasks in theSIS Safety Lifecycle that need to be accomplished are

Conceptual Design of the Safety Instrumented System and SIL Verification. This stage is where verification that each ofthe required SILs has been achieved by the system that hasbeen designed is accomplished.

These two steps really go hand-in-hand, and often they areiterative in nature. The typical starting point is a ConceptualDesign of the SIF that is either based on prior experience withthe application, or engineering judgment based on the requiredSIL. This design is then evaluated in order to determinewhether the SIL has been achieved. The Conceptual Design isthen modified in an iterative fashion until all facets of the SILrating have been achieved by the design; including, componenttype, architecture, fault tolerance, functional testing, anddiagnostic capabilities. The purpose of conceptual design


48/128


evaluation is to determine whether the equipment, and how itis maintained, is appropriate for the selected SIL. The result isa set of functional specifications of the system that can be usedin detailed design engineering (i.e., safety requirementsspecifications).

As shown in Figure 14, there are several parameters in thedesign of a SIS that could potentially affect the achieved SIL.These are the selection of the components, the fault toleranceof the design (which is dependant on the architecture that hasbeen selected), the functional testing interval of the system(and its components), the potential for common cause failuresto defeat any fault tolerant design features, as well as anydiagnostics that are incorporated into the design of the systemcomponents.

Fi g u r e 1 4 P a r a m e t e r s I m p a c t i n g A c h i e v e d S I L


49/128

37

Component Selection

The component selection process considers both qualitative andquantitative aspects of the components set of properties. Thequalitative aspects include:

Suitability for the selected application

Suitability for use in safety

The former criterion speaks to the components ability toaccurately react in the specific process application, and thelatter criterion speaks to the components reliability for safetyapplications. Both of these criteria are critical, and neither canbe ignored.

For a device to be suitable for a specific application, theprinciples that the device employs must have a proven historyof effective performance in a specific application. For instance,vortex meters and magnetic (Mag) meters both measureflow, but cannot be interchanged in all applications becausetheir effectiveness is not equal in all cases, and is verydependent on the substance being measured. This is a criticalconsideration when employing certified equipment. Even ifequipment is certified for IEC 61508 compliance, it still cannotbe used unless an assessment is made by the users that thetechnology the device employs is suitable for the application.

In order for a device to be suitable for safety, the user musteither have successful prior use experience with the device orit must be manufactured in accordance with industryrecognized standards for suppliers of Safety InstrumentedSystem components; specifically IEC 61508. This is typically

verified by an independent third party certification. Thesemeasures are meant to speak to suitable reliability of thedevice. In the case of prior use, the end user analyzes pastperformance of the device to determine acceptability, and in


50/128


the case of certification it is assumed that the highlycontrolled design and manufacturing processes will yield highreliability.

In addition to the two qualitative criteria, the technology of thedevice will also play a role in what equipment is selected.Decisions between programmable technologies, as opposed tohard-wired electromechanical devices, are typically made bybalancing the low cost of small hard-wired systems with thedecreased cost and engineering effort associated with largeprogrammable systems. In addition, the technology will alsoaffect other quantitative parameters that will be discussed laterin this section such as failure rate, safe failure fraction, anddiagnostic coverage.

Fault Tolerance

Fault tolerance is the ability of the SIS to be able to perform itsintended actions (and not perform unintended actions) in thepresence of failure of one or more of the SIS components.Fault tolerance is typically achieved through the use of multipleredundant components that are arranged to vote upon actionof the SIF. This arrangement of multiple redundantcomponents is referred to as the architecture of a SIF

subsystem. Some voting architectures would potentially resultin loss of safety upon failure of a component, while others couldpotentially increase the level of safety if one or more ofcomponents in the architecture failed.

The most common architectures employed as SIS subsystemsare listed below. In general, these figures are described in M-out-of-N systems, where M is the number of components thatmust function in order to take the safety action and N is thetotal number of components.

One-out-of-One (simplex)


51/128

39

One-out-of-Two

Two-out-of-Two

Two-out-of-Three

The 1oo1 architecture is a single, individual component, andserves as the baseline in comparing the various available SISarchitectures. The 1oo2 arrangement is the safest of theoptions, meaning it provides the lowest probability of failure ondemand. In this arrangement, if either of two transmitters

votes to shutdown, the shutdown action is taken. The 1oo2arrangement provides one degree of fault tolerance withrespect to dangerous failures, but none with respect tospurious failures. In fact, the 1oo2 arrangement will result in aspurious failure twice as often as the rate resulting from asingle device. The 2oo2 arrangement provides one degree offault tolerance to spurious failures, but none to safety. As a

result, its PFDavg is twice that of a single component (i.e.,more dangerous), but has a nuisance trip rate that is an orderof magnitude lower. Finally, 2oo3 offers a compromisebetween 1oo2 and 2oo2. This arrangement has both lowerPFDavg and lower spurious trip rate than a single device, but isneither as safe as 1oo2 nor as spurious trip resistant as 2oo2.

In addition to the quantitative impacts of architecture, SIL

levels require the achievement of Architectural Constraintswhich are essentially restrictions on the minimum faulttolerance that must be supplied for any given subsystem.Generally, Safety Integrity Level 1 requires no fault toleranceunless it is necessary to achieve the desired probability inPFDavg target. Safety Integrity Level 2 requires at least onedegree of fault tolerance, which could be achieved by, forexample, a 1oo2 voting architecture. A detailed discussion of

achieving minimum fault tolerance, along with the minimumfault tolerance tables out of IEC 61511 and IEC 61508 isincluded in Appendix F .


52/128


Functional Test Interval

Functional testing of a SIF decreases its probability of failure,and increases its effective SIL, by effectively reducing thefraction of time that a SIF is in the failed state. When a test ofa SIF is performed, any latent failures in the system areidentified and subsequently repaired. As the test intervalbecomes shorter (i.e., testing is more frequent), a failed SIFwill not remain in that failed state for as long a period of time,reducing unavailability. Figure 15 demonstrates this conceptfrom the unreliability perspective. The curves in the graph showunreliability which is essentially the probability of failure. Astime increases, the unreliability increases until a test isperformed. After the test confirms successful operation of thesystem (or results in repair of failed components) theprobability of failure then returns to zero. If a system is testedmore frequently it does not travel as far up the unreliabilitycurve before being reset to zero.

F i g u r e 1 5 I m p a c t o f T e s t I n t e r v a l o n S I L

Common Cause Failures

Common Cause recognizes that a potential single event orstress on a SIF could result in multiple simultaneous failures ofSIF components. For example, two or more sensors could failat the same time if their process taps were plugged. Common


53/128

41

Cause Failures are often handled using an analysis of CommonCause Failure percentages that affects the achieved SIL. This iscalled the Beta Factor Method. Common Cause Failures can beeliminated, or substantially reduced, by using not onlyredundant architectures, but by diverse types of equipmentwithin a redundant architecture.

Diagnostic Coverage

Diagnostic Coverage is another factor that allows achievementof potentially higher SIL targets. Diagnostics are essentiallyproof tests of an individual SIS component that occur rapidlyand automatically, but only detect some of the potential failuresof the device. The fraction of the failures that can be detectedis referred to as the diagnostic coverage.

Diagnostics decrease the overall probability of failure of a SIFby effectively reducing the dangerous failure rate. If adangerous failure of an SIF component is detected bydiagnostics, it can then be converted into a safe failure byconfiguring the SIF to automatically go to safe state in thepresence of a detected failure.

PFD Calculation

The overall probability of failure calculation, which considers allof the previously described factors, is performed usingreliability models such as fault tree analysis, simplifiedequations, or Markov models to evaluate each SIF. Industrystandards require quantitative verification that the selected SILtargets were achieved for the selected design. While each ofthe potential methods for performing SIL verificationcalculations have their strengths and weaknesses, thesimplified equation options is primarily used by industry


54/128


practitioners where possible. In cases where the situation thatis being modeled cannot be described using the standard set ofsimplified equations, more robust but difficult to employ tools, such as fault tree analysis are used to support thesimplified equations.

Calculation of the overall PFDavg of a SIF begins with use ofone of the equations shown below for each subsystem sensor,logic solver, and final element. The equations used consideringthe specific failure rates of the analyzed device and theproposed test interval of the subsystem. Some typical failurerates for common instrumentation that is used in safetyapplications is given in Appendix G . The following sectioncontains simplified equations for most common SIS subsystemarchitectures. More details regarding the equations can befound in Appendix E .

Simplified Equations

Equations for Probability of Failure on Demand

1oo1 2TI

PFD avg DU

1oo1D-NT xMTTR DDSD DU

2TI

PFD avg

1oo2

23PFD

22

avg

TI TI DU DU

2oo2 TI DU avgPFD


55/128

43

2oo3

2)()(PFD 22avg

TI TI DU DU

Equations for Spurious Trip Rate (STR)

1oo1 DDS STR

1oo1D-NTSU STR

1oo2 )(2 DDS STR

2oo2 DDS DDS MTTRSTR 2)(2

2oo3 DDS DDS MTTRSTR 2)(6


56/128


Safety Requirements Specifications

The Safety Requirements Specifications task is the next stepin the Safety Lifecycle. The Safety Requirements Specifications(SRS) development occurs at the end of the ConceptualDesign/SIL Verification phase after the proposed design hasbeen confirmed to achieve its target. The objective of the SRSis to define both functional and performance related

requirements for the SRS. The SRS is prepared in enoughdetail that the functionality of the entire SIS (particularly thelogic solver) is defined in sufficient rigor that detailed designengineering tasks can proceed (typically by a different groupthan prepare the SRS package).

The IEC 61511 / ISA 84.00.01-2004 standard provides a listingof the information that should be documented, or at least

considered during this phase. This information includes thefollowing items:

A description of all the safety instrumented functionsnecessary to achieve the required functional safety

Requirements to identify and take account of commoncause failures

A definition of the safe state of the process for eachidentified safety instrumented function

A definition of any individually safe process states which,when occurring concurrently, create a separate hazard (forexample, overload of emergency storage, multiple relief toflare system)

The assumed sources of demand and demand rate on thesafety instrumented function

Requirement for proof-test intervals


57/128

45

Response time requirements for the SIS to bring theprocess to a safe state

The safety integrity level and mode of operation(demand/continuous) for each safety instrumented function

A description of SIS process measurements and their trippoints

A description of SIS process output actions and the criteriafor successful operation, for example, requirements for tightshut-off valves

The functional relationship between process inputs andoutputs, including logic, mathematical functions and anyrequired permissives

Requirements for manual shutdown

Requirements relating to energize or de-energize to trip

Requirements for resetting the SIS after a shutdown

Maximum allowable spurious trip rate

Failure modes and desired response of the SIS (for

example, alarms, automatic shutdown)

Any specific requirements related to the procedures forstarting up and restarting the SIS

All interfaces between the SIS and any other system(including the BPCS and operators)

A description of the modes of operation of the plant andidentification of the safety instrumented functions requiredto operate within each mode


58/128


The application software safety requirements

Requirements for overrides/inhibits/bypasses including howthey will be cleared

The specification of any action necessary to achieve ormaintain a safe state in the event of fault(s) being detectedin the SIS. Any such action shall be determined takingaccount of all relevant human factors

The mean time to repair which is feasible for the SIS, takinginto account the travel time, location, spares holding,service contracts, environmental constraints

Identification of the dangerous combinations of outputstates of the SIS that need to be avoided

The extremes of all environmental conditions that are likely

to be encountered by the SIS shall be identified. This mayrequire consideration of the following: temperature,humidity, contaminants, grounding, electromagneticinterference/radiofrequency interference (EMI/RFI),shock/vibration, electrostatic discharge, electrical areaclassification, flooding, lightning, and other related factors

Identification of normal and abnormal modes for both the

plant as a whole (for example, plant start-up) and individualplant operational procedures (for example, equipmentmaintenance, sensor calibration and/or repair). Additionalsafety instrumented functions may be required to supportthese modes of operation

Definition of the requirements for any safety instrumentedfunction necessary to survive a major accident event, for

example, time required for a valve to remain operational inthe event of a fire


59/128

47

While all of the information described above must be developedto fully define a SIS, it is not good practice to attempt tocombine all of the information into a single document. Often,engineers who are new to SIS, have not had significantexperience in specification of instrumentation and controlsystem, and use a reading of the standards as their only basisfor how to specify control systems erroneously attempt to useIEC 61511 / ISA 84.00.01 as a design guideline instead of thecollection of requirements that it is. This often results in anSRS document that uses the list of bullet items shown above asan outline and then proceeds to fill in the blank for eachSIF. This process usually yields poor results. The documentsare difficult for systems integrators and equipment vendors touse, as they do not present a comprehensive view of thesystem, and also include large amounts of repetitive data thatis not useful to system designers, and often does not getupdated when subsequent changes occur.

A much better approach is to provide a more comprehensivepackage that describes an entire SIS. This type of packagetypically contains a functional logic description, often in theconcise and easy-to-use cause and effect diagram format. Acollection of requirements that are uniformly applied to all SIF such as bypass requirements and failure response actions arebest contained in a single general requirements document.Finally, complexities of the system that are unique to a single

SIF and too complicated to be explained in the context of thefunctional logic description (e.g., cause and effect diagram) canbe described in a specific notes document.

Using this methodology, a holistic system view is provided,repetition of information is minimized, and information that isnot relevant to the users of the SRS package (such as SILselection details) are not included. Instead, the general

requirements section simply refers to the other projectdocuments in which this additional information is contained.


60/128


Once the SRS package has been prepared, it can be provided todetailed design contractors and equipment vendors. Thesegroups can then implement a system that is consistent with theSafety Integrity Levels that were selected in previous SafetyLifecycle steps. A good SRS package will allow contractors andvendors to provide equipment bids and perform their detaileddesign tasks with minimal additional input from the SIS designbasis team.


61/128

49

Detailed Design and Specifications

The Detailed Engineering Design and Specification phaseoccurs after the SIS Design Basis team has completed theSafety Requirements Specification, which then serves as thebasis for all subsequent design tasks. In this step, the designof a SIS is very similar to the design of other non-safety relatedcontrol systems. Some of the tasks that are performed duringthis phase include the following:

Development of instrumentation specifications andrequisitions

Development of loop sheets

Development of logic solver system input/output lists

Development of logic solver system cabinet layout

Development of logic solver cabinet internal wiring diagrams

Preparation of interconnecting wiring diagrams and cable

schedules

Development of PLC programs


62/128


Procedure Development

The next step in the Safety Lifecycle is ProcedureDevelopment. By this we mean Operations Procedures, aswell as procedures for maintenance and testing of the SafetyInstrumented System.

Procedures should address various modes of operations of theSafety Instrumented System, including startup, bypass, andreset operations. Procedures should address manual responseto detected failures of the Safety Instrumented System.Procedures should also include maintenance and testingrequirements of the Safety Instrumented System, andfunctional testing requirements to achieve the required Safety

Integrity Level. The functional test interval must be consistentwith the Safety Requirements Specifications that were identifiedearlier in the Safety Lifecycle.

Before procedures can be written, the end user must establishthe preferred philosophy of how the SIS will get tested,maintained and operated. Seemingly minor details can have amajor impact on SIS effectiveness.

The end user must determine how each function will beperiodically tested. Generally it is preferable to conduct a fullfunctional test whenever practical, which simultaneously tests


63/128

51

all components of the SIF starting with the sensing device,through the logic solver and out to the final element. Anexample of a full functional test is to isolate a pressuretransmitter from the process impulse lines, connect a handpump to the transmitter test port, pressure the sensor to thetrip point and confirm the function activated at the correctvalue. If special requirements exist for the final element (forexample, a valve that must achieve Class VI bubble-tightshutoff) the test can be designed to confirm this has also beenachieved.

A full functional test has the best chance at discovering covertfailures. This, in turn, makes it much easier for the end user toachieve the dangerous failure rate claimed as part of the SILverification calculations. When a full functional test is notperformed the SIL verification calculations must be modified toaccount for non-ideal test conditions.

An example of an inferior test practice is to connect a signalsimulator to the field terminals and drive a signal to the I/Ocard. This only reveals a small portion of the overall failures ina typical sensing device, those portions related to the lineintegrity, signal ranging and logic. It does nothing to revealfailure sensor failure modes related to impulse lines, sensingelement, transmitter circuit board, transmitter internal settings,firmware and software.

When establishing bypass philosophy, the end user should takeinto account human factors; in most major accidents accidentalor intentional bypassing are cited as key contributing factors.

There is recognized value in being able to temporarily place asensing element in bypass. If the sensor needs recalibration,maintenance or replacement, a sensor bypass can allow those

activities without requiring a shutdown. The bypass can bedone via software or a hardwired switch, although software isusually more convenient.


64/128


When software bypasses are in place and can be activatedthrough the DCS, the SIS-DCS communication must becarefully designed to ensure that the SIS can quickly go from

bypass enabled to normal mode without the operator beingrequired to remove each bypassed sensor by hand. Also, SIS-DCS communication diagnostics must be used that will allowthe SIS to function properly in the case of a communication lossbetween the systems.

The SIS interface should be designed so that the operator,instrument technician and engineer are not capable ofbypassing outputs (final elements). Most outputs are activatedby multiple different sensors. For example, in a fired heater thefuel supply valves may be closed because of high fireboxpressure, high/low fuel gas pressure, high temperature,oxygen/combustible analyzer and fan failures. An abnormalcondition in any of these different variables can require theactivation of a shutdown. If an output is bypassed, it iseffectively bypassing ALL of this critical interlockssimultaneously.

Testing and bypassing philosophy are only two of the manyimportant protocols to establish when considering SIS design.When making these decisions, the user should be aware of theirimpact on the effectiveness of the system. Whatever philosophyis chosen, the decisions should be made during the early part of

the design phase and then implemented in testing procedures.


65/128

53

Construction, Installation, andCommissioning

The next step of the Safety Lifecycle is the Construction,Installation, and Commissioning. This step is very similar to

other standard (non-SIS) control systems design,commissioning, and startup activities. It involves purchasingequipment, on-site installation, importing and loading softwareprograms, and connecting wiring. This must be done prior toPre-Startup Acceptance Testing.


66/128


Pre-Startup Acceptance Testing

Pre-Startup Acceptance Testing (PSAT) is the next step in theSafety Lifecycle. In this step, the requirement is to verify thatthe installed equipment and software conform to the SafetyRequirement Specifications (SRS). This is an activity that takes

place on site during the commission, installation, and startupactivities. Design engineers review the hardware and softwareto ensure all the requirements that were established in theSafety Requirements Specification were achieved. Relevantdeviations should be noted and corrected prior to placing theequipment in service. In addition, a full-functional test of thesystem is generally required during pre-startup acceptancetesting to prove that the system behaves as it was specified in

the Safety Requirement Specification.The correct method of conducting a PSAT is to confirm thedesign is in accordance with the SRS. This is because the SRScontains the critical design decisions, preferences andrequirements that form the basis of a well-designed system. Ifa SIS integrator has misinterpreted a requirement within theSRS, the PSAT is the last chance for the design defect to bediscovered and corrected before the system becomesoperational. This is also a good reason why a third party who isindependent of the SIS integrator, and who has a thoroughunderstanding of the SRS requirements, should conduct the

8/13/2019 SIS Engineering Hand

sis engineering handbook - kenexsis

Documents