ANSI-ISA-S84.01

AMERICAN NATIONAL STANDARD

ANSI/ISA–S84.01–1996

Application of Safety Instrumented Systems for the Process Industries

Approved 15 March 1997

COPYRIGHT 2000 Instrument Society of America

ANSI/ISA-S84.01 — Application of Safety Instrumented Systems for the Process Industries

ISBN: 1-55617-590-6

Copyright � 1996 by the Instrument Society of America. All rights reserved. Printed in the United States of America. No part of this publication may be reproduced, stored in a retrieval r etrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), without the prior written permission of the publisher. ISA 67 Alexander Drive P.O. Box 12277 Research Triangle Park, North Carolina 27709


ANSI/ISA-S84.01 — Application of Safety Instrumented Systems for the Process Industries

ISBN: 1-55617-590-6

Copyright � 1996 by the Instrument Society of America. All rights reserved. Printed in the United States of America. No part of this publication may be reproduced, stored in a retrieval r etrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), without the prior written permission of the publisher. ISA 67 Alexander Drive P.O. Box 12277 Research Triangle Park, North Carolina 27709


Preface

This preface as well as all footnotes, annexes, and draft technical report 84.02 (ISA-dTR84.02) are included for informational purposes and are not part of ANSI/ISA-S84.01. ANSI/ISA-S84.01. ISA-dTR84.02 was still in development at the time that ANSI/ISA-S84.01 was published; for information, contact ISA. This standard has been prepared as part of the service of ISA, the international society for measurement and control, toward a goal of uniformity in the field of instrumentation. instrumentation. To be of real value, this document should not be static but should be subject to periodic review. review. Toward this end, the Society welcomes all comments and criticisms and asks that they be addressed to the Secretary, Secretary, Standards and Practices Board; ISA; 67 Alexander Drive; P. P. O. Box 12277; Research Triangle Park, NC 27709; Telephone Telephone (919) 549-8411; Fax (919) 549-8288; E-mail: [email protected]. The ISA Standards and Practices Department is aware of the growing need for attention a ttention to the metric system of units in general, and the International System of Units (SI) in particular, in the preparation of instrumentation standards, recommended practices, practices, and technical reports. reports. The Department is further aware of the benefits to USA users of ISA standards of incorporating suitable references to the SI (and the metric system) in their business and professional dealings with other countries. Toward this end, this Department will endeavor to introduce SI and acceptable metric units in all new and revised standards to the greatest extent possible. The Metric Practice Guide , which has been published by the Institute of Electrical and Electronics Engineers as ANSI/IEEE Std. 268-1992, and future revisions, will be the reference guide for definitions, symbols, abbreviations, and conversion factors. It is the policy of ISA to encourage and welcome the participation of all concerned individuals and interests in the development development of ISA standards. Participation in the ISA standards-making standards-making process by an individual in no way constitutes endorsement by the employer of that individual, of ISA, or of any of the standards, recommended practices, and technical reports that ISA develops. S84.01 has been developed with the intent that it will eventually become a part of a group of standards being developed by the International International Electrotechnical Commission Commission (IEC). This has resulted in a format and structure that may be somewhat different from previous ISA Standards. Some background information is, therefore, offered to assist the reader in better understanding the focus of S84.01. IEC has commissioned the development of a set of international standards encompassing all aspects of safety safety systems systems for all industries. industries. It is titled titled "Functional Safety: Safety: Safety-Related Systems." This effort is under the direction of IEC Technical Technical Committee No. 65, Subcommittee 65A, Working Group 10. It is titled IEC draft Publication 1508 and a nd is still in development but, as it exists today, today, there are seven parts: • Part Part 1 - General General requir requireme ements nts • Part 2 - Requirements for Electrical/Electronic Electrical/Electronic / Programmable Electronic Systems (E/E/PES) • Part 3 --Softw Software are requirement requirements s • Part 4 - Definiti Definitions ons and abbrevia abbreviations tions of terms • Part 5 - Guidelines Guidelines on the the applicatio application n of Part 1 • Part 6 - Guidelines Guidelines on the applicati application on of Parts Parts 2 and 3

ANSI/ISA-S84.01-1996 COPYRIGHT 2000 Instrument Society of America

3

• Part 7 - Bibliograp Bibliography hy of technique techniques s and measures measures This work is to define requirements requirements common to all industries. It is IEC's intent that there will then be additional standards developed to reflect specific requirements for the various industry sectors, such as nuclear, pharmaceutical, aeronautical, process, etc. IEC has commissioned a subcommittee, identified as IEC 1511, for the development of an industry-specific international standard that addresses the application of safety instrumented systems for the process industries. industries. ISA-S84.01-1995 has been written with the intent that it will serve as the basis for that sector-specific sector-specific standard. The structure, format, and content of S84.01 has been developed in this context. context. There are significant differences differences in S84.01 from IEC draft Publication 1508-1995, as described in Clause 12. However, However, IEC draft Publication 1508 was still being developed at the time that S84.01 was published. As a result, ISA SP84 will will continue to support and monitor IEC draft Publication 1508 development and will modify S84.01 as needed when IEC draft Publication 1508 is published. The IEC style guide has been used to facilitate the harmonization of this material with the general standards and other sector-specific standards being developed for IEC draft Publication 1508.

The following people served as active members of ISA Committee SP84: NAME V. Maggioli, Chairman R. Boyd, Jr., Vice Chairman W. Calder III, Managing Director *R. Adamski R. Aldridge R. Bailliet N. Battikha L. Beckman R. Bell S. Bender P. Bennett K . B i n g h am W. Black J. Blagg R. Bloomfield *K. Bond K. Bosch S. Boyer *B. Bradley A. Brombacher D. Brown *L. Brown M. Cannon J. Carew L. Cheung R. Desrochers (deceased)

COMPANY Feltronics Corporation Aramco Calder Enterprises Triconex Consultant Shell Offshore, Inc. ICI Canada, Inc. HIMA Americas, Inc. Technology & Health Sciences Division S.K. Bender & Associates Center for Software Engineering Hinz Consulting, Ltd. BP GRE Eco Waste Technologies Adelard Shell Oil Company G3 IQSE Iliad Engineering, Inc. Mobil Research & Development Corporation Eindhoven University of Technology Fisher-Rosemount Systems Arco Oil & Gas Industrial Equipment Company Stone & Webster, Inc. W.R. Grace & Company Sun Company

*One vote per company

4 COPYRIGHT 2000 Instrument Society of America

ANSI/ISA-S84.01-1996

R. Dillman

Conoco, Inc.

NAME

COMPANY

J. Duran P. Early *R. Ewbank T. Fisher J. Forrest *T. Frederickson, Jr. R. Freeman D. Fritsch *K. Gandhi R. Gardner *F. Gellner J. Gilman R. Glaser W. Goble *C. Goring *J. Gray D. Green T. Green J. Greenwald *R. Grehofsky P. Gruhn *A. Habib *A. Hamers A. Hammons B. Hampton C. Hardin D. Haysley *A. Heckman *K. Hill L. Hoffman B. Humes *D. Inverso J. Jarvi W. Jay K. Jennings D. Jensen R. Johnson *W. Johnson *D. Karydas K. Kassner R. Kier D. Leonard *E. Lewis J. Martel *T. McAdams

Lagoven SA ABB Industrial Systems, Inc. Rhone-Poulenc, Inc. Lubrizol Corporation ABS Industrial Verification, Inc. Triconex Monsanto Phillips Petroleum Company M. W. Kellogg Company DuPont Engineering E. I. du Pont de Nemours & Company Procter & Gamble Company Dow Chemical Company Moore Products Company August Systems, Ltd. Chevron Research & Technology Company Rohm & Haas Stubbs Overbeck & Associates Fina Oil & Chemical Company E. I. du Pont de Nemours & Company Industrial Control Service, Inc. Rhone-Poulenc, Inc. Honeywell SMS Chevron USA Consultant Hoechst Celanese Corporation Murphy Oil Company Bently Nevada Mobil Research & Development Corporation BASF Corporation Bently Nevada E.I. du Pont de Nemours & Company Teknillinen Tarkastuskeskus Entergy Operations, Inc. Square D Company Price Engineering Company Kingwood Technology Group E. I. du Pont de Nemours & Company Factory Mutual Research Corporation CALTEK Pacific-Minas Corporation Kinetics Technology International Consultant Union Carbide Corporation Exxon Chemical Company Allen-Bradley Company



5

S. McCormick

3M Company

NAME

COMPANY

*M. McElroy F. McKenna N. McLeod R. McNab *F. Mears *W. Mostia, Jr. I. Nimmo J. Nye *D. Ogwude T. Ostrowski *J. Palomar J. Paques B. Phelps *W. Purser R. Raghaven G. Ramachandran *K. Rashida C. Richard L. Richardson *C. Rischar *W. Robinson G. Russcher *D. Sanders K. Schilowsky J. Schroeder R. Shah T. Shephard *J. Simon I. Smith S. Smith J. Sottnik R. Spiker R. Spinks *P. Stavrianidis R. Stevens H. Storey L. Suttinger H. Thomas *C. Thurston M. Toffolo *W. Valerie T. Walczak D. Watkins M. Weber S. Weiner

Pepperl + Fuchs Systems FMcK Associates, Ltd. Elf Atochem Arco Chemical Company Mobil Research & Development Corporation Amoco Corporation Honeywell, Inc. Exxon Research and Engineering Company Chevron Research & Technology Company Occidental Chemical Corporation Chevron Research & Technology Company Institut de Recherche Citgo Petroleum Corporation Shell Oil Company Consultant Cytec Industries, Inc. Allen-Bradley Company Mobil Oil Company UOP Allen-Bradley Company Amoco Corporation Westinghouse Electric Company August Systems, Ltd. Marathon Oil Company Tosco Corporation Koch Industries Caltex Services Corporation M. W. Kellogg Company Campbell Love Associates Touch Technology, Inc. United Engineers & Constructors GTI Industrial Automation Petrocon Engineering, Inc. Factory Mutual Research Corporation U.S. Department of Energy Shell Development Company Westinghouse Savannah River Company Air Products & Chemicals Union Carbide Corporation Elsag Bailey (Canada), Inc. Arco Oil & Gas GE Fanuc Dow Chemical Company TUV-IQSE PC&E Consulting Engineers




W. Welz, Jr. *G. Wristen

BHP Engineers & Constructors, Inc. E. I. du Pont de Nemours & Company

This published standard was approved for publication by the ISA Standards and Practices Board on February 15, 1996. NAME

COMPANY

M. Widmeyer, Vice President H. Baumann D. Bishop P. Brett W. Calder III H. Dammeyer R. Dieck W. Holland A. Iverson K. Lindner T. McAvinew A. McCauley, Jr. G. McFarland J. Mock E. Montgomery D. Rapley R. Reimer R. Webb W. Weidman J. Weiss J. Whetstone H. Wiegle C. Williams G. Wood M. Zielinski

Washington Public Power Supply System H. D. Baumann, Inc. Chevron USA Production Company Honeywell, Inc. Calder Enterprises Phoenix Industries, Inc. Pratt & Whitney Southern Company Services, Inc. Lyondell Petrochemical Company Endress + Hauser GmbH + Company Metro Wastewater Reclamation District Chagrin Valley Controls, Inc. Honeywell Industrial Automation & Control Consultant Fluor Daniel, Inc. Rapley Engineering Services Rockwell Automation A-B Pacific Gas & Electric Company Consultant Electric Power Research Institute National Institute of Standards & Technology Canus Corporation Eastman Kodak Company Graeme Wood Consulting Fisher-Rosemount


7


Contents

Introduction ............................................................................................................................... 13 1 Scope ...................................................................................................................................... 15 1.1 Boundaries of the Safety Instrumented System (SIS) ................................................. 15 1.2 Exclusions ................................................................................................................... 16 2 Conformance to this standard............................................................................................. 17 2.1 Conformance guidance ................................................................................................ 17 2.2 Existing systems .......................................................................................................... 17 3 Definition of terms and acronyms....................................................................................... 18 3.1 Definitions .................................................................................................................... 18 3.2 Acronyms..................................................................................................................... 22 4 Safety life cycle ..................................................................................................................... 23 4.1 Scope .......................................................................................................................... 23 4.2 Safety Life Cycle steps ................................................................................................ 25 5 Safety requirements specifications development............................................................. 27 5.1 5.2 5.3 5.4

Objective...................................................................................................................... 27 Input requirements....................................................................................................... 27 Safety functional requirements .................................................................................... 27 Safety integrity requirements ....................................................................................... 28

6 SIS conceptual design.......................................................................................................... 28 6.1 Objectives.................................................................................................................... 28 6.2 Conceptual design requirements ................................................................................. 28 7 SIS detailed design............................................................................................................... 29 7.1 7.2 7.3 7.4 7.5 7.6 7.7 7.8 7.9

Objective...................................................................................................................... 29 General requirements .................................................................................................. 29 SIS logic solver ............................................................................................................ 30 Field devices................................................................................................................ 31 Interfaces ..................................................................................................................... 32 Power sources ............................................................................................................. 34 System environment .................................................................................................... 34 Application logic requirements..................................................................................... 34 Maintenance or testing design requirements ............................................................... 35

8 Installation, commissioning and pre-startup acceptance test......................................... 36 8.1 8.2 8.3 8.4

Objective...................................................................................................................... 36 Installation ................................................................................................................... 36 Commissioning ............................................................................................................ 36 Pre-Startup Acceptance Test (PSAT) .......................................................................... 36


9

9 SIS operation and maintenance .......................................................................................... 38 9.1 9.2 9.3 9.4 9.5 9.6 9.7 9.8

Objective...................................................................................................................... 38 Training........................................................................................................................ 38 Documentation ............................................................................................................ 38 SIS operating procedures ............................................................................................ 38 Maintenance program.................................................................................................. 38 Testing, inspection, and maintenance ......................................................................... 39 Functional testing ........................................................................................................ 39 Documentation of functional testing ............................................................................ 40

10 SIS Management Of Change (MOC) .................................................................................. 41 10.1 Objective.................................................................................................................... 41 10.2 MOC procedure ......................................................................................................... 41 10.3 MOC documentation.................................................................................................. 42 11 Decommissioning ............................................................................................................... 42 11.1 Objective.................................................................................................................... 42 11.2 General...................................................................................................................... 43 12 Differences .......................................................................................................................... 43 12.1 Terminology ............................................................................................................... 44 12.2 Organizational differences ......................................................................................... 44 12.3 Technology differences ............................................................................................. 46 Annexes A (Informative) — Information and examples illustrating methods for determining Safety Integrity Level (SIL) for a Safety Instrumented System (SIS) ......... 47 A.1 Introduction ................................................................................................................. 47 A.2 Safety Integrity Level (SIL) considerations and the process example ......................... 48 A.3 Example methods for selecting SIL ............................................................................. 50 B (Informative) — SIS design considerations....................................................................... 55 B.1 Separation - identical or diverse.................................................................................. 55 B.2 Redundancy - identical or diverse ............................................................................... 58 B.3 Software design considerations .................................................................................. 59 B.4 Technology selection .................................................................................................. 60 B.5 Failure rates and failure modes ................................................................................... 63 B.6 Architecture ................................................................................................................. 66 B.7 Power sources ............................................................................................................ 66 B.8 Common cause failures .............................................................................................. 69 B.9 Diagnostics.................................................................................................................. 70 B.10 Field devices ............................................................................................................. 72 B.11 User interface ............................................................................................................ 75 B.12 Security ..................................................................................................................... 77 B.13 Wiring practices......................................................................................................... 78 B.14 Documentation .......................................................................................................... 79 B.15 Functional test interval .............................................................................................. 79 C (Informative) — Informative references ............................................................................. 81



D (Informative) — Example ..................................................................................................... 85 D.1 D.2 D.3 D.4 D.5 D.6

Introduction to the example problem ........................................................................... 85 Safety Life Cycle (Figure 4.1) ..................................................................................... 85 Safety requirement specification ................................................................................. 85 Safety integrity requirements (5.4) .............................................................................. 88 Conceptual design (6.0) .............................................................................................. 89 Detail design (7.0) ....................................................................................................... 90

E (Informative) — Index........................................................................................................... 93 Figures 1.1 4.1 A.1 A.2 A.3 D.1 D.2

— Definition of Safety Instrumented Systems (SIS) ............................................................ 16 — Safety Life Cycle ............................................................................................................. 24 — Company ABC, Site XX, Specific SIL implementation techniques, example only .......... 50 — Process example ............................................................................................................ 51 — Company ABC, Site XX, Example of a qualitative matrix for the determining SIL .......... 52 — Basic process control scheme ........................................................................................ 86 — Tentative design solution ................................................................................................ 91

Tables 3.1 4.1 A.1 B.5.1 B.5.2 B.9.1 B.9.2

— Safety Integrity Level (SIL)........................................................................................... 21 — Safety Integrity Level performance requirements ........................................................ 25 — Modified HAZOP documentation example ................................................................... 53 — Typical SIS failure modes ............................................................................................ 64 — Typical Programmable Electronic Failure Modes ......................................................... 65 — Fault types.................................................................................................................... 70 — Diagnostic tests for programmable electronics ............................................................ 72


11


Introduction

Purpose This standard addresses the application of Safety Instrumented Systems (SIS) for the process industries. The SIS addressed includes Electrical (E)/, Electronic (E)/ and Programmable Electronic (PE) technology. This standard is process industry specific within the framework of the International Electrotechnical Commission (IEC) draft Publication 1508 (References C.8 and C.9). This standard follows the Safety Life Cycle presented later (see Figure 4.1). This document is intended for those who are involved with SIS in the areas of • design and manufacture of SIS products, selection, and application • installation, commissioning, and Pre-Startup Acceptance Test • operation, maintenance, documentation, and testing Objective The objective is to define the requirements for Safety Instrumented Systems. Organization This standard is organized into three major parts. The main body of the standard (Clauses 1-11) present mandatory specific requirements. Clause 12 provides key differences between ISA-S84.01 and IEC draft Publication 1508. Informative Annexes A through E present additional non-mandatory (informative) technical information that is useful in SIS applications. Draft Technical Report 84.02 (ISA-dTR84.02), which is issued under separate cover, provides non-mandatory (informative) technical guidance in Safety Integrity Level analysis.


13


1 Scope

NOTE — THIS CLAUSE IS PART OF THIS STANDARD AND CONTAINS MANDATORY REQUIREMENTS. This standard addresses Electrical/Electronic/Programmable Electronic System (E/E/PES), associated sensors, final elements, and interfaces used in automated Safety Instrumented Systems (SIS) for the process industries (Reference C.6). Examples of the E/E/PES technologies are: a) Electromechanical relays; b) Solid state logic; c) PES; d) Motor-driven timers; e) Solid state relays and timers; f) Hard-wired logic; and g) Combinations of the above.

1.1 Boundaries of the Safety Instrumented System (SIS) 1.1.1 Figure 1.1 defines the boundaries of the SIS and identifies the devices that may be included in the system. The SIS described in this standard is that portion of the diagram enclosed within the double lined box. 1.1.2 The SIS includes all elements from the sensor to the final element, including inputs, outputs, power supply, and logic solvers. SIS user interface may be in the SIS. 1.1.3 Other interfaces to the SIS are considered a part of the SIS if they have potential impact on its safety function.


15

Figure 1.1 — Definition of Safety Instrumented Systems (SIS)

1.2 Exclusions 1.2.1 This standard identifies all the steps of the Safety Life Cycle (see Figure 4.1) but does not define the method(s) that may be used in some of the steps. 1.2.2 This standard does not address management of the non-SIS portion of the design or the management of the startup process. 1.2.3 In jurisdictions where the governing authorities (Federal, State, Province, County, City, etc.) have established Process Safety Design, Process Safety Management, or other requirements, these laws shall in all cases take precedence over those requirements defined in this standard. These factors must be integrated into the Safety Life Cycle at the appropriate step. 1.2.4 This standard does not address the codes, regulations, and other requirements that apply only to the Nuclear Industry. 1.2.5 The activity of identifying process hazards by use of Process Hazards Analysis methods is not part of this standard. 1.2.6

Defining the need for a Safety Instrumented Systems is not included in this standard.

1.2.7 This standard is not intended to be used as a stand-alone system purchase specification. It will not eliminate the need for sound engineering judgment. It also does not mandate the use of any particular technology. 1.2.8

The standard is not intended to apply to Basic Process Control Systems (BPCS).

1.2.9

This standard is not intended for pneumatic or hydraulic logic solvers.



1.2.10 This standard does not consider the use of technology that is not currently utilized in Sa fety Instrumented Systems. As new technology evolves and becomes available (e.g., ISA SP50 Fieldbus) it will be addressed in scheduled (5 year) revisions to this standard. In the interim, if new system performance justifies its use, new technology shall be user approved before use in safety applications. In these cases, the new technology implementation may require exception to some standard requirements of S84.01. Exceptions shall be documented to demonstrate that the new approach satisfies the safety requirements. 1.2.11 Analysis of the capability of humans to act on human-machine interface information is part of the Process Hazards Analysis and is outside the scope of this standard. 1.2.12 Instrumentation installed for the purpose of monitoring conditions that may lead to chronic health effects is not covered by this standard. 1.2.13 This standard does not cover instrumentation installed principally for the purpose of property protection. 1.2.14 Systems where operator action is the sole means required to return the process to a safe state are not covered by this standard. (e.g., alarm systems, fire and gas monitoring systems, etc.)

2 Conformance to this standard

NOTE — THIS CLAUSE IS PART OF THIS STANDARD AND CONTAINS MANDATORY REQUIREMENTS. To conform to the requirements of this standard, the following shall be adhered to:

2.1 Conformance guidance 2.1.1 To conform to this Standard, it must be shown that each of the requirements have been satisfied and therefore the Clause objectives have been met. 2.1.2 Where a requirement is qualified by reference to an informative annex, this indicates that a range of techniques and measures can be used to satisfy that requirement including techniques and measures not listed in the informative annex. 2.1.3 The techniques and measures included in normative Clauses 1 through 11 are considered good engineering practices in the design and support of Safety Instrumented Systems.

2.2 Existing systems 2.2.1 For existing SIS designed and constructed in accordance with codes, standards, or practices prior to the issue of this standard, the owner/operator shall determine that the equipment is designed, maintained, inspected, tested, and operating in a safe manner.


17

3 Definition of terms and acronyms

NOTE — THIS CLAUSE IS PART OF THIS STANDARD AND CONTAINS MANDATORY REQUIREMENTS.

3.1 Definitions For the purposes of this standard, the following definitions apply: 3.1.1

application program: See software (3.1.58.1).

3.1.2

application software: See software (3.1.58.1).

3.1.3 architecture: The arrangement and interconnection of the hardware components or modules that comprise the SIS. 3.1.4

availability: See safety availability (3.1.51).

3.1.5 Basic Process Control System (BPCS): A system that responds to input signals from the equipment under control and/or from an operator and generates output signals, causing the equipment under control to operate in the desired manner. Some examples include control of an exothermic reaction, anti-surge control of a compressor, and fuel/air controls in fired heaters. Also referred to as Process Control System. 3.1.6

bypassing: Act of temporarily defeating a safety function in a SIS.

3.1.7

common cause

3.1.7.1 common cause fault: A single source that will cause failure in multiple elements of a system. The single source may be either internal or external to the system. 3.1.7.2 common cause failure: The result of a common cause fault. 3.1.8

communication

3.1.8.1 external communication: Data exchange between the SIS and a variety of systems or devices that are outside the SIS. These include shared operator interfaces, maintenance/engineering interfaces, data acquisition systems, host computers, etc. 3.1.8.2 internal communication: Data exchange between the various devices within a given SIS. These include bus backplane connections, the local or remote I/O bus, etc. 3.1.9

coverage: See diagnostic coverage (3.1.14).

3.1.10 covert fault: Faults that can be classified as hidden, concealed, undetected, unrevealed, latent, etc. 3.1.11 decommissioning: The permanent removal of a complete SIS from active service.



3.1.12 de-energize to trip: SIS circuits where the outputs and devices are energized under normal operation. Removal of the source of power (e.g., electricity, air) causes a trip action. 3.1.13 demand: A condition or event that requires the SIS to take appropriate action to prevent a hazardous event from occurring or mitigate the consequence of a hazardous event. 3.1.14 diagnostic coverage: For SIS with active fault-detection capabilities, the ratio of detectable faults to the total number of faults. 3.1.15 diverse: Use of different technologies, equipment or design methods to perform a common function with the intent to minimize common cause faults (see 3.1.45, 3.1.55, and B.2). 3.1.16 Electrical (E)/ Electronic (E)/Programmable Electronic Systems (PES) (E/E/PES): When used in this context, electrical refers to logic functions performed by electromechanical techniques, (e.g., electromechanical relay, motor driven timers, etc.), electronic refers to logic functions performed by electronic techniques, (e.g., solid state logic, solid state relay, etc.), and Programmable Electronic System refers to logic performed by programmable or configurable devices [e.g., Programmable Logic Controller (PLC), Single Loop Digital Controller (SLDC), etc.] Field devices are not included in E/E/PES. 3.1.17 electronic (/E): See E/E/PES (3.1.16). 3.1.18 embedded software: See software (3.1.58.2). 3.1.19 energize to trip: SIS circuits where the outputs and devices are de-energized under normal operation. Application of power (e.g., electricity, air) causes a trip action. 3.1.20 fail-safe: The capability to go to a predetermined safe state in the event of a specific malfunction. 3.1.21 fault tolerance: Built-in capability of a system to provide continued correct execution of its assigned function in the presence of a limited number of hardware and software faults. 3.1.22 field devices: Equipment connected to the field side of the SIS I/O terminals. Such equipment includes field wiring, sensors, final control elements, and those operator interface devices hard-wired to SIS I/O terminals. 3.1.23 firmware: Special purpose memory units containing software embedded in protected memory required for the operation of programmable electronics. 3.1.24 forcing: A PES engineering station function that provides the capability to override the application program and to change the states of inputs and outputs. 3.1.25 functional testing: Periodic activity to verify that the SIS is operating per the Safety Requirement Specifications Testing. 3.1.26 hardware configuration: See architecture (3.1.3). 3.1.27 hard-wired: Electrical connections accomplished without the use of software or firmware. 3.1.28 hazard: Chemical or physical condition that has the potential for causing injury to people or the environment (Reference C.12).


19

3.1.29 input/output modules 3.1.29.1 input module: E/E/PES or subsystem that acts as an interface to external devices and converts input signals into signals that the E/E/PES can utilize. 3.1.29.2 output module: E/E/PES or subsystem that acts as an interface to external devices and converts output signals into signals that can actuate external devices. 3.1.30 interface: Shared boundary through which information is conveyed. 3.1.31 integration: Process of assembling multiple components or subsystems to form a system. 3.1.32 logic solver: E/E/PES components or subsystems that execute the application logic. Electronic and programmable electronics include input/output modules. 3.1.33 off-line: Process, to which the SIS is connected, is shut down. 3.1.34 on-line: Process, to which the SIS is connected, is operating. 3.1.35 overt faults: Faults that are classified as announced, detected, revealed, etc. 3.1.36 permissive: Condition within a logic sequence that must be satisfied before the sequence is allowed to proceed to the next phase. 3.1.37 Pre-Startup Acceptance Test (PSAT): Process of confirming performance of the total integrated SIS to assure its conformance to the Safety Requirement Specifications and design. 3.1.38 preventive maintenance: Maintenance practice in which equipment is maintained on the basis of a fixed schedule, dictated by manufacturer’s recommendation or by accumulated data from operating experience. 3.1.39 Probability of Failure on Demand (PFD): A value that indicates the probability of a system failing to respond to a demand. The average probability of a system failing to respond to a demand in a specified time interval is referred to as PFDavg. PFD equals 1 minus Safety Availability [ see safety availability (3.1.51)]. 3.1.40 process industry sector: Refers to those processes involved in, but not limited to, the production, generation, manufacture, and/or treatment of oil, gas, wood, metals, food, plastics, petrochemicals, chemicals, steam, electric power, pharmaceuticals, and waste material(s). 3.1.41 Programmable Electronic System (PES): See E/E/PES (3.1.16). 3.1.42 protection layer: Engineered safety features or protective systems or layers that typically involve special process designs, process equipment, administrative procedures, the Basic Process Control System (BPCS), and/or planned responses to protect against an imminent hazard. These responses may be either automated or initiated by human actions (see Annex A for guidance). 3.1.43 qualitative methods: Methods of design and evaluation developed through experience and/or the application of good engineering judgement. 3.1.44 quantitative methods: Methods of design and evaluation based on numerical data and mathematical analysis.



3.1.45 redundancy: Use of multiple elements or systems to perform the same function. Redundancy can be implemented by identical elements (identical redundancy) or by diverse elements (diverse redundancy). 3.1.46 reliability: Probability that a system can perform a defined function under stated conditions for a given period of time. 3.1.47 replacement in kind: A replacement that satisfies the design specification. 3.1.48 reset: Action that restores the equipment under control to a predetermined normal enabled or operating state. 3.1.49 risk assessment: Process of making risk estimates and using the results to make decisions. 3.1.50 safe state: State that the equipment under control, or process, shall attain as defined by the Process Hazards Analysis (PHA). 3.1.51 safety availability: Fraction of time that a safety system is able to perform its designated safety service when the process is operating. In this standard, the average Probability of Failure on Demand (PFDavg) is the preferred term. (PFD equals 1 minus Safety Availability; see 3.1.39.) 3.1.52 Safety Integrity Level (SIL): One of three possible discrete integrity levels (SIL 1, SIL 2, SIL 3) of Safety Instrumented Systems. SILs are defined in terms of Probability of Failure on Demand (PFD) (see Table 3.1).

Table 3.1 — Safety Integrity Level (SIL) Safety Integrity Level (SIL)

Probability of Failure on Demand Average Range (PFD avg)

1

10-1 to 10-2

2

10-2 to 10-3

3

10-3 to 10-4

3.1.53 Safety Instrumented Systems (SIS): System composed of sensors, logic solvers, and final control elements for the purpose of taking the process to a safe state when predetermined conditions are violated (see Figure 1.1). Other terms commonly used include Emergency Shutdown System (ESD, ESS), Safety Shutdown System (SSD), and Safety Interlock System. 3.1.54 Safety Life Cycle: Sequence of activities involved in the implementation of the Safety Instrumented Systems from conception through decommissioning (see Figure 4.1). 3.1.55 separation: The use of multiple devices or systems to segregate control from safety functions. Separation can be implemented by identical elements (identical separation) or by diverse elements (diverse separation). 3.1.56 shall: Indicates a mandatory requirement. 3.1.57 SIS components: A constituent part of a SIS. Examples of SIS components are field devices, input modules, output modules, and logic solvers.


21

3.1.58 software 3.1.58.1 application software: Software specific to the user application in that it is the SIS functional description programmed in the PES to meet the overall Safety Requirement Specifications (see Clause 5). In general, it contains logic sequences, permissives, limits, expressions, etc., that control the appropriate input, output, calculations, decisions necessary to meet the safety functional requirements. 3.1.58.2 embedded software: Software that is part of the system supplied by the vendor and is not accessible for modification by the end user. Embedded software is also referred to as firmware or system software. 3.1.58.3 utility software: Software tools for the creation, maintenance, and documentation of application programs. These software tools are not required for the operation of the SIS. 3.1.59 spurious trip: Refers to the shutdown of the process for reasons not associated with a problem in the process that the SIS is designed to protect (e.g., the trip resulted due to a hardware fault, software fault, electrical fault, transient, ground plane interference, etc.). Other terms used include nuisance trip and false shut down. 3.1.60 systematic failures: Failures due to errors (including mistakes and acts of omissions) in Safety Life Cycle activities that cause the SIS to fail under some particular combination of inputs or under a particular environmental condition. Systematic failures can arise in any Safety Life Cycle step. 3.1.61 Test Interval (TI): Time between functional tests. 3.1.62 user approved: Hardware, software, procedures, etc., that the user has evaluated and determined to be acceptable for the application. 3.1.63 verification: Process of confirming for certain steps of the Safety Life Cycle that the objectives are met. 3.1.64 voting system: Redundant system (e.g., "m" out of "n", one out of two [1oo2] to trip, two out of three [2oo3], etc.) that requires at least "m" of the "n" channels to be in agreement before the SIS can take an action.

3.2 Acronyms BPCS:

Basic Process Control System

CFR:

Code of Federal Regulations

E/E/PES:

Electrical/Electronic/Programmable Electronic System

I/O:

Input/Output

MOC:

Management of Change

MTBF:

Mean Time Between Failures

MTTF:

Mean Time To Failure

MTTR:

Mean Time To Repair

OSHA:

Occupational Safety and Health Administration



PES:

Programmable Electronic System

PFD:

Probability of Failure on Demand

PHA:

Process Hazards Analysis

PSAT:

Pre-Startup Acceptance Test

PSSR:

Pre-Startup Safety Review

SIL:

Safety Integrity Level

SIS:

Safety Instrumented Systems

WDT:

Watchdog Timer

4 Safety life cycle


4.1 Scope The clauses in this standard are organized based on the Safety Life Cycle (see Figure 4.1). The Safety Life Cycle covers the Safety Instrumented Systems (SIS) activities from initial conception through decommissioning. Note that this standard does not address the method for performing initial Safety Life Cycle activities, such as: a) Performing conceptual process design b) Performing Process Hazards Analysis & risk assessment c) Defining non-SIS protection layers d) Defining the need for an SIS e) Determining required Safety Integrity Level These activities are outside the scope of this standard.


23

(4.2.15)

Figure 4.1 — Safety Life Cycle



During the Safety Life Cycle of a SIS, there may be points where iterations are necessary. A few of these are indicated in the Safety Life Cycle presented, but these should not be considered the only points where iteration may be necessary.

4.2 Safety Life Cycle steps 4.2.1 The first step in the Safety Life Cycle is concerned with the conceptual process design. The method for accomplishing this step is outside the scope of this standard. 4.2.2 The second step is concerned with identifying the hazards and hazardous events for a process and assessing the level of risk involved. This standard does not address the methods for performing this analysis and evaluation but assumes it has taken place prior to applying the principles in this document. The method(s) for accomplishing this step is outside the scope of this standard. 4.2.3 Once the hazards and risks have been identified, appropriate technology (including process and equipment modifications) is applied to eliminate the hazard, to mitigate their consequences or reduce the likelihood of the event. The third step involves the application of non-SIS protection layers to the process. The method(s) for accomplishing this step is outside the scope of this standard. 4.2.4 Next an evaluation is made to determine if an adequate number of non-SIS protection layers have been provided. The desire is to provide appropriate number of non-SIS protection layers, such that SIS protection layer(s) are not required. Therefore, consideration should be given to changing the process and/or its equipment utilizing various non-SIS protection techniques, before considering adding SIS protection layer(s). The method for accomplishing this step is outside the scope of this standard. 4.2.5 If an SIS is appropriate, the next step is establishing the requirements for the SIS by defining a target Safety Integrity Level (SIL) (See Annex A for guidance). A SIL defines the level of performance needed to achieve the user ’s process safety objective. SILs are defined as 1, 2, and 3. SISs above SIL 3 are not addressed in this standard. The higher the SIL, the more available the safety function of the SIS. Performance is improved by the addition of redundancy, more frequent testing, use of diagnostic fault detection, and use of diverse sensors and final control elements, etc. Performance is also improved through better control of design, operation, and maintenance procedures. Associated with the SIL are Probability of Failure on Demand average (see Table 4.1).

Table 4.1 — Safety Integrity Level performance requirements SAFETY INTEGRITY LEVEL SIS PERFORMANCE REQUIREMENTS

1

2

3

Safety Availability Range 0.9 to 0.99

0.99 to 0.999

0.999 to 0.9999

PFD Average Range 10-1 to 10-2


10-2 to 10 -3

10-3 to 10-4

25

The SIL concept is utilized in several steps of the Safety Life Cycle. See Annex A for guidance on SIL determination. The method for accomplishing this step is outside the scope of this standard. 4.2.6 The next step is developing Safety Requirement Specifications. The Safety Requirement Specifications document functional and integrity requirements for the SIS (see Clause 5). 4.2.7 The next step involves developing the SIS Conceptual Designs that may meet the Safety Requirement Specifications. Annex B provides guidance on the selection of architectures to meet SIL requirements (see Clause 6). 4.2.8 Once SIS Conceptual Design is complete, the detailed design can be performed (see Clause 7). 4.2.9

Install the SIS (see Clause 8).

4.2.10 After installation is complete, the Commissioning and Pre-Startup Acceptance Test (PSAT) of the SIS shall be performed (see Clause 8). 4.2.11 SIS Operation and Maintenance Procedures may be developed at any step of the Safety Life Cycle and shall be completed prior to startup (see Clause 9). 4.2.12 Prior to startup of the SIS, a Pre-Startup Safety Review (PSSR) shall take place. This PSSR shall include the following SIS activities: a) Verification that the SIS was constructed, installed, and tested in accordance with the Safety Requirement Specifications. b) Safety, operating, maintenance, Management of Change (MOC), and emergency procedures pertaining to the SIS are in place and are adequate. c) PHA recommendations that apply to the SIS have been resolved or implemented. d) Employee training has been completed and includes appropriate information about the SIS. The planning and execution of this activity is outside the scope of this standard. 4.2.13 After PSSR, the SIS may be placed in operation. This step includes startup, normal operation, maintenance, and periodic Functional Testing (see Clause 9). 4.2.14 If modifications are proposed, their implementation shall follow a Management of Change (MOC) procedure. The appropriate steps in the Safety Life Cycle shall be repeated to address the safety impact of the change (see Clause 10). 4.2.15 At some time, the need for the SIS will cease. For example, this may be caused by plant closure, or the removal or change of the process. The decommissioning of the SIS shall be planned, and appropriate steps should be taken to ensure that this is accomplished in a manner that does not compromise safety (see Clause 11).



5 Safety requirements specifications development


5.1 Objective The objective is to develop specifications for Safety Instrumented Systems (SIS) design. These Safety Requirement Specifications consist of both safety functional requirements and safety integrity requirements. The Safety Requirement Specifications can be a collection of documents or information.

5.2 Input requirements The information required from the Process Hazards Analysis (PHA) or process design team to develop the Safety Requirement Specifications, includes the following. 5.2.1

A list of the safety function(s) required and the SIL of each safety function.

5.2.2 Process information ( incident cause, dynamics, final elements, etc.) of each potential hazardous event that requires a SIS. 5.2.3

Process common cause failure considerations such as corrosion, plugging, coating, etc.

5.2.4

Regulatory requirements impacting the SIS.

5.3 Safety functional requirements The safety functional requirements shall include the following. 5.3.1

The definition of the safe state of the process, for each of the identified events.

5.3.2

The process inputs to the SIS and their trip points,

5.3.3

The normal operating range of the process variables and their operating limits,

5.3.4

The process outputs from the SIS and their actions,

5.3.5 The functional relationship between process inputs and outputs, including logic, math functions, and any required permissives. 5.3.6

Selection of de-energized to trip or energized to trip.

5.3.7

Consideration for manual shutdown.

5.3.8

Action(s) to be taken on loss of energy source(s) to the SIS.


27

5.3.9

Response time requirements for the SIS to bring the process to a safe state.

5.3.10 Response action to any overt fault. 5.3.11 Human-machine interfaces requirements. 5.3.12 Reset function(s).

5.4 Safety integrity requirements Safety integrity requirements shall include the following. 5.4.1

The required SIL for each safety function.

5.4.2

Requirements for diagnostics to achieve the required SIL (see B.9 for guidance).

5.4.3

Requirements for maintenance and testing to achieve the required SIL.

5.4.4

Reliability requirements if spurious trips may be hazardous.

6 SIS conceptual design


6.1 Objectives To define those requirements needed to develop and verify a SIS Conceptual Design that meets the Safety Requirements Specifications.

6.2 Conceptual design requirements 6.2.1 The Safety Instrumented Systems (SIS) architecture for each safety function shall be selected to meet its required Safety Integrity Level (SIL). (e.g., The selected architecture may be one out of one [1oo1], 1oo2 voting, 2oo3 voting, etc.) 6.2.2 A SIS may have a single safety function or multiple safety functions that have a common logic solver and/or input and output devices. When multiple safety functions share common components, the common components shall satisfy the highest SIL of the shared safety function. Components of the system that are not common must meet the SIL requirements for the safety function that they address. When multiple SISs are combined in a system where they share common logic or components, the potential for common cause faults is increased. Programming, accessibility, maintenance, power supplies, and security are typical common cause issues to consider.



6.2.3

The desired SIL shall be met through a combination of the following design considerations: a) Separation - identical or diverse (see B.1 for guidance) b) Redundancy - identical or diverse (see B.2 for guidance) c) Software design considerations (see B.3 for guidance) d) Technology selection (see B.4 for guidance) e) Failure rates and failure modes (see B.5 for guidance) f) Architecture (see B.6 for guidance) g) Power sources (see B.7 for guidance) h) Common cause failures (see B.8 for guidance) i) Diagnostics (see B.9 for guidance) j) Field devices (see B.10 for guidance) k) User interface (see B.11 for guidance) l) Security (see B.12 for guidance) m) Wiring practices (see B.13 for guidance) n) Documentation (see B.14 for guidance) o) Functional test interval (see B.15 for guidance)

7 SIS detailed design


7.1 Objective To provide detailed requirements for the design of the Safety Instrumented Systems (SIS) to achieve the requirements of the Safety Requirement Specifications and conceptual design.

7.2 General requirements 7.2.1

The SIS design shall be capable of meeting the Safety Integrity Level (SIL).

7.2.2 The SIS may include sequencing functions to take the process to or maintain it in a safe state.


29

7.2.3

The SIS may contain one or more interlocks or safety functions.

7.2.4 The SIS design documents shall be under control of a formal revision and release control program. 7.2.5 The manufacturer of equipment used in SIS service shall maintain a formal revision and release control program for the equipment, including applicable software. The use of visible markings or user interfaces to identify this information is acceptable (e.g., part #, serial #, batch #, etc.). 7.2.6 The design shall ensure that the hardware and software used in an application are compatible. 7.2.7 The action of any non-safety function, if implemented by the SIS, shall not interrupt or compromise any SIS safety functions. 7.2.8 The required safe states of each SIS component required for the safety function shall be defined. 7.2.9 The SIS shall be designed such that once it has placed the process in a safe state, it shall remain in the safe state until a reset has been initiated. The requirement for a manual or automatic reset shall be as defined in the Safety Requirements Specifications. 7.2.10 Manual means, independent of the logic solver, shall be provided to actuate the SIS final elements unless otherwise directed by the Safety Requirements Specifications. 7.2.11 Any detected single fault that causes a SIS failure shall result in an automatic, predetermined, safe failure action; and/or a safe process condition if the appropriate response action is undertaken. 7.2.12 The design shall apply codes and standards for environmental and hazardous area classifications (e.g., NFPA 70, National Electrical Code, Article 500) (see C.5 for guidance). 7.2.13 SIS Input/Output power circuits shall be separated from circuits used for any other purpose except where the sensor or final control element is shared as allowed in 7.4.2.2 and 7.4.3.1.

7.3 SIS logic solver 7.3.1 The logic solver supplier shall provide an integrated design including, where applicable, input module(s), output module(s), maintenance interface device(s), communication(s), and utility software. The integrated design shall be documented. 7.3.2 The logic solver supplier shall provide Mean Time To Failure (MTTF) data, covert failure mode listing, and frequency of occurrence of identified covert failures. The method and data sources for the above shall be provided. 7.3.3 PES logic solvers shall have methods (internal and/or external) to protect against covert faults (e.g., comparison of logic solver performance versus process action, embedded or application software testing the logic solver performance). 7.3.4 The logic solver shall be separated (see B.1 for guidance) from the Basic Process Control System (BPCS) except where some applications have combined BPCS and SIS functions in one "logic solver" (e.g., gas turbines). In these cases, the BPCS/SIS logic solver shall meet the SIL (see C.1 for additional guidance).



7.3.5 The logic solver shall be designed to ensure the process will not automatically restart when power is restored, unless Process Hazards Analysis indicates this is appropriate.

7.4 Field devices 7.4.1

General requirements

7.4.1.1 Energize to trip discrete input/output circuits shall apply a method (e.g., end-of- line monitor, such as pilot current continuously monitored to ensure circuit continuity; the pilot current shall not be of sufficient magnitude to affect proper I/O operation) to assure circuit integrity. 7.4.1.2 When remote input/output is used, it shall be evaluated in conjunction with the logic solver (see B.6 for guidance). 7.4.1.3 Each individual field device shall have its own dedicated wiring to the system Input/Output, except in the following cases: a) Multiple connected discrete sensors connected in series to a single input if the sensors monitor the same process condition (e.g., motor overloads) b) Multiple connected Final Control Elements (FCE) to a single output if each FCE services the same process condition c) User approved systems such as fire and gas detection systems d) See 1.2.10 for ISA SP50 Fieldbus. 7.4.1.4 Field devices shall be selected and installed to minimize failures that could relate inaccurate information due to conditions arising from the process and environmental conditions. Conditions that shall be considered include corrosion, freezing of materials in pipes, suspended solids, polymerization, coking, and temperature and pressure extremes. 7.4.2

Sensor requirements

7.4.2.1 Smart sensors shall be write protected to prevent inadvertent modification from a remote location, unless appropriate safety review allows the use of read/write. 7.4.2.2 Sensors for SIS shall be separated from the sensors for the Basic Process Control System (BPCS). Two exceptions are allowed provided the failure of the sensor does not create a condition that the SIS is intended to protect against: a) If redundant sensors are used, they may be connected to both the BPCS and the SIS provided that any failure in the BPCS will not affect the proper operation of the sensor or the ability of the SIS to read the sensor properly (see B.1.5). b) If the PHA determines that one or more protection layers other than the BPCS and the SIS offers protection redundant to that provided by the sensor (for further guidance, see Annex A). 7.4.2.3 Sensor diagnostics, vendor or user supplied , shall be provided as required to meet the SIL (see B.9 for guidance).


31

7.4.3

Final control element requirements

7.4.3.1 A control valve from the BPCS shall not be used as the only final element for SIL 3. A safety review shall be required to use a single BPCS control valve as the only final element for SIL 1 and 2. For additional information, see B.1.6. 7.4.3.2 Motor starters Motor starters are typically common to both the BPCS and the SIS unless the Process Hazards Analysis dictates otherwise (see B.10.4.3 for guidance).

7.5 Interfaces This section addresses all human-machine and communication interfaces to the SIS. These can include, but are not limited to a) operator interface(s); b) maintenance/engineering interface(s); and c) communication interface(s). 7.5.1

Operator interface requirements

Operator interface refers to that media (e.g., CRTs, indicating lights, push-buttons, horns, alarms, etc.) used to communicate information between the operator and the SIS. 7.5.1.1 The operator interface system design shall take into consideration the loss of the SIS operator interface and the resulting requirements as defined by appropriate safety review. The design shall ensure that, upon failure of the SIS operator interface, sufficient alternate means shall be provided for the operator to bring the process to a safe state and that the automatic functions of the SIS are not compromised. 7.5.1.2 The SIS status information that is critical to maintaining the SIL shall be available as part of the operator interface. This information may include a) where the process is in its sequence; b) indication that SIS protective action has occurred; c) indication that a protective function is bypassed; d) indication that automatic action(s) such as degradation of voting and/or fault handling has occurred; e) status of sensors and final control elements; f) the loss of energy where that energy loss impacts safety; g) the results of comparison diagnostics; and h) failure of environmental conditioning equipment that is necessary to support the SIS.



7.5.1.3 Changes to the SIS application software shall not be allowed from the SIS operator interface. Where the SIS maintenance/engineering interface is used as the operator interface to the SIS, changes to application software from this interface shall require appropriate safety review and access security. There may be some safety-related information that needs to be transmitted from the BPCS to the SIS. For example, in batch systems a SIS may have different setpoints or logic functions depending on the recipe being used. If so, the operator interface may be used to select the appropriate logic function in the SIS or may be used to select recipe-specific tables. For these types of applications, use only SIS systems that offer the ability to selectively allow writing to a SIS variable that is accessible to the BPCS (see B.1.8 for additional guidance), and a confirmation procedure to ensure the proper selection has been transmitted and received in the SIS. Enabling and disabling the read-write access shall be done only by a configuration or programming process using the Maintenance/Engineering Interface with appropriate documentation and security measures. An Operator Interface shall not be allowed to perform this function. 7.5.2

Maintenance/Engineering interface requirements

Maintenance/Engineering interface is that media provided to allow proper SIS maintenance. It can include instructions and diagnostics that may be found in software, programming terminals, diagnostic tools, indicators, bypass devices, test devices, and calibration devices. 7.5.2.1 The design of SIS maintenance/engineering interface shall ensure that any failure of this interface shall not adversely affect the ability of the SIS to bring the process to a safe state. This may require disconnecting of maintenance/engineering interfaces, such as programming panels, during normal SIS operation. 7.5.2.2 The maintenance/engineering interface shall provide the following functions: a) Access security protection to the SIS operating mode, program, data, means of disabling alarm communication, test, bypass, maintenance, etc. b) Access to SIS diagnostic, voting and fault handling services c) Access to add, delete, or modify application software d) Access to data necessary to troubleshoot the SIS 7.5.3

Communication interface requirements

Communication interface refers to hardware and software communication between the SIS and other devices such as the operator interfaces, maintenance/engineer interfaces, BPCS, network or peripherals. 7.5.3.1 The design of the communication interface of the SIS shall ensure that any failure of the communication interface shall not adversely affect the ability of the SIS to bring the process to a safe state. 7.5.3.2 Communication signals shall be isolated from other energy sources through the use of good engineering practices, such as the use of shielded cable while maintaining a single ground plane with a single dedicated power source, or the use of fiber optics.


33

7.6 Power sources The design shall ensure that each power source meets the needs of the SIS as specified in the Safety Requirement Specifications (see B.7 for guidance).

7.7 System environment The system environment must be addressed to ensure proper SIS operation. This may require consideration of the following: temperature, humidity, contaminants, grounding, Electro Magnetic Interference/Radio Frequency Interference (EMI/RFI), shock/vibration, electrostatic discharge, electrical area classification, flooding, etc. 7.7.1 All environmental conditions to which the SIS will be exposed and the operating environmental specifications for all components of the SIS shall be considered in the system design. 7.7.2 The system design shall take specific steps to resolve all differences between the environmental conditions and equipment specifications in a manner that will allow the SIS to perform in accordance with the Safety Requirement Specifications, such as installing heating, ventilation/air conditioning equipment, and/or air filtration.

7.8 Application logic requirements 7.8.1

Application logic for electrical systems

7.8.1.1 Only application logic under the control of a formal revision and release control program shall be provided and considered for use on a SIS. 7.8.1.2 The application logic formal revision and release control program shall be provided and maintained by the user. 7.8.1.3 The user shall ensure the application logic is documented in a clear, precise, and complete way (see B.14 for guidance). 7.8.2

Application logic for electronic system

7.8.2.1 Only application logic under the control of a formal revision and release control program shall be provided and considered for use on a SIS. 7.8.2.2 The application logic formal revision and release control program shall be provided and maintained by the user. 7.8.2.3 The user shall ensure the application logic is documented in a clear, precise, and complete way (See B.14 for guidance).



7.8.3

Application logic for PES

Software discussed in this subclause addresses the SIS applications. Embedded and utility software is discussed as far as it impacts application software. 7.8.3.1 Only software under the control of a formal revision and release control program shall be provided and considered for use on a SIS. 7.8.3.2 The embedded software and utility software formal revision and release control programs shall be provided and maintained by the SIS manufacturer(s). The manufacturer(s) shall also provide and maintain a bug list and advise customers of any software faults which may lead to a failure to function on demand. 7.8.3.3 The user shall not modify the SIS embedded or utility software. 7.8.3.4 The user shall ensure the application software is documented in a clear, precise, and complete way (see B.3 and B.14 for guidance). 7.8.3.5 The application software formal revision and release control programs shall be maintained by the user.

7.9 Maintenance or testing design requirements 7.9.1 The design shall allow for testing of the overall system. It shall be possible to test final element actuation in response to sensor operation. Where the interval between scheduled process downtime is greater than the functional test interval, then on-line testing facilities are required. 7.9.2 When on-line functional testing is required, test facilities shall be an integral part of the SIS design to test for covert failures. 7.9.3 When test and/or bypass facilities are included in the SIS, they shall conform with the following: a) SIS shall be designed in accordance with the maintenance and testing requirements defined in the Safety Requirement Specifications. b) The operator shall be alerted to the bypass of any portion of the SIS via an alarm and/ or operating procedure. c) Bypassing of any portion of the SIS shall not result in the loss of detection and/or annunciation of the condition(s) being monitored. 7.9.4

Forcing of inputs and outputs shall not be used as a part of: a) application software; b) operating procedure(s); and c) maintenance, except as noted.

Forcing of inputs and outputs without taking the SIS out of service shall not be allowed unless supplemented by procedures and access security. Any such forcing shall be annunciated or alarmed, as appropriate.


35

8 Installation, commissioning, and pre-startup acceptance test


8.1 Objective 8.1.1 The objective of this clause is to ensure that the Safety Instrumented Systems (SIS) is installed per the detail design and performs per the Safety Requirement Specifications. 8.1.2 Any modification or change to SIS-specific equipment during installation, commissioning, or Pre-Startup Acceptance Test (PSAT) shall require a return to the appropriate phase (the one first affected by the change) of the Safety Life Cycle.

8.2 Installation 8.2.1

All equipment shall be installed per the design.

8.3 Commissioning 8.3.1 Commissioning ensures the SIS is installed per the detailed design and is ready for the Pre-Startup Acceptance Test. 8.3.2 The SIS commissioning activities shall include, but may not be limited to, confirmation that the following are installed per the detailed design documents and are performing as specified in the Safety Requirement Specifications: a) Equipment and wiring are properly installed. b) Energy sources are operational. c) All instruments have been properly calibrated. d) Field devices are operational. e) Logic solver and Input/Output are operational.

8.4 Pre-Startup Acceptance Test (PSAT) 8.4.1 A PSAT provides a full functional test of the SIS to show conformance with the Safety Requirement Specifications. The PSAT shall include, but may not be limited to, confirmation of the following: a) SIS communicates (where required) with the Basic Process Control System or any other system or network.



b) Sensors, logic, computations, and final control elements perform in accordance with Safety Requirement Specifications. c) Safety devices are tripped at the setpoints as defined in the Safety Requirement Specifications. d) The proper shutdown sequence is activated. e) The SIS provides the proper annunciation and proper operation display. f) The accuracy of any computations that are included in the SIS. g) That the system total and partial reset functions as planned. h) Bypass and bypass reset functions operate correctly. i) Manual shutdown systems operate correctly. j) Test interval is documented in maintenance procedures consistent with SIL requirements. k) SIS documentation is consistent with actual installation and operating procedures. 8.4.2 A PSAT shall be satisfactorily completed prior to the introduction of hazards the SIS is designed to prevent or mitigate. 8.4.3 Accuracy of calibration of test instruments used in the PSAT shall be consistent with the application. For example, the margin between the SIS setpoint and the hazardous process condition may be used to determine the required accuracy. 8.4.4 Documentation to substantiate completion of the Commissioning and PSAT shall be completed prior to the introduction of hazards the SIS is designed to prevent or mitigate. As a minimum, this documentation shall include the following: a) Identification of the SIS that has been tested b) Confirmation that Commissioning is complete c) Date the PSAT was performed d) Reference to the procedures used in the PSAT e) Authorized signature that indicates PSAT has been satisfactorily completed


37

9 SIS operation and maintenance


9.1 Objective The objective of this clause is to ensure that the Safety Instrumented Systems (SIS) functions in accordance with the Safety Requirement Specifications throughout the SIS operational life.

9.2 Training 9.2.1 Employees involved in the operation and maintenance activities of the SIS shall be properly trained. 9.2.2 Employee training shall adhere to requirements specified in applicable regulation(s) (e.g., OSHA 29CFR1910.119, Reference C.11).

9.3 Documentation The user shall have appropriate documentation (as noted in each Clause 9 subsection) and shall keep the documentation current (see B.14 for guidance).

9.4 SIS operating procedures Operating procedures shall be written to explain the safe and correct methods of operating the SIS. These procedures are typically part of the unit operating procedures. These procedures should include, but not be limited to, the following: a) Limits of safe operation (i.e., trip points) and the safety implications of exceeding them b) How the SIS takes the process to a safe state c) The correct use of operational bypasses, permissives, system reset, etc. (where required) d) The correct response to SIS alarms and trips

9.5 Maintenance program 9.5.1 A maintenance program shall be established, which includes written procedures for maintaining, testing, and repairing the SIS.



9.5.2

SIS maintenance shall include, but not be limited to, the following: a) Regularly scheduled functional testing of the SIS b) Regularly scheduled preventative maintenance, as required (e.g., replacement of ventilation filters, lubrication, battery replacement, calibration, etc.) c) Repair of detected faults, with appropriate testing after repair

9.6 Testing, inspection, and maintenance 9.6.1 Vendor manuals that describe the SIS maintenance and testing requirements (e.g., battery maintenance, fuse replacement) may be included in the maintenance procedures. 9.6.2 Bypassing may be necessary. If the process is hazardous while a SIS function is being bypassed, administrative controls and written procedures shall be provided to maintain the safety of the process. 9.6.3 The user shall have a periodic inspection program for the SIS to detect equipment faults, defects, etc.

9.7 Functional testing Not all system faults are self revealing. Covert faults that may inhibit SIS action on demand can only be detected by testing the entire system. 9.7.1 Periodic Functional Tests shall be conducted using a documented procedure (see 9.7.4.1) to detect covert faults that prevent the SIS from operating per the Safety Requirement Specifications. 9.7.2 The entire SIS shall be tested including the sensor(s), the logic solver, and the final element(s) (e.g., shutdown valves, motors). 9.7.3

Frequency of functional testing

9.7.3.1 The SIS shall be tested at specific intervals based on the frequency specified in the Safety Requirement Specifications (see B.15 for guidance). Note that different portions of the SIS may require different periodic test intervals. 9.7.3.2 At some periodic interval (determined by the user), the frequency(s) of testing for the SIS or portions of the SIS shall be re-evaluated based on historical data plant experience, hardware degradation, software reliability, etc. 9.7.3.3 Any change to the application logic requires full functional testing. Exceptions to this are allowed if appropriate review and partial testing of changes are done to ensure the SIL has not been compromised.


39

9.7.4

Functional testing procedures

9.7.4.1 A documented functional test procedure, describing each step to be performed, shall be provided for each SIS. 9.7.4.2 Any deficiencies found during the functional testing shall be repaired in a safe and timely manner. 9.7.4.3 The functional testing procedures shall include, but not be limited to, verifying the following: a) Operation of all input devices including primary sensors and SIS input modules b) Logic associated with each input device c) Logic associated with combined inputs d) Trip initiating values (setpoints) of all inputs e) Alarm functions f) Speed of response of the SIS when necessary g) Operating sequence of the logic program h) Function of all final control elements and SIS output modules i) Computational functions performed by the SIS j) Function of the manual trip to bring the system to its safe state k) Function of user diagnostics l) Complete system functionality m) The SIS is operational after testing. 9.7.5

On-line functional testing

9.7.5.1 Procedures shall be written to allow on-line functional testing (if required). 9.7.5.2 For those applications where exercising the final trip element may not be practical, the procedure shall be written to include a) testing the final element during unit shut down; and b) exercising the output(s) as far as practical (e.g., output trip relay, shut down solenoid, partial valve movement) during on-line testing.

9.8 Documentation of functional testing 9.8.1 A description of all tests performed shall be documented. The user shall maintain records to certify that tests and inspections have been performed. 9.8.2

Documentation shall include the following information as a minimum: a) Date of inspection b) Name of the person who performed the test or inspection



c) Serial number or other unique identifier of equipment (loop number, tag number, equipment number, user approved number, etc.) d) Results of inspection/test ("as-found" and "as-left" condition)

10 SIS Management Of Change (MOC)


10.1 Objective The objective of this clause is to ensure that the management of change requirements are addressed in any changes made to an operating SIS.

10.2 MOC procedure 10.2.1 A written procedure shall be in place to initiate, document, review the change, and approve changes to the SIS other than "replacement in kind" (e.g., OSHA 29 CFR 1910.119, Section “B”) (see Reference C.11 for guidance). The MOC Procedure could be required as a result of a) modification to the operating procedure; b) modification necessary because of new or amended safety legislation; c) modifications to the process; d) modification to the Safety Requirement Specifications; e) modifications to fix software or firmware errors; f) modifications to correct systematic failures; g) modification as a result of a failure rate higher than desired; h) modifications resulting from increased demand rate on the SIS; and i) modifications to software (embedded, utility, application). 10.2.2 The MOC procedure shall ensure that the following considerations are addressed prior to any change: a) The technical basis for the proposed change b) Impact of change on safety and health c) Modifications for operating procedures


41

d) Necessary time period for the change e) Authorization requirements for the proposed change f) Availability of memory space g) Effect on response time h) On-line versus off-line change, and the risks involved 10.2.3 The review of the change shall ensure a) that the required safety integrity has been maintained; and b) personnel from appropriate disciplines have been included in the review process. 10.2.4 Personnel affected by the change shall be informed of the change and trained prior to implementation of the change or startup of the process, as appropriate. 10.2.5 All changes to the SIS shall initiate a return to the appropriate phase (first phase affected by the modification) of the Safety Life Cycle. All subsequent Safety Life Cycle phases shall then be carried out, including appropriate verification that the change has been carried out correctly and documented. Implementation of all changes (including application software) shall adhere to the previously established SIS design procedures.

10.3 MOC documentation 10.3.1 All changes to operating procedures, process safety information, and SIS documentation (including software) shall be noted prior to startup and updated accordingly. 10.3.2 The documentation shall be appropriately protected against unauthorized modification, destruction, or loss. 10.3.3 All SIS documents shall be revised, amended, reviewed, approved, and be under the control of an appropriate document control procedure.

11 Decommissioning


11.1 Objective 11.1.1 To ensure proper review prior to permanently retiring a Safety Instrumented Systems (SIS) from active service.



11.2 General 11.2.1 Management of Change procedures shall be implemented for all decommissioning activities (see Clause 10). 11.2.2 The impact of decommissioning an SIS on adjacent operating units and facility services shall be evaluated prior to decommissioning.

12 Differences

NOTE — THIS CLAUSE IS PART OF THIS STANDARD. IT ILLUSTRATES THE KEY DIFFERENCES BETWEEN ISA-S84.01 AND IEC DRAFT PUBLICATION 1508. Generally, ISA-S84.01 varies from IEC draft Publication 1508-1995, Parts 1 through 7. These differences are discussed in 12.1 Terminology, 12.2 Organizational, and 12.3 Technical, and are based on the comparison of published S84.01 to a 1995 version of IEC draft Publication 1508 that is undergoing much change. When IEC draft Publication 1508 is published, the SP84 committee will revisit Clause 12 then revise and reissue S84.01, if required. This clause only compares the normative portion (i.e., Parts 1, 2, 3, and 4) of IEC draft Publication 1508 to ISA-S84.01. The modes of operation in which a Safety Instrumented Systems is intended to be used are classified as follows: a) Demand Mode: SIS designed to attain appropriate probability of failure to perform its design function on demand b) Continuous Mode: SIS designed to attain appropriate probability of a dangerous failure per year (e.g., Avionics). This standard does not address this continuous mode of operation.


43

12.1 Terminology

IEC draft Publication 1508 (Part 4)

ISA-S84.01

Comment

E/E/PES Safety Related System

SIS

IEC draft Publication 1508 refers to Safety Related Systems utilizing all technologies, while S84.01 refers only to technologies utilizing Safety Instrumented Systems.

PES

PES

IEC draft Publication 1508 "PES" includes sensors & final control elements, while S84.01 "PES" does not include sensors & final control elements.

EUC

Process

IEC draft Publication 1508 uses "equipment under control" as a generic term for the process S84.01 uses.

Assessment

PSSR

IEC draft Publication 1508 refers to assessment where S84.01 refers to verifications and pre-startup safety review (PSSR).

Functional Requirements Specification

Safety Requirement Specifications

IEC draft Publication 1508 refers to functional requirements specification, while S84.01 refers to Safety Requirement Specifications

12.2 Organizational differences ISA-S84.01 is prepared by instrumentation personnel for ISA, the international society for measurement and control, and American National Standards Institute (ANSI). As such, it does not detail information of process hazards reviews and those issues presently mandated by U.S.A. regulations such as OSHA 29 CFR 1910.119. The result is training, management of change, personnel certification, and process hazards reviews are only briefly discussed and references provided. IEC draft Publication 1508 discusses these issues in greater depth.



IEC draft Publication 1508 Part 1

ISA-S84.01

Specifies the requirements for achieving functional safety of external risk reduction facilities

Does not specify external risk reduction facilities requirements for achieving functional safety

Applies to the total combination of safety related systems and external risk reduction facilities

Applies only to E/E/PES safety related systems (e.g., SIS)

Applies Safety Integrity Levels (SIL) to external risk reduction facilities

Does not apply Safety Integrity Levels (SIL) to external risk reduction facilities

Mandates the use of ISO 9000 Series of Quality Systems or equivalent

Does not mandate the use of ISO 9000 S eries of Quality Systems

Mandates the use of Tables in IEC draft Publication 1508 that specify “minimum level of independence of person, department, organization”

Does not mandate the use of IEC draft P ublication 1508 Tables

Mandates the documentation of rationale for not implementing "Highly Recommended" measures or techniques in IEC draft Publication 1508

Does not mandate documentation of reasons for using a different implementation scheme

Mandates the use of a Safety Plan (see details that follow)

Mandates documentation consistent with OSHA 1910.119, Reference C.11 - Safety Plan not required

(4.6) Mandates adhering to respective Measures and Techniques

Does not mandate adhering to any specific measure or technique Does mandate use of good engineering practice

(4.6) Mandates witnessing tests to ensure compliance with this standard

Does not mandate witnessing tests to ensure compliance

(5)

Refers "Competence of Persons" to OSHA 1910.119, Reference C.11

Addresses "Competence of Persons" by providing detailed requirements in addition to ISO 9000

(6.0) Defines "Safety Management" activities during the whole Safety Life Cycle

Does not address management issues, except management of change

(7.1) Mandates that each phase of the overall Safety Life Cycle be followed by planned verification activity, documented with design review, testing, and analysis of results

Mandates commissioning and Pre-Startup Acceptance Test (PSAT) of the SIS with appropriate documentation (see 8.3 & 8.4)

(7.1.3.2) Mandates ISO 9000 procedures plus IEC draft Publication 1508 requirements be implemented for all aspects of the Safety Life Cycle

Does not mandate the use of ISO 90 00

(7.1.3.1) Mandates adhering to each step in the Safety Life Cycle and providing a documented Safety Plan defining deviations

Does not address conceptual process design, process hazard and risk analysis, non-SIS protection layers, need for a SIS and determining required SIL

(7.1.3.3) Mandates each phase of the overall Safety Life Cycle be divided into elementary tasks with well defined input, output activity for each, scope, and documented

SP84 requires that these activities be completed prior to implementation of SP84


45

IEC draft Publication 1508 Part 1

S84.01

(7.2) Requires process conceptional design information and overall process concept description

The method for accomplishing this is outside the scope of this standard

(7.3) Requires EUC definition documented in this overall scope definition description (7.4) Defines Hazard and Risk Analysis and mandates implementation methodology and documentation (7.5) Mandates: Risk Reduction All Safety Functions Level of Safety Specifies Risk Reduction Method

Items: 7.5.2.4 7.5.2.6 7.5.2.7 7.5.2.2 7.5.2.3

The method for accomplishing this is outside the scope of this standard

7.5.2.5

(7.6.1) Safety requirements allocation is PHA oriented and has external risk reduction facilities (7.7) Overall operator and (7.15) maintenance planning includes external risk reduction systematic analysis (7.8) Validation includes external risk (7.14) reduction (7.9) Provides installation mandates (7.13) Mandates overall modification and retrofit issues

Refer to Management of Change in OSHA1910.119, Reference C.11

Mandates decommissioning log, verification plan, functional safety assessment plan and report, levels of independence

Does not mandate these requirements

Addresses documentation for all phases

Only addresses SIS documentation

Parts 2 and 3 are normative

Parts 2 and 3 type information is part normative and part informative -- to be defined

12.3 Technology differences IEC draft Publication 1508

ISA-S84.01

Comment

SIL 1, 2, 3, 4

SIL 1, 2, 3

S84.01 does not address Safety Integrity Level (SIL) 4 other than recognizes its existence. SIL 4 development is not normally found in the process industries.

Equipment Under Control (EUC) control system excluding the safety controls

Basic Process Control System (BPCS)

IEC draft Publication 1508 refers to the EUC control system, while S84.01 refers to the BPCS.



Annex A (Informative) — Information and examples illustrating methods for determining Safety Integrity Level (SIL) for a Safety Instrumented System (SIS)

NOTE — THIS ANNEX IS NOT A REQUIREMENT OF THIS STANDARD. IT IS PROVIDED FOR INFORMATION ONLY.

A.1 Introduction This annex provides four examples of methods for determining SIL as part of process safety activities. These examples provide only general information on the range and types of approaches for determining SIL. These and additional methods are described in Reference C.1. Determining where a SIS is appropriate, what process variables actuate it, and what final process actions it takes, are beyond the scope of this annex. The four SIL determination methods are applied to an example in only enough detail to show conceptually how SIL can be determined. Details on how to use and understand these SIL determination methods, and others, are described in the references. Four example SIL determination methods were selected to illustrate the variety of approaches. A simple matrix method was chosen to briefly present the key factors, recognizing that many more comprehensive matrix methods are available. The consequences only method exemplifies a straight-forward SIL selection method that involves adoption of some very conservative safety premises. To illustrate a qualitative risk evaluation SIL determination method, a modified HAZOP method was chosen. Quantitative risk assessment methods are represented by describing how a fault tree analysis can be used to determine SIL. Regardless of the method used to select SIL, it is done as part of process safety activities. The team involved in making SIL decisions consists of participants with certain types of expertise. It is generally appropriate to include the following expertise and qualifications on the process safety team: a) Ownership — those who have direct responsibility for operating the equipment b) Process Knowledge — an understanding of the basic science and technology involved in the process and equipment operation c) Design Knowledge — how the equipment or process should work, particularly instrumentation for complex control systems d) Operating Experience — those with direct "hands on" operating and maintenance experience e) Others — skill in running process hazards reviews and other appropriate knowledge as needed This annex does not provide enough information to adequately understand the use of any method, and it does not indicate or imply any safety criteria, or recommend any particular approach.


47

As described in Clause 4 of the standard, determination of Safety Integrity Level (SIL), for a Safety Instrumented Systems (SIS) is a part of process safety activities. As depicted in the Safety Life Cycle, (see Figure 4.1), steps 2, 3, 4, 5, and 6 summarize the process safety concepts involved in determining SIL. These life cycle steps are as follows: f) Step 2 - Evaluate consequences and likelihood for hazardous events g) Step 3 - Evaluate preventive, protective and mitigating process safety features for these events, other than SIS h) Step 4 - Decide if a SIS is appropriate for this application i) Step 5 - Determine target SIL for the SIS j) Step 6 - Determine other process safety-related specifications and design criteria Process safety activities, which include consequence analysis and process hazards reviews (References C.14 and C.15), have the objective of helping to assure that the process will be safe to operate. Hazards, and hazardous events, are identified, and means to control the risk and potential consequences are decided upon, as part of these activities. Risk control and risk reduction decisions are made on many process safety features of the process. These include items, such as, procedures, basic process design, over-pressure protection, and SIS.

A.2 Safety Integrity Level (SIL) considerations and the process example Safety Integrity Level (SIL) is a basic concept in this standard. SIL defines the level of safety performance for a SIS. SILs are defined as 1, 2, or 3. The higher the SIL, the better the safety performance of the SIS. Better SIS performance is achieved by higher availability of the safety function. SIS performance is improved by the addition of redundancy, more frequent testing, use of diagnostic fault detection, etc., as described in the standard and annexes. Some understanding of how the three SIL levels will be implemented is important for the process safety team making the SIL determinations. As the team learns the process, and how hazardous events can occur, they should understand how the SIS will perform its safety function. With an understanding of the important safety aspects of the SIS, including what is needed to achieve the different SIL, the team helps to ensure that the process design and operation do not compromise performance of the SIS. Figure A.1 conceptually shows how the three SIL will be implemented in the example application. The implementation depicted in Figure A.1 is specific to this example. As described in this standard and ISA-dTR84.02 (Reference C.2), there are many ways to implement SIS to achieve a specified SIL. Figure A.2 depicts a simplified piping and instrumentation diagram for the process example. A high pressure vapor is used to control pressure in a low pressure system. The low pressure system is protected from over-pressure by a) a pressure relief valve; b) a pressure control system; and c) an operator response to a high pressure alarm.



Protection of the low pressure system is achieved by stopping flow from the high pressure system, or by the pressure relief valve opening. The consequence of over-pressuring the low pressure system is rupture of the low pressure vessel. The process safety team has identified a potential SIS to prevent over-pressure from occurring in the low pressure system. The SIS would be implemented by sensing pressure and closing valves for the different SIL, with sensors, final elements, and logic solvers arranged as shown in Figure A.1. Figure A.2 simply illustrates the process and is not intended to depict any specific SIL requirements.


49

A.3 Example methods for selecting SIL In the following sections, four different methods will be described for selecting SIL for this high pressure shutdown SIS. afety Integrity Level

Sensor

Logic Solver

SIL 1

...T XXXX

Logic Solver

Actuator

Figure A.1a

...T XXXX

Logic Solver

SIL 2 ...T YYYY

Note 1

Logic Solver

Note: 1) Sensors, logic solvers, and/or final elements may be redundant as safety availability requirements dictate Figure A.1b

Logic Solver

...T XXXX

SIL 3

Note 2 ...T YYYY

Logic Solver

2) The performance of two identical SIL 1 SIS’s may not equal that of one SIL 3 SIS. Figure A.1c

...T XXXX

SIL 3 ...T YYYY

Logic Solver(s) *

Figure A.1d

* Logic Solver(s) as required to meet SIL

Figure A.1 — Company ABC, Site XX, Specific SIL implementation techniques, example only 50 COPYRIGHT 2000 Instrument Society of America


Figure A.2 — Process example

A.3.1 Example method - the safety layer matrix (Reference C.1) The method is based on a qualitative understanding of the process risk, and requires a qualitative evaluation of potential consequences, or impact of harm, that could occur if the SIS and other protection did not stop an initiating event from proceeding to completion. It requires a qualitative evaluation; primarily identification of all the different initiating events and their potential consequences. The method uses a qualitative matrix, shown in Figure A.3, that requires an evaluation of all the initiating events that could lead to the consequences, and the effectiveness of protection, other than the SIS. Qualitative guidance for determining the range of low to high values for the matrix inputs is specific to many considerations such as company guidance, local factors, the nature of the process, etc. The matrix used here is strictly for illustrative purposes. Matrixes actually used will be company dependent. Use of the matrix requires qualitative evaluation of the severity of the consequences for hazardous events the SIS is protecting against. The process safety team felt that the severity was moderate for this example. The matrix also requires an evaluation of the likelihood of occurrence for all the initiating events that could lead to consequences. The process safety team felt the likelihood was moderate for this example. The third axis of the matrix requires a qualitative evaluation of the effectiveness of other protection layers. Layers, other than the SIS under consideration, are evaluated for their effectiveness in preventing the initiating events from leading to consequences. The process safety team felt the effectiveness was between low and medium for this example. This judgement was based on the need for extremely rapid operator response and the tendency for the pressure relief valve to plug. Using these qualitative evaluations, the matrix indicates SIL 2 for the high pressure shutdown system. A.3.2 Example method - the consequences only method This method has fewer steps than many other methods and only requires evaluation of the severity of consequences possible if the SIS and other protection fails. The process safety team felt this method should be used because it could expedite SIL decisions by reducing the time spent on evaluations. The possible trade-off was that the design selection of SIL could be higher


51

than predicted by use of other SIL selection methods. Erring on the side of designing a higher than necessary SIL level was felt to be conservative by this team. The team preferred to save time that would be spent on risk evaluations and to incur the potential cost penalties imposed by selecting a higher SIL than might otherwise result. Money spent on equal or better safety performing SIS was felt to be a good investment in safety.

Figure A.3 — Company ABC, Site XX, Example of a qualitative matrix for the determining SIL

The method only requires an evaluation of the severity of consequences, should the SIS and other protective safety items fail. Since this is a conservative method, this particular plant decided to simplify the SIL selection process from three SIL choices to two SIL choices. This was done by selecting only SIL 1 or SIL 3 designs. If the consequences are above a base threshold, then a SIL 1 is selected. If they are above a "major" severity criteria, then a SIL 3 is selected. These two severity levels were defined to include injuries, property damage, and environmental impact specific to this process. Risk was addressed in setting these guidelines, by the underlying assumption that the frequence of occurrence of initiating events for all SIS applications was assumed to be frequent, or “likely.” The team evaluated the severity of consequences for the high pressure shutdown SIS in the example and felt they exceeded the "major" criteria. Based on that evaluation, a SIL 3 was selected. A.3.3 Example method - the modified HAZOP method In order to determine the SIL, the modified HAZOP method includes the consideration of the severity of the consequences, their probability of occurrence, along with other risk-related



factors. Specific risk reduction recommendations can be evaluated in terms of their effectiveness in reducing risk. The team decides on recommendations, or the adequacy of current risk controls, based on this evaluation process. Using an experienced leader in HAZOP methodology, the process segment is systematically analyzed using a set of guide words to identify process deviations that could lead to hazardous events. A spreadsheet format is used to associate the process deviation, with a specific upset cause. The upset cause is followed by the potential consequences of the upset, factors that prevent or protect against the consequences, and the action or judgement of the team on how to control the associated risk. The team decides on recommendations or the adequacy of current risk controls, based on this evaluation process. Part of the modified HAZOP documentation for the example is summarized in Table A.1. The modified HAZOP team also identified operator error when in manual mode during startup as a cause of a high pressure upset. Based on the severity of the consequences, the team’s feeling for the likelihood of these upsets, and overall performance of the protective systems, the team agreed a SIS was needed. Initially, a SIL 2 or 3 was considered by the team for further evaluation. The team considered safety, equipment reliability, and operation and maintenance costs then determined that an SIL 2 SIS is more appropriate for this application.

Table A.1 — Modified HAZOP documentation example PROCESS DEVIATION

CAUSE

CONSEQUENCES

More Flow

Pressure control valve fails to open

Vessel rupture with potential injuries, property damage, and environmental damage

More Pressure

Pressure sensor fails, drifts to a false low pressure output

Same as More Flow

PROTECTION – Relief Valve – Operator response to high pressure alarms – High pressure shutdown SIS – Same as More Flow, except the operator response is only triggered by a single high pressure signal

A.3.4 Example method - SIL determined from a fault tree Based on the example vessel rupture hazard and several other major hazards in this process, a fault tree analysis was done for a large part of the process, which included the example. The fault tree quantitatively estimated the frequency of occurrence for explosive over-pressure rupture of several process vessels. Fault trees are logic diagrams that systematically display sequences of failures. Sequences of failures that begin with basic events, such as a sensor failure, and lead to a defined "top" event are diagramed. The top event in this case is explosive over-pressure rupture of process vessels. The fault tree logic diagram can be analyzed to estimate the frequency of occurrence for the top event. Failure rates and conditional failure probabilities are assigned to each basic event. Then the top event frequency of occurrence can be calculated. Fault tree analysis is briefly described


53

in Reference C.1, page 56, and extensively covered in Reference C.13. Details of the fault tree covering the example are too complex to describe or depict in this annex. The first step in using the fault tree to determine SIL for the example was to develop the fault tree logic diagram. The initial fault tree was based on the assumption of a high pressure shutdown SIS designed as shown in Figure A.2, a SIL 1 design. Appropriate failure information were determined for all the failure events associated with the example. For example, failure frequencies were estimated for initiating events, such as the pressure control valve failing to open. A top event frequency for vessel rupture was then calculated. After reviewing the fault tree results, the team decided that the fault tree should be changed for evaluation of an SIL 2 and 3 design for this SIS. Subsequent results of this fault tree evaluation indicated a substantial safety improvement for the SIL 2 design, versus the SIL 1 design. The top event vessel rupture frequency of occurrence decreased by a substantial percentage. A similar comparison of SIL 2 versus SIL 3 designs, indicated only a small safety improvement, i.e., the top event frequency decreased only slightly. Based on these comparisons, the team selected SIL 2 for the high pressure shut down SIS.



Annex B (Informative) — SIS design considerations

NOTE — THIS ANNEX IS NOT A REQUIREMENT OF THIS STANDARD. IT IS PROVIDED FOR INFORMATION ONLY. This informative annex addresses design methods to meet SIL requirements. The following SIS design considerations are addressed: B.1

Separation - identical or diverse

B.2

Redundancy - identical or diverse

B.3

Software design considerations

B.4

Technology selection

B.5

Failure rate and failure modes

B.6

Architecture

B.7

Power sources

B.8

Common cause failures

B.9

Diagnostics

B.10

Field devices

B.11

User interface

B.12

Security

B.13

Wiring practices

B.14

Documentation

B.15

Function test interval

B.1 Separation - identical or diverse B.1.1 Separation between BPCS and SIS functions reduces the probability that both control and safety functions become unavailable at the same time, or that inadvertent changes affect the safety functionality of the SIS. Therefore, it is generally necessary to provide separation between the BPCS and SIS functions. B.1.2 Identical separation is generally acceptable for SIL 1 applications. Diverse separation offers the additional benefit of reducing the probability of systematic faults (a factor especially important in SIL 3 applications) and reducing common cause failures (see B.8). B.1.3 There are four areas where separation may be needed to meet the safety functionality and safety integrity requirements: a) Application of field sensors b) Application of final control elements


55

c) The logic solver d) Communication between SIS and BPCS or other equipment B.1.4 Each of these four areas should be evaluated to ensure that the required SIL is met. B.1.5 Sensors A single sensor used for both BPCS and SIS requires further safety review and analysis as part of the process safety activity (see Annex A). For example, a level sensor used for both BPCS and high level trip SIS can create a demand if it fails below the setpoint of the level controller; as a result, the controller may drive the valve open, and this protection will be lost. B.1.5.1 For SIL 1, a single sensor may be used for both BPCS and SIS, provided the safety integrity requirements are met. B.1.5.2 For SIL 2, identical separation between BPCS and SIS is typically needed to meet the required safety integrity. B.1.5.3 For SIL 3, identical or diverse separation between BPCS and SIS is typically needed to meet the required safety integrity. B.1.5.4 When redundant SIS sensors are used, the sensors may be connected to both the SIS and BPCS provided that a safety review and analysis shows the connection to the BPCS does not compromise the safety integrity of the SIS. B.1.6 Control and shutdown valves B.1.6.1 For SIL 1, a single valve may be used for both BPCS and SIS, provided the valve’s unsafe failure rate meets the safety integrity requirements. The design should ensure that the SIS action overrides the BPCS action. B.1.6.2 For SIL 2, identical separation between BPCS and SIS is typically needed to meet the required safety integrity. A single valve used for both BPCS and SIS requires further safety review and analysis, since it may not meet the required safety integrity. For example, a valve used for both BPCS and SIS can create a demand if it fails in the open position. If this valve is also used for an interlock, this protection will be lost, since the SIS could not close the valve. B.1.6.3 For SIL 3, identical or diverse separation between BPCS and SIS is typically needed to meet the required safety integrity. B.1.6.4 When redundant SIS valves are used, the valves may be connected to both the SIS and BPCS provided that a safety review and analysis shows the connection to the BPCS does not compromise the safety integrity of the SIS. B.1.6.5 Additional considerations for determining valve requirements are a) shutoff requirements; b) reliability experience with the valve; c) unsafe failure modes of the valve; and d) operating procedures that make the valve less effective (e.g., open bypass valves).



B.1.7 Logic solver B.1.7.1 For SIL 1, identical or diverse separation between BPCS and SIS is typically needed to meet the required safety integrity. B.1.7.2 For SIL 2, diverse separation between BPCS and SIS is typically needed to meet the required safety integrity. Identical separation between BPCS and SIS may be used provided safety review and analysis shows that it meets the safety integrity requirements. B.1.7.3 For SIL 3, diverse separation between BPCS and SIS should be considered to meet the required safety integrity. B.1.7.4 There may be special cases where it is not possible to provide separation between BPCS and SIS (e.g., a gas turbine control system includes both control and safety functions). Additional considerations when combining control and safety functions in the same device are a) evaluation of the failure of common components and software and their impact on SIS performance; b) life cycle support of the entire system as a SIS with respect to changes, maintenance, testing, and documentation; and c) limiting access to the programming or configuration functions of the system. B.1.8 Communications between BPCS and SIS B.1.8.1 Communications between BPCS and SIS can enhance the overall safety of the application. However, external communications, particularly writes to the SIS, can compromise the safety integrity of the SIS. Provision must be made to ensure all writes are valid and do not negatively impact the system safety or operation. (See B.1.8.2 sections (c) and (d) for further guidance.) B.1.8.2 There are five basic ways to approach external communication between BPCS and SIS: a) No external communication between BPCS and SIS This is acceptable for all SILs. b) Hard-wired communication between BPCS and SIS This is acceptable for SIL 1 and SIL 2, but use of this method for SIL 3 requires additional safety review and analysis. For example, analog or discrete output from one device to the input of another device. c) Read only external communication from SIS to BPCS This may be acceptable for all SILs if review and analysis is done to assure that the safety function is not compromised. Measures to achieve write protection of the safety function include, but are not limited to 1) hard-wired switch (or jumper) to limit write access; and 2) implementation of the safety function in SIS ROM. d) Read/write external communications with write protection of the safety function This is acceptable for SIL 1 and 2, but use of this method for SIL 3 requires additional


57

safety review and analysis. Measures to achieve write protection of the safety function include but are not limited to 1) limited time window for write access; and 2) software switch (e.g., password) to limit write access. e) Read/write external communications with limited or no write protection of the safety function Use of this method may be acceptable for SIL 1. Use of this method for SIL 2 requires additional safety review and analysis. Use of this method in SIL 3 is discouraged.

B.2 Redundancy - identical or diverse B.2.1 Redundancy can be applied to provide enhanced safety integrity or improved fault tolerance. The designer should determine the redundancy requirements that achieve the SIL and reliability requirements for all components of the SIS including sensors, logic solver, and final control elements. B.2.2 An example of this is where the SIS requires a 1oo2 architecture, but there is concern about spurious trips. In such a situation, the designer may choose a 2oo3 architecture, which may improve reliability without substantially reducing safety integrity. B.2.3 Redundancy is applicable to both hardware and software (see B.10). B.2.4 Redundancy should be analyzed for common cause faults. Elimination or reduction of the fault source, or the use of diverse redundancy, are methods to mitigate common cause faults. Some examples of common cause faults are a) plugging of shared instrument lead lines; b) corrosion; c) hardware faults; d) software errors; and e) power supply/source. B.2.5 Diverse redundancy uses different technology, design, manufacture, software, firmware, etc., to reduce the influence of common cause faults. Diverse redundancy should be used if it is required to meet the SIL. Diverse redundancy should not be used where its application can result in the use of lower reliability components that will not meet system reliability requirements. B.2.6 Measures that can be used to achieve diverse redundancy include, but are not limited to a) the use of different measurements (e.g., pressure and temperature) when there is a known relationship between them; b) the use of different measurement technologies of the same variable (e.g., coriolis flow and vortex flow); c) the use of different types of PES for each channel of redundant architecture; and



d) the use of geographic diversity (e.g., alternate routes for redundant communications media). B.2.7 Some typical concerns with PES technology that could warrant diverse redundancy in SIS would be undetected faults in a) hardware; b) manufacturing; c) components; d) operating system; e) communications; f) firmware; g) software; h) application programming; and i) environment.

B.3 Software design considerations B.3.1 Embedded Software B.3.1.1 Embedded software is provided by PES suppliers and is typically transparent to the preparation of application software. Considerations that should be understood before proceeding with the application software development include the following: a) The supplier has a software quality plan. b) The embedded software revision level is defined. c) The embedded software revision level is the same as the revision level analyzed when initially approving the PES for use as a SIS. d) All enhancements to, or fixes of, embedded software functionality contained in new software releases have been reviewed and analyzed. B.3.2 Utility software B.3.2.1 Use of utility software should adhere to the same criteria as embedded software (see B.3.1). Utility software from third parties may be available and considered for use. Use of third party utility software for applications program development, without testing and approval of the PES manufacturer of the utility software package, is not recommended. B.3.3 Application software B.3.3.1 Modular design is highly desirable in application programs. Modular design tends to enhance design simplicity and integrity. B.3.3.2 Application software should include provision for diagnostic testing if required to meet the system SIL. A typical diagnostic testing scheme using an external Watchdog Timer is illustrated in Reference C.1.


59

B.3.3.3 Programming languages that are mature and/or have been certified to accepted industry standards are preferred. B.3.3.4 Programming guidelines should be established to enforce consistent style among the design team. Implementation of a software quality plan may facilitate development of a consistent programming style. B.3.3.5 To avoid unnecessary complexity and features that make the behavior of the system difficult to predict, the following should be considered: a) The software should have a definite order and structure so that it ensures understanding of where you are in the application software at all times b) If nested sequences are used, nesting should be limited to as few layers as possible c) Peer reviews of application software B.3.3.6 To verify that the software design meets each of the requirements established in the Safety Requirement Specifications, consider the following: a) An analysis to demonstrate that each of the requirements established in the Safety Requirement Specifications is implemented in the design b) Peer review of designs of safety critical functions B.3.3.7 Confirm that the application software meets the requirements established in the Safety Requirement Specifications under all expected operating conditions. Consider the following: a) Tests should be developed to exercise the software beyond the normal bounds for data, commands, keyboard inputs, and other actions. b) A bug-reporting and resolution system should be implemented. c) Application software should be tested to determine software behavior in the presence of hardware faults.

B.4 Technology selection B.4.1 Safety Instrumented Systems (SIS) can be developed using Electrical, Electronic or Programmable Electronic (E/E/PE) technologies. B.4.2 A hybrid scheme combining technologies (e.g., PE, Electrical, etc.) may be used to develop a SIS. B.4.3 There are other technologies that can be used other than E/E/PE in the design of an SIS, such as pneumatics, hydraulics, etc. These technologies are outside the scope of this standard (see 1.2.9). B.4.4 Electrical technology used in SISs B.4.4.1 Direct-wired systems B.4.4.1.1 Direct-wired systems have the discrete sensor directly connected to the final element. This technology can only be used in the simplest applications. There is minimal diagnostic coverage, so proof testing frequency may have to be increased.



B.4.4.2 Electromechanical devices B.4.4.2.1 Electromechanical devices include relays and timers. Relays are often used where simple logic functions are adequate to provide the necessary safety logic. Extensive operating experience with relays and their mature technology make acceptance of this device in a SIS widespread. B.4.4.2.2 Standards and guidelines for implementing electromechanical relays in SIS applications are available to users (see Reference C.4). Unsafe failure modes of relays can also be quantified. B.4.4.2.3 Successful users of relays in safety applications have followed some simple guidelines. They include using a relay that a) has a good in-plant track record; b) has the proper "fail-to-shelf" position (e.g., position when completely disconnected) characteristics when installed; c) is found reliable through life-cycle testing; d) is user approved for safety applications; and e) is suitable for the environment in which it is placed (e.g., hermetically sealed). B.4.4.2.4 The relay SIS has other attributes that should be considered: a) The on/off status can be readily obtained by checking contact position (e.g., open or closed). b) Its interconnected logic is very difficult to change (requires rewiring). c) It is simple and understood by plant personnel and can be easily supported. d) It is easily identified and secured as a critical control device. e) It has failure modes that can be isolated to reduce common mode failures. B.4.4.2.5 Relay logic should not be considered inherently fail-safe. Even if the relays are properly selected and applied, the contacts may weld and the spring may not return the switching contacts to the de-energized position. B.4.4.2.6 Electromechanical relay logic systems should consider the following criteria: a) Contacts open on coil de-energization or failure. b) The coil has gravity dropout or dual springs. c) Contacts are of proper material and rating. d) Energy limiting load resistance is installed to prevent contacts from welding closed. e) Proper arc suppression of the contacts is provided for inductive loads. B.4.4.2.7 There are low energy loads (e.g., 50 volts or below and/or 10 mA or below) that require special contact materials or designs (e.g., hermetically-sealed contacts) to eliminate oxidation build-up on contacts resulting in unreliable operation (e.g., load dropout). This is referred to as contact-wetting. When utilizing these special contacts, specific failure mode analysis is needed for these contacts to ensure that a fail-safe electromechanical system is being designed.


61

B.4.4.2.8 Electromechanical relays may not be suitable for SIS applications with a) high duty-cycles resulting in frequent state changes; b) timers or latching functions; c) complex math functions; d) analog measurements; and e) large logic applications. B.4.4.3 Motor driven timers B.4.4.3.1 Motor driven timers provide acceptable performance for key safety applications such as burner purge timing. Most motor driven timers require a locking device or appropriate modification to eliminate tampering with critical settings. Motor driven timers are limited in timing resolution and the ability to handle high duty cycles. B.4.5 Electronic technology used in SISs B.4.5.1 Solid state relays B.4.5.1.1 Solid state relays are used in high duty-cycle application and have unsafe failure modes that can be identified and quantified. Appropriate design features should be added to handle these unsafe failure modes. Some additional applications of solid state relays are described in the following paragraphs. B.4.5.2 Solid state timers B.4.5.2.1 Solid state timers are used where the application’s complexity does not warrant a PES. Solid state timer technology can be categorized as either Resistor-Capacitor (RC) circuit or pulse counting. RC timing devices may not be suitable for safety applications because of poor repeatability and unsafe failure modes. Note that RC circuitry is often used in the time setting portion of pulse-counting timers; this does not preclude the use of these timers. B.4.5.2.2 The pulse-counting timer, sometimes referred to as a digital timer, can use a number of methods to achieve pulse counting. These include a) a line frequency (50 or 60 Hz); b) an electronic oscillator; and c) a quartz crystal oscillator. B.4.5.2.3 A user-approved safety crystal oscillator (e.g., quartz) timer is recommended because of high repeatability and good reliability. B.4.5.3 Solid state logic B.4.5.3.1 Solid state logic refers to the transistor family of components like Complimentary Metal Oxide Semiconductor (CMOS), Resistor-Transistor Logic (RTL), transistor-transistor logic (TTL), and High Noise Immunity Logic (HNIL). These components are assembled in stand-alone modules, plug-in board modules, or in highly integrated, high-density chips. They differ from typical computer-type equipment in that they have no Central Processing Unit (CPU). They perform according to the logic obtained by the direct-wiring techniques of interconnecting the various logic components such as ANDs, ORs, and NOTs. These systems have limitations in fail-safe requirements (e.g., indeterminate failure modes) that should be recognized. 62 COPYRIGHT 2000 Instrument Society of America


B.4.5.3.2 Solid state logic has generally been integrated with direct-wiring and relay schemes for SIS. Solid state logic is not recommended for SISs unless provided with additional diagnostics to test for unsafe failure modes. PESs are sometimes used as a diagnostic tool to make solid state logic systems suitable for SIS. B.4.5.4 Pulsed electronic logic B.4.5.4.1 Pulsed electronic logic generates pulses with a specified amplitude and period. A pulse train is recognized as a logic "true” or "one," while all other signals (e.g., grounds, non-specified pulses, and continuous "on" or "off") are recognized as a logic "false" or "zero." B.4.5.4.2 Pulsed electronic logic can be considered in a SIS if it meets the requirements noted in this standard and is user approved. B.4.5.4.3 Pulsed electronic logic can offer high safety integrity. However, PES designs offer some functions that may not be available with pulsed solid state systems or electronic logic such as calculation capability, improved communications, and networking. B.4.6 PES technology used in SIS B.4.6.1 The PES can be a programmable controller, a distributed control system controller, or an application-specific stand alone microcomputer. Caution should be used when using personal computers, since they generally do not have the safety integrity required for SIS applications. B.4.6.2 The use of PES results in many difficult to recognize failure modes, many of which can be unsafe. B.4.6.3 Some techniques that can be used to minimize the unsafe failure modes of PES are a) extensive diagnostics to detect covert faults (see B.9 for guidance); b) use of redundancy, fault tolerance (e.g., 2oo3), and similar architectures; c) use of Watchdog Timers, both internal and external; and d) use of outputs with diagnostics to detect output module failures. B.4.6.4 Select PES technology for SIS when a) there are large numbers of Input/Output, or many analog signals; b) logic requirements are complex, or the logic includes computational functions; c) extensive data communications with the BPCS is required; and d) different trip points are required for different operations (e.g., batch application recipe selection).

B.5 Failure rates and failure modes B.5.1 Failure rate is the average rate at which faults occur within the SIS components. The failure rate for the overt failure mode of a component may be quite different than the failure rate for the covert mode. The failure rates for both of these modes and their safety implication should be considered in the design of the SIS. Failure rates are influenced by component design, manufacturing quality, installation practice, and environmental and process conditions. See ISA-dTR84.02 for additional information.


63

B.5.2 Tables B.5.1 and B.5.2 list some of the possible faults which should be considered in the design of SIS.

Table B.5.1 — Typical SIS failure modes Device(s) SENSOR

Failure Mode

Device(s)

Failure Mode

Isolation from process Sensor/X-mitter stuck Up/Downscale stuck; Incorrect signal

WIRING/CONNECTORS

BARRIER/ TERMINATION

EXTERNAL COMMUNICATION


Wiring faults; Coil burn out; Relay race

Drift/Calibration Fault

Timing faults

Noise

Welded contacts

Conversion time fault; Conversion fault

Stuck armature

Incorrect supply voltage

Contact fidelity

Open/short

SOLID STATE LOGIC

Wiring fault

Ground fault

Noise/dynamic faults/ x-talk

Noise

Stuck gates (on-off)/ back-plane faults

Open/short

Counter failure

Ground fault

FINAL ELEMENT

Pilot device fault

Isolation failure

Stuck open/closed/ intermediate

Wrong signal

Mechanism stuck

Corrupt data

Energy source

Incorrect data

Conversion time fault

Incorrect source/ destination Incorrect handshaking

Conversion fault

Duplicate source/ destination

64

ELECTROMECHANICAL RELAY/TIMER

COMMON MODE

Over-voltage, current, pressure, etc.

Incorrect Input/Output addressing

Under-voltage, current, etc.

Loss of connection

Total loss of energy

Loss of receiver/ transmitter

Backup-Energy failure (UPS)

Response timeout

Temporary energy fluctuations

Faulty error correction

Temperature too high or too low

Shorts or open circuits

Corrosion

Loss of redundant channel

Electromagnetic interference


Table B.5.2 — Typical programmable electronic failure modes Device(s) PES

Failure Mode Stuck bit / multiple bits

x-talk (DMA) Bus request stuck (DMA)

Instruction time / Wait states / stall

Transfer time incorrect (DMA)

uCode / macro code

Wrong sample time

Arithmetic Logic Unit (ALU) faults

Timer register fault

Access time wait state logic

Wrong timer

Access time

Timeout / overrun

Stuck Interrupt Request (IRQ)

Timebase fault

Stuck / loss of timing

Set / reset fault

Device specific (custom IC)

IRQ / poll fault (Timer)

Stuck Input/Output bit

Trigger pattern (WDT)

x-talk on Input / Output lines

Trigger too early / late (WDT) INPUT

Stuck on/off

Data direction fault (I/O Port)

Upscale / Downscale / conversion fault

Signal too fast / slow (I/O Port)

Drift calibration

Lost bit / byte / message (comm)

Unstable input

Wrong sender / receiver / message

Isolation fault

Timeout / multidrop conflict

Linearization / Compensation

Deadlock (comm)


PES

Failure Mode

Dynamic faults / x-talk

Wrong Input / Output line


Device(s)

OUTPUT

Stuck on / off / Conversion fault

Parity generator fault

Upscale / Downscale

Frame fault / buffer overrun

Drift / Calibration

Stuck Direct Memory Access (DMA)

Unstable output

x-talk (DMA)

Isolation fault

Loss of Input/Output communication

Linearization/ Compensation

65

B.6 Architecture B.6.1 Selection of the SIS architecture is an activity performed during the conceptual design step of the Safety Life Cycle. The architecture has a major impact on the overall safety integrity of the SIS. The architecture also influences SIS reliability (likelihood of spurious trips) (Reference C.3). B.6.2 Some of the activities involved in determining the SIS architecture are a) selection of energize to trip or de-energize to trip design; b) selection of identical or diverse redundancy for the SIS sensors, logic solver, and final control elements; c) selection of redundancy for power sources and SIS power supplies; d) selection of operator interface components (e.g., CRT, alarm annunciator, pushbuttons) and their method of interconnection to the SIS; and e) selection of data communications interfaces between SIS and other subsystems (e.g., BPCS) and their method of communication (e.g., read only or read/write). B.6.3 A SIS may utilize architectures (e.g., 2oo3 sensor, 1oo1 logic solver, 1oo2 final element) for reasons that may include different a) SILs in the same SIS; b) testing requirements; c) equipment reliability and failure modes; and d) user interfaces. B.6.4 Architecture that may typically meet the SIL performance requirements includes: SIL 1 -

A 1oo1 architecture with a single sensor, single logic solver, and a single final control element.

SIL 2 -

Requires more diagnostics and typically includes redundancy of the logic solver and sensors, with redundancy of final control elements as necessary.

SIL 3 -

Typically two separate and diverse 1oo1 arrangements, each with their own sensor, logic solver, and final control element. The 1oo1 arrangements would be connected in a 1oo2 voting scheme. Diverse separation, redundancy, and exhaustive diagnostic capabilities are considered significant aspects of a SIL 3 system.

The user must determine the failure rates of the system components, diagnostic coverage, test intervals, redundancy, etc., and evaluate each specific SIS to validate its performance (see ISA-dTR84.02 for additional guidance).

B.7 Power sources Power sources include, but are not limited to, electrical power, pneumatic power (e.g., instrument air), and hydraulic power. Grounding is included in this subclause after electrical power.



B.7.1 Electrical power source B.7.1.1 The electrical power source should be designed to meet the safety integrity and reliability requirements of the application. B.7.1.2 Electrical power source redundancy is frequently provided to improve the reliability of the SIS, although redundancy may not be necessary to meet the safety integrity requirements for deenergized to trip applications. For energize to trip applications, electrical power source redundancy is typically provided to meet the safety integrity requirements. B.7.1.3 Electrical power source redundancy can be provided using an alternate source with automatic transfer, an Uninterruptible Power Supply (UPS), or battery backup by an alternate source. Design considerations when transferring to alternate sources include a) detection of fault prior to impacting SIS operation; b) transfer to back-up source without impacting SIS operation; c) ability to maintain UPS or batteries without impacting SIS operation; and d) minimize common cause failures. B.7.1.4 Consider providing power source(s) diagnostics that will not allow SIS startup unless all power sources are available. B.7.1.5 Electronic and programmable electronic SIS frequently include internal power supplies that convert electrical power source(s) to lower level voltages for internal use. Power supply redundancy should be considered to meet the reliability requirements of the application. B.7.1.6 Electronic and programmable electronic SIS typically are more sensitive to electrical noise (e.g., radio frequency interference or electromagnetic interference) Utilize shielding, good wiring practices (see B.13), and proper grounding (see B.7.2). B.7.1.7 Electronic and programmable electronic SIS typically have a lower insulation breakover voltage rating than an electrical SIS. Therefore, additional surge protection may be required. B.7.1.8 Programmable electronic SIS may require electrical power with lower total harmonic distortion than electrical or electronic SIS. B.7.1.9 Input/Output (I/O) may have separate power distribution, fused to minimize common cause in case of a wiring fault. These fuses should coordinate with upstream fuses to insure minimum impact on system performance if a fuse blows. B.7.1.10 A checklist of AC electrical power considerations includes a) voltage and current range including inrush current; b) frequency range; c) harmonics; d) non-linear loads; e) ac transfer time; f) overload and short circuit protection and coordination; g) lightning protection;


67

h) protection against transients such as spikes, surges, brown outs, and electrical noise; i) protection against undervoltages; j) protection against overvoltages; and k) grounding. B.7.1.11 A checklist of DC electrical power considerations includes a) voltage range and current range including inrush current; and b) non-linear loads. B.7.2 Grounding B.7.2.1 Grounding is critical in E/E/PE technology to ensure personnel safety (Reference C.5) and proper equipment performance. This subclause deals only with the voltages found in SIS applications (typically 240 volt AC or below, and 125 volts DC and below). B.7.2.2 Note that the grounding becomes more restrictive when moving from electrical to electronic and from electronic to programmable electronic. Therefore, electrical equipment grounding can be easily achieved in a grounding system designed for electronic and/or Programmable Electronic equipment, and electronic equipment grounding can be easily achieved in a grounding system designed for programmable electronic equipment. Programmable Electronic equipment installed in a grounding system designed for electrical technology may not be appropriate. B.7.2.3 For ungrounded systems, consider using ground fault detection relays and alarms as appropriate. B.7.2.4 Note that electrical or electronic technologies may integrate Programmable Electronic into their equipment to enhance performance through improved communication, diagnostics, humanmachine interfaces, etc. In those cases, treat the grounding as if it is Programmable Electronic grounding, unless vendor installation guidelines dictate a different approach. B.7.2.5 The grounding system should meet the manufacturer’s recommendations. Deviations should have safety review and analysis. B.7.2.6 A checklist of grounding considerations includes a) corrosion protection; b) cathodic protection; c) lightning cone of protection; d) ground planes (Reference C.16); e) raised floor grounding; f) static electricity protection; g) shield ground; h) single point ground; i) test ground; j) intrinsic safety barrier grounds; and k) ground terminal(s) availability.



B.7.3 Pneumatic power B.7.3.1 Instrument air (or other gas) is typically used with final elements such as control valves. The solenoid valve acts as an electrical to instrument gas relay. The instrument gas should be filtered, dried, and continuously monitored to assure proper pressure is maintained, and the system should be backed up to attain the uptime required to meet the reliability. B.7.3.2 Instrument air checklist: a) Pressure b) Moisture c) Contaminants d) Lubrication where required e) Volume B.7.4 Hydraulic power B.7.4.1 Hydraulic power is typically used where high motive force is required, such as very large valves. B.7.4.2 Hydraulic power checklist: a) Pressure b) Volume c) Contaminants d) Fluid properties

B.8 Common cause failures B.8.1 Common cause faults can be caused by a single (non-redundant) component or by systematic errors in redundant components. B.8.2 Some examples of common cause faults include a) specification errors; b) hardware design errors; c) software design errors; d) human-machine interface design; e) environmental over-stress (HI/LO temperature - humidity - pressure, corrosion); f) single elements (common process taps, Reference C.1, Figure 5.11, common conduit single energy sources, single field devices, etc.); g) process corrosion or fouling; h) vibration; i) maintenance (e.g., tools, procedures, calibration, training); and j) susceptibility to mis-operation (e.g., training, procedures, activity under abnormal stress).


69

B.8.3 Common cause faults or systematic errors may be reduced during design using appropriate fault avoidance measures. Consider using the following methods: a) Provide supplier with application-specific information (e.g., codes, model number(s), etc.) b) Verification c) Diverse separation d) Diverse redundancy e) Identical redundancy f) Identical separation B.8.4 A number of functionally separate SIS may share the same environment, cabinet, operator interface, and maintenance/engineering interface. These separate systems may however require physical separation of power and logic solver to accomplish testing maintenance or modification. The impact of these activities should be considered during system layout.

B.9 Diagnostics B.9.1 General considerations B.9.1.1 Diagnostics are tests performed periodically and automatically to detect covert faults that prevent the SIS from responding to a demand (see ISA-dTR84.02 for further guidance). B.9.1.2 Various types of faults that can occur are included in Table B.9.1:

Table B.9.1 — Fault types Fault Type

Example

Faults that immediately disable the capability of the SIS to respond to a demand (critical faults)

Stuck-on or stuck off of a critical output point

Faults that in combination with other faults disable the capability of the SIS to respond to a demand (potential critical faults)

Diagnostic of a critical output point not performed

Faults initiating a safe response of the SIS without a demand

Spurious trip due to a component fault

Faults that have no impact on the capability of the SIS to respond to a demand (benign faults)

Burned out, not critical LED

B.9.1.3 A covert fault in a system may prevent the SIS from responding to a demand. This can be the first fault in a single channel system or a combination of faults in a multi-channel system. Therefore it is important to not only discover critical faults but also potentially critical faults before they accumulate.



B.9.1.4 Faults can result in two types of failures: a) Random failures, a spontaneous failure of a component b) Systematic failures (or errors), a hidden fault in design or implementation B.9.1.5 Hardware is prone to random failures, but can also have systematic failures (incorrect timing, components used outside their specified range, etc.). B.9.1.6 Software is generally free of random failures, but has a high probability of systematic failures. Once a systematic failure becomes overt, it can be corrected and will cease to exist. B.9.1.7 Random failures occur spontaneously. Depending on the persistence of the fault over time two conditions are possible: a) Permanent random faults persist until they are repaired. b) Dynamic random faults (cross-talk, thermal faults, etc.) occur under certain circumstances and disappear. B.9.2 Diagnostic tests B.9.2.1 Diagnostics may be accomplished using a variety or combination of methods, including: a) hardware integrity monitoring (e.g., impedance monitoring in thermocouples); b) automatic built-in tests provided within the purchased SIS equipment (e.g., Input/Output module self-tests); c) automatic test incorporated as part of the application specific design (e.g., readback of output signals through input points); d) Watchdog Timers, signal comparison, end-of-line detection, etc.; and e) comparing redundant signals. B.9.2.2 An inherently safe response to a fault may replace the requirement for a diagnostic for that fault. However, a so called "safe" design of a component may not always result in a safe response of the SIS, as this is application specific. B.9.3 Diagnostic coverage B.9.3.1 A particular diagnostic technique is usually less than 100% effective in detecting all possible failures. An estimate of the "effectiveness" of the diagnostics used may be provided for the set of failures being addressed. B.9.3.2 Improved diagnostic coverage of the SIS may assist in satisfying the requirements of the target Safety Integrity Level. Specific failure modes that may be covered by diagnostics are listed in Table B.9.2. This or a similar list of failure modes may be needed to identify those areas where diagnostic coverage is required. B.9.3.3 Critical and potentially critical faults (like faults to CPU / RAM / ROM ...) will inhibit almost the entire processing of data and are therefore more far reaching than a fault of a single output point. The coverage requirements for these kind of faults are therefore stricter. Additionally, failure modes that carry a high failure probability have to be detected with more confidence. Further, the detectability of failure modes has to be taken into account - failure modes that are detectable using simple means should be implemented whenever possible.


71

B.9.3.4 For each diagnostic implemented, the following should be identified: a) Testing interval b) Resulting action on fault detection c) Both criteria should meet the Safety Requirement Specifications B.9.3.5 Where certain diagnostics are not "built-in" to the vendor-supplied equipment, appropriate diagnostics may be implemented at the system or application level. B.9.3.6 Diagnostics may not be capable of detecting systematic errors (like software bugs). However, appropriate precautionary measures to detect possible systematic faults may be implemented.

Table B.9.2 — Diagnostic tests for programmable electronics Hardware possible cause Chip error

Data

Software detection

Hardware fault testing

Processing

detection

Wrong constants Indexing

Hard limit checking

Wrong circuit

Event

Event verification

Component out of specification

Scheduling

Scheduler monitor

Algorithm

Assertions Plausibility check Reverse computation diversity

Address Time

possible cause

Voter fault

Random voter test

B.10 Field devices B.10.1 General considerations B.10.1.1 Many common cause failures of field devices may be avoided by properly applied redundancy and/or diversity. One example is an application requiring redundant sensors using different principles of operation and/or different manufacturers. B.10.1.2 Two analog sensors, two discrete sensors (switches), or one of each could be selected. If one analog device and one discrete device are selected to provide diversity, as opposed to two analog devices, the advantage of continuous comparison of signals is lost. Proper operation of the discrete device can only be verified by testing or the occurrence of a process demand. If two analog devices are selected, they can be continuously compared. This comparison significantly reduces Mean Time To Detection of failure thus providing more available protection. B.10.1.3 The following SIS considerations related to field devices may enhance the application of field devices: a) Continuously compare redundant sensors while system operates (e.g., alarm or shut down on unacceptable deviation) 72 COPYRIGHT 2000 Instrument Society of America


b) Compare flow or other related variables to modulating valve position c) At each shutdown, compare sensor readings with known shutdown conditions and each other (e.g., use these comparisons as permissives for the next startup. This reduces Mean Time To Detection of field device failures. This applies also to valve positions monitored by limit switches.) d) If SIS has a built-in feature that displays the last good value on a bad value of the field sensor, this feature should be defeated (For SIS applications the signal should be permitted to go to its extreme value) e) Feedback to alarm when a final element fails to go to its commanded state f) Alarm if field devices change state without a command from the SIS g) Vendors MTBF data h) Predictability of failure modes i) Performance following long periods in the same position j) Avoid using measurements outside the accuracy limit of the sensors (e.g., accuracy/ turndown; for example, where zero flow is to be verified, a flow sensor should not be used) k) Identification (typing, color code, etc.) l) With analytical measurements, try to design the system to provide a comparison between analytical readings and related basic measurements such as pressure, temperature, etc. B.10.2 Field device failure modes and their detection B.10.2.1 Essentially all field devices have three failure states - their extreme states or somewhere in between. Sensors:

upscale, downscale, on scale

Current/voltage alarm trips: current/voltage alarm trips convert current and voltage (e.g., 4 - 20 mA or 0 - 10 V DC) analog inputs into discrete signal outputs. The trip value is field adjustable. These switches have unsafe failure modes; appropriate analysis and design features should be provided to ensure safe operation. Valves:

open, closed, partially open

Relays:

coil inoperative, contacts held in their "normal" positions, contacts welded closed, contacts worn resulting in high resistance/restricted current flow, and stuck armature

B.10.2.2 Given these failure modes, consider selecting components with built in features that drive the device to one of its detectable extremes in a high percentage of its failure modes. B.10.3 Sensor selection criteria B.10.3.1 Some considerations for the selection of sensors include a) analog devices are preferred to discrete types; b) where possible, try to obtain redundancy and/or diversity by measuring different variables where each is indicative of the same abnormal condition;


73

c) carefully review process/ambient conditions that could effect the filling/emptying of impulse lines; d) verify seal liquids in diaphragm seal applications for resistance to amalgamation, freezing, polymerization, all of which can cause false readings; e) devices that are selected to achieve diversity should have sufficient reliability to meet system reliability requirements or alternate approaches to diversity should be considered; and f) carefully weigh the use of devices that are foreign to a plant’s maintenance organization. B.10.3.2 A minimum number of shutoff valves should be employed between the process and a sensor in SIS service. Each sensor requiring a process shutoff should have its own dedicated connection and valve (see Reference C.1, Figure 5.11). B.10.4 Final element application considerations B.10.4.1 Some considerations in the application of valves used as final control elements include a) opening/closing speeds; b) shutoff differential pressure in both directions of flow; c) leakage (degree of shutoff requirements); d) fire resistance — body and actuator; e) performance following long periods in the same position; f) where it will meet the requirements, consider the use of a modulating control valve as one of the final valve elements since the proper operation of the control loop verifies the valve is not stuck in a single position; g) do not compromise reliability to achieve diversity; h) materials suitability/comparability; i) carefully weigh the use of devices that are foreign to a plant's maintenance organization; j) fail position considerations; and k) valve position indication. B.10.4.2 Solenoid valves B.10.4.2.1 Some considerations in the application of solenoid valves include a) consider temperature, voltage, area classification, loading, etc., when selecting solenoid valves; b) effects of air pressure, minimum or maximum, on the valve; c) ensure the solenoid valve is sized properly; d) adjustable flow paths provide an opportunity for defeating an SIS function if improperly adjusted; e) mounting the solenoid between the positioner and the valve;



f) some solenoids are mounting position sensitive — consider installation detail requirements; and g) solenoid vents should have protection against plugging, dirt, insects, freezing, etc. B.10.4.3 Motor starters B.10.4.3.1 In general, redundant motor starters are not used. Redundancy is applied in the form of contacts in the control circuit. Auxiliary contacts may be fed back to the SIS to verify starter status (position). B.10.5 Input signal conditioners and output amplifiers Input/output interface devices are special purpose solid state relays. They have unsafe failure modes that should be identified and quantified. Appropriate design features should be added to handle these unsafe failure modes before they can be approved for use in a SIS. Input/output interfaces are required as the signal conditioners for solid state logic systems or PESs. Input signal conditioners receive sensor signals at the strength required for suitable operation on the factory floor (e.g., 120 V, 48 V, 24 V, 4 - 20 mA). The purpose of the inputs and outputs in a solid state SIS is to isolate the low energy logic system (typically low voltage DC) from the high energy field system (typical signal levels are 120 volt AC and 24 volt DC). Low energy signal levels are utilized in the logic system to achieve signal processing speed. High energy signal levels are used in the field devices to ensure a high signal to noise ratio over long transmission distances and to assure that contacts on discrete sensors used as input devices have sufficient power (voltage and current) to provide appropriate contact-wetting. Output amplifiers receive the low energy signal from the solid state or PES logic solver and convert it to a signal suitable for driving the final element (e.g., solenoid valve).

B.11 User interface User interfaces to a safety-related PES are operator interfaces and maintenance/engineering interfaces. B.11.1 Operator interfaces The operator interface used to communicate information between the operator and the SIS may include a) video displays; b) panels containing lamps, push buttons, indicators, and switches; c) annunciators; d) printers; and e) any combination of these. B.11.1.1 Video displays B.11.1.1.1 Video displays may share safety and process control functions. A BPCS, or other computer-based control system, through its normal operator displays, may provide the sole operator interface to a SIS.


75

B.11.1.1.2 SIS data displayed to the operator should be updated and refreshed at the rate required to communicate between the operator and the SIS during emergency conditions so safe response(s) can be attained. B.11.1.1.3 Displays relating to the SIS should be clearly identified as such, avoiding ambiguity or potential for operator confusion in an emergency situation. Operators should have easy access to safety-related displays, preferably by a single key-stroke or touch-screen stroke giving entry into a display hierarchy. B.11.1.1.4 Give the operator enough information on one display to rapidly convey critical information. Display consistency is important. Provide the same access methods, alarm conventions, and display components as are used in the non-safety-related displays. B.11.1.1.5 Display layout is also important. Too much information on one display may lead to operators misreading data and taking wrong actions. Use colors, flashing indicators, and judicious data spacing to guide the operator to important information and to reduce the possibility of confusion. Messages must be clear, concise, and unambiguous. B.11.1.1.6 The operator interface and associated system (such as a Distributed Control System) may be used to provide automatic safety-related event logging and alarming functions. Conditions to be logged should include SIS events (such as trip and pre-trip occurrences), whenever the SIS is accessed for program changes, and diagnostics. B.11.1.2 Panel(s) B.11.1.2.1 Panels should be located to give operators easy access. B.11.1.2.2 Arrange panel to ensure that the layout of the push buttons, lamps, gauges, and other information is not confusing to the operator. Shutdown switches for different process units or equipment that look the same and are grouped together may result in the wrong equipment being shut down by an operator under stress in an emergency situation. Physically separate the shutdown switches and boldly label their function. Provide means to test all lamps. B.11.1.3 Printer(s) B.11.1.3.1 Printers connected to the SIS should not compromise the safety function if the printer fails, is turned off, is disconnected, runs out of paper, or behaves abnormally. B.11.1.3.2 A SIS connected to a BPCS may use BPCS facilities to perform its safety-related logging and reporting functions. B.11.1.3.3 Printers are useful to document Sequence Of Events (SOE) information, diagnostics, and other safety-related events and alarms, with time and date stamping and identification by tag number. Report formatting utilities should be provided. B.11.1.3.4 If printing is a buffered function (information is stored, then printed on demand or on a timed schedule), then the buffer should be sized so that information is not lost, and under no circumstances should SIS functionality be compromised due to filled buffered memory space. B.11.2 Maintenance/Engineering interface(s) B.11.2.1 Maintenance/Engineering interfaces consist of means to program, test, and maintain the SIS. Interfaces are devices used for functions such as: a) System hardware configuration



b) Application software development, documentation, and downloading to the SIS, logic solver c) Access to application software for changes, testing, and monitoring d) Viewing SIS system resource and diagnostic information e) Changing SIS security levels and access to application software variables B.11.2.2 Maintenance/Engineering Interfaces should have capabilities to display the operating and diagnostic status of all SIS components (such as Input/Output modules, processors, etc.) including the communication among them. B.11.2.3 Maintenance/Engineering Interfaces should provide means for copying application programs to storage media. B.11.2.4 A user-approved personal computer may be used as a Maintenance/Engineering Interface.

B.12 Security B.12.1 General B.12.1.1 Means should be provided to control access to SIS including the logic solver, SIS maintenance interfaces, test and bypass functions, SIS alarms, sensors, and final elements. The access protection may be in the form of locked cabinets, "read only" communication, access codes, passwords, administrative procedures, etc. B.12.1.2 For guidance in the application of these options see Reference C.1, Section 6.1.9. B.12.2 Exceptions Protection against the following are beyond the scope of this annex: a) Malicious modification b) Modification errors B.12.3 Additional PES considerations B.12.3.1 Access control and security may be provided by a combination of application logic and host functions for any SIS user-interface device that could interfere with performance of the safety function: a) Parameters that are appropriate for operator interaction should be accessible. b) Parameters that may be changed on-line with appropriate review should come under access control. c) Parameters or functions that require validation after change should be accessible only off-line. B.12.3.2 The ability to restrict access to the SIS operating mode, program, and data should be an integral feature of the SIS.


77

B.13 Wiring practices B.13.1 Wiring practices should meet the manufacturers’ recommendations and NEC requirements. Deviations should have safety review and analysis. B.13.2 Consider enhancing wiring practices by: a) Eliminating circuit commons for multiple circuits; b) Adding circuits for better isolation; c) Adding fuses to isolate faults in a way that reduces common cause; d) Implementing test facilities; e) Elimination of ground loop problems; and f) Separating SIS terminations from all other terminations. B.13.3 Additional considerations for electronic or programmable electronic SIS include: a) Twisted pair signal wires for EMI protection (Reference C.7); b) Shield and drain wire for RFI protection, usually grounded at the power source end; c) Overall metallic covering (e.g., cable armor) or raceway (e.g., cable tray, duct, conduit) for EMI and lightning protection should be grounded at both ends, and depending on the distance, at intermediate points; d) separation of energy levels to eliminate cross-talk and radiated noise pickup; e) surge protection as appropriate; f) provide isolation (e.g., fiber optic) between different ground planes; g) data communication cable specification and shielding should meet manufacturer’s recommendations; and h) cabinet wiring should be arranged to minimize electrical noise interference and high temperature. B.13.4 Electronic and programmable electronic logic solvers use internal low level logic signals. Use of low level logic outside the shielded controller cabinet may be inappropriate. B.13.5 Electronic and programmable electronic logic solvers may require a more restrictive wiring approach because inductive or capacitive coupling may falsely turn on inputs. B.13.6 Use caution when using solid state inputs or outputs because leakage current may falsely actuate final control elements.



B.14 Documentation B.14.1 A list of the documentation that may be used to implement a SIS, includes the following: a) Safety Requirement Specifications b) Application logic c) Design documentation d) Commissioning Pre-Startup Acceptance Test procedure(s) e) SIS operating procedure(s) f) SIS maintenance procedure(s) g) Functional test procedure(s) h) Management of Change documentation i) Qualitative or quantitative verification that the SIS meets the SIL NOTE — Not all this documentation needs to be maintained. B.14.2 Applications program backup B.14.2.1 A backup technique allows the entire system to be restored to operation as quickly as possible. These techniques may include one or several of the following: a) Copy to a removable medium such as magnetic tape or disk which can be copied back b) Copy to a removable medium which can be used as a disk replacement for a corrupted PES c) Copy to an on-line device (e.g., disk) used to backup d) A communications link with another digital system B.14.2.2 Consider maintaining a separate backup for data that is accumulated by the application software to generate reports, records, and trends.

B.15 Functional test interval See 9.7 for mandates related to functional testing. The following is guidance, which may be used to determine the functional test interval. B.15.1 The frequency of functional tests should be consistent with applicable manufacturer’s recommendations and good engineering practices, and more frequently if determined to be necessary by prior operating experience. B.15.2 The functional test interval should be selected to achieve the Safety Integrity Level (SIL). B.15.3 ISA-dTR84.02 illustrates various methods to determine the functional test interval.


79


Annex C (Informative) — Informative references

NOTES 1.

Utilize latest edition of the reference.

2.

In case of conflicting information, ISA-S84.01 takes precedence.

3.

Within the body of the text and the Index, references are cited by the reference numbers (in italics and brackets) given below.

AMERICAN INSTITUTE OF CHEMICAL ENGINEERS (AIChE) [Ref. C.13]

Guidelines for Chemical Process Quantitative Risk Analysis , New York, 1989

[Ref. C.14]

Guidelines for Hazard Evaluation Procedures , New York, 1985

[Ref. C.1]

Guidelines for Safe Automation of Chemical Processes , New York, 1993

Available from:

AIChE 345 East 47th Street New York, NY 10017

Tel: (212) 705-7657

CHEMETICS INTERNATIONAL COMPANY [Ref. C.15]

Knowlton, R. Ellis, An Introduction to Hazard and Operability Studies , 1988

Available from:

Chemetics International Company Chemical Technology Division 1818 Corwall Avenue Vancouver BC V6J 1C7 Canada

Tel: (604) 734-1200

CHEMICAL INDUSTRIES ASSOCIATION [Ref. C.15]

A Guide to Hazard and Operability Studies , London, 1977

Available from:


Chemical Industries Association King’s Buildings Smith Square London SW1P 2JJ England

Tel: 44 71 8343399

81

INTERNATIONAL ELECTROTECHNICAL COMMISSION (IEC) [Ref. C.8 & C.9]

Parts 1-7 IEC draft Publication 1508-1995, Functional safety of electrical/electronic/programmable electronic safety-related systems

NOTE — IEC draft Publication 1508 is in development; for more information, contact your national committee. Available from:

IEC P.O. Box 131 3, rue de Varembe 1211 Geneva 20 Switzerland

Tel: 41 22 734 0150

INSTITUTE OF ELECTRICAL AND ELECTRONICS ENGINEERS (IEEE) [Ref. C.7]

IEEE 518-1982, RA-1990

Available from:

Guide for the Installation of Electrical Equipment to Minimize Electrical Noise Inputs to Controllers from External Sources

IEEE P.O. Box 1331 445 Hoes Lane Piscataway, NJ 08855-1331

Tel: (800) 678-4333

ISA [Ref. C.2]

ISA-dTR84.02-1996

Electrical (E) / Electronics (E) / Programmable Electronic Systems (PES) for Use in Safety Applications - Safety Integrity Evaluation Techniques

NOTE — dTR84.02 is in development; for information, contact ISA. [Ref. C.6]

ISA-S91.01-1995

[Ref. C.3]

Goble, W.M., Evaluating Control System Reliability Techniques and Applications , 1992

Available from:


Identification of Emergency Shutdown Systems and Controls That are Critical to Maintaining Safety in Process Industries

ISA P.O. Box 12277 67 Alexander Drive Research Triangle Park, NC 27709

Tel: (919) 990-9200


MCGRAW-HILL, INC. [Ref. C.16]

Dictionary of Scientific and Technical Terms , fifth edition, 1993

Available from:

McGraw-Hill, Inc. 1221 Avenue of the Americas New York, NY 10020

Tel: (800) 262-4729

NATIONAL FIRE PROTECTION ASSOCIATION (NFPA) [Ref. C.5]

NFPA 70-1993

Available from:

National Electrical Code NFPA P.O. Box 9101 One Batterymarch Park Quincy, MA 02269-9101

Tel: (617) 770-3000

UNDERWRITERS LABORATORIES, INC. (UL) [Ref. C.4]

UL Standard 508-1989 (15th Edition)

Available from:

Standard for Safety, Industrial Control Equipment

UL 333 Pfingsten Road Northbrook, IL 60062

Tel: (708) 272-8800

UK ATOMIC ENERGY AUTHORITY (AEA TECHNOLOGY) [Ref. C.10]

Risk Control and Instrument Protective Systems in the Process Industries , Warrington, UK, 1980

Available from:


UK Atomic Energy Authority Safety and Reliability Directorate Wigshaw Lane Culcheth Warrington WA3 4NE England

Tel: 44 71 925 254486

83

UNITED STATES CODE OF FEDERAL REGULATIONS (CFR) [Ref. C.11]

29 CFR 1910.119-1992 (Final Rule: February 24, 1992)

Process Safety Management of Highly Hazardous Chemicals, Explosives, and Blasting Agents

[Ref. C.12]

40 CFR Part 68 (Proposed rules: October 23, 1993)

Risk Management Programs for Chemical Accidental Release Prevention

Available from:


U. S. Government Printing Office Superintendent of Documents Washington, DC 20402

Tel: (202) 512-1800


Annex D (Informative) — Example

NOTE — THIS CLAUSE IS NOT A REQUIREMENT OF THIS STANDARD. IT IS PROVIDED FOR INFORMATION ONLY.

D.1 Introduction to the example problem This example problem is provided as an aid to illustrate how a user company might apply this standard to design a Safety Instrumented Systems (SIS). The example problem is maintaining a level in a process surge tank in the KIS2 Corporation. The results of the KIS2 Process Hazards Analysis (PHA) that was conducted on this vessel is an input to this example problem. The information provided in Annex D is intended to illustrate the thought process in designing a SIS and the relationship of each step to this standard. References to the standard and the appropriate annexes are provided in parentheses ( ), and in addition, exact extractions from the normative portion of this standard are shown in italics. It is necessary to read the complete annex to understand how all design issues are addressed. Because of the amount of detail that is required to achieve a high-integrity safety design, this example includes a number of simplifications. The specific design choices made in this example do not reflect practices associated with any particular company and are not intended to be the only possible choices. This example does provide guidance to users on how to implement this standard. It is expected that each company will have guidelines that address the methodology that should be used in arriving at their own particular solution. The final design, by whatever methodology used, should meet the specified Safety Integrity Level (SIL). The figures and guidance provided in Annex D are an overview of what is needed and do not provide the detail necessary to specify, design, install, and maintain a SIS.

D.2 Safety Life Cycle (Figure 4.1) This example reviews the development of the Safety Requirement Specifications (Clause 5), addresses the issues in SIS Conceptual Design (Clause 6), and briefly touches on Detail Design (Clause 7). Subsequent functions (Commissioning, Pre-Startup Acceptance Test, Maintenance, etc.) are not addressed except as they pertain to the design of the SIS.

D.3 Safety requirement specification D.3.1 Input requirements (5.2) The information required from the Process Hazards Analysis (PHA) or process design team used to develop the Safety Requirement Specifications, includes the following.


85

D.3.1.1 Process information description (5.2.1) Process information description (dynamics, sensors, final elements, etc.) of each potential hazardous event that requires a SIS (Reference C.6). The process as shown in Figure D.1 contains hot wash water with varying amounts of flammable organics and other hazardous chemicals.

Figure D.1 — Basic process control scheme

The level inside the process surge tank must be maintained. The level is sensed and transmitted by a level transmitter (LT-1) to a controller (LC-1) which in turn regulates the position of a control valve (LV-1) by transmitting a 4 - 20 mA signal to a current-to-air transducer (I/P-1). The tank (1-101) is provided with a relief valve to prevent over-pressure due to overfilling or fire. The relief valve discharges directly to the atmosphere. If the relief valve discharges, the resulting spray could cause serious personnel injury due to the hazardous chemicals inside the tank. In addition, since the fluid is also flammable, the potential for a fire or explosion exists, which could also result in serious injury to personnel. The PHA team has identified two possible causes of an overfill event in the tank: a) LV-1 fails in an open position due to foreign material in the pipeline. b) LT-1 fails indicating a low level which causes the level controller to open LV-1. Although the instruments in service (LT-1, LC-1, and LV-1) have been reliable in the past, the PHA team believes that due to the number of safety issues involved, additional safeguards should be added to reduce this risk.



One possibility would be to eliminate the relief valve. However, this option is barred by the ASME Code and could lead to a catastrophic failure of the tank in the event of over-pressure due to an external fire. Another option is to install a catch tank on the line from the relief valve. An alarm could be provided to indicate the presence of a liquid in the tank, which would in turn indicate that Tank 1-101 has overflowed. In this particular case, the PHA team is very concerned about contamination in the catch tank, pluggage of the overflow line, and also believes that the catch tank could overflow. This option was rejected. Since an intrinsic safety fix is not easy and/or may create additional safety problems, a SIS will be installed. D.3.1.2 Safety Integrity Level of each safety function (5.2.2) The PHA team agreed that the SIS for this application shall be designed and maintained to provide SIL 2 performance. D.3.1.3 Process common cause failure consideration (5.2.3) The design team should be aware of the following process common cause failure possibilities: a) There is a potential for chemical buildup on the level sensor. Consideration should be given to selecting the best sensor that guards against this failure and installing it so that the buildup does not take place or is reduced to a maintainable level. b) Valves should also be selected that guard against this same concern (chemical buildup). Therefore, full port-line size ball valves should be considered. D.3.1.4 Regulatory requirements (5.2.4) Because of the significant quantity of hazardous chemicals used in this process, the SIS shall be required to adhere to OSHA 29 CFR 1910 (Reference C.11). D.3.2 Safety functional requirements (5.3) D.3.2.1 The process safe state is to shut off all raw material feeds into Tank 1-101. D.3.2.2 Process inputs to the SIS and their trip points (5.3.2) All feeds to the tank are to shut off when the level reaches ninety percent. D.3.2.3 Normal operation range (5.3.3) The normal operation is twenty to eighty percent of tank level. D.3.2.4 Process outputs from the SIS and their action (5.3.4) Redundant (1oo2) shutoff valves are required, one of which is shared with the BPCS (LV-1). Both valves are to fail closed. D.3.2.5 Functional relationships between process inputs and outputs, including logic, math functions, and any required permissives (5.3.5) For complex control system functional relationships, logic diagrams are provided and in some cases may have to be supplemented with text to properly communicate the functional requirements. In this example, the logic is so simple a P&ID with narrative is sufficient. D.3.2.6 Selection of de-energized to trip or energized to trip (5.3.6) This SIS shall be de-energized to trip.


87

D.3.2.7 Considerations for manual shutdown (5.3.7) Manual push buttons and a panel mounted alarm will be provided so that the operators can shutdown the flow in the event that the SIS fails or the operator observes some other unusual condition. D.3.2.8 Action to be taken on loss of energy source to the SIS (5.3.8) Loss of electricity or air supply will result in closure of block valves. D.3.2.9 Response time requirements for the SIS to bring the process to a safe state (5.3.9) Since the tank fills slowly, response time for this SIS to function upon detection of high level is adequate. D.3.2.10 Response action to any overt fault (5.3.10) If the operator becomes aware of any failure in the SIS, the operator shall immediately shut off all feeds into the tank by pressing the emergency shutdown switch. D.3.2.11 Human-machine interface requirements (5.3.11) a) Pre-high alarm from BPCS b) Manual shutdown capability c) SIS tripped alarm d) SIS diagnostics alarm(s) (see D.4.2) D.3.2.12 Reset function (5.3.12) In the event that the SIS tripped, it is necessary for the operator to push a reset button to restart the feed into the tank.

D.4 Safety integrity requirements (5.4) D.4.1 Required SIL (5.4.1) SIL 2 is required. D.4.2 Diagnostic requirements (5.4.2) Limit switches on the shutoff valve will be used to compare the position of the valve with the signal from the logic solver. If they don’t agree, the operator will be notified (by an alarm and/or printer) that there is an equipment failure. D.4.3 Maintenance and testing (5.4.3) This SIS shall be inspected and tested once per year. In addition, if any problems are detected with the SIS, correction will be started immediately and work will continue round-the-clock until repair is complete. D.4.4 Spurious trips (5.4.4) Spurious trips will not cause any safety-related problems.



D.5 Conceptual design (6.0) D.5.1 Objective (6.1) The following requirements define the conceptual design requirements for this SIS. D.5.1.1 Considerations (6.2.3) a) Separation The SIS shall be separate from the BPCS except for a shared valve. b) Redundancy Require redundant shutoff valves. c) Software design considerations The application program shall utilize function block-type software. d) Technology selection This SIS could be performed using any approved technology. PES is selected to allow this example to be more useful to the reader. e) Failure rates and failure modes The failure rates and failure modes for the SIS equipment used in this design has been developed from the data compiled within the KIS2 Corporation. f) Architecture requirements Using internal KIS2 Corporation guidelines, the architectural requirements for a SIL 2 is as follows: Sensor

Logic Solvers

Valves

1oo1

1oo1

1oo2

g) Power sources The electrical and pneumatic system power sources required for this batch process shall be provided using good engineering practices. This shall include 1) dedicated power source from a separately derived system (Reference C.5, Sections 250-5 and 250-26); 2) power sources capable of being individually maintained; 3) power sources with no common mode failure mechanisms due to failure of non-related power sources (except the main power source header); and 4) grounding using good engineering practices. An Uninterruptible Power Supply is not required because of the high system reliability experienced with the plant electrical power system.


89

h) Common cause Sensors and valves selected to reduce chemical buildup problems. i) Diagnostics Limit switches on the shutoff valve will be used to compare the position of the valve with the signal from the logic solver. If they don’t agree, the operator will be notified (by an alarm and/or printer) that there is an equipment failure. j) Field devices Smart transmitters shall be utilized for all process measurements. k) User interface User interface shall be panel-mounted alarm panel, manual reset switch, and manual shutdown switch. l) Security The KIS2 facility is secure. The SIS logic solver shall be located in the equipment control room. The SIS sensors and final control elements are red tagged (in addition to standard identification) to note their safety functional status to plant personnel. All smart transmitter communication to the SIS logic solver shall be write protected to prevent changing the transmitter settings while on-line. Any communication link between the SIS and the BPCS shall be write protected to prevent inadvertent program changes to the SIS from the BPCS. m) Wiring practices The wiring shall be in accordance with the National Electrical Code (Reference C.5), local codes and regulations, and SIS equipment supplier guidelines. Two separate raceway systems, one for electrical power (e.g., 120/240V) and one for instrument signal (e.g., 4 - 20 mA) shall be provided. SIS wiring can use the same terminal box as BPCS wiring, but clearly identified separate terminals shall be provided for all SIS wiring. n) Documentation Compliance with OSHA 29 CFR 1910 documentation requirement is mandatory. o) Function test interval The SIS shall be tested once a year.

D.6 Detail design (7.0) D.6.1 Objective (7.1) The following is an overview of how the information developed in the Safety Requirement Specifications and the SIS Conceptual Design is used to develop the SIS Detail Design.



D.6.2 General requirements (7.2) KIS2 Corporation has developed corporate guidelines for the detail design of SISs. The architecture is selected using KIS2 corporate guidelines and the information developed. The conceptual design is shown in Figure 2. Using the Safety Requirement Specifications, the SIS Conceptual Design requirement, and internal KIS2 corporate guideline, the SIS can now be designed. Using these documents, the final design is reflected in Figure D.2.

Figure D.2 — Tentative design solution


91


Annex E (Informative) — Index

1 1oo1 28, 66, 89 1oo2 22, 28, 58, 66, 87, 89

2 2oo3 22, 28, 58, 63, 66

A abnormal stress 69 AC transfer time 67 access 33, 35, 65, 76, 77 access method(s) 76 accuracy 37, 73 Accuracy of calibration 37 achitecture(s) 66 actuator 74 adequacy of current risk controls 53 adhere 38, 42, 59, 87 administrative controls 39 administrative procedure(s) 20, 77 aeronautical 4 air 19, 66, 69, 74, 86, 88 air conditioning 34 air filtration 34 alarm convention(s) 76 alarm systems 17 alarm(s) 32, 33, 35, 40, 48, 53, 66, 68, 72, 73, 76, 87, 88, 90 algorithm(s) 72 alternate 32, 59, 67, 74 ambient 74 ambiguity 76 American National Standards Institute (ANSI) 44 amplifier(s) 75 amplitude 63 analog 57, 62, 63, 66, 72, 73 analog devices 72, 73 analytical measurement(s) 73 annunciator(s) 66, 75 anti-surge control 18 application program(s) 18, 19, 22, 59, 79, 89 application software 18, 22, 30, 33, 35, 42, 59, 60, 77, 79 application specific 70, 71 appropriate technology 25 arc suppression 61 architecture(s) 18, 19, 26, 28, 29, 58, 63, 66, 89, 91 armature 64, 73 as-found 41 as-left 41 assessment 46 authorization requirements 42


93

automated 15, 20 automatic 30, 32, 71, 76 automatic reset 30 automatic transfer 67 automatically restart 31 auxiliary contact(s) 75 availability 18, 42, 48, 68 avionics 43

B backed up 69 backup 64, 67, 79 barrier 64 basic events 53 Basic Process Control System(s) (BPCS) 16, 18, 20, 22, 30, 31, 36, 46 batch # 30 battery(ies) 39, 67 benign faults(s) 70 boundaries 15 brown outs 68 buffer 65, 76 buffered 76 bug 35 bug-reporting 60 built-in test(s) 71 bypass 56 bypassed 32, 39 bypassing 18, 35, 39

C C.1 30, 38, 47, 51, 54, 59, 69, 74, 77, 81, 87 C.2 48, 82 C.3 66, 82 C.4 61, 83 C.5 30, 68, 83, 89, 90 C.6 15, 82, 86 C.7 78, 82 C.8 13, 82 C.9 13, 82 C.10 83 C.11 41, 45, 46, 84 C.12 19, 84 C.13 54, 81 C.14 48, 81 C.15 48, 81 C.16 68, 83 cabinet wiring 78 cabinet(s) 70, 77, 78 calculation 22, 63 calibration 33, 39, 64, 65, 69 capacitive 78 cathodic protection 68 caution 63, 78 Central Processing Unit (CPU) 62 certified 60 certify 40 channel(s) 22, 58, 64, 70 checklist 67, 68, 69 chronic health effects 17 circuit common(s) 78



closed 61, 64, 73, 87 coating 27 code(s) 16, 17, 30, 70, 77, 87, 90 coil 61, 64, 73 coking 31 color code 73 color(s) 76 commands 60 commissioning 13, 26, 36, 37, 45, 79, 85 common cause 18, 28, 67, 78, 90 common cause failure(s) 18, 27, 29, 55, 67, 72, 87 common cause fault(s) 18, 19, 28, 58, 69, 70 common components 57 common elements 28 common logic 28 common mode 64 common mode failure mechanisms 89 common mode failures 61 communication(s) 18, 30, 32, 33, 56, 57, 58, 59, 63, 64, 65, 66, 68, 77, 78, 79, 90 company guidance 51 competence of persons 45 complex 47, 54, 62, 63, 87 Complimentary Metal Oxide Semiconductor (CMOS) 62 compressor 18 computational 40, 63 conceptual design 29, 66, 89, 91 conceptual process design 23, 25, 45 conditioner(s) 75 cone of protection 68 configuration 19, 33, 57, 76 conformance 20, 36 confusion 76 consequence analysis 48 consequence(s) 19, 25, 48, 49, 51, 52, 53 consequences only method 47, 51 conservative 47, 52 contact 61, 64, 73, 75 contact-wetting 61, 75 contaminants 34, 69 continuous 63, 72 continuous mode 43 control and safety functions 55, 57 control valve(s) 32, 69, 86 coordination 67 coriolis flow 58 corrosion 27, 31, 58, 64, 68, 69 cost 52 coverage 18, 71 covert 35 covert failure mode 30 covert failure(s) 30 covert fault(s) 18, 30, 39, 63, 70 covert mode 63 criteria 47, 48, 59, 61, 72, 73 Critical 71 critical 32, 61, 62, 68, 70 critical faults 70, 71 critical information 76 cross-talk 71, 78 CRT 32 current 31, 38, 53, 64, 67, 68, 73, 75, 78, 86 customers 35


95

D decommissioning 18, 21, 23, 26, 43, 46 dedicated power source 33, 89 dedicated wiring 31 de-energize(d) to trip 19, 27, 66, 67, 87 de-energized 19, 61 defects 39 definitions 3, 18 degradation 32 demand 19, 20, 39, 43, 56, 70, 72, 76 demand mode 43 demand rate 41 design considerations 29, 55, 67 designer 58 detail design 36, 85, 90, 91 detectability 71 detectable 19, 71, 73 detected faults 39 detection 19, 35, 67, 72, 73, 88 diagnostic coverage 18, 19, 60, 66, 71 diagnostic fault detection 25, 48 diagnostic testing 59 diagnostic(s) 28, 29, 32, 33, 40, 63, 66, 67, 68, 70, 71, 72, 76, 77, 88, 90 diagram 15 differences 4, 13, 34, 43 digital 19, 79 digital timer 62 direct-wired 60 direct-wiring 62, 63 dirt 75 disabling 33 discrete 21, 57, 72, 73 discrete input/output 31 discrete sensor(s) 31, 60, 72, 75 disk(s) 79 display(s) 37, 53, 73, 75, 76, 77 distributed control system 63, 76 diverse 19, 21, 25, 29, 66 diverse redundancy 21, 58, 59, 66, 70 diverse separation 21, 55, 56, 57, 66, 70 diversity 72, 73, 74 document control procedure 42 document(s) 13, 25, 26, 27, 30, 36, 41, 42, 76, 91 documentation 13, 22, 29, 33, 37, 38, 40, 42, 45, 46, 53, 57, 77, 78, 79, 90 downscale 64, 65, 73 drain wire 78 dropout 61 dTR84.02 3, 13, 48, 63, 66, 70, 79, 82 duty cycles 62 dynamic random fault(s) 71 dynamics 27, 86

E electrical area classification 34 electrical fault 22 electrical noise 67, 78 electrical technology 60, 68 Electrical/Electronic/Programmable Electronic System (E/E/PES) 15 Electro Magnetic Interference (EMI) 34, 67 electromechanical 19



electromechanical devices 61 electromechanical relay 19 electromechanical relay(s) 15, 61, 62, 64 electronic technology 62 electrostatic discharge 34 embedded software 19, 22, 35, 59 emergency 26, 76, 88 Emergency Shutdown System 21 end-of-line detection 71 energize(d) to trip 19, 27, 31, 66, 67, 87 equipment reliability 53, 66 equipment under control 18, 21, 46 event logging 76 explosive 53 external risk reduction 45, 46

F factory floor 75 fail position 74 fail-safe 19, 61, 62 failure mode(s) 29, 61, 63, 64, 65, 66, 71, 73, 89 failure rate(s) 29, 41, 53, 56, 63, 66, 89 failure state(s) 73 failure to function on demand 35 false 53, 63, 74 false shut down 22 falsely 78 fault avoidance 70 fault detection 72 fault source 58 fault tolerance 19, 58, 63 fault tree analysis 47, 53 fault tree logic diagram 53, 54 fault tree(s) 53, 54 fault type(s) 70 feedback 73 fiber optic(s) 33, 78 field control element(s) [See field device(s).] field device(s) 19, 21, 29, 31, 36, 69, 72, 73, 75, 90 field element(s) [See field device(s).] field sensor(s) 55, 73 field wiring 19 fieldbus 17, 31 fire and gas detection systems 31 fire and gas monitoring systems 17 fire resistance 74 firmware 19, 22, 41, 58, 59 fixes 59 flooding 34 flow 49, 53, 73, 74, 88 fluid 69, 86 forcing 19, 35 foreign 74, 86 formal revision and release control program(s) 30, 34, 35 formatting utilities 76 fouling 69 freezing 31, 74, 75 frequency 34, 39, 54, 62, 67, 79 frequency of occurrence 30, 53, 54 frequency(s) of testing 39 fuel/air controls 18 functional description 22


97

functional test interval 29, 35, 79 functional test procedure(s) 40, 79 functional test(s) 22, 36, 39, 79 functional testing 19, 26, 35, 39, 40, 79 functional testing procedures 40 fuse(s) 39, 67, 78

G gas turbine(s) 30, 57 geographic diversity 59 good engineering practices 17, 33, 79, 89 governing authorities 16 gravity 61 ground fault detection 68 ground loop(s) 78 ground plane(s) 22, 33, 68, 78 ground(s) 63, 64, 68 grounding 34, 66, 67, 68, 89 guide words 53 guideline(s) 3, 52, 61, 68, 85, 89, 90, 91

H hands on 47 hardware 18, 19, 22, 30, 33, 58, 59, 69, 71, 72, 76 hardware degradation 39 hardware fault(s) 22, 58, 60 hard-wired 19, 57 hard-wired logic 15 harm 51 harmonics 67 hazard and risk analysis 45, 46 hazard(s) 16, 19, 20, 25, 37, 44, 48, 53 hazardous 28, 37, 39, 86, 87 hazardous area classifications 30 hazardous event(s) 19, 25, 27, 48, 51, 53, 86 HAZOP 53 heaters 18 hermetically sealed 61 hidden fault(s) 71 High Noise Immunity Logic (HNIL) 62 high pressure 48, 49, 50, 51, 52, 53, 54 highly recommended 45 historical data 39 horns 32 host 18 host functions 77 human actions 20 human machine interface(s) 17, 28, 69, 88 humidity 34, 69 hybrid 60 hydraulic power 66, 69 hydraulic(s) 16, 60



I identical 21 identical redundancy 21, 29, 66, 70 identical separation 21, 29, 55, 56, 57, 70 IEC 3, 4 IEC draft Publication 1508 3, 4, 13, 43, 44, 45, 46 impedance 71 incident cause 27 indeterminate failure modes 62 indicating lights 32 indicators 33, 75, 76 inductive 61, 78 industry 4 industry sectors 4 industry standards 60 inherently 61 inherently safe 71 inhibit 39, 71 initiating event(s) 51, 52, 54 injury 19, 86 input requirements 85 input/output devices 28, 75 input/output modules 20, 21, 30, 71, 77 inrush current 67, 68 insect(s) 75 inspection(s) 40, 41 installation 13, 26, 36, 37, 46, 63, 68, 75 instrument gas 69 insulation 67 integration 20 interface(s) 15, 20, 30, 32, 33, 66, 68, 75, 76, 77 interlock(s) 30, 56 internal 18, 30, 63, 67, 78, 89, 91 internal communication 18 intrinsic safety barrier 68 ISO 9000 45 isolation 64, 65, 78

K keyboard 60

L label(s) 76 lamp(s) 75, 76 latching 62 laws 16 layers 20, 51, 60 layout 70, 76 leakage 74, 78 legislation 41 level controller 56, 86 level of risk 25 level of safety 46, 48 level sensor 56, 87 life cycle 48, 57


99

lightning 67, 68, 78 limited time window 58 limiting access 57 local factors 51 locking 62 log 46 logged 76 logic diagrams 53, 87 logic function(s) 19, 33, 61 logic solver(s) 15, 16, 20, 21, 30, 31, 39, 49, 56, 57, 58, 66, 70, 77, 78, 88, 89, 90 loop # 41 low energy 61, 75 low pressure 48, 49, 53 lubrication 39, 69

M magnetic tape 79 maintenance 20, 22, 26, 28, 30, 33, 35, 38, 39, 46, 47, 57, 69, 70, 74, 77, 85, 88 maintenance costs 53 maintenance procedures 25, 26, 37, 39, 79 maintenance program 38 maintenance/engineering interface(s) 18, 32, 33, 70, 75, 76, 77 major criteria 52 major severity 52 malicious modification 77 management 16, 45 Management of Change (MOC) 22, 26, 41, 44, 45, 46 Management of Change (MOC) documentation 79 Management of Change (MOC) procedure(s) 26, 43 manual mode 53 manual reset 30, 90 manual shutdown 27, 37, 88, 90 manual trip 40 manufacture 13, 20, 58 manufacturer 20, 30, 35, 59, 68, 72, 78, 79 material(s) 4, 20, 31, 61, 74, 86, 87 math functions 27, 62, 87 mathematical analysis 20 matrix method(s) 47 mature 60 mature technology 61 Mean Time Between Failures (MTBF) 22 Mean Time To Detection (MTTD) 72, 73 Mean Time To Failure (MTTF) 22, 30 Mean Time To Repair (MTTR) 22 measure(s) 3, 17, 33, 45, 57, 58, 70, 72 measurement(s) 58, 62, 73, 90 medium 51, 79 memory 19, 42, 65, 76 metallic covering 78 microcomputer 63 minimum level of independence 45 mitigate 19, 25, 37, 58 mode(s) 33, 43, 63, 77 modification errors 77 modification(s) 22, 25, 26, 31, 36, 41, 42, 46, 62, 70 modified HAZOP method 47, 52 modular design 59 modulating 73, 74 moisture 69 monitoring 17, 71, 77 motor driven timer(s) 15, 19, 62



motor overload(s) 31 motor starter(s) 32, 75 motor(s) 39 mounting 74, 75

N name(s) 40 National Electrical Code (NEC) 30, 78, 90 nested 60 network 33, 36 networking 63 NFPA 70 30 noise 64, 68 non-linear 67, 68 non-safety function 30 non-safety related display(s) 76 non-SIS protection layers 23, 25, 45 normal operating range 27 normal operation 19, 26, 87 normal operation range 87 not recommended 59, 63 Nuclear Industry 16 nuisance trip 22 numerical data 20

O objective(s) 13, 17, 22, 25, 27, 36, 38, 41, 48, 89, 90 off-line 20, 42, 77 on scale 73 on-line 20, 35, 40, 42, 77, 79, 90 on-line testing 35, 40 open 53, 54, 56, 61, 64, 73, 86 operating conditions 60 operating experience 20, 47, 61, 79 operating limits 27 operating procedure(s) 35, 37, 38, 41, 42, 56, 79 operating system(s) 59 operational bypasses 38 operator action 17 operator error 53 operator interface(s) 18, 19, 32, 33, 66, 70, 75, 76 operator response 48, 51, 53 operator(s) 18, 32, 35, 46, 75, 76, 77, 88, 90 organization(s) 13, 45, 74 oscillator 62 OSHA 22, 38, 41, 44, 45, 46, 87, 90 output(s) [See input/output devices and input/output modules.] output trip relay 40 overload 67 over-pressure 48, 49, 53, 86, 87 override(s) 19, 56 overt 63, 71 overt fault(s) 20, 28, 88 overvoltage(s) 68 owner/operator 17 ownership 47 oxidation 61


101

P panel(s) 33, 75, 76, 88, 90 parameter(s) 77 part # 30 partially open 73 password(s) 58, 77 peer review(s) 60 period(s) 21, 42, 63, 73, 74 periodic inspection program 39 periodic test intervals 39 permanent random fault(s) 71 permissives 22, 27, 38, 73, 87 personal computer(s) 63, 77 personnel safety 68 PES logic solver(s) 30, 75 PFD Average Range 25 pharmaceutical(s) 4, 20 physical 19, 70 piping and instrumentation diagram (P&ID) 48 plant 26, 39, 52, 61, 74, 89, 90 plugging 27, 58, 75 pneumatic(s) 16, 60, 66, 69, 89 poll fault 65 polymerization 31, 74 possible cause(s) 72, 86 power 19, 20, 28, 30, 31, 66, 67, 68, 69, 70, 75, 89, 90 power distribution 67 power source(s) 29, 34, 66, 67, 78, 89 power supply (supplies) 15, 58, 67 predictability 73 pressure 31, 48, 49, 53, 58, 64, 69, 73, 74 pressure control valve 53, 54 pressure relief valve 48, 49, 51 pressure sensor 53 Pre-Startup Acceptance Test (PSAT) 13, 20, 23, 26, 36, 37, 45, 79, 85 Pre-Startup Safety Review (PSSR) 23, 26 pre-trip 76 preventive 48 preventive maintenance 20 printer(s) 75, 76, 88, 90 Probability of Failure on Demand (PFD) 20, 21, 23, 25 Process Control System 18 process deviation(s) 53 Process Hazards Analysis (PHA) 16, 17, 21, 23, 27, 31, 32, 85 process hazards review(s) 44, 47, 48 process industry sector 20 process industry(ies) 4, 13, 15, 46 process knowledge 47 process risk 51 Process Safety Design 16 Process Safety Management 16 process safety team 47, 48, 49, 51 process variable(s) 27, 47 program(s) 33, 40, 76, 77, 90 programmable controller 63 Programmable Electronic Failure Mode(s) 65 Programmable Electronic System(s) (PES) 3, 15, 19, 20, 22, 23 Programmable Logic Controller (PLC) 19 programming 28, 33, 57, 59, 60 programming guidelines 60 programming language(s) 60 programming terminal(s) 33 proof testing frequency 60



property damage 52, 53 property protection 17 protect against the consequences 53 protection layer(s) 20, 25, 31, 51 pulse counting 62 pulsed 63 pulsed electronic logic 63 purchase specification 16 purge 62 purpose(s) 17, 18, 21, 30, 51, 75 pushbutton(s) 66

Q qualitative 20, 51, 79 qualitative matrix 51, 52 qualitative risk evaluation SIL determination method 47 quality 59, 60, 63 quality system(s) 45 quantified 61, 62, 75 quantitative 20, 79 quantitative risk assessment 47 quartz 62

R radiated noise 78 raised floor grounding 68 Random Access Memory (RAM) 71 random failure(s) 71 read 31, 85 read only 57, 66, 77 read/write 31, 57, 58, 66 reading(s) 73, 74 read-write access 33 recipe 33, 63 redundancy 21, 25, 48, 58, 63, 66, 67, 72, 73, 75, 89 Redundant 87 redundant 22, 31, 56, 58, 59, 64, 69, 71, 75, 89 redundant sensors 31, 72 references [See Annex C page 81 and C.1 - C.16.] regulation(s) 16, 22, 38, 44, 90 regulatory requirement(s) 27, 87 relay(s) 61, 63, 64, 68, 69, 73 reliability 21, 28, 58, 62, 66, 67, 69, 74, 89 reliability experience 56 relief valve 53, 86, 87 remote I/O 18, 31 repair 39, 88 repeatability 62 replacement in kind 21, 41 reporting 76 reset 21, 30, 38, 65, 88 reset function(s) 28, 37, 88 resistor-capacitor (RC) 62 Resistor-Transistor Logic (RTL) 62 resolution 60, 62 response action 28, 30, 88 response time 42, 88 response time requirements requirements 28, 88


103

response(s) 20, 35, 38, 64, 71 revise 43 revision level 59 rewiring 61 risk assessment 21, 23 risk control(s) 53 risk estimates 21 risk evaluation(s) 52 risk reduction 46, 48, 53 risk related 52 risk(s) 25, 42, 48, 52, 53, 86 ROM 57, 71

S safe process condition(s) 30 safe response(s) 70, 71, 76 safe state(s) 17, 19, 21, 27, 28, 29, 30, 32, 33, 38, 40, 87, 88 safety and health 22, 41 safety availability 18, 20, 21 safety availability range 25 safety critical function(s) 60 safety function(s) 15, 18, 21, 25, 27, 28, 30, 46, 48, 57, 58, 76, 77, 87 safety functional requirements 22, 27, 87 safety functionality 55 Safety Instrumented Systems (SIS) 4, 13, 15, 16, 17, 21, 23, 27, 28, 29, 36, 38, 42, 43, 48, 60, 85 safety integrity 42, 56, 57, 58, 63, 66, 67 Safety Integrity Level (SIL) 13, 21, 23, 25, 28, 29, 45, 46, 48, 79, 85, 87 safety integrity requirements 27, 28, 55, 56, 67 Safety Interlock System 21 safety layer matrix 51 Safety Life Cycle 13, 16, 21, 22, 23, 24, 25, 26, 36, 42, 45, 48, 66 safety logic 61 safety management 45 safety plan 45 safety related display(s) 76 safety related system(s) 45 Safety Requirement Specifications 19, 20, 22, 26, 27, 28, 29, 30, 34, 35, 36, 37, 38, 39, 41, 60, 72, 78, 85, 90, 91 safety review 31, 32, 33 safety review and analysis 56, 57, 58, 68, 78 Safety Shutdown System (SSD) 21 science 47 scope 17, 23, 25, 26, 45, 46, 47, 60, 77 security 28, 29, 33, 35, 77, 90 self revealing 39 self-tests 71 sensor diagnostics 31 separate(s) 13, 66, 67, 70, 76, 79, 89, 90 separated 30, 31 separating 78 separation 21, 55, 57, 70, 78, 89 Sequence Of Events (SOE) 76 sequence(s) of failure(s) 53 sequencing functions 29 serial # 30, 41 setpoint(s) 37, 40, 56 severity 51, 52 severity of (the) consequences 51, 52, 53 shield 68, 78 shielding 67, 78 shock 34 short circuit 67 shutdown 22, 37, 39, 50, 51, 52, 53, 54, 56, 73, 82, 88



shutdown switches 76, 88 shutoff valves 74, 87, 88, 89, 90 signal comparison 71 signal processing speed 75 signal to noise ratio 75 SIL 1 21, 32, 46, 52, 54, 55, 56, 57, 58, 66 SIL 2 21, 46, 51, 53, 54, 56, 57, 58, 66, 87, 88, 89 SIL 3 21, 25, 32, 46, 52, 54, 55, 56, 57, 58, 66 SIL 4 46 SIL determination method(s) 47 SIL performance 66 SIL selection 47, 52 simple 47, 61, 71, 87 simplicity 59 single point 68 SIS alarm(s) 38, 77 SIS applications 52, 61, 62, 63, 68, 73 SIS architecture 28, 66 SIS Conceptual Design(s) 26, 28, 85, 90, 91 SIS failure mode(s) 64 SIS performance 48, 57 smart sensors 31 software 3, 18, 19, 22, 30, 33, 35, 41, 42, 57, 58, 59, 60, 71, 72, 89 software bugs 72 software design 60, 69 software design considerations 29, 89 software error(s) 58 software fault(s) 19, 22, 35 software release(s) 59 software reliability 39 software revision 59 software switch 58 solenoid valve(s) 69, 74, 75 solid state 75, 78 solid state logic 15, 19, 62, 63, 64 solid state logic system(s) 63, 75 solid state relay(s) 15, 19, 62, 75 solid state system(s) 63 solid state timer(s) 62 special purpose(s) 19, 75 speed of response 40 spring(s) 61 spurious trip(s) 22, 28, 58, 66, 70, 88 Standards and Practices (S&P) Board 3, 7 startup 16, 26, 42, 53, 67, 73 static electricity 68 storage media 77 supplier(s) 30, 59, 70, 90 surge(s) 67, 68, 78, 85, 86 suspended solid(s) 31 switch(es) 57, 72, 73, 75, 88, 90 system software 22 systematic error(s) 69, 70, 72 systematic failure(s) 22, 41, 71 systematic fault(s) 55, 72

T tag # 41, 76 tampering 62 target SIL 25, 48, 71 team 27, 47, 48, 52, 53, 54, 60, 85, 86, 87 technology selection 29, 89


105

temperature 31, 34, 58, 64, 69, 73, 74, 78 terminology 43 test and bypass functions 77 test facilities 35, 78 test interval(s) 22, 37, 72, 90 test(s) 33, 35, 37, 40, 41, 60, 63, 66, 68, 70, 71, 72, 76 testing 13, 19, 25, 28, 30, 35, 38, 39, 40, 45, 48, 57, 59, 61, 66, 70, 72, 77, 88 thermal fault(s) 71 thermocouple(s) 71 third party(ies) 59 time(s) 4, 20, 21, 22, 26, 42, 51, 52, 55, 60, 62, 64, 65, 71, 72, 76 timer(s) 15, 61, 62, 64, 65 top event 53, 54 TR84.02 [See ISA-dTR84.02.] track record 61 training 26, 38, 44, 69 transfer time 65 transient(s) 22, 68 transistor(s) 62 transmission 75 trip point(s) 27, 38, 63, 87 trip(s) 19, 22, 38, 40, 56, 73, 76 turndown 73 twisted pair 78

U undervoltage(s) 68 ungrounded 68 Uninterruptible Power Supply (UPS) 67, 89 unreliable 61 unsafe failure mode(s) 56, 61, 62, 63, 73, 75 upscale 64, 65, 73 upset 53 upset cause 53 uptime 69 user approved 17, 22, 31, 41, 61, 62, 63, 77 user interface(s) 15, 29, 30, 66, 75, 77, 90 utility software 22, 30, 35, 59

V validate(s) 66 validation 46, 77 valve(s) 39, 40, 49, 56, 69, 73, 74, 87, 88, 89, 90 variable(s) 33, 58, 73, 77 vendor(s) 22, 31, 39, 68, 72, 73 vent(s) 75 ventilation 34, 39 verification(s) 22, 26, 42, 45, 46, 70, 72, 79 verify 19, 28, 60, 74, 75 vessel rupture 53, 54 vessel(s) 49, 53, 85 vibration 34, 69 video display(s) 75 visible markings 30 voltage(s) 64, 67, 68, 73, 74, 75 volume 69 vortex flow 58 voting 22, 28, 32, 33, 66



W Watchdog Timer(s) (WDT) 23, 59, 63, 71 wiring 36, 64, 67, 78, 90 wiring practice(s) 29, 67, 78, 90 witnessing test(s) 45 Working Group 10 (WG10) 3 write access 57, 58 write protected 31, 90 write protection 57, 58 write(s) 57


107



ANSI-ISA-S84.01

Recommend Documents